快速上手Thanos：高可用的 Prometheus - 網安 - 專業的網絡安全產業、社區、知識平臺

在一個成千上萬的服務和應用程序部署在多個基礎設施中的世界，在高可用性環境中進行監控已成為每個開發過程的重要組成部分。

本文將介紹使用 Thanos 在EKS多集群架構上存儲多個集群的 Prometheus 指標的思考過程和經驗教訓。

介紹

隨著 HiredScore 的產品和客戶群越來越大，我們開始向 Kubernetes 過渡并迅速采用它。Kubernetes 是我們重要的障礙之一，也可能是最大的監控基礎設施。此外，它還允許我們為 HiredScore 的高速增長做好準備。

我們在使用 Prometheus / Grafana 堆棧進行監控方面有一些經驗，了解到我們希望創建一個更好、高可用性和彈性的基礎架構，具有可行且具有成本效益的數據保留。

CNCF 推廣了多種基礎設施，可以解決這些監控痛點，并實現具有高可用性、數據保留和成本效益的監控。

要求

單點可觀察性將聚合來自任何區域的所有集群的所有數據
Prometheus 的高可用性和彈性基礎架構
我們所有應用程序數據的數據保留
經濟高效的解決方案

我們選擇了 Bitnami 的 Kube-Prometheus 解決方案和 Thanos-io 的 Kube-Thanos 解決方案。該解決方案效果很好，并成功滿足了我們的所有需求。

讓我們來認識一下players：

Prometheus — 用于事件監控和警報的免費軟件應用程序。它在使用 HTTP 拉取模型構建的時間序列數據庫中記錄實時指標，具有靈活的查詢和實時警報。
Thanos — 一個基于 Prometheus 組件的開源 CNCF 沙盒項目，用于創建全球規模的高可用性監控系統。它通過幾個簡單的步驟無縫地擴展了 Prometheus。

它是如何工作的？

正如我們在圖中所看到的，每個EKS集群在同一個名稱空間中擁有兩個 Prometheus pods，它們通過抓取集群行為來監視它們。每個 Prometheus pods 在專用PVC中保存最后幾個小時，在規定的保留時間后，數據通過 Thanos sidecar 發送到S3桶。通過這種方式，我們可以在少量本地存儲上節省成本，并將其他所有存儲都集中在一個地方(S3)。

為了顯示來自 k8s 集群的 Grafana 數據，我們創建了一個專用集群，負責使用連接到 thanos-sidecar 容器的 GRPC 直接從每個集群收集所有實時（最近約 2 小時）數據（暴露默認情況下在端口 10901 上）并從 S3 存儲桶（配置存儲）中獲取遠程數據。

讓我們深入了解實現細節：

第一階段是在每個集群中實現 kube-prometheus 和 Thanos sidecar。
第二階段是在“聚合”集群中實現 kube-thanos 。它將負責從集群中收集所有集群的實時數據，并從發送到 S3 存儲桶（ObjectStore）的保留數據中收集數據。

聽起來很棒，那么我們實際上如何做到這一點呢？

第一階段

在這里，我們關注如何在我們要監控的每個集群中部署和配置 Prometheus 以及 Thanos sidecar。在每個集群中創建一個名為 monitoring 的命名空間：

kubectl create ns monitoring

創建一個存儲類以使 Prometheus 能夠持久化日期:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: prometheus-storage-class
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: Immediate

kubectl apply -f prometheus-storage-class.yaml -n monitoring

安裝 kube-prometheus：

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

將要配置的相關值復制到本地文件夾中。需要在值中應用的一些更改：

第1步：使 Prometheus 高可用：設置Prometheus Replica Count— 所需的Prometheus副本數（超過2個）

https://github.com/bitnami/charts/blob/master/bitnami/kube-prometheus/values.yaml
https://github.com/bitnami/charts/blob/46afe376ae87a5af32504bc230a25
d9c7e4522e2/bitnami/kube-prometheus/values.yaml#L760

## @param prometheus.replicaCount Number of Prometheus replicas desired
  ##
  replicaCount: 2

第2步：定義 pod 資源限制 Prometheus 資源-定義它以避免 Prometheus 消耗所有服務資源

resources:
  requests:
    cpu: 512m
    memory: 3072Mi
  limits:
    cpu: 512m
    memory: 4096Mi

第 3 步：啟用 Thanos Sidecar 創建

thanos:
  ## @param prometheus.thanos.create Create a Thanos sidecar container
  ##
  create: true

第4步：將 Thanos sidecar 服務類型從更改 ClusterIP 為 LoadBalancer- 它將創建一個AWS經典負載均衡器端點，該端點將在GRPC端口 ( 10901) 中公開 sidecar，然后我們可以使用此端點通過 route53 將其路由到某個 DNS 名稱 thanos-prometheus-(cluster_name)。在您自己的集群中公開 Thanos 端點 prometheus.thanos.service ：https://github.com/bitnami/charts/blob/46afe376ae87a5af32504bc230a25d9c7e4522e2/bitnami/kube-prometheus/values.yaml#L1034

service:
  type: LoadBalancer
  port: 10901
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"

現在，在創建 CLB 之后，我們需要在 kube-thanos 清單中實現它。我們稍后會在第二階段討論。

第 5 步：禁用壓縮并定義保留——這是通過 Thanos sidecar 上傳數據的一個非常重要的步驟：

https://prometheus.io/docs/prometheus/latest/storage/#operational-aspects

為了使用 Thanos 邊車上傳，這兩個值必須相等--storage.tsdb.min-block-duration，--storage.tsdb.max-block-duration默認情況下，它們設置為2小時。Prometheus 的保留時間建議不低于 min block duration 的3倍，即6小時。可以在此處找到其他說明：

https://thanos.io/tip/components/sidecar.md/

retention: 12h
disableCompaction: true

第 6 步：啟用配置密鑰——通過啟用對象存儲配置，我們可以將數據寫入 S3 或任何其他受支持的 BlockDevice ，以確保我們長期數據的持久性

## @param prometheus.thanos.objectStorageConfig Support mounting a Secret for the objectStorageConfig of the sideCar container.
objectStorageConfig:
  secretName: thanos-objstore-config
  secretKey: thanos.yaml

雖然源文件 thanos-storage-config.yaml 必須采用這種形式：

type: s3
config:
  bucket: thanos-store #S3 bucket name
  endpoint: s3..amazonaws.com #S3 Regional endpoint
  access_key:
  secret_key:

值得一提的是，目前我們只能使用單個 S3 存儲桶（ObjectStore）使用以下命令創建密鑰：

kubectl -n monitoring create secret generic thanos-objstore-config --from-file=thanos.yaml=thanos-storage-config.yam

第 7 步：現在我們可以使用我們的相關自定義來安裝/升級 helm chart

helm install kube-prometheus -f values.yaml bitnami/kube-prometheus -n monitorin

或者

helm upgrade kube-prometheus -f values.yaml bitnami/kube-prometheus -n monitorin

如果你做到了這里，你現在應該已經運行帶有 Thanos sidecar 容器的 Prometheus pod，一方面通過GRPC將抓取的數據發送到清單，另一方面，相同的 sidecar 發送（大約 2 小時后）數據到S3存儲桶（配置存儲）。恭喜！

第二階段

我們專注于如何在主要的可觀察性集群上部署和配置 Thanos 。如前所述，它將負責從我們在第一階段部署的所有集群中收集所有數據。

為此，我們使用 kube-thanos manifests。就目的而言，我們發現，只需實現查詢和存儲部分。

第1步：安裝和自定義kube-thanos。在主可觀察性集群中創建一個名為thanos的命名空間：

kubectl create ns thano

可以選擇克隆 kube-thanos 存儲庫并使用清單文件夾或自己編譯 kube-thanos 清單。最后一個不需要復制整個存儲庫，只需要清單文件。

第2步：在通過第一階段后，我們將負責 thanos-query-deployment.yaml 從第一階段開始與其他集群之間的通信。為此，需要添加以下內容：

kubectl -n thanos create secret generic thanos-objectstorage --from-file=thanos.yaml=thanos-storage-config.yaml- --store=dnssrv+_grpc._tcp.thanos-prometheus-<cluster_name>.<domain_name>:1090

進入args我們在上面公開和定義的 Thanos sidecar GRPC 端點部分（步驟 4）

- args:
    - query
    - --grpc-address=0.0.0.0:10901
    - --http-address=0.0.0.0:9090
    - --log.level=info
    - --log.format=logfmt
    - --query.replica-label=prometheus_replica
    - --query.replica-label=rule_replica
    - --store=dnssrv+_grpc._tcp.thanos-store.thanos.svc.cluster.local:10901
    - --store=dnssrv+_grpc._tcp.thanos-receive-ingestor-default.thanos.svc.cluster.local:10901
    - --store=dnssrv+_grpc._tcp.thanos-prometheus-.&lt;domain_name&gt;:10901
    - --query.auto-downsampling

第 3 步：現在，我們將處理 thanos-store 與配置要從第一階段發送到的數據的S3存儲桶（ObjectStore）之間的通信。因此，正如在第一步中所做的那樣，我們需要配置一個名稱，該名稱在注入環境 thanos-store-statefulSet.yaml 的一部分中請求到 Thanos 存儲 pod

env:
  - name: OBJSTORE_CONFIG
    valueFrom:
      secretKeyRef:
        key: thanos.yaml
        name: thanos-objectstorage

然后我們可以重用第一階段的相同源文件并為thanos-storethanos-storage-config.yaml創建一個秘密：

kubectl -n thanos create secret generic thanos-objectstorage --from-file=thanos.yaml=thanos-storage-config.yam

第4步：安裝清單

kubectl apply -f manifests -n thano

現在，應該關閉循環。Thanos 通過 thanos-query 部署從其他集群接收實時數據，并通過 thanos-store-statefulSet 保留來自 S3 存儲桶（ObjectStore）的數據。

結論

Thanos 讓我們改變了對 Prometheus 高度可用、耐用和經濟高效的看法，在許多 Kubernetes 集群上實施 Thanos 和 Prometheus 需要付出很多努力，但如果我們關心確保高可用的 Prometheus，那么這是值得的。