## 概述 繼上一篇 [Thanos 部署與實踐](https://mp.weixin.qq.com/s/NrOwhfKgoqg-y3E0d-VUuA) 釋出半年多之後，隨著技術的發展，本系列又迎來了一次更新。本文將介紹如何結合 Kvass 與 Thanos，來更好的實現大規模容器叢集場景下的監控。 ## 有 Thanos 不夠嗎 ? 有同學可能會問，Thanos 不就是為了解決 Prometheus 的分散式問題麼，有了 Thanos 不就可以實現大規模的 Prometheus 監控了嗎？為什麼還需要個 Kvass？ Thanos 解決了 Prometheus 的分散式儲存與查詢的問題，但沒有解決 Prometheus 分散式採集的問題，如果採集的任務和資料過多，還是會使 Prometheus 達到的瓶頸，不過對於這個問題，我們在系列的第一篇 [大規模場景下 Prometheus 的優化手段](https://mp.weixin.qq.com/s/82Fr4nlsOP4tj9Rg6GyV-g) 中就講了一些優化方法: 1. 從服務維度拆分採集任務到不同 Prometheus 例項。 2. 使用 Prometheus 自帶的 hashmod 對採集任務做分片。 但是，這些優化方法還是存在一些缺點: 1. 配置繁瑣，每個 Prometheus 例項的採集配置都需要單獨配。 2. 需要提前對資料規模做預估才好配置。 3. 不同 Prometheus 例項採集任務不同，負載很可能不太均衡，控制不好的話仍然可能存在部分例項負載過高的可能。 4. 如需對 Prometheus 進行擴縮容，需要手動調整，無法做到自動擴縮容。 Kvass 就是為了解決這些問題而生，也是本文的重點。 ## 什麼是 Kvass ? Kvass 專案是騰訊雲開源的輕量級 Prometheus 橫向擴縮容方案，其巧妙的將服務發現與採集過程分離，並用 Sidecar 動態給 Prometheus 生成配置檔案，從而達到無需手工配置就能實現不同 Prometheus 採集不同任務的效果，並且能夠將採集任務進行負載均衡，以避免部分 Prometheus 例項負載過高，即使負載高了也可以自動擴容，再配合 Thanos 的全域性檢視，就可以輕鬆構建只使用一份配置檔案的超大規模叢集監控系統。下面是 Kvass+Thanos 的架構圖:  更多關於 Kvass 的詳細介紹，請參考 [如何用 Prometheus 監控十萬 container 的 Kubernetes 叢集](https://mp.weixin.qq.com/s/P3F1grbVpb7LF2hcxYNOcg) ，文章中詳細介紹了原理和使用效果。 ## 部署實踐 ### 部署準備 首先下載 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 部署與實踐](https://mp.weixin.qq.com/s/NrOwhfKgoqg-y3E0d-VUuA) 對 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 為指標生成器生成的指標名):   如果需要用 Grafana 面板檢視監控資料，可以新增 thanos-query 地址作為 Prometheus 資料來源: `http://thanos-query.default.svc.cluster.local:9090`。 ## 小結 本文介紹瞭如何結合 Kvass 與 Thanos 來實現超大規模容器叢集的監控，如果你使用了騰訊雲容器服務，可以直接使用運維中心下的 `雲原生監控` 服務，此服務就是基於 Kvass 構建的產品。 >【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！ ![](https://img2020.cnblogs.com/other/2041406/202012/2041406-20201208093450934-124897