背景

通常而言，叢集的穩定性決定了一個平臺的服務質量以及對外口碑，當一個平臺管理了相當規模數量的 Kubernetes 叢集之後，在穩定性這件事上也許會“稍顯被動”。

我們可能經常會遇到這樣的場景：客戶一個電話，火急火燎地說業務出現問題了，你們平臺快幫忙查詢一下是不是哪裡出了問題呀？技術同學連忙放下手頭工作，上去一通操作加安撫客戶……看似專業且厲害，急使用者之所急，細想之後實則無章無法，一地雞毛。

通常我們依賴監控系統來提前發現問題，但是監控資料作為一個正向鏈路，很難覆蓋到所有場景，經常會有因為叢集配置的不一致性或者一些更底層資源的異常，即使監控資料完全正常，但是整個系統依然會有一些功能不可用。對此，我們做了一套巡檢系統，針對系統中一些薄弱點以及一致性做診斷，但是這套系統的擴充套件性不是很好，對叢集跟巡檢項的管理也相對粗暴了一點。

最後我們決定做一個更加雲原生的診斷工具，使用 operator 實現叢集跟診斷項的管理，抽象出叢集跟診斷項的資源概念，以此來解決大規模 Kubernetes 叢集的診斷問題，通過在中心下發診斷項到其他叢集，並統一收集其他叢集的診斷結果，實現任何時刻都可以從中心獲取到其他所有叢集的執行狀態，做到對大規模 Kubernetes 叢集的有效管理以及診斷。

Talk is cheap, show me the demo：

Demo

Kubeprober

專案介紹

專案地址： https://github.com/erda-project/kubeprober
官網地址： https://k.erda.cloud

Kubeprober 是一個針對大規模 Kubernetes 叢集設計的診斷工具，用於在 Kubernetes 叢集中執行診斷項以證明叢集的各項功能是否正常，Kubeprober 有如下特點:

• 支援大規模叢集
  支援多叢集管理，支援在管理端配置叢集跟診斷項的關係以及統一檢視所有叢集的診斷結果；

• 雲原生
  核心邏輯採用 operator 來實現，提供完整的 Kubernetes API 相容性;

• 可擴充套件
  支援使用者自定義巡檢項。

其核心架構如下：

區別於監控系統，Kubeprober 從巡檢的角度來驗證叢集的各項功能是否正常，監控作為正向鏈路，無法覆蓋系統中的所有場景，即使系統中各個環境的監控資料都正常，也無法保證系統是 100% 可用的，因此我們就需要一個工具從反向來證明系統的可用性，根本上做到先於使用者發現叢集中不可用的點，比如：

• 叢集中的所有節點是否均可以被排程，有沒有特殊的汙點存在等；
• pod 是否可以正常的建立，銷燬，驗證從 Kubernetes，Kubelet 到 Docker 的整條鏈路；
• 建立一個 service，並測試連通性，驗證 kube-proxy 的鏈路是否正常；
• 解析一個內部或者外部的域名，驗證 CoreDNS 是否正常工作；
• 訪問一個 ingress 域名，驗證叢集中的 ingress 元件是否正常工作；
• 建立並刪除一個 namespace，驗證相關的 webhook 是否正常工作；
• 對 Etcd 執行 put/get/delete 等操作，用於驗證 Etcd 是否正常執行；
• 通過 mysql-client 的操作來驗證 MySQL 是否正常執行；
• 模擬使用者對業務系統進行登入，操作，驗證業務的主流程是否正常；
• 檢查各個環境的證書是否過期；
• 雲資源的到期檢查；
• ……

元件介紹

Kubeprober 整體採用 Operator 來實現核心邏輯，叢集之間的管理使用 remotedialer 來維持被納管叢集跟管理叢集之間的心跳連結，被納管叢集通過 RBAC 賦予 probe-agent 最小所需許可權並且通過心跳連結實時上報被納管叢集元資訊以及訪問 apiserver 的 token，實現在管理叢集可以對被管理叢集的相關資源進行操作的功能。

probe-master

執行在管理叢集上的 operator 維護著兩個 CRD：一個是 Cluster，用於管理被納管的叢集；另一個是 Probe，用於管理內建的以及使用者自己編寫的診斷項。probe-master 通過 watch 這兩個 CRD，將最新的診斷配置推送到被納管的叢集，同時 probe-master 提供介面用於檢視被納管叢集的診斷結果。

probe-agent

執行在被納管叢集上的 operator，這個 operator 維護兩個 CRD：一個是跟 probe-master 完全一致的 Probe，probe-agent 按照 probe 的定義去執行該叢集的診斷項；另一個是 ProbeStatus，用於記錄每個 Probe 的診斷結果，使用者可以在被納管的叢集中通過 kubectl get probestatus 來檢視本叢集的診斷結果。

什麼是 Probe

Kubeprobe 中執行的診斷計劃我們稱之為 Probe，一個 Probe 為一個診斷項的集合，我們建議將統一場景下的診斷項作為一個 Probe 來執行，probe-agent 元件會 watch probe 資源，執行 Probe 中定義的診斷項，並且將結果寫在 ProbeStatus 的資源中。

我們期望有一個輸出可以清晰地看到當前叢集的執行狀態，因此我們建議所有的 Probe 都儘可能屬於應用、中介軟體、Kubernetes 以及基礎設定這四大場景，這樣我們可以在展示狀態的時候，清晰且自上而下地檢視究竟是系統中哪個層面引起的問題。

目前的 Probe 還比較少，我們還在繼續完善，也希望跟大家一起共建。歡迎廣大愛好者一起來共建：
自定義 Probe

對比其他診斷工具

目前社群已經有 Kuberhealthy 以及 Kubeeye 來做 Kubernetes 叢集診斷這件事情。

Kuberheathy 提供一套比較清晰的框架可以讓你輕鬆編寫自己的診斷項，將診斷項 CRD 化，可以輕鬆地使用Kubernetes 的方式來對單個 Kubernetes 進行體檢。

Kubeeye 同樣是針對單個叢集，主要通過呼叫 Kubernetes 的 event api 以及 Node-Problem-Detector 來檢測叢集控制平面以及各種節點問題，同時也支援自定義診斷項。

其實，Kubeprober 做的也是診斷 Kubernetes 叢集這件事情，提供框架來編寫自己的診斷項。除此之外，Kubeprober 主要解決了大規模 Kubernetes 叢集的診斷問題，通過中心化的思路，將叢集跟診斷項抽象成 CRD，可以實現在中心 Kubernetes 叢集管理其他 Kubernetes 診斷項配置，診斷結果收集，未來也會解決大規模 Kubernetes 叢集的運維問題。

如何使用

Kubeprober 主要解決大規模 Kubernetes 叢集的診斷問題，通常我們選擇其中一個叢集作為 master 叢集，部署probe-master，其他叢集作為被納管叢集，部署 probe-agent，詳細的使用說明可參考官方文件。

視覺化

Kubeprober 在多叢集中根據 probe 的策略執行診斷項，會產生大量的診斷事件。由此，對這些診斷項進行視覺化的展示就顯得尤為重要，此時如果有一個全域性的 dashboard 對大規模叢集的海量診斷項進行統一檢視分析，將會更有利於我們掌握這些叢集的執行狀態。

Kubeprober 支援將診斷項事件寫入 influxdb，通過 grafana 配置圖表來統一展示診斷結果，比如：我們將 ERROR 事件統一展示出來作為最高優先順序進行關注。

同時，我們也可以通過擴充套件 probe-agent 上報的叢集資訊，展示一張詳盡的叢集列表：

結語

隨著數字化的逐漸發展，企業的 IT 架構也變得越來越複雜，如何在複雜環境中保證業務連續性及穩定性？相信這是每一個 IT 從業者都會面臨的問題，如果大家對穩定性的話題或者是對 Kuberprober 專案感興趣，歡迎聯絡我們一起深入探討，同時也歡迎廣大開源愛好者一起參與，共同打造一個大規模的 Kubernetes 叢集的管理神器。Contributing to Kubeprober

我們致力於決社群使用者在實際生產環境中反饋的問題和需求，
如果您有任何疑問或建議，
歡迎關注【爾達Erda】公眾號給我們留言，
加入 Erda 使用者群參與交流或在 Github 上與我們討論！