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

作者 |  韓堂、柘遠、沉醉
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/ZdVH83Q0T24bACpIE6xwpg)

# 前言

臺灣作家林清玄在接受記者採訪的時候，如此評價自己 30 多年寫作生涯：“第一個十年我才華橫溢，‘賊光閃現’，令周邊黯然失色；第二個十年，我終於‘寶光現形’，不再去搶風頭，反而與身邊的美麗相得益彰；進入第三個十年，繁華落盡見真醇，我進入了‘醇光初現’的階段，真正體味到了境界之美”。

長夜有窮，真水無香。領略過了 K8s“身在江湖”的那種驚心動魄以及它那生態系統的繁花似錦，該是回過頭來體味高可用體系境界之美的時候了。畢竟僅能經得起敲打還是不能獨步武林的！

在 K8s 高可用領域有一個問題被大家所熟知，那就是 K8s 單叢集規模帶來的 SLO 問題，如何持續保障？今天就以單叢集的規模增長帶來的高可用挑戰來作為引子來給大家一個體感。

ASI 單叢集規模支撐超過社群的 5000 臺，這是個非常有意思且具備極大挑戰的事情，對需要進行 K8s 生產化的同學，甚至具備 K8s 生產化經驗的同學來說，一定會是個感興趣的話題。回看 ASI 單叢集規模從 100 到 10000 的發展之路，伴隨著業務的增長和創新帶來的每一次叢集規模增長，都在逐步使我們的壓力和挑戰發生質變。

> ASI：Alibaba Serverless infrastructure，阿里巴巴針對雲原生應用設計的統一基礎設施，ASI 是阿里公共雲服務 ACK 的阿里集團企業版。

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

大家知道 K8s 社群只能夠支撐五千個節點，當超過這個規模時，會出現各種效能瓶頸問題，比如：

- etcd 出現大量的讀寫延遲。
- kube-apiserver 查詢 pods/nodes 延時很高，甚至導致 etcd oom。
- 控制器無法及時感知資料變化，如出現 watch 資料延遲。

以電商場景為例，100 節點增長到 4 千節點的時候，我們提前針對 ASI apiserver 的客戶端和服務端做了大量的效能最佳化，從 apiserver 客戶端的角度優先訪問本地 cache，在客戶端去做負載均衡；apiserver 服務端主要做了 watch 最佳化和 cache 索引最佳化；在 etcd 核心上利用併發讀提升單 etcd 叢集讀處理能力，基於 hashmap 的 freelist 管理新演算法提高 etcd 儲存上限，基於 raft learner 技術來提高多備能力等等。

從 4 千節點增長到 8 千節點，我們又做了 qps 限流管理和容量管理最佳化、etcd 單資源物件儲存拆分、元件規範全生命週期落地透過客戶端的規範約束降低對 apiserver 的壓力和以及穿透到 etcd 的壓力等等。

終於迎來 8 千節點增長到上萬節點的時刻，我們開始如火如荼地開展 etcdcompact 演算法最佳化；etcd 單節點多 multiboltdb 的架構最佳化，apiserver 的服務端資料壓縮，透過元件治理降低 etcd 寫放大等；同時開始打造常態化的壓測服務能力，持續回答 ASI 的 SLO。

這些例子在高可用挑戰中司空見慣，列出的能力也只是其中一小部分，你也許很難看到能力之間的關聯和底層的演進邏輯。當然，更多的能力建設沉澱到了我們的系統和機制當中。本篇文章會作為一個開始，以綜述的形式分享我們在建設 ASI 全域性高可用體系中的幾個關鍵部分，再往後會有針對性地對進行技術點和演進路線的詳解。如果大家有什麼問題或者希望瞭解的部分，歡迎在評論區留言。

# ASI 全域性高可用概述

高可用是個比較複雜的命題，任何日常的變化例如服務升級、硬體更新、資料遷移、流量突增等都可能造成服務 SLO 受損，甚至不可用。

ASI 作為容器平臺，並非孤立存在，而是與雲底層及公共服務形成完備的生態系統。要解決 ASI 的高可用問題，需要縱觀全域性，找出每層的最優解，最終串聯組成最優的整體解決方案。涉及到的層面包括：

- 雲基礎相關管理，包括可用區的選擇，規劃和硬體資產的管理
- 節點的管理
- ASI 叢集管理
- 公共服務
- 叢集運維
- 應用研發

特別是在 ASI 這個場景下，要支撐的業務叢集數量龐大，涉及到的研發運維人員眾多，功能釋出頻繁的迭代開發模式以及業務種類繁多帶來的執行時的複雜多變，相比其他容器平臺來看，ASI 高可用面臨更多的挑戰，其難度不言而喻。

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

# ASI 全域性高可用設計

如下圖所示，現階段高可用能力建設整體策略以 1-5-10（故障 1 分種發現、5 分鐘定位、10 分鐘止損）為目標牽引，注重將能力沉澱到系統或機制中，讓 SRE/Dev 能夠無差別的 oncall。

儘量避免發生問題、儘快發現、定位及恢復問題，是實現目標的關鍵，為此我們將 ASI 全域性高可用體系的實現分三大部分展開：一是基礎能力建設；二是應急體系建設；三是透過常態化壓測以及故障演練等完成上述能力的保鮮和持續演進。

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

透過 3 個部分的輪轉驅動，實現一個 ASI 全域性高可用體系的構建，其頂層是 SLO 體系和 1-5-10 應急體系。在應急體系和資料驅動的體系背後，我們建設了大量高可用基礎能力，包括防禦體系、高可用架構升級、故障自愈體系、以及持續改進機制。與此同時，我們建立了多個基礎性平臺為高全用體系提供配套能力，如常態化故障演練平臺、全鏈路模擬壓測平臺、告警平臺、預案中心等等。

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

# 全域性高可用基礎能力建設

在建設全域性高可用能力之前，我們的系統在迅速發展和變化下不斷出現事故和險情，需要隔三差五去應急，導致讓問題追身的局面，並且追身後沒高效應對的手段，面臨著幾個嚴峻的挑戰：

- 如何在架構和能力上去提升我們的可用性，降低系統發生故障的機率和影響面？
- 如何在核心鏈路效能和架構上做一些突破，能夠支撐這麼複雜多變的業務場景和業務增長的通用需求？
- 如何讓問題不再追身，做好預防工作，避免應急？
- 如何在應急發生時，能夠快速發現，快速診斷，快速止損？

針對這些問題，並且總結出以下幾個核心原因：

- 可用效能力不足：在集團場景下，元件不斷在變化，不斷增加系統的壓力和複雜度，ASI 在生產可用性的能力上缺失，如限流降級、負載均衡等，元件容易亂用造成低階錯誤，影響叢集可用性。
- 系統風控和 pod 保護能力不足：在人為誤操作或系統 bug 時, 容易造成業務 pod 無辜受損或者大面積受損。
- 容量風險：叢集數量幾百，元件接近一百；另外歷史問題因 podCIDR 和節點 IP 數的配置，大多 ASI 元叢集的節點規模被約束在 128 臺以內，隨著業務快速發展，對容量風險而言存在較大挑戰。
- 單叢集規模受限，加上橫向擴充套件能力不足影響業務發展：單叢集不斷增長規模，以及業務型別變化，元件變化都對單叢集支撐的最大規模產生影響，對 SLO 持續穩定產生影響。

## 1. 高可用基礎能力頂層設計

針對這些解決的問題，我們做了高可用基礎能力的頂層設計，這些基礎能力建設整體主要分為幾個部分：

- 效能最佳化和高可用架構建設：主要是從效能最佳化和架構升級的角度來提升整個叢集支撐的業務型別和業務量。
- 元件規範全生命週期管理：主要從規範的角度在元件的整個生命週期去落地，從出生啟用和叢集准入開始，到每一次變更，到下線整個生命週期都要防止元件亂用、野蠻生長、無限膨脹，控制元件在系統可承受範圍之內。
- 攻防體系建設：主要從 ASI 系統本身觸發，在從攻擊和防禦的角度來提升系統的安全，防禦和風控能力。

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

下面針對我們的一些痛點進行幾個關鍵能力建設的描述。

## 2. K8s 單叢集架構的痛點

- 對 ApiServer 的掌控能力不夠，應急能力不足，我們自己的經歷，歷次叢集 Master 出現異常的次數超過 20+，歷次恢復時間最長超過 1 小時。
- ApiServer 是 APIServer 叢集的單點，爆炸半徑大。
- 單叢集規模大， Apiserver 記憶體水位比較高，壓力來源於頻繁的查詢，寫入更多更大的資源物件。
- 在業務層缺少跨機房的容災能力，當 ASI 不可用的時候，只能依賴 ASI 的恢復能力。
- 叢集規模的持續擴大，離線任務的大量建立和刪除對叢集的造成更大壓力。

這裡面從兩個大的角度可以去提高叢集架構的可用性，除了在單叢集進行架構最佳化以及效能突破外，還要透過多叢集這樣的橫向擴充套件能力去支撐更大的規模。

- 一是透過聯邦這樣的多叢集能力來解決單叢集的橫向擴充套件能力以及單地域跨叢集容災能力。
- 另外一個單叢集本身的架構還可以從隔離和優先順序策略的架構角度來進行差異化 SLO 保障。

## 3. ASI 架構升級落地

### **1）APIServer 多路架構升級**

核心方案就是透過對 apiserver 進行分組，透過不同的優先順序策略進行對待，從而對服務進行差異化 SLO 保障。

- 透過分流以降低主鏈路 apiserver 壓力（核心訴求）
   - P2 及以下元件接入旁路 apiserver，並可以在緊急情況（如自身穩定性收到影響）下，做整體限流。
- 旁路 apiserver 配合主鏈路做藍綠、灰度（次級訴求）
   - 旁路 apiserver 可以使用獨立版本，增加新功能灰度維度，如使用獨立的限流策略，如開啟新的 feature 功能驗證。
- SLB 災備（次級訴求）
   - 旁路 apiserver 可以在主 apiserver 發生異常時，對外提供服務（需 controller 自行切換目標地址）。

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

### **2）ASI 多叢集聯邦架構升級**

目前張北中心的一個機房就幾萬節點，如果不解決多叢集的管理問題，帶來的問題如下：

- **容災層面**：把核心交易應用的中心單元部署在一個叢集的風險是很大的，最壞情況下叢集不可用導致整個應用服務不可用。

- **效能層面**：對於業務來說，如因核心應用在某一時點使用時極其敏感而設定各種單機最大限制、CPU 互斥獨佔保證，如果都部署在一個叢集的話，會因為叢集節點規模限制，導致應用發生堆疊，造成 cpu 熱點，效能不滿足要求；對於 ASI 管控 Master 來說，單叢集無限制擴大，效能總會出現瓶頸，總有一天會無法支撐。
- **運維層面**：當某個應用擴容發現沒資源，SRE 還得考慮節點加到哪個叢集，額外加大了 SRE 叢集管理的工作。

因此 ASI 需要達成統一的多叢集管理解決方案，幫助上層各個 Pass、SRE、應用研發等提供更好的多叢集管理能力，透過它來遮蔽多叢集的差異、方便的進行多方資源共享。

ASI 選擇基於社群聯邦 v2 版本來開發滿足我們的需求。

## 4. K8s 叢集遭遇規模增長帶來的極大效能挑戰

在一個大規模的 K8s 叢集中效能會遇到哪些問題呢？

- **首先是查詢相關問題**。在大叢集中最重要的就是如何最大程度地減少 expensive request。對百萬級別的物件數量來說，按標籤、namespace 查詢 Pod，獲取所有 Node 等場景時，很容易造成 etcd 和 kube-apiserver OOM 和丟包，乃至雪崩等問題發生。

- **其次是寫入相關問題**。etcd 適用場景是讀多寫少，大量寫請求可能會導致 db size 持續增長、寫效能達到瓶頸被限速、影響讀效能。如大量的離線作業需要頻繁的建立和刪除 pod，透過 ASI 鏈路對 pod 物件的寫放大，最終對 etcd 的寫壓力會放大幾十倍之大。

- **最後是大資源物件相關問題**。etcd 適合儲存較小的 key-value 資料，在大 value 下，效能急速下降。

## 5. ASI 效能瓶頸突破

### **ASI 效能最佳化的方向**

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

ASI 的效能最佳化可以從 apiserver 客戶端、apiserver 服務端、etcd 儲存 3 個方面來進行最佳化。

- 客戶端側，可以做 cache 最佳化，讓各個 client 優先訪問本地 informer cache，也需要做負載均衡最佳化，主要包括對 apiserver,etcd 的負載均衡。同時針對客戶端的各種最佳化，可以透過元件效能規範，在元件啟用，准入的時候進行校驗是否滿足。
- APIServer 側，可以從訪問層，快取層，儲存層 3 個層次進行最佳化。在快取層，我們重點建設了 cache 的索引最佳化以及 watch 最佳化，在儲存層上重點透過 snappy 壓縮演算法對 pod 進行資料壓縮，在訪問層上重點建設了限流能力。

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

- etcd 儲存側的最佳化，我們也從幾個方面做了很多工作，包括 etcd 核心層面各種演算法最佳化工作，還有透過將不同資源拆分到不同 etcd 叢集的能力實現了基本的水平拆分能力，同時也在 etcd server 層做 multi boltdb 的擴充套件能力提升。

## 6. K8s 叢集的預防能力薄弱

在 K8s 中，kube-apiserver 作為統一入口，所有的控制器/client 都圍繞 kube-apiserver 在工作，儘管我們 SRE 透過元件的全生命週期進行規範約束卡點改進，比如透過在元件的啟用和叢集准入階段進行了卡點審批，透過各個元件 owner 的全面配合改造後，大量的低階錯誤得到防範，但還是有部分控制器或部分行為並不可控。

除了基礎設施層面的故障外，業務流量的變化，是造成 K8s 非常不穩定的因素，突發的 pod 建立和刪除，如果不加以限制，很容易把 apiserver 打掛。

另外非法的操作或程式碼 Bug 有可能造成業務 pod 影響，如不合法的 pod 刪除。

結合所有風險進行分層設計，逐層進行風險防控。

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

## 7. ASI 單叢集的預防能力加強

### **1）支援 API 訪問層的多維度（resource/verb/client）精細化限流**

社群早期採用的限流方式主要透過 inflight 控制讀寫總體併發量，我們當時在 apf 沒有出來之前就意識到限流能力的不足，沒有能力去對請求來源做限流。而 apf 透過 User 來做限流（或者說要先經過 authn filter）存在一些不足，一方面因為Authn 並不是廉價的，另外一方面它只是將 API Server 的能力按配置來做分配，並不是一種限流方案和應急預案。我們需要緊急提供一種限流能力，以應對緊急情況，自研了 ua limiter 限流能力，並基於 ua limiter 簡單的配置方式實現了一套限流管理能力，能夠很方便在幾百個叢集當中進行預設限流管理，以及完成應急限流預案。

下面是我們自研的 ua limiter 限流方案和其他限流方案的詳細對比：

![10.jpg](https://ucc.alicdn.com/pic/developer-ecology/9af7ccdf441843cfbdb1c0e5a9b206df.jpg)

ua limiter、APF、sentinel 在限流上的側重點是不一樣的：

- ua limiter 是根據 ua 提供一個簡單的 QPS hard limit。
- apf 更加側重於併發度的控制，考慮的是流量的隔離和隔離後的公平性。
- sentinel 功能全面，但是對於公平性的支援並沒有 APF 全面，同時複雜度有一些過高。

考慮我們現階段的需求和場景，發現 ua limiter 落地最為合適，因為我們透過 user agent 的不同，來對於元件進行限流。當然後續進行更加精細的限流，還是可以考慮結合使用 APF 等方案進一步加強。

限流策略如何管理，數百套叢集，每套叢集規模都不太一樣，叢集節點數、pod 數都是不同的，內部元件有近百個，每個元件請求的資源平均有 4 種，對不同資源又有平均 3 個不同的動作，如果每個都做限流，那麼規則將會爆炸式增長，即便做收斂後維護成本也非常的高。因此我們抓最核心的：核心資源 pod\node、核心動作（建立、刪除、大查詢）；最大規模的：daemonset 元件、PV/PVC 資源。並結合線上實際流量分析，梳理出二十條左右的通用限流策略，並將其納入到叢集 交付流程中實現閉環。

當新的元件接入，我們也會對其做限流設計，如果比較特殊的，則繫結規則並在叢集准入和部署環節自動下發策略，如果出現大量的限流情況，也會觸發報警，由 SRE 和研發去跟進最佳化和解決。

### **2）支援業務 POD 級別的精細化限流**

所有 pod 相關的操作都會對接 Kube Defender 統一風控中心，進行秒級別、分鐘級、小時級、天級別的流控。該全域性風控限流元件，實行中心端部署，維護各場景下的介面呼叫限流功能。

defender 是站在整個 K8s 叢集的視角，針對使用者發起的或者系統自動發起的有風險的操作進行防護（流控、熔斷、校驗）和審計的風控系統。之所以做 defender，主要從以下幾個方面考慮：

- 類似 kubelet/controller 這樣的元件，在一個叢集中存在多個程式，任一單一程式都無法看到全域性的檢視，無法進行準確的限流。
- 從運維視角，分散在各個元件中的限速規則難以配置與審計，當部分操作因為限流原因失敗時，排查鏈路過長影響問題定位的效率。
- K8s 面向終態的分散式設計，每個元件都有決策的能力，那麼就需要一個集中的服務對那些危險決策進行風控。

defender 的框架圖如下所示：

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

- defender server 是 K8s 叢集級的服務，可以部署多個，其中一個 active，其餘 standby。
- 使用者可以透過kubectl配置風控規則。
- K8s 中的元件，例如 controller，kubelet，extension-controller 等，都可以透過 defender sdk 接入 defender（改動很小），在進行危險操作前請求 defender 進行風控，根據風控結果決定是否繼續該危險操作。defender 作為一個叢集級的風控防護中心，為 K8s 叢集的整體穩定性進行保駕護航。

### **3）數字化容量治理**

在只有幾個 core 叢集的場景下，依靠專家經驗管理容量完全可以輕鬆搞定，但隨著容器業務的快速發展，覆蓋泛交易、中介軟體、新生態、新計算以及售賣區等業務在接入 ASI，短短几年時間就發展了幾百個叢集，再發展幾年數以千計萬計？如此多的叢集依靠傳統的人肉資源管理方式難以勝任，人力成本越來越高，特別是面臨諸如以下問題，極易造成資源使用率低下，機器資源的嚴重浪費，最終造成部分叢集容量不足導致線上風險。

- 元件變更不斷，業務型別和壓力也在變化，線上真實容量（到底能扛多少 qps）大家都不得而知，當業務需要增大流量時是否需要擴容？是否橫向擴容也無法解決問題？
- 早期申請容器資源隨意，造成資源成本浪費嚴重，需要基於容器成本耗費最小化明確指導應該合理申請多少資源（包括 cpu，記憶體及磁碟）。同一個地域，同一個元叢集的業務叢集，一個叢集浪費了資源就會造成其他叢集資源的緊張。

在 ASI 中，元件變化是常態，元件容量如何自適應這種變化也是一個非常大的挑戰。而日常的運維及診斷須要有精準的容量資料來作為備容支撐。

因此我們決定透過資料化指導元件申請合理的（成本低，安全）容器資源。透過資料化提供日常運維所需要的容量相關資料，完成備容，在生產水位異常時，完成應急擴容。

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

目前我們完成了水位監控、全量風險播報、預排程、profile 效能資料定時抓取、進而透過元件規範中推進 CPU 記憶體以及 CPU 記憶體比例最佳化。正在做的包括自動化的規格建議，節點資源補充建議，以及自動化匯入節點，結合 chatops 正在打造釘群“一鍵備容”閉環。另外還在結合全鏈路壓測服務資料，得出各個元件的基線對比，透過風險決策，進行釋出卡點，確保元件上線安全。同時未來會結合線上真實的變更，來持續回答真實環境的 SLO 表現，精準預測容量。

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

# 全域性高可用應急能力建設

高可用基礎能力的建設可以為 ASI 提供強有力的抗風險保障，從而在各種風險隱患出現時，儘可能保證我們服務的可用性。但是在風險出現後，如何快速介入消滅隱患，或者在高可用能力無法覆蓋的故障出現後，進行有序止損，就變成了一個非常具有技術深度和橫向複雜度的工程難題，也讓 ASI 的應急能力建設成為我們非常重要的投入方向。

在建設應急體系之初，我們的系統由於迅速的發展和變化，不斷出現的事故和險情，明顯的暴露出當時我們面臨的幾個嚴重的問題：

- 為什麼客戶總是早於我們發現問題？
- 為什麼恢復需要這麼長的時間？
- 為什麼同樣的問題會重複出現？
- 為什麼只有幾個人能處理線上的問題？

針對這些問題，我們也進行了充分的腦暴和探討，並且總結出以下幾個核心原因：

- 發現問題手段單一：只有 metrics 資料作為最基本暴露問題的手段。
- 定位問題能力缺乏：只有少數監控大盤，核心元件的可觀測能力建設程度沒有統一。
- 恢復手段缺乏體系：線上問題的修復需要臨時敲命令，寫指令碼，效率低且風險大。
- 應急缺少體系規範：缺乏與業務方聯動，工程師思維嚴重，不是以止損為第一目標，對問題嚴重度缺乏意識。
- 長期問題缺乏跟蹤：線上發現的隱患，或者事故覆盤的跟進項，缺乏持續跟進能力，導致重複踩坑。
- 缺乏能力保鮮機制：業務變化非常快速，導致一些能力在一段時間後，進入一個“不會用也不敢用，也不能保證一定能用”的尷尬境地。

## 1. 應急能力建設頂層設計

針對這些亟待解決的問題，我們也做了應急能力的頂層設計，架構圖如下：

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

應急能力建設整體可以分為幾個部分：

- **1-5-10 應急體系**：針對線上出現的任何突發風險，都能做到“一分鐘發現，五分鐘定位，十分鐘恢復”的底層能力和機制。
- **問題追蹤跟進**：針對線上發現的所有風險隱患，無論嚴重與否，都能持續跟蹤推進的能力。
- **能力保鮮機制**：針對建設的 1-5-10 能力，鑑於其使用頻率比較低的本質特性。

## 2. 應急能力建設子模組建設

針對頂層設計中的每個子模組，我們都已經做出了一些階段性的工作和成果。

### **1）一分鐘發現：問題發現能力**

為了解決無法早於客戶發現問題的難題，我們的工作最重要的目標就是要做到：讓一切問題都無處遁形，被系統主動發現。

所以這就像是一場持久戰，我們要做的，就是透過各種可能的手段去覆蓋一個又一個新的問題，攻佔一個又一個城池。

在這個目標的驅使下，我們也總結出一套非常行之有效的“戰略思想”，即**「1+1 思想」**。它的核心觀點在於，任何發現問題的手段，都可能因為對外部的依賴或者自身穩定性的缺陷，導致偶發的失效，所以必須有能夠作為互備的鏈路來進行容錯。

在這個核心思想的指導下，我們團隊建設了兩大核心能力，即黑盒/白盒報警雙通道，這兩個通道的各有各的特點：

- 黑盒通道：基於黑盒思想，從客戶視角把 ASI 整體當做黑盒，直接發出指令，探測正向功能；比如直接擴容一個 statefulset。
- 白盒通道：基於白盒思想，藉助系統內部暴露出來的各種維度的可觀測性資料的異常波動來發現潛在問題；比如 APIServer 的記憶體異常上漲。

黑盒通道對應的具體產品叫做 kubeprobe，是由我們團隊脫胎於社群 kuberhealthy 專案的思想上進行更多的最佳化和改造形成的新產品，並且也成為我們判斷叢集是否出現嚴重風險的重要利器。

白盒通道的建設相對更為複雜，它需要建設在完備的可觀測資料的基礎之上，才能夠真正發揮它的功力。所以為此我們首先從 metrics、日誌、事件 3 個維度分別基於 SLS 建設 3 種資料通道，將所有可觀測資料統一到 SLS 上管理。另外我們也建設了告警中心，負責完成對當前上百套叢集的告警規則的批次管理，下發能力，最終構造了出了一個資料完備，問題覆蓋廣泛的白盒告警系統。最近還在進一步將我們的告警能力向 SLS 告警 2.0 遷移，實現更加豐富的告警功能。

### **2）五分鐘定位：問題根因自動定位能力**

隨著線上問題排查經驗的不斷豐富，我們發現有很多問題會比較頻繁地出現。它們的排查方法和恢復手段基本已經比較固化。即便某個問題背後的原因可能有多種，但是隨著線上排查經驗的豐富，基本都可以慢慢迭代出對這個問題的排查路線圖。如下圖所示，是針對 etcd 叢集不健康的告警設計的排查路線：

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

如果把這些相對比較確認的排查經驗固化到系統中，在問題出現後可以自動觸發形成決策，勢必可以大幅減少我們對線上問題的處理耗時。所以在這個方面，我們也開始了一些相關能力的建設。

從黑盒通道方面，kubeprobe 構建了一套自閉環的根因定位系統，將問題排查的專家經驗下沉進系統中，實現了快速和自動的問題定位功能。透過普通的根因分析樹以及對失敗巡檢探測事件/日誌的機器學習分類演算法（持續開發投入中），為每一個 KubeProbe 的探測失敗 Case 做根因定位，並透過 KubeProbe 內統一實現的問題嚴重性評估系統（目前這裡的規則仍比較簡單），為告警的嚴重性做評估，從而判斷應該如何做後續的處理適宜，比如是否自愈，是否電話告警等等。

![16.png](https://ucc.alicdn.com/pic/developer-ecology/4267fea42060486f95c0cbf112e2055c.png)

從白盒通道方面，我們透過底層的 pipeline 引擎的編排能力，結合已經建設的資料平臺中的多維度資料，實現了一個通用的根因診斷中心，將透過各種可觀測資料從而排查問題根因的過程透過 yaml 編排的方式固化到系統中，形成一個根因診斷任務，並且在觸發任務後形成一個問題的診斷結論。並且每種結論也會繫結對應的恢復手段，比如呼叫預案、自愈等等。

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

兩種通道都透過釘釘機器人等手段實現類似 chatops 的效果，提升 oncall 人員的處理問題速度。

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

![19.png](https://ucc.alicdn.com/pic/developer-ecology/9544b1cd892243b79960d1eba5307ead.png)

### **3）十分鐘恢復：恢復止損能力**

為了能夠提升執行時故障的止損恢復速度，我們也把恢復止損能力的建設放在第一優先順序，這個方面我們的核心準則是兩個：

- 止損能力要系統化，白屏化，可沉澱。
- 一切以止損為目標，而不是以找到絕對的根因為目標。

所以在這兩個準則的驅使下，我們做了兩個方面的工作：

- **建設預案中心**：中心化沉澱我們所有的止損能力到系統中，白屏管理，接入，執行。一方面也可以將以前散落在各個研發手中或者文件中的預案統一收攏中心端統一管理，實現了對預案的中心化管控。另一方面預案中心也開發了支援使用者透過 yaml 編排的方式來錄入預案的能力，從而實現低成本接入。
- 建設通用止損手段集：根據過往歷史經驗，結合 ASI 的特有特性，建設多種通用的止損能力集合，作為應急時的重要抓手。包括了元件原地重啟，元件快速擴容，controller/webhook 快速降級，叢集快速切換隻讀等等常用功能。

### **4）問題持續跟蹤機制 BugFix SLO**

針對缺乏跟進能力的問題，我們提出了 BugFix SLO 機制。正如名字所描述的那樣，我們認為每個發現的問題都是一個要被修復的 “Bug”，並且針對這種 Bug 我們做了一下工作：

- 一方面，定義了一系列分類方法保證問題能夠明確到團隊和具體的一個負責人。
- 一方面，定義解決優先順序，即解決這個問題的 SLO，L1 - L4，不同優先順序代表不同的解決標準，L1 代表必須當天內迅速跟進並且解決。

每兩週，透過過去一段時間收集的新的問題，我們會產出一份穩定性週報，進行問題解決程度的通曬以及重點問題的同步。另外也會在每兩週進行一次全員拉會對齊，對每個新問題的負責人確定，優先順序確認進行對齊。

### **5）能力驗收保鮮機制**

由於穩定性風險是相對低頻發生的，所以對穩定效能力的最好的保鮮手段就是演練，所以在這個基礎之上我們設計或者參與了兩種演練方案，分別是：

- 常態化故障演練機制
- 生產突襲演練機制

![20.png](https://ucc.alicdn.com/pic/developer-ecology/087d6ea927ac4e9cab47c103f7920ef9.png)

#### 【常態化演練機制】
常態化故障演練機制的核心目的在於以更頻繁的頻率對 ASI 系統相關的故障場景以及針對這個故障的恢復能力進行持續驗收，從而既發現某些元件的在穩定性方面的缺陷，也可以驗收各種恢復手段預案的有效性。

所以為了能夠儘可能提升演練頻率，我們：

- 一方面開始建設自身的故障場景庫，將所有場景進行入庫，分類，管理，保證場景的覆蓋面夠全面。
- 另一方面同質量保證團隊合作，充分利用其 chorus 平臺提供的注入故障能力將我們的設計場景逐個落地，並且配置為後臺持續執行。我們還藉助該平臺靈活的外掛豐富能力，將平臺同我們的告警系統，預案系統進行 API 對接，在故障場景被觸發注入後，可以完全透過後臺自動呼叫的模式完整的針對這個場景的注入、檢查、恢復都透過後臺執行完成。

鑑於常態化演練的演練頻率如此之高，我們通常在一個專用的叢集中進行持續的後臺演練場景觸發，以降低因為演練帶來的穩定性風險。

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

#### 【生產突襲演練機制】
常態化故障演練即便做的再頻繁，我們也不能完全保證在生產叢集真的出現同樣的問題，我們是否能夠以同樣的方式進行應對；也沒有辦法真正確認，這個故障的影響範圍是否與我們預期的範圍一致；這些問題最根本的原因還是在於我們在常態化故障演練中的叢集一般是沒有生產流量的測試叢集。

所以在生產環境進行故障模擬才能夠更加真實的反應線上的實況，從而提升我們對恢復手段的正確性的信心。在落地方面，我們透過積極參與到雲原生團隊組織的季度生產突襲活動，將我們一些相對複雜或者比較重要的演練場景實現了在生產環境的二次驗收，與此同時也對我們的發現速度，響應速度也進行了側面評估，不僅發現了一些新的問題，也為我們如何在測試叢集設計更符合線上真實情況的場景帶來了很多參考輸入。

# 寫在最後

本篇僅作為開篇從整體上介紹了 ASI 全域性高可用體系建設上一些探索工作以及背後的思考，後續團隊會針對具體的領域比如 ASI 應急體系建設，ASI 預防體系建設，故障診斷與恢復、全鏈路精細化 SLO 建設和運營、ASI 單叢集規模的效能瓶頸突破上等多個方面進行深入的解讀，敬請期待。

ASI 作為雲原生的引領實施者，它的高可用，它的穩定性影響著甚至決定著阿里集團和雲產品的業務的發展。ASI SRE 團隊長期招人，技術挑戰和機會都在，感興趣的同學歡迎來撩：en.xuze@alibaba-inc.com，hantang.cj@taobao.com。

【深度】阿里巴巴萬級規模 K8s 叢集全域性高可用體系之美

相關文章