打造雲原生大型分散式監控系統(四): Kvass+Thanos 監控超大規模容器叢集

騰訊雲原生發表於2020-12-08
分散式

概述

繼上一篇 Thanos 部署與實踐 釋出半年多之後，隨著技術的發展，本系列又迎來了一次更新。本文將介紹如何結合 Kvass 與 Thanos，來更好的實現大規模容器叢集場景下的監控。

有 Thanos 不夠嗎 ?

有同學可能會問，Thanos 不就是為了解決 Prometheus 的分散式問題麼，有了 Thanos 不就可以實現大規模的 Prometheus 監控了嗎？為什麼還需要個 Kvass？
Thanos 解決了 Prometheus 的分散式儲存與查詢的問題，但沒有解決 Prometheus 分散式採集的問題，如果採集的任務和資料過多，還是會使 Prometheus 達到的瓶頸，不過對於這個問題，我們在系列的第一篇 大規模場景下 Prometheus 的優化手段 中就講了一些優化方法:

  1. 從服務維度拆分採集任務到不同 Prometheus 例項。
  2. 使用 Prometheus 自帶的 hashmod 對採集任務做分片。

但是，這些優化方法還是存在一些缺點:

  1. 配置繁瑣，每個 Prometheus 例項的採集配置都需要單獨配。
  2. 需要提前對資料規模做預估才好配置。
  3. 不同 Prometheus 例項採集任務不同，負載很可能不太均衡，控制不好的話仍然可能存在部分例項負載過高的可能。
  4. 如需對 Prometheus 進行擴縮容，需要手動調整，無法做到自動擴縮容。

Kvass 就是為了解決這些問題而生，也是本文的重點。

什麼是 Kvass ?

Kvass 專案是騰訊雲開源的輕量級 Prometheus 橫向擴縮容方案，其巧妙的將服務發現與採集過程分離，並用 Sidecar 動態給 Prometheus 生成配置檔案，從而達到無需手工配置就能實現不同 Prometheus 採集不同任務的效果，並且能夠將採集任務進行負載均衡，以避免部分 Prometheus 例項負載過高，即使負載高了也可以自動擴容，再配合 Thanos 的全域性檢視，就可以輕鬆構建只使用一份配置檔案的超大規模叢集監控系統。下面是 Kvass+Thanos 的架構圖:

img

更多關於 Kvass 的詳細介紹，請參考 如何用 Prometheus 監控十萬 container 的 Kubernetes 叢集 ，文章中詳細介紹了原理和使用效果。

部署實踐

部署準備

首先下載 Kvass 的 repo 並進入 examples 目錄:

git clone https://github.com/tkestack/kvass.git
cd kvass/examples

在部署 Kvass 之前我們需要有服務暴露指標以便採集，我們提供了一個 metrics 資料生成器，可以指定生成一定數量的 series，在本例子中，我們將部署 6 個 metrics 生成器副本，每個會生成 10045 series，將其一鍵部署到叢集:

kubectl create -f  metrics.yaml

部署 Kvass

接著我們來部署 Kvass:

kubectl create -f kvass-rbac.yaml # Kvass 所需的 RBAC 配置
kubectl create -f config.yaml # Prometheus 配置檔案
kubectl create -f coordinator.yaml # Kvass coordinator 部署配置

其中，config.yaml 的 Prometheus 配置檔案，配了對剛才部署的 metrics 生成器的採集:

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    cluster: custom
scrape_configs:
- job_name: 'metrics-test'
  kubernetes_sd_configs:
    - role: pod
  relabel_configs:
  - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
    regex: metrics
    action: keep
  - source_labels: [__meta_kubernetes_pod_ip]
    action: replace
    regex: (.*)
    replacement: ${1}:9091
    target_label: __address__
  - source_labels:
    - __meta_kubernetes_pod_name
    target_label: pod

coordinator.yaml 我們給 Coordinator 的啟動引數中設定每個分片的最大 head series 數目不超過 30000:

--shard.max-series=30000

然後部署 Prometheus 例項(包含 Thanos Sidecar 與 Kvass Sidecar)，一開始可以只需要單個副本:

kubectl create -f prometheus-rep-0.yaml

如果需要將資料儲存到物件儲存，請參考上一篇 Thanos 部署與實踐 對 Thanos Sidecar 的配置進行修改。

部署 thanos-query

為了得到全域性資料，我們需要部署一個 thanos-query:

kubectl create -f thanos-query.yaml

根據上述計算，監控目標總計 6 個 target, 60270 series，根據我們設定每個分片不能超過 30000 series，則預期需要 3 個分片。我們發現，Coordinator 成功將 StatefulSet 的副本數改成了 3。

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
kvass-coordinator-c68f445f6-g9q5z   2/2     Running   0          64s
metrics-5876dccf65-5cncw            1/1     Running   0          75s
metrics-5876dccf65-6tw4b            1/1     Running   0          75s
metrics-5876dccf65-dzj2c            1/1     Running   0          75s
metrics-5876dccf65-gz9qd            1/1     Running   0          75s
metrics-5876dccf65-r25db            1/1     Running   0          75s
metrics-5876dccf65-tdqd7            1/1     Running   0          75s
prometheus-rep-0-0                  3/3     Running   0          54s
prometheus-rep-0-1                  3/3     Running   0          45s
prometheus-rep-0-2                  3/3     Running   0          45s
thanos-query-69b9cb857-d2b45        1/1     Running   0          49s

我們再通過 thanos-query 來檢視全域性資料，發現資料是完整的(其中 metrics0 為指標生成器生成的指標名):

img

img

如果需要用 Grafana 皮膚檢視監控資料，可以新增 thanos-query 地址作為 Prometheus 資料來源: http://thanos-query.default.svc.cluster.local:9090。

小結

本文介紹瞭如何結合 Kvass 與 Thanos 來實現超大規模容器叢集的監控，如果你使用了騰訊雲容器服務，可以直接使用運維中心下的 雲原生監控 服務，此服務就是基於 Kvass 構建的產品。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！

相關文章