作者 | ?韓堂、柘遠(yuǎn)、沉醉
來源 | 阿里巴巴云原生公眾號
?

前言

臺灣作家林清玄在接受記者采訪的時候，如此評價自己 30 多年寫作生涯：“第一個十年我才華橫溢，‘賊光閃現(xiàn)’，令周邊黯然失色；第二個十年，我終于‘寶光現(xiàn)形’，不再去搶風(fēng)頭，反而與身邊的美麗相得益彰；進(jìn)入第三個十年，繁華落盡見真醇，我進(jìn)入了‘醇光初現(xiàn)’的階段，真正體味到了境界之美”。
?
長夜有窮，真水無香。領(lǐng)略過了 K8s“身在江湖”的那種驚心動魄以及它那生態(tài)系統(tǒng)的繁花似錦，該是回過頭來體味高可用體系境界之美的時候了。畢竟僅能經(jīng)得起敲打還是不能獨(dú)步武林的！
?
在 K8s 高可用領(lǐng)域有一個問題被大家所熟知，那就是 K8s 單集群規(guī)模帶來的 SLO 問題，如何持續(xù)保障？今天就以單集群的規(guī)模增長帶來的高可用挑戰(zhàn)來作為引子來給大家一個體感。
?
ASI 單集群規(guī)模支撐超過社區(qū)的 5000 臺，這是個非常有意思且具備極大挑戰(zhàn)的事情，對需要進(jìn)行 K8s 生產(chǎn)化的同學(xué)，甚至具備 K8s 生產(chǎn)化經(jīng)驗(yàn)的同學(xué)來說，一定會是個感興趣的話題。回看 ASI 單集群規(guī)模從 100 到 10000 的發(fā)展之路，伴隨著業(yè)務(wù)的增長和創(chuàng)新帶來的每一次集群規(guī)模增長，都在逐步使我們的壓力和挑戰(zhàn)發(fā)生質(zhì)變。
?

ASI：Alibaba Serverless infrastructure，阿里巴巴針對云原生應(yīng)用設(shè)計的統(tǒng)一基礎(chǔ)設(shè)施，ASI 是阿里公共云服務(wù) ACK 的阿里集團(tuán)企業(yè)版。

大家知道 K8s 社區(qū)只能夠支撐五千個節(jié)點(diǎn)，當(dāng)超過這個規(guī)模時，會出現(xiàn)各種性能瓶頸問題，比如：

• etcd 出現(xiàn)大量的讀寫延遲。
• kube-apiserver 查詢 pods/nodes 延時很高，甚至導(dǎo)致 etcd oom。
• 控制器無法及時感知數(shù)據(jù)變化，如出現(xiàn) watch 數(shù)據(jù)延遲。

以電商場景為例，100 節(jié)點(diǎn)增長到 4 千節(jié)點(diǎn)的時候，我們提前針對 ASI apiserver 的客戶端和服務(wù)端做了大量的性能優(yōu)化，從 apiserver 客戶端的角度優(yōu)先訪問本地 cache，在客戶端去做負(fù)載均衡；apiserver 服務(wù)端主要做了 watch 優(yōu)化和 cache 索引優(yōu)化；在 etcd 內(nèi)核上利用并發(fā)讀提升單 etcd 集群讀處理能力，基于 hashmap 的 freelist 管理新算法提高 etcd 存儲上限，基于 raft learner 技術(shù)來提高多備能力等等。
?
從 4 千節(jié)點(diǎn)增長到 8 千節(jié)點(diǎn)，我們又做了 qps 限流管理和容量管理優(yōu)化、etcd 單資源對象存儲拆分、組件規(guī)范全生命周期落地通過客戶端的規(guī)范約束降低對 apiserver 的壓力和以及穿透到 etcd 的壓力等等。
?
終于迎來 8 千節(jié)點(diǎn)增長到上萬節(jié)點(diǎn)的時刻，我們開始如火如荼地開展 etcdcompact 算法優(yōu)化；etcd 單節(jié)點(diǎn)多 multiboltdb 的架構(gòu)優(yōu)化，apiserver 的服務(wù)端數(shù)據(jù)壓縮，通過組件治理降低 etcd 寫放大等；同時開始打造常態(tài)化的壓測服務(wù)能力，持續(xù)回答 ASI 的 SLO。
?
這些例子在高可用挑戰(zhàn)中司空見慣，列出的能力也只是其中一小部分，你也許很難看到能力之間的關(guān)聯(lián)和底層的演進(jìn)邏輯。當(dāng)然，更多的能力建設(shè)沉淀到了我們的系統(tǒng)和機(jī)制當(dāng)中。本篇文章會作為一個開始，以綜述的形式分享我們在建設(shè) ASI 全局高可用體系中的幾個關(guān)鍵部分，再往后會有針對性地對進(jìn)行技術(shù)點(diǎn)和演進(jìn)路線的詳解。如果大家有什么問題或者希望了解的部分，歡迎在評論區(qū)留言。

ASI 全局高可用概述

高可用是個比較復(fù)雜的命題，任何日常的變化例如服務(wù)升級、硬件更新、數(shù)據(jù)遷移、流量突增等都可能造成服務(wù) SLO 受損，甚至不可用。
?
ASI 作為容器平臺，并非孤立存在，而是與云底層及公共服務(wù)形成完備的生態(tài)系統(tǒng)。要解決 ASI 的高可用問題，需要縱觀全局，找出每層的最優(yōu)解，最終串聯(lián)組成最優(yōu)的整體解決方案。涉及到的層面包括：
?

• 云基礎(chǔ)相關(guān)管理，包括可用區(qū)的選擇，規(guī)劃和硬件資產(chǎn)的管理
• 節(jié)點(diǎn)的管理
• ASI 集群管理
• 公共服務(wù)
• 集群運(yùn)維
• 應(yīng)用研發(fā)

特別是在 ASI 這個場景下，要支撐的業(yè)務(wù)集群數(shù)量龐大，涉及到的研發(fā)運(yùn)維人員眾多，功能發(fā)布頻繁的迭代開發(fā)模式以及業(yè)務(wù)種類繁多帶來的運(yùn)行時的復(fù)雜多變，相比其他容器平臺來看，ASI 高可用面臨更多的挑戰(zhàn)，其難度不言而喻。
?

ASI 全局高可用設(shè)計

如下圖所示，現(xiàn)階段高可用能力建設(shè)整體策略以 1-5-10（故障 1 分種發(fā)現(xiàn)、5 分鐘定位、10 分鐘止損）為目標(biāo)牽引，注重將能力沉淀到系統(tǒng)或機(jī)制中，讓 SRE/Dev 能夠無差別的 oncall。??
?
盡量避免發(fā)生問題、盡快發(fā)現(xiàn)、定位及恢復(fù)問題，是實(shí)現(xiàn)目標(biāo)的關(guān)鍵，為此我們將 ASI 全局高可用體系的實(shí)現(xiàn)分三大部分展開：一是基礎(chǔ)能力建設(shè)；二是應(yīng)急體系建設(shè)；三是通過常態(tài)化壓測以及故障演練等完成上述能力的保鮮和持續(xù)演進(jìn)。?
?

通過 3 個部分的輪轉(zhuǎn)驅(qū)動，實(shí)現(xiàn)一個 ASI 全局高可用體系的構(gòu)建，其頂層是 SLO 體系和 1-5-10 應(yīng)急體系。在應(yīng)急體系和數(shù)據(jù)驅(qū)動的體系背后，我們建設(shè)了大量高可用基礎(chǔ)能力，包括防御體系、高可用架構(gòu)升級、故障自愈體系、以及持續(xù)改進(jìn)機(jī)制。與此同時，我們建立了多個基礎(chǔ)性平臺為高全用體系提供配套能力，如常態(tài)化故障演練平臺、全鏈路仿真壓測平臺、告警平臺、預(yù)案中心等等。
?

全局高可用基礎(chǔ)能力建設(shè)

在建設(shè)全局高可用能力之前，我們的系統(tǒng)在迅速發(fā)展和變化下不斷出現(xiàn)事故和險情，需要隔三差五去應(yīng)急，導(dǎo)致讓問題追身的局面，并且追身后沒高效應(yīng)對的手段，面臨著幾個嚴(yán)峻的挑戰(zhàn)：
?

• 如何在架構(gòu)和能力上去提升我們的可用性，降低系統(tǒng)發(fā)生故障的概率和影響面？
• 如何在核心鏈路性能和架構(gòu)上做一些突破，能夠支撐這么復(fù)雜多變的業(yè)務(wù)場景和業(yè)務(wù)增長的通用需求？
• 如何讓問題不再追身，做好預(yù)防工作，避免應(yīng)急？
• 如何在應(yīng)急發(fā)生時，能夠快速發(fā)現(xiàn)，快速診斷，快速止損？

針對這些問題，并且總結(jié)出以下幾個核心原因：
?

• 可用性能力不足：在集團(tuán)場景下，組件不斷在變化，不斷增加系統(tǒng)的壓力和復(fù)雜度，ASI 在生產(chǎn)可用性的能力上缺失，如限流降級、負(fù)載均衡等，組件容易亂用造成低級錯誤，影響集群可用性。
• 系統(tǒng)風(fēng)控和 pod 保護(hù)能力不足：在人為誤操作或系統(tǒng) bug 時, 容易造成業(yè)務(wù) pod 無辜受損或者大面積受損。
• 容量風(fēng)險：集群數(shù)量幾百，組件接近一百；另外歷史問題因 podCIDR 和節(jié)點(diǎn) IP 數(shù)的配置，大多 ASI 元集群的節(jié)點(diǎn)規(guī)模被約束在 128 臺以內(nèi)，隨著業(yè)務(wù)快速發(fā)展，對容量風(fēng)險而言存在較大挑戰(zhàn)。
• 單集群規(guī)模受限，加上橫向擴(kuò)展能力不足影響業(yè)務(wù)發(fā)展：單集群不斷增長規(guī)模，以及業(yè)務(wù)類型變化，組件變化都對單集群支撐的最大規(guī)模產(chǎn)生影響，對 SLO 持續(xù)穩(wěn)定產(chǎn)生影響。

1. 高可用基礎(chǔ)能力頂層設(shè)計

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

• 性能優(yōu)化和高可用架構(gòu)建設(shè)：主要是從性能優(yōu)化和架構(gòu)升級的角度來提升整個集群支撐的業(yè)務(wù)類型和業(yè)務(wù)量。
• 組件規(guī)范全生命周期管理：主要從規(guī)范的角度在組件的整個生命周期去落地，從出生啟用和集群準(zhǔn)入開始，到每一次變更，到下線整個生命周期都要防止組件亂用、野蠻生長、無限膨脹，控制組件在系統(tǒng)可承受范圍之內(nèi)。
• 攻防體系建設(shè)：主要從 ASI 系統(tǒng)本身觸發(fā)，在從攻擊和防御的角度來提升系統(tǒng)的安全，防御和風(fēng)控能力。

下面針對我們的一些痛點(diǎn)進(jìn)行幾個關(guān)鍵能力建設(shè)的描述。
?

2. K8s 單集群架構(gòu)的痛點(diǎn)

• 對 ApiServer 的掌控能力不夠，應(yīng)急能力不足，我們自己的經(jīng)歷，歷次集群 Master 出現(xiàn)異常的次數(shù)超過 20+，歷次恢復(fù)時間最長超過 1 小時。
• ApiServer 是 APIServer 集群的單點(diǎn)，爆炸半徑大。
• 單集群規(guī)模大， Apiserver 內(nèi)存水位比較高，壓力來源于頻繁的查詢，寫入更多更大的資源對象。
• 在業(yè)務(wù)層缺少跨機(jī)房的容災(zāi)能力，當(dāng) ASI 不可用的時候，只能依賴 ASI 的恢復(fù)能力。
• 集群規(guī)模的持續(xù)擴(kuò)大，離線任務(wù)的大量創(chuàng)建和刪除對集群的造成更大壓力。

這里面從兩個大的角度可以去提高集群架構(gòu)的可用性，除了在單集群進(jìn)行架構(gòu)優(yōu)化以及性能突破外，還要通過多集群這樣的橫向擴(kuò)展能力去支撐更大的規(guī)模。
?

• 一是通過聯(lián)邦這樣的多集群能力來解決單集群的橫向擴(kuò)展能力以及單地域跨集群容災(zāi)能力。
• 另外一個單集群本身的架構(gòu)還可以從隔離和優(yōu)先級策略的架構(gòu)角度來進(jìn)行差異化 SLO 保障。

3. ASI 架構(gòu)升級落地

1）APIServer 多路架構(gòu)升級

核心方案就是通過對 apiserver 進(jìn)行分組，通過不同的優(yōu)先級策略進(jìn)行對待，從而對服務(wù)進(jìn)行差異化 SLO 保障。
?

• 通過分流以降低主鏈路 apiserver 壓力（核心訴求）
  • P2 及以下組件接入旁路 apiserver，并可以在緊急情況（如自身穩(wěn)定性收到影響）下，做整體限流。
• 旁路 apiserver 配合主鏈路做藍(lán)綠、灰度（次級訴求）
  • 旁路 apiserver 可以使用獨(dú)立版本，增加新功能灰度維度，如使用獨(dú)立的限流策略，如開啟新的 feature 功能驗(yàn)證。
• SLB 災(zāi)備（次級訴求）
  • 旁路 apiserver 可以在主 apiserver 發(fā)生異常時，對外提供服務(wù)（需 controller 自行切換目標(biāo)地址）。

2）ASI 多集群聯(lián)邦架構(gòu)升級

目前張北中心的一個機(jī)房就幾萬節(jié)點(diǎn)，如果不解決多集群的管理問題，帶來的問題如下：
?

• 容災(zāi)層面：把核心交易應(yīng)用的中心單元部署在一個集群的風(fēng)險是很大的，最壞情況下集群不可用導(dǎo)致整個應(yīng)用服務(wù)不可用。

• 性能層面：對于業(yè)務(wù)來說，如因核心應(yīng)用在某一時點(diǎn)使用時極其敏感而設(shè)定各種單機(jī)最大限制、CPU 互斥獨(dú)占保證，如果都部署在一個集群的話，會因?yàn)榧汗?jié)點(diǎn)規(guī)模限制，導(dǎo)致應(yīng)用發(fā)生堆疊，造成 cpu 熱點(diǎn)，性能不滿足要求；對于 ASI 管控 Master 來說，單集群無限制擴(kuò)大，性能總會出現(xiàn)瓶頸，總有一天會無法支撐。

• 運(yùn)維層面：當(dāng)某個應(yīng)用擴(kuò)容發(fā)現(xiàn)沒資源，SRE 還得考慮節(jié)點(diǎn)加到哪個集群，額外加大了 SRE 集群管理的工作。

因此 ASI 需要達(dá)成統(tǒng)一的多集群管理解決方案，幫助上層各個 Pass、SRE、應(yīng)用研發(fā)等提供更好的多集群管理能力，通過它來屏蔽多集群的差異、方便的進(jìn)行多方資源共享。
?
ASI 選擇基于社區(qū)聯(lián)邦 v2 版本來開發(fā)滿足我們的需求。
?

4. K8s 集群遭遇規(guī)模增長帶來的極大性能挑戰(zhàn)

在一個大規(guī)模的 K8s 集群中性能會遇到哪些問題呢？
?

• 首先是查詢相關(guān)問題。在大集群中最重要的就是如何最大程度地減少 expensive request。對百萬級別的對象數(shù)量來說，按標(biāo)簽、namespace 查詢 Pod，獲取所有 Node 等場景時，很容易造成 etcd 和 kube-apiserver OOM 和丟包，乃至雪崩等問題發(fā)生。

• 其次是寫入相關(guān)問題。etcd 適用場景是讀多寫少，大量寫請求可能會導(dǎo)致 db size 持續(xù)增長、寫性能達(dá)到瓶頸被限速、影響讀性能。如大量的離線作業(yè)需要頻繁的創(chuàng)建和刪除 pod，通過 ASI 鏈路對 pod 對象的寫放大，最終對 etcd 的寫壓力會放大幾十倍之大。

• 最后是大資源對象相關(guān)問題。etcd 適合存儲較小的 key-value 數(shù)據(jù)，在大 value 下，性能急速下降。

5. ASI 性能瓶頸突破

ASI 性能優(yōu)化的方向

ASI 的性能優(yōu)化可以從 apiserver 客戶端、apiserver 服務(wù)端、etcd 存儲 3 個方面來進(jìn)行優(yōu)化。
?

• 客戶端側(cè)，可以做 cache 優(yōu)化，讓各個 client 優(yōu)先訪問本地 informer cache，也需要做負(fù)載均衡優(yōu)化，主要包括對 apiserver,etcd 的負(fù)載均衡。同時針對客戶端的各種優(yōu)化，可以通過組件性能規(guī)范，在組件啟用，準(zhǔn)入的時候進(jìn)行校驗(yàn)是否滿足。
• APIServer 側(cè)，可以從訪問層，緩存層，存儲層 3 個層次進(jìn)行優(yōu)化。在緩存層，我們重點(diǎn)建設(shè)了 cache 的索引優(yōu)化以及 watch 優(yōu)化，在存儲層上重點(diǎn)通過 snappy 壓縮算法對 pod 進(jìn)行數(shù)據(jù)壓縮，在訪問層上重點(diǎn)建設(shè)了限流能力。

• etcd 存儲側(cè)的優(yōu)化，我們也從幾個方面做了很多工作，包括 etcd 內(nèi)核層面各種算法優(yōu)化工作，還有通過將不同資源拆分到不同 etcd 集群的能力實(shí)現(xiàn)了基本的水平拆分能力，同時也在 etcd server 層做 multi boltdb 的擴(kuò)展能力提升。

6. K8s 集群的預(yù)防能力薄弱

在 K8s 中，kube-apiserver 作為統(tǒng)一入口，所有的控制器/client 都圍繞 kube-apiserver 在工作，盡管我們 SRE 通過組件的全生命周期進(jìn)行規(guī)范約束卡點(diǎn)改進(jìn)，比如通過在組件的啟用和集群準(zhǔn)入階段進(jìn)行了卡點(diǎn)審批，通過各個組件 owner 的全面配合改造后，大量的低級錯誤得到防范，但還是有部分控制器或部分行為并不可控。
?
除了基礎(chǔ)設(shè)施層面的故障外，業(yè)務(wù)流量的變化，是造成 K8s 非常不穩(wěn)定的因素，突發(fā)的 pod 創(chuàng)建和刪除，如果不加以限制，很容易把 apiserver 打掛。
?
另外非法的操作或代碼 Bug 有可能造成業(yè)務(wù) pod 影響，如不合法的 pod 刪除。
?
結(jié)合所有風(fēng)險進(jìn)行分層設(shè)計，逐層進(jìn)行風(fēng)險防控。
?

7. ASI 單集群的預(yù)防能力加強(qiáng)

1）支持 API 訪問層的多維度（resource/verb/client）精細(xì)化限流

社區(qū)早期采用的限流方式主要通過 inflight 控制讀寫總體并發(fā)量，我們當(dāng)時在 apf 沒有出來之前就意識到限流能力的不足，沒有能力去對請求來源做限流。而 apf 通過 User 來做限流（或者說要先經(jīng)過 authn filter）存在一些不足，一方面因?yàn)锳uthn 并不是廉價的，另外一方面它只是將 API Server 的能力按配置來做分配，并不是一種限流方案和應(yīng)急預(yù)案。我們需要緊急提供一種限流能力，以應(yīng)對緊急情況，自研了 ua limiter 限流能力，并基于 ua limiter 簡單的配置方式實(shí)現(xiàn)了一套限流管理能力，能夠很方便在幾百個集群當(dāng)中進(jìn)行默認(rèn)限流管理，以及完成應(yīng)急限流預(yù)案。
?
下面是我們自研的 ua limiter 限流方案和其他限流方案的詳細(xì)對比：
?

ua limiter、APF、sentinel 在限流上的側(cè)重點(diǎn)是不一樣的：
?

• ua limiter 是根據(jù) ua 提供一個簡單的 QPS hard limit。
• apf 更加側(cè)重于并發(fā)度的控制，考慮的是流量的隔離和隔離后的公平性。
• sentinel 功能全面，但是對于公平性的支持并沒有 APF 全面，同時復(fù)雜度有一些過高。

考慮我們現(xiàn)階段的需求和場景，發(fā)現(xiàn) ua limiter 落地最為合適，因?yàn)槲覀兺ㄟ^ user agent 的不同，來對于組件進(jìn)行限流。當(dāng)然后續(xù)進(jìn)行更加精細(xì)的限流，還是可以考慮結(jié)合使用 APF 等方案進(jìn)一步加強(qiáng)。
?
限流策略如何管理，數(shù)百套集群，每套集群規(guī)模都不太一樣，集群節(jié)點(diǎn)數(shù)、pod 數(shù)都是不同的，內(nèi)部組件有近百個，每個組件請求的資源平均有 4 種，對不同資源又有平均 3 個不同的動作，如果每個都做限流，那么規(guī)則將會爆炸式增長，即便做收斂后維護(hù)成本也非常的高。因此我們抓最核心的：核心資源 pod\node、核心動作（創(chuàng)建、刪除、大查詢）；最大規(guī)模的：daemonset 組件、PV/PVC 資源。并結(jié)合線上實(shí)際流量分析，梳理出二十條左右的通用限流策略，并將其納入到集群交付流程中實(shí)現(xiàn)閉環(huán)。
?
當(dāng)新的組件接入，我們也會對其做限流設(shè)計，如果比較特殊的，則綁定規(guī)則并在集群準(zhǔn)入和部署環(huán)節(jié)自動下發(fā)策略，如果出現(xiàn)大量的限流情況，也會觸發(fā)報警，由 SRE 和研發(fā)去跟進(jìn)優(yōu)化和解決。
?

2）支持業(yè)務(wù) POD 級別的精細(xì)化限流

所有 pod 相關(guān)的操作都會對接 Kube Defender 統(tǒng)一風(fēng)控中心，進(jìn)行秒級別、分鐘級、小時級、天級別的流控。該全局風(fēng)控限流組件，實(shí)行中心端部署，維護(hù)各場景下的接口調(diào)用限流功能。
?
defender 是站在整個 K8s 集群的視角，針對用戶發(fā)起的或者系統(tǒng)自動發(fā)起的有風(fēng)險的操作進(jìn)行防護(hù)（流控、熔斷、校驗(yàn)）和審計的風(fēng)控系統(tǒng)。之所以做 defender，主要從以下幾個方面考慮：
?

• 類似 kubelet/controller 這樣的組件，在一個集群中存在多個進(jìn)程，任一單一進(jìn)程都無法看到全局的視圖，無法進(jìn)行準(zhǔn)確的限流。
• 從運(yùn)維視角，分散在各個組件中的限速規(guī)則難以配置與審計，當(dāng)部分操作因?yàn)橄蘖髟蚴r，排查鏈路過長影響問題定位的效率。
• K8s 面向終態(tài)的分布式設(shè)計，每個組件都有決策的能力，那么就需要一個集中的服務(wù)對那些危險決策進(jìn)行風(fēng)控。

defender 的框架圖如下所示：

• defender server 是 K8s 集群級的服務(wù)，可以部署多個，其中一個 active，其余 standby。
• 用戶可以通過kubectl配置風(fēng)控規(guī)則。
• K8s 中的組件，例如 controller，kubelet，extension-controller 等，都可以通過 defender sdk 接入 defender（改動很小），在進(jìn)行危險操作前請求 defender 進(jìn)行風(fēng)控，根據(jù)風(fēng)控結(jié)果決定是否繼續(xù)該危險操作。defender 作為一個集群級的風(fēng)控防護(hù)中心，為 K8s 集群的整體穩(wěn)定性進(jìn)行保駕護(hù)航。

3）數(shù)字化容量治理

在只有幾個 core 集群的場景下，依靠專家經(jīng)驗(yàn)管理容量完全可以輕松搞定，但隨著容器業(yè)務(wù)的快速發(fā)展，覆蓋泛交易、中間件、新生態(tài)、新計算以及售賣區(qū)等業(yè)務(wù)在接入 ASI，短短幾年時間就發(fā)展了幾百個集群，再發(fā)展幾年數(shù)以千計萬計？如此多的集群依靠傳統(tǒng)的人肉資源管理方式難以勝任，人力成本越來越高，特別是面臨諸如以下問題，極易造成資源使用率低下，機(jī)器資源的嚴(yán)重浪費(fèi)，最終造成部分集群容量不足導(dǎo)致線上風(fēng)險。
?

• 組件變更不斷，業(yè)務(wù)類型和壓力也在變化，線上真實(shí)容量（到底能扛多少 qps）大家都不得而知，當(dāng)業(yè)務(wù)需要增大流量時是否需要擴(kuò)容？是否橫向擴(kuò)容也無法解決問題？
• 早期申請容器資源隨意，造成資源成本浪費(fèi)嚴(yán)重，需要基于容器成本耗費(fèi)最小化明確指導(dǎo)應(yīng)該合理申請多少資源（包括 cpu，內(nèi)存及磁盤）。同一個地域，同一個元集群的業(yè)務(wù)集群，一個集群浪費(fèi)了資源就會造成其他集群資源的緊張。

在 ASI 中，組件變化是常態(tài)，組件容量如何自適應(yīng)這種變化也是一個非常大的挑戰(zhàn)。而日常的運(yùn)維及診斷須要有精準(zhǔn)的容量數(shù)據(jù)來作為備容支撐。
?
因此我們決定通過數(shù)據(jù)化指導(dǎo)組件申請合理的（成本低，安全）容器資源。通過數(shù)據(jù)化提供日常運(yùn)維所需要的容量相關(guān)數(shù)據(jù)，完成備容，在生產(chǎn)水位異常時，完成應(yīng)急擴(kuò)容。
?

目前我們完成了水位監(jiān)控、全量風(fēng)險播報、預(yù)調(diào)度、profile 性能數(shù)據(jù)定時抓取、進(jìn)而通過組件規(guī)范中推進(jìn) CPU 內(nèi)存以及 CPU 內(nèi)存比例優(yōu)化。正在做的包括自動化的規(guī)格建議，節(jié)點(diǎn)資源補(bǔ)充建議，以及自動化導(dǎo)入節(jié)點(diǎn)，結(jié)合 chatops 正在打造釘群“一鍵備容”閉環(huán)。另外還在結(jié)合全鏈路壓測服務(wù)數(shù)據(jù)，得出各個組件的基線對比，通過風(fēng)險決策，進(jìn)行發(fā)布卡點(diǎn)，確保組件上線安全。同時未來會結(jié)合線上真實(shí)的變更，來持續(xù)回答真實(shí)環(huán)境的 SLO 表現(xiàn)，精準(zhǔn)預(yù)測容量。
?

全局高可用應(yīng)急能力建設(shè)

高可用基礎(chǔ)能力的建設(shè)可以為 ASI 提供強(qiáng)有力的抗風(fēng)險保障，從而在各種風(fēng)險隱患出現(xiàn)時，盡可能保證我們服務(wù)的可用性。但是在風(fēng)險出現(xiàn)后，如何快速介入消滅隱患，或者在高可用能力無法覆蓋的故障出現(xiàn)后，進(jìn)行有序止損，就變成了一個非常具有技術(shù)深度和橫向復(fù)雜度的工程難題，也讓 ASI 的應(yīng)急能力建設(shè)成為我們非常重要的投入方向。
?
在建設(shè)應(yīng)急體系之初，我們的系統(tǒng)由于迅速的發(fā)展和變化，不斷出現(xiàn)的事故和險情，明顯的暴露出當(dāng)時我們面臨的幾個嚴(yán)重的問題：
?

• 為什么客戶總是早于我們發(fā)現(xiàn)問題？
• 為什么恢復(fù)需要這么長的時間？
• 為什么同樣的問題會重復(fù)出現(xiàn)？
• 為什么只有幾個人能處理線上的問題？

針對這些問題，我們也進(jìn)行了充分的腦暴和探討，并且總結(jié)出以下幾個核心原因：
?

• 發(fā)現(xiàn)問題手段單一：只有 metrics 數(shù)據(jù)作為最基本暴露問題的手段。
• 定位問題能力缺乏：只有少數(shù)監(jiān)控大盤，核心組件的可觀測能力建設(shè)程度沒有統(tǒng)一。
• 恢復(fù)手段缺乏體系：線上問題的修復(fù)需要臨時敲命令，寫腳本，效率低且風(fēng)險大。
• 應(yīng)急缺少體系規(guī)范：缺乏與業(yè)務(wù)方聯(lián)動，工程師思維嚴(yán)重，不是以止損為第一目標(biāo)，對問題嚴(yán)重度缺乏意識。
• 長期問題缺乏跟蹤：線上發(fā)現(xiàn)的隱患，或者事故復(fù)盤的跟進(jìn)項(xiàng)，缺乏持續(xù)跟進(jìn)能力，導(dǎo)致重復(fù)踩坑。
• 缺乏能力保鮮機(jī)制：業(yè)務(wù)變化非常快速，導(dǎo)致一些能力在一段時間后，進(jìn)入一個“不會用也不敢用，也不能保證一定能用”的尷尬境地。

1. 應(yīng)急能力建設(shè)頂層設(shè)計

針對這些亟待解決的問題，我們也做了應(yīng)急能力的頂層設(shè)計，架構(gòu)圖如下：
?

應(yīng)急能力建設(shè)整體可以分為幾個部分：
?

• 1-5-10 應(yīng)急體系：針對線上出現(xiàn)的任何突發(fā)風(fēng)險，都能做到“一分鐘發(fā)現(xiàn)，五分鐘定位，十分鐘恢復(fù)”的底層能力和機(jī)制。
• 問題追蹤跟進(jìn)：針對線上發(fā)現(xiàn)的所有風(fēng)險隱患，無論嚴(yán)重與否，都能持續(xù)跟蹤推進(jìn)的能力。
• 能力保鮮機(jī)制：針對建設(shè)的 1-5-10 能力，鑒于其使用頻率比較低的本質(zhì)特性。

2. 應(yīng)急能力建設(shè)子模塊建設(shè)

針對頂層設(shè)計中的每個子模塊，我們都已經(jīng)做出了一些階段性的工作和成果。
?

1）一分鐘發(fā)現(xiàn)：問題發(fā)現(xiàn)能力

為了解決無法早于客戶發(fā)現(xiàn)問題的難題，我們的工作最重要的目標(biāo)就是要做到：讓一切問題都無處遁形，被系統(tǒng)主動發(fā)現(xiàn)。
?
所以這就像是一場持久戰(zhàn)，我們要做的，就是通過各種可能的手段去覆蓋一個又一個新的問題，攻占一個又一個城池。
?
在這個目標(biāo)的驅(qū)使下，我們也總結(jié)出一套非常行之有效的“戰(zhàn)略思想”，即**「1+1 思想」**。它的核心觀點(diǎn)在于，任何發(fā)現(xiàn)問題的手段，都可能因?yàn)閷ν獠康囊蕾嚮蛘咦陨矸€(wěn)定性的缺陷，導(dǎo)致偶發(fā)的失效，所以必須有能夠作為互備的鏈路來進(jìn)行容錯。
?
在這個核心思想的指導(dǎo)下，我們團(tuán)隊建設(shè)了兩大核心能力，即黑盒/白盒報警雙通道，這兩個通道的各有各的特點(diǎn)：
?

• 黑盒通道：基于黑盒思想，從客戶視角把 ASI 整體當(dāng)做黑盒，直接發(fā)出指令，探測正向功能；比如直接擴(kuò)容一個 statefulset。
• 白盒通道：基于白盒思想，借助系統(tǒng)內(nèi)部暴露出來的各種維度的可觀測性數(shù)據(jù)的異常波動來發(fā)現(xiàn)潛在問題；比如 APIServer 的內(nèi)存異常上漲。

黑盒通道對應(yīng)的具體產(chǎn)品叫做 kubeprobe，是由我們團(tuán)隊脫胎于社區(qū) kuberhealthy 項(xiàng)目的思想上進(jìn)行更多的優(yōu)化和改造形成的新產(chǎn)品，并且也成為我們判斷集群是否出現(xiàn)嚴(yán)重風(fēng)險的重要利器。
?
白盒通道的建設(shè)相對更為復(fù)雜，它需要建設(shè)在完備的可觀測數(shù)據(jù)的基礎(chǔ)之上，才能夠真正發(fā)揮它的功力。所以為此我們首先從 metrics、日志、事件 3 個維度分別基于 SLS 建設(shè) 3 種數(shù)據(jù)通道，將所有可觀測數(shù)據(jù)統(tǒng)一到 SLS 上管理。另外我們也建設(shè)了告警中心，負(fù)責(zé)完成對當(dāng)前上百套集群的告警規(guī)則的批量管理，下發(fā)能力，最終構(gòu)造了出了一個數(shù)據(jù)完備，問題覆蓋廣泛的白盒告警系統(tǒng)。最近還在進(jìn)一步將我們的告警能力向 SLS 告警 2.0 遷移，實(shí)現(xiàn)更加豐富的告警功能。
?

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

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

如果把這些相對比較確認(rèn)的排查經(jīng)驗(yàn)固化到系統(tǒng)中，在問題出現(xiàn)后可以自動觸發(fā)形成決策，勢必可以大幅減少我們對線上問題的處理耗時。所以在這個方面，我們也開始了一些相關(guān)能力的建設(shè)。
?
從黑盒通道方面，kubeprobe 構(gòu)建了一套自閉環(huán)的根因定位系統(tǒng)，將問題排查的專家經(jīng)驗(yàn)下沉進(jìn)系統(tǒng)中，實(shí)現(xiàn)了快速和自動的問題定位功能。通過普通的根因分析樹以及對失敗巡檢探測事件/日志的機(jī)器學(xué)習(xí)分類算法（持續(xù)開發(fā)投入中），為每一個 KubeProbe 的探測失敗 Case 做根因定位，并通過 KubeProbe 內(nèi)統(tǒng)一實(shí)現(xiàn)的問題嚴(yán)重性評估系統(tǒng)（目前這里的規(guī)則仍比較簡單），為告警的嚴(yán)重性做評估，從而判斷應(yīng)該如何做后續(xù)的處理適宜，比如是否自愈，是否電話告警等等。
?

從白盒通道方面，我們通過底層的 pipeline 引擎的編排能力，結(jié)合已經(jīng)建設(shè)的數(shù)據(jù)平臺中的多維度數(shù)據(jù)，實(shí)現(xiàn)了一個通用的根因診斷中心，將通過各種可觀測數(shù)據(jù)從而排查問題根因的過程通過 yaml 編排的方式固化到系統(tǒng)中，形成一個根因診斷任務(wù)，并且在觸發(fā)任務(wù)后形成一個問題的診斷結(jié)論。并且每種結(jié)論也會綁定對應(yīng)的恢復(fù)手段，比如調(diào)用預(yù)案、自愈等等。
?

兩種通道都通過釘釘機(jī)器人等手段實(shí)現(xiàn)類似 chatops 的效果，提升 oncall 人員的處理問題速度。
?

3）十分鐘恢復(fù)：恢復(fù)止損能力

為了能夠提升運(yùn)行時故障的止損恢復(fù)速度，我們也把恢復(fù)止損能力的建設(shè)放在第一優(yōu)先級，這個方面我們的核心準(zhǔn)則是兩個：
?

• 止損能力要系統(tǒng)化，白屏化，可沉淀。
• 一切以止損為目標(biāo)，而不是以找到絕對的根因?yàn)槟繕?biāo)。

所以在這兩個準(zhǔn)則的驅(qū)使下，我們做了兩個方面的工作：
?

• 建設(shè)預(yù)案中心：中心化沉淀我們所有的止損能力到系統(tǒng)中，白屏管理，接入，運(yùn)行。一方面也可以將以前散落在各個研發(fā)手中或者文檔中的預(yù)案統(tǒng)一收攏中心端統(tǒng)一管理，實(shí)現(xiàn)了對預(yù)案的中心化管控。另一方面預(yù)案中心也開發(fā)了支持用戶通過 yaml 編排的方式來錄入預(yù)案的能力，從而實(shí)現(xiàn)低成本接入。
• 建設(shè)通用止損手段集：根據(jù)過往歷史經(jīng)驗(yàn)，結(jié)合 ASI 的特有特性，建設(shè)多種通用的止損能力集合，作為應(yīng)急時的重要抓手。包括了組件原地重啟，組件快速擴(kuò)容，controller/webhook 快速降級，集群快速切換只讀等等常用功能。

4）問題持續(xù)跟蹤機(jī)制 BugFix SLO

針對缺乏跟進(jìn)能力的問題，我們提出了 BugFix SLO 機(jī)制。正如名字所描述的那樣，我們認(rèn)為每個發(fā)現(xiàn)的問題都是一個要被修復(fù)的 “Bug”，并且針對這種 Bug 我們做了一下工作：
?

• 一方面，定義了一系列分類方法保證問題能夠明確到團(tuán)隊和具體的一個負(fù)責(zé)人。
• 一方面，定義解決優(yōu)先級，即解決這個問題的 SLO，L1 - L4，不同優(yōu)先級代表不同的解決標(biāo)準(zhǔn)，L1 代表必須當(dāng)天內(nèi)迅速跟進(jìn)并且解決。

每兩周，通過過去一段時間收集的新的問題，我們會產(chǎn)出一份穩(wěn)定性周報，進(jìn)行問題解決程度的通曬以及重點(diǎn)問題的同步。另外也會在每兩周進(jìn)行一次全員拉會對齊，對每個新問題的負(fù)責(zé)人確定，優(yōu)先級確認(rèn)進(jìn)行對齊。
?

5）能力驗(yàn)收保鮮機(jī)制

由于穩(wěn)定性風(fēng)險是相對低頻發(fā)生的，所以對穩(wěn)定性能力的最好的保鮮手段就是演練，所以在這個基礎(chǔ)之上我們設(shè)計或者參與了兩種演練方案，分別是：
?

• 常態(tài)化故障演練機(jī)制
• 生產(chǎn)突襲演練機(jī)制

【常態(tài)化演練機(jī)制】

常態(tài)化故障演練機(jī)制的核心目的在于以更頻繁的頻率對 ASI 系統(tǒng)相關(guān)的故障場景以及針對這個故障的恢復(fù)能力進(jìn)行持續(xù)驗(yàn)收，從而既發(fā)現(xiàn)某些組件的在穩(wěn)定性方面的缺陷，也可以驗(yàn)收各種恢復(fù)手段預(yù)案的有效性。
?
所以為了能夠盡可能提升演練頻率，我們：
?

• 一方面開始建設(shè)自身的故障場景庫，將所有場景進(jìn)行入庫，分類，管理，保證場景的覆蓋面夠全面。
• 另一方面同質(zhì)量保證團(tuán)隊合作，充分利用其 chorus 平臺提供的注入故障能力將我們的設(shè)計場景逐個落地，并且配置為后臺持續(xù)運(yùn)行。我們還借助該平臺靈活的插件豐富能力，將平臺同我們的告警系統(tǒng)，預(yù)案系統(tǒng)進(jìn)行 API 對接，在故障場景被觸發(fā)注入后，可以完全通過后臺自動調(diào)用的模式完整的針對這個場景的注入、檢查、恢復(fù)都通過后臺運(yùn)行完成。

鑒于常態(tài)化演練的演練頻率如此之高，我們通常在一個專用的集群中進(jìn)行持續(xù)的后臺演練場景觸發(fā)，以降低因?yàn)檠菥殠淼姆€(wěn)定性風(fēng)險。

【生產(chǎn)突襲演練機(jī)制】

常態(tài)化故障演練即便做的再頻繁，我們也不能完全保證在生產(chǎn)集群真的出現(xiàn)同樣的問題，我們是否能夠以同樣的方式進(jìn)行應(yīng)對；也沒有辦法真正確認(rèn)，這個故障的影響范圍是否與我們預(yù)期的范圍一致；這些問題最根本的原因還是在于我們在常態(tài)化故障演練中的集群一般是沒有生產(chǎn)流量的測試集群。
?
所以在生產(chǎn)環(huán)境進(jìn)行故障模擬才能夠更加真實(shí)的反應(yīng)線上的實(shí)況，從而提升我們對恢復(fù)手段的正確性的信心。在落地方面，我們通過積極參與到云原生團(tuán)隊組織的季度生產(chǎn)突襲活動，將我們一些相對復(fù)雜或者比較重要的演練場景實(shí)現(xiàn)了在生產(chǎn)環(huán)境的二次驗(yàn)收，與此同時也對我們的發(fā)現(xiàn)速度，響應(yīng)速度也進(jìn)行了側(cè)面評估，不僅發(fā)現(xiàn)了一些新的問題，也為我們?nèi)绾卧跍y試集群設(shè)計更符合線上真實(shí)情況的場景帶來了很多參考輸入。

寫在最后

本篇僅作為開篇從整體上介紹了 ASI 全局高可用體系建設(shè)上一些探索工作以及背后的思考，后續(xù)團(tuán)隊會針對具體的領(lǐng)域比如 ASI 應(yīng)急體系建設(shè)，ASI 預(yù)防體系建設(shè)，故障診斷與恢復(fù)、全鏈路精細(xì)化 SLO 建設(shè)和運(yùn)營、ASI 單集群規(guī)模的性能瓶頸突破上等多個方面進(jìn)行深入的解讀，敬請期待。
?
ASI 作為云原生的引領(lǐng)實(shí)施者，它的高可用，它的穩(wěn)定性影響著甚至決定著阿里集團(tuán)和云產(chǎn)品的業(yè)務(wù)的發(fā)展。ASI SRE 團(tuán)隊長期招人，技術(shù)挑戰(zhàn)和機(jī)會都在，感興趣的同學(xué)歡迎來撩：en.xuze@alibaba-inc.com，hantang.cj@taobao.com。
?

數(shù)字時代，如何更好地利用云的能力？什么是新型、便捷的開發(fā)模式？如何讓開發(fā)者更高效地構(gòu)建應(yīng)用？科技賦能社會，技術(shù)推動變革，拓展開發(fā)者的能量邊界，一切，因云而不同。點(diǎn)擊立即報名活動，2021 阿里云開發(fā)者大會將會帶給你答案。

總結(jié)

以上是生活随笔為你收集整理的【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。