![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/0a0c8d91550d4907905ace065c01aeec.png)

作者 | 彭南光（光南）
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/EXFAywUqHq3QlaAydVuLeQ)

> _千里之堤，潰於蟻穴。_

# 緒論
不知道大家是否經歷過這樣的情景：突然被使用者告知系統出現問題，然後一臉懵地惶惶然排查修復；或是等到自己發現系統出現故障時，實際已經對使用者造成了嚴重的惡劣影響。

所謂千里之堤，潰於蟻穴。使用者信任的建立是長期而艱難的，然而要摧毀這種信任卻很簡單。一旦出現上述問題，不僅極大影響使用者使用體驗，同時會給使用者留下一個這個產品/團隊不可靠的印象，喪失使用者對產品/團隊長期好不容易積累下來的信用資本，未來再想建立這樣的信任關係就很難了。

這也是為什麼我們說快速發現問題的能力如此重要的原因，只有先做到快速發現問題，才能談怎樣排查問題、如何解決問題。

那麼怎樣才能在複雜的大規模場景中，做到真正先於使用者發現問題呢？下面我會帶來我們在管理大規模 ASI 叢集過程中對於快速發現問題的一些經驗和實踐，希望能對大家有所啟發。

注：ASI 是 Alibaba Serverless infrastructure 的縮寫，是阿里巴巴針對雲原生應用設計的統一基礎設施。有興趣可以閱讀：[《揭開阿里巴巴複雜任務資源混合排程技術面紗》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247498271&idx=1&sn=d18b7abf3ba14aacc7bc0e1028629023&chksm=fae6f1d0cd9178c67368b98161b289a6fb489f745992d0129dbb65edc0c027024ea777370a57&scene=21#wechat_redirect)。

# 背景
## 1. 複雜的場景和曾面臨的困境
我們所管理的大規模 ASI 叢集場景非常複雜，這為我們的工作帶來了極大挑戰，任何一個場景處理不慎就有可能導致意料之外的傷害擴大化。

- 從元件維度看，我們目前有幾百個元件，每年有幾萬次的元件變更。頻繁的元件變更如何在穩定性和效率之間取得權衡，怎樣讓變更時更穩定，怎樣讓灰度更確信，從而降低爆炸半徑？

- 從叢集維度看，目前有上千個叢集和海量節點，碰到的叢集/節點問題較多，監控鏈路覆蓋比較繁複，怎樣讓叢集執行時更加可信?

- 從二方使用者和業務場景看，我們支援了大量的集團二方使用者，同時業務場景也非常複雜，怎樣保證各有特色的業務場景都能得到一致的細心關照?

![1.png](https://ucc.alicdn.com/pic/developer-ecology/7a57002f17b24cc0a44eba154a8e0fac.png)

## 2. 問題預判和解決思路
基於長期的叢集管理經驗，我們有如下預設：

1. 資料監控作為正向鏈路，無法無死角覆蓋所有場景。即使鏈路中各個節點的監控資料正常，也不能 100% 保證鏈路可用。
   - 叢集狀態每時每刻都在變化，各個元件也在不停地更新升級，同時鏈路上的每個系統也在不停的變更，監控資料的覆蓋永遠是正向的追趕，只能逼近 100% 全覆蓋而無法完全達到。
   - 即使整個叢集鏈路中所有元件/節點的監控資料都正常，也不能保證叢集鏈路 100% 可用。就如同業務系統一樣，看上去都是可用的，沒有問題暴露。但只有透過全鏈路壓測實際探測過整個鏈路後，才能得到實際可用的結論。
   - 你要正向證明一個東西可用，需要舉證無數的例子。而如果要反向證明不可用，一個反例就夠了。資料監控鏈路只能逼近全覆蓋，而無法保證真正全覆蓋。

2. 大規模場景下，資料無法達到 100% 的完全一致性。
   - 當叢集規模足夠大時，資料的一致性問題將會愈加顯現。比如全域性風控元件是否全叢集鏈路覆蓋？相關流控配置是否全叢集鏈路推平？pod 主容器時區是否與上層一致？叢集客戶端節點證書是否有即將過期？等等問題，一旦疏忽，將有可能釀成嚴重的故障。

只有彌補上述兩類風險點，才能有底氣真正做到先於使用者發現問題。我們解決上述兩類風險的思路分別是：

1. 黑盒探測
   - 所謂黑盒探測，既模擬廣義上的使用者行為，探測鏈路是否正常。
2. 定向巡檢
   - 所謂巡檢，既檢查叢集異常指標，找到已有或可能將存在的風險點。

基於以上思路，我們設計並實現了 KubeProbe 探測/巡檢中心，用於彌補複雜系統的正向監控的不足，幫助我們更好、更快地發現系統風險和線上問題。

# 設計
## 黑盒探測和定向巡檢
### **1）黑盒探測**
不知道你是否也經歷過一條鏈路上各個系統監控資料都正常，但是實際鏈路流程就是跑不通。或者因為系統變化快，監控覆蓋不到 100% 的場景總是會有遺漏，導致影響到了使用者卻沒有報警，對使用者沒有實質影響卻報警頻發從而疲於奔命。

如果一個系統開發者自己都不使用自己的系統，那麼怎麼可能先於使用者發現系統問題呢？所以要先於使用者發現系統問題，首先我們自己就得先成為使用者，而且一定是使用最多，瞭解最深，無時無刻不在使用和感知系統狀況的使用者。

所謂黑盒探測，就是讓自己成為自己的使用者，模擬廣義"使用者"的行為去對叢集/元件/鏈路等待待測物件做探測。注意，這裡的"使用者"並不僅僅是狹義上使用系統的同學，而是廣義使用者。比如，etcd 的"使用者"是 APIServer，而 ASI 的"使用者"可能是某個透過 APIServer 操作叢集的同學，也可能是 Normandy 發起的釋出/擴容/縮容操作。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/cbba25604e414bc9a0f4e311fa199489.png)

我們希望 KubeProbe 能在 變更時（監聽到叢集狀態發生變化/元件變更/元件釋出/系統升級等等事件）/執行時（週期，高頻）/故障恢復時（手動），透過週期/事件觸發/手動觸發，執行各種不同型別的黑盒探測，第一時間感知元件/叢集/鏈路的可用性。

以 etcd 叢集的可用性來舉例，我們可以實現一個探測用例，邏輯是對 etcd 做 create/get/delete/txn 等等操作，並記錄每個操作的成功率/消耗時間，當成功率低於 100% 或消耗時間超過容忍閾值後，觸發報警。我們將週期高頻執行這個 etcd 的探測用例，同時對於 etcd 叢集的任何變更都會發出一個事件 event 觸發這個 etcd 探測立即執行，這樣就能儘量確保第一時間發現 etcd 可用性故障了。同時，當 etcd 叢集因為某些原因不可用了，我們也可以透過手動觸發等其他方式做探活，也能第一時間得到是否恢復的資訊。

### **2）定向巡檢**
在大規模集叢集/系統場景下，資料一致性是一定會面臨的難題。資料不一致，將導致一些隱患，可能會在未來引發某些確定性的故障。

相比於黑盒探測面對的未知故障場景，定向巡檢的目標是對叢集的已知風險點做掃描。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/90ef9fb067234de3bd7ed136b315c586.png)

我們希望 KubeProbe 能夠定期對整個叢集/鏈路做定向的巡檢，找出這些資料不一致的點，判斷資料不一致是否可能引發風險，從而能夠防患於未然，治未病。

比如 etcd 冷熱備多叢集覆蓋不全，可能導致叢集遇到故障無法快速恢復。那麼我們就定期對 etcd 的冷熱備覆蓋情況做定向巡檢，找出沒有覆蓋推平的叢集，並告警。比如 叢集風控系統沒有全叢集鏈路覆蓋，限流配置沒有全叢集鏈路推平，可能導致某些故障場景引發叢集全面崩潰，我們定期對風控配置全網掃描，判斷是否可能導致故障，找出這些隱藏的已知風險點並告警。

# 實現
## 1. 架構
### **1）基本架構**
KubeProbe 的基本實現架構大致如下圖，KubeProbe 中心端配置叢集/叢集組與巡檢/探測用例/用例集之間的關聯關係，負責對叢集做具體某次探測例項下發。某個具體的巡檢/探測用例下發到具體某個叢集將使用用例的映象建立一個 pod，這個 pod 裡會執行若干巡檢/探測邏輯，當執行完成後會回撥中心端回寫本次巡檢/探測結果。其具體結果在中心端統一展示/告警，並提供給其他消費者消費（如支援 ASIOps 平臺的釋出阻斷）。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/5b4c953a37bf46deadbc3473f01602b9.png)

### **2）高頻架構**
除了上述的基本架構之外，我們對於高頻探測用例（既探測週期短，觸發頻率需要非常頻繁，甚至保持無縫探測的場景）設計了一套叢集內的分散式常駐探測架構，該架構透過叢集內的 ProbeOperator 元件 watch 自定義物件 probeConfig 的變化，在叢集內建立一個常駐的探測 pod，將持續無間斷的執行探測邏輯，實現接近無縫的持續探測，並將結果透過去噪/令牌桶限流等處理後，上報中心端，共給其他消費者消費。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/2f8b3c7a211b4924aaf083da526fbb71.png)

## 2. KubeProbe 探測/巡檢用例管理
所有的探測/巡檢用例都使用統一的 git 倉庫管理，由我們提供一個統一的 client 庫，client 庫最核心提供的方法主要有兩個。

```
KPclient "gitlab.alibaba-inc.com/{sigma-inf}/{kubeProbe}/client"

// 報告成功
// 此方法會向KubeProbe報告本次巡檢結果為成功
KPclient.ReportSuccess()
os.Exit(0)

// 報告失敗
// 報告方法會向KubeProbe報告本次巡檢結果為失敗，並且失敗資訊為 `我失敗啦`
KPclient.ReportFailure([]string{"我失敗啦!"})
os.Exit(1)
```

我們可以透過提供好的 Makefile 將這個用例打包成映象，錄入 KubeProbe 中心端就可以對叢集做配置和下發了。將具體巡檢/探測邏輯和 KubeProbe 中心管控端解耦，可以靈活而又簡便的讓更多的二方使用者接入自己的特殊巡檢/探測邏輯。

目前已經使用的探測/巡檢用例包括：

- 通用探測：模擬 pod / deployment / statefulset 生命週期探測叢集整條管控鏈路。
- etcd 黑盒探測：模擬 etcd 的基本操作，探測元叢集中各 etcd 狀態。
- 金絲雀探測（感謝質量技術同學的大力支援）：模擬使用者使用 ASI 的部署場景，實現金絲雀應用的全鏈路模擬釋出/擴容/縮容。
- Virtual cluster 探測：探測 vc 虛擬叢集的管控鏈路狀態。
- 聯邦鏈路探測：探測聯邦控制器相關鏈路的狀態。
- 節點通用探測：在叢集每個節點上模擬排程一個探測 pod，探測節點側鏈路狀態。
- ASI 客戶端/服務端證書巡檢：檢查客戶端/服務端證書有效性以及到期時間是否已超過告警閾值。
- 全域性風控限流巡檢：檢查各 ASI 叢集是否已經推平並開啟 KubeDefender 全侷限流風控配置。
- ······

## 3. KubeProbe 中心端管控
編寫完成探測/巡檢用例，並打包上傳好映象後，就需要在 KubeProbe 中心端註冊這個用例模版，即將映象註冊進 KubeProbe 中心端的資料庫中。

我們可以透過"渲染配置"引數傳入一些指定的 env 環境變數到巡檢/探測 pod 中，用於執行不同的業務邏輯，實現同一個用例模版生成多個用例。

最後透過統一的配置管控將用例和叢集做繫結，配置對應的引數，執行各種下發邏輯。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/fb298b7bcbed46b6b4aa4e53c391e30a.png)

同時，我們還在 KubeProbe 中心端做了大量許可權安全管控，髒資料資源清理以及提效增速的工作（比如採用完全以 ownerreferences 的巡檢/探測用例資源自動清理能力等等），這裡不再贅述。

## 4. 打通釋出 / 變更阻斷
我們打通了 KubeProbe 探測與釋出變更的關聯，當對應叢集中有任何變更發生時（如某元件在做釋出），我們會自動透過相應的事件觸發此叢集繫結的所有巡檢/探測用例，檢查叢集狀態是否正常。如果探測失敗，則會將變更阻斷，降低爆炸半徑，提升叢集變更時穩定性。

## 5. 為什麼不使用 Kuberhealthy
社群有一個 Operator 叫 Kuberhealthy 也可以做類似的事情，我們曾經也考慮採用，並且深度使用過 Kuberhealthy 和參與 kuberhealthy 的社群貢獻，最終得出不適合的結論，主要原因是對大規模叢集的支援較弱，同時高頻呼叫時主流程卡死問題比較嚴重，不支援事件/手動單次觸發特性，不支援統一上報資料中心等等，最終選擇了自研自建的方式，目前來看是一個比較正確的選擇。

# 一點小結果
KubeProbe 上線以來，實現探測/巡檢用例幾十個，在集團數百個 ASI 叢集中執行千萬餘次，主動發現叢集故障和問題百餘次，其中某些小故障一旦沒有發覺很有可能升級成為大故障，有效降低了系統風險。同時打通了變更/釋出系統，提升了變更穩定性。並且在特殊故障時，多次先於業務方提前發現問題，更早地推動解決問題，客觀降低了故障損失。

下面是一個具體例子:

- 我們會接收到每個叢集中各個元件的釋出事件，由釋出事件觸發我們會在對應叢集中執行相關的巡檢/探測，比如排程一個定向的 pod 到某個節點元件釋出的節點上去。我們發現 kube-proxy 的釋出會導致節點的短暫不可用，排程上去的 pod 無法建立成功，從簡單的返回/日誌/叢集事件上看不出具體的問題，並且持續復現。經過深入排查，得知是 kube-proxy 的問題，存在 netns 洩露。執行久了會洩露，當 kube-proxy 重啟的時候，核心要清理 netns，會卡一段時間來清理，導致節點一段時間鏈路不通，pod 可以排程上去但是執行不起來，從而後續推進了 kube-proxy 的問題修復。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/710c1fe7c2ff4cfc99aced1f936e8155.png)

![8.png](https://ucc.alicdn.com/pic/developer-ecology/97a206a85a07440aaf9ee9d0b6c5f48f.png)

# 發現問題之後
## 1. KubeProbe 和資料監控的告警區別
KubeProbe 所面對的場景和資料監控不同，更多偏向於鏈路探測。

比如，監控告警一般的告警可能如下：

- xx容器記憶體使用率 99%
- webhook 雙副本全部掛掉了
- apiserver 三副本全部當機了

這些告警，往往內容中就包含了具體的故障點，而 KubeProbe 的鏈路探測告警就有很多不一樣，比如：

- Statefulset 鏈路探測失敗，Failed to create pod sandbox: rpc error: code = Unknown
- etcd 全流程黑盒探測失敗，context deadline exceeded
- CloneSet 擴容失敗，connect: connection refused

這些 KubeProbe 的告警往往比較難從字面看出到底這次巡檢/探測是為什麼失敗了，我們往往需要根據相關的用例返回日誌，巡檢/探測 pod 日誌，KubeProbe 相關叢集事件綜合排查，定位失敗原因。

## 2. 根因定位
我們以比較混沌的 KubeProbe 探測失敗告警作為線索，構建了一套 KubeProbe 自閉環的根因定位系統，將問題排查的專家經驗下沉進系統中，實現了快速和自動的問題定位功能，一個簡單的定位規則如下：

![9.png](https://ucc.alicdn.com/pic/developer-ecology/241b9f91d90e42a4ad030666be7687ed.png)

我們會透過普通的根因分析樹以及對失敗巡檢探測事件/日誌的機器學習分類演算法（持續開發投入中），為每一個 KubeProbe 的探測失敗 Case 做根因定位，並透過 KubeProbe 內統一實現的問題嚴重性評估系統（目前這裡的規則仍比較簡單），為告警的嚴重性做評估，從而判斷應該如何做後續的處理適宜，比如是否自愈，是否電話告警等等。

## 3. Oncall 和 ChatOps
有了上面提到的根因定位以及告警嚴重性評估系統，我們使用了 nlp 告警機器人，實現了一套自動化的 Oncall 系統以及 ChatOps，展示一些使用的 case 如下，透過 ChatOps 和 Oncall 機器人，極大的降低了問題處理的複雜度，儘量用技術的手段解決重複的問題。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/0ad5d4933f6b4277ade841824ef0cea1.png)

![11.png](https://ucc.alicdn.com/pic/developer-ecology/6686f51e2aa6472c912ce0725e7b9308.png)

![12.png](https://ucc.alicdn.com/pic/developer-ecology/2d2e607d9cc44acd80ac11759e7761e6.png)

# 我們仍在路上
以上是我們在管理大規模 Kubernetes 叢集中的一點經驗，也解決了一些常見的問題，希望能對大家有所幫助。同時，這些工作在阿里雲海量規模的場景下還需要持續打磨，我們仍在路上，並且將持續在路上。

面對大規模 K8s 叢集，如何先於使用者發現問題？

相關文章