作者 | 彭南光（光南）
來(lái)源 | 阿里巴巴云原生公眾號(hào)

千里之堤，潰于蟻穴。

緒論

不知道大家是否經(jīng)歷過(guò)這樣的情景：突然被用戶告知系統(tǒng)出現(xiàn)問(wèn)題，然后一臉懵地惶惶然排查修復(fù)；或是等到自己發(fā)現(xiàn)系統(tǒng)出現(xiàn)故障時(shí)，實(shí)際已經(jīng)對(duì)用戶造成了嚴(yán)重的惡劣影響。

所謂千里之堤，潰于蟻穴。用戶信任的建立是長(zhǎng)期而艱難的，然而要摧毀這種信任卻很簡(jiǎn)單。一旦出現(xiàn)上述問(wèn)題，不僅極大影響用戶使用體驗(yàn)，同時(shí)會(huì)給用戶留下一個(gè)這個(gè)產(chǎn)品/團(tuán)隊(duì)不可靠的印象，喪失用戶對(duì)產(chǎn)品/團(tuán)隊(duì)長(zhǎng)期好不容易積累下來(lái)的信用資本，未來(lái)再想建立這樣的信任關(guān)系就很難了。

這也是為什么我們說(shuō)快速發(fā)現(xiàn)問(wèn)題的能力如此重要的原因，只有先做到快速發(fā)現(xiàn)問(wèn)題，才能談怎樣排查問(wèn)題、如何解決問(wèn)題。

那么怎樣才能在復(fù)雜的大規(guī)模場(chǎng)景中，做到真正先于用戶發(fā)現(xiàn)問(wèn)題呢？下面我會(huì)帶來(lái)我們?cè)诠芾泶笠?guī)模 ASI 集群過(guò)程中對(duì)于快速發(fā)現(xiàn)問(wèn)題的一些經(jīng)驗(yàn)和實(shí)踐，希望能對(duì)大家有所啟發(fā)。

注：ASI 是 Alibaba Serverless infrastructure 的縮寫(xiě)，是阿里巴巴針對(duì)云原生應(yīng)用設(shè)計(jì)的統(tǒng)一基礎(chǔ)設(shè)施。有興趣可以閱讀：《揭開(kāi)阿里巴巴復(fù)雜任務(wù)資源混合調(diào)度技術(shù)面紗》。

背景

1. 復(fù)雜的場(chǎng)景和曾面臨的困境

我們所管理的大規(guī)模 ASI 集群場(chǎng)景非常復(fù)雜，這為我們的工作帶來(lái)了極大挑戰(zhàn)，任何一個(gè)場(chǎng)景處理不慎就有可能導(dǎo)致意料之外的傷害擴(kuò)大化。

• 從組件維度看，我們目前有幾百個(gè)組件，每年有幾萬(wàn)次的組件變更。頻繁的組件變更如何在穩(wěn)定性和效率之間取得權(quán)衡，怎樣讓變更時(shí)更穩(wěn)定，怎樣讓灰度更確信，從而降低爆炸半徑？

• 從集群維度看，目前有上千個(gè)集群和海量節(jié)點(diǎn)，碰到的集群/節(jié)點(diǎn)問(wèn)題較多，監(jiān)控鏈路覆蓋比較繁復(fù)，怎樣讓集群運(yùn)行時(shí)更加可信?

• 從二方用戶和業(yè)務(wù)場(chǎng)景看，我們支持了大量的集團(tuán)二方用戶，同時(shí)業(yè)務(wù)場(chǎng)景也非常復(fù)雜，怎樣保證各有特色的業(yè)務(wù)場(chǎng)景都能得到一致的細(xì)心關(guān)照?

2. 問(wèn)題預(yù)判和解決思路

基于長(zhǎng)期的集群管理經(jīng)驗(yàn)，我們有如下預(yù)設(shè)：

數(shù)據(jù)監(jiān)控作為正向鏈路，無(wú)法無(wú)死角覆蓋所有場(chǎng)景。即使鏈路中各個(gè)節(jié)點(diǎn)的監(jiān)控?cái)?shù)據(jù)正常，也不能 100% 保證鏈路可用。

• 集群狀態(tài)每時(shí)每刻都在變化，各個(gè)組件也在不停地更新升級(jí)，同時(shí)鏈路上的每個(gè)系統(tǒng)也在不停的變更，監(jiān)控?cái)?shù)據(jù)的覆蓋永遠(yuǎn)是正向的追趕，只能逼近 100% 全覆蓋而無(wú)法完全達(dá)到。
• 即使整個(gè)集群鏈路中所有組件/節(jié)點(diǎn)的監(jiān)控?cái)?shù)據(jù)都正常，也不能保證集群鏈路 100% 可用。就如同業(yè)務(wù)系統(tǒng)一樣，看上去都是可用的，沒(méi)有問(wèn)題暴露。但只有通過(guò)全鏈路壓測(cè)實(shí)際探測(cè)過(guò)整個(gè)鏈路后，才能得到實(shí)際可用的結(jié)論。
• 你要正向證明一個(gè)東西可用，需要舉證無(wú)數(shù)的例子。而如果要反向證明不可用，一個(gè)反例就夠了。數(shù)據(jù)監(jiān)控鏈路只能逼近全覆蓋，而無(wú)法保證真正全覆蓋。

大規(guī)模場(chǎng)景下，數(shù)據(jù)無(wú)法達(dá)到 100% 的完全一致性。

• 當(dāng)集群規(guī)模足夠大時(shí)，數(shù)據(jù)的一致性問(wèn)題將會(huì)愈加顯現(xiàn)。比如全局風(fēng)控組件是否全集群鏈路覆蓋？相關(guān)流控配置是否全集群鏈路推平？pod 主容器時(shí)區(qū)是否與上層一致？集群客戶端節(jié)點(diǎn)證書(shū)是否有即將過(guò)期？等等問(wèn)題，一旦疏忽，將有可能釀成嚴(yán)重的故障。

只有彌補(bǔ)上述兩類(lèi)風(fēng)險(xiǎn)點(diǎn)，才能有底氣真正做到先于用戶發(fā)現(xiàn)問(wèn)題。我們解決上述兩類(lèi)風(fēng)險(xiǎn)的思路分別是：

黑盒探測(cè)

• 所謂黑盒探測(cè)，既模擬廣義上的用戶行為，探測(cè)鏈路是否正常。

定向巡檢

• 所謂巡檢，既檢查集群異常指標(biāo)，找到已有或可能將存在的風(fēng)險(xiǎn)點(diǎn)。

基于以上思路，我們?cè)O(shè)計(jì)并實(shí)現(xiàn)了 KubeProbe 探測(cè)/巡檢中心，用于彌補(bǔ)復(fù)雜系統(tǒng)的正向監(jiān)控的不足，幫助我們更好、更快地發(fā)現(xiàn)系統(tǒng)風(fēng)險(xiǎn)和線上問(wèn)題。

設(shè)計(jì)

黑盒探測(cè)和定向巡檢

1）黑盒探測(cè)

不知道你是否也經(jīng)歷過(guò)一條鏈路上各個(gè)系統(tǒng)監(jiān)控?cái)?shù)據(jù)都正常，但是實(shí)際鏈路流程就是跑不通。或者因?yàn)橄到y(tǒng)變化快，監(jiān)控覆蓋不到 100% 的場(chǎng)景總是會(huì)有遺漏，導(dǎo)致影響到了用戶卻沒(méi)有報(bào)警，對(duì)用戶沒(méi)有實(shí)質(zhì)影響卻報(bào)警頻發(fā)從而疲于奔命。

如果一個(gè)系統(tǒng)開(kāi)發(fā)者自己都不使用自己的系統(tǒng)，那么怎么可能先于用戶發(fā)現(xiàn)系統(tǒng)問(wèn)題呢？所以要先于用戶發(fā)現(xiàn)系統(tǒng)問(wèn)題，首先我們自己就得先成為用戶，而且一定是使用最多，了解最深，無(wú)時(shí)無(wú)刻不在使用和感知系統(tǒng)狀況的用戶。

所謂黑盒探測(cè)，就是讓自己成為自己的用戶，模擬廣義"用戶"的行為去對(duì)集群/組件/鏈路等待待測(cè)對(duì)象做探測(cè)。注意，這里的"用戶"并不僅僅是狹義上使用系統(tǒng)的同學(xué)，而是廣義用戶。比如，etcd 的"用戶"是 APIServer，而 ASI 的"用戶"可能是某個(gè)通過(guò) APIServer 操作集群的同學(xué)，也可能是 Normandy 發(fā)起的發(fā)布/擴(kuò)容/縮容操作。

我們希望 KubeProbe 能在 變更時(shí)（監(jiān)聽(tīng)到集群狀態(tài)發(fā)生變化/組件變更/組件發(fā)布/系統(tǒng)升級(jí)等等事件）/運(yùn)行時(shí)（周期，高頻）/故障恢復(fù)時(shí)（手動(dòng)），通過(guò)周期/事件觸發(fā)/手動(dòng)觸發(fā)，執(zhí)行各種不同類(lèi)型的黑盒探測(cè)，第一時(shí)間感知組件/集群/鏈路的可用性。

以 etcd 集群的可用性來(lái)舉例，我們可以實(shí)現(xiàn)一個(gè)探測(cè)用例，邏輯是對(duì) etcd 做 create/get/delete/txn 等等操作，并記錄每個(gè)操作的成功率/消耗時(shí)間，當(dāng)成功率低于 100% 或消耗時(shí)間超過(guò)容忍閾值后，觸發(fā)報(bào)警。我們將周期高頻運(yùn)行這個(gè) etcd 的探測(cè)用例，同時(shí)對(duì)于 etcd 集群的任何變更都會(huì)發(fā)出一個(gè)事件 event 觸發(fā)這個(gè) etcd 探測(cè)立即運(yùn)行，這樣就能盡量確保第一時(shí)間發(fā)現(xiàn) etcd 可用性故障了。同時(shí)，當(dāng) etcd 集群因?yàn)槟承┰虿豢捎昧?#xff0c;我們也可以通過(guò)手動(dòng)觸發(fā)等其他方式做探活，也能第一時(shí)間得到是否恢復(fù)的信息。

2）定向巡檢

在大規(guī)模集集群/系統(tǒng)場(chǎng)景下，數(shù)據(jù)一致性是一定會(huì)面臨的難題。數(shù)據(jù)不一致，將導(dǎo)致一些隱患，可能會(huì)在未來(lái)引發(fā)某些確定性的故障。

相比于黑盒探測(cè)面對(duì)的未知故障場(chǎng)景，定向巡檢的目標(biāo)是對(duì)集群的已知風(fēng)險(xiǎn)點(diǎn)做掃描。

我們希望 KubeProbe 能夠定期對(duì)整個(gè)集群/鏈路做定向的巡檢，找出這些數(shù)據(jù)不一致的點(diǎn)，判斷數(shù)據(jù)不一致是否可能引發(fā)風(fēng)險(xiǎn)，從而能夠防患于未然，治未病。

比如 etcd 冷熱備多集群覆蓋不全，可能導(dǎo)致集群遇到故障無(wú)法快速恢復(fù)。那么我們就定期對(duì) etcd 的冷熱備覆蓋情況做定向巡檢，找出沒(méi)有覆蓋推平的集群，并告警。比如 集群風(fēng)控系統(tǒng)沒(méi)有全集群鏈路覆蓋，限流配置沒(méi)有全集群鏈路推平，可能導(dǎo)致某些故障場(chǎng)景引發(fā)集群全面崩潰，我們定期對(duì)風(fēng)控配置全網(wǎng)掃描，判斷是否可能導(dǎo)致故障，找出這些隱藏的已知風(fēng)險(xiǎn)點(diǎn)并告警。

實(shí)現(xiàn)

1. 架構(gòu)

1）基本架構(gòu)

KubeProbe 的基本實(shí)現(xiàn)架構(gòu)大致如下圖，KubeProbe 中心端配置集群/集群組與巡檢/探測(cè)用例/用例集之間的關(guān)聯(lián)關(guān)系，負(fù)責(zé)對(duì)集群做具體某次探測(cè)實(shí)例下發(fā)。某個(gè)具體的巡檢/探測(cè)用例下發(fā)到具體某個(gè)集群將使用用例的鏡像創(chuàng)建一個(gè) pod，這個(gè) pod 里會(huì)執(zhí)行若干巡檢/探測(cè)邏輯，當(dāng)執(zhí)行完成后會(huì)回調(diào)中心端回寫(xiě)本次巡檢/探測(cè)結(jié)果。其具體結(jié)果在中心端統(tǒng)一展示/告警，并提供給其他消費(fèi)者消費(fèi)（如支持 ASIOps 平臺(tái)的發(fā)布阻斷）。

2）高頻架構(gòu)

除了上述的基本架構(gòu)之外，我們對(duì)于高頻探測(cè)用例（既探測(cè)周期短，觸發(fā)頻率需要非常頻繁，甚至保持無(wú)縫探測(cè)的場(chǎng)景）設(shè)計(jì)了一套集群內(nèi)的分布式常駐探測(cè)架構(gòu)，該架構(gòu)通過(guò)集群內(nèi)的 ProbeOperator 組件 watch 自定義對(duì)象 probeConfig 的變化，在集群內(nèi)創(chuàng)建一個(gè)常駐的探測(cè) pod，將持續(xù)無(wú)間斷的運(yùn)行探測(cè)邏輯，實(shí)現(xiàn)接近無(wú)縫的持續(xù)探測(cè)，并將結(jié)果通過(guò)去噪/令牌桶限流等處理后，上報(bào)中心端，共給其他消費(fèi)者消費(fèi)。

2. KubeProbe 探測(cè)/巡檢用例管理

所有的探測(cè)/巡檢用例都使用統(tǒng)一的 git 倉(cāng)庫(kù)管理，由我們提供一個(gè)統(tǒng)一的 client 庫(kù)，client 庫(kù)最核心提供的方法主要有兩個(gè)。

KPclient "gitlab.alibaba-inc.com/{sigma-inf}/{kubeProbe}/client"// 報(bào)告成功 // 此方法會(huì)向KubeProbe報(bào)告本次巡檢結(jié)果為成功 KPclient.ReportSuccess() os.Exit(0)// 報(bào)告失敗 // 報(bào)告方法會(huì)向KubeProbe報(bào)告本次巡檢結(jié)果為失敗，并且失敗信息為 `我失敗啦` KPclient.ReportFailure([]string{"我失敗啦!"}) os.Exit(1)

我們可以通過(guò)提供好的 Makefile 將這個(gè)用例打包成鏡像，錄入 KubeProbe 中心端就可以對(duì)集群做配置和下發(fā)了。將具體巡檢/探測(cè)邏輯和 KubeProbe 中心管控端解耦，可以靈活而又簡(jiǎn)便的讓更多的二方用戶接入自己的特殊巡檢/探測(cè)邏輯。

目前已經(jīng)使用的探測(cè)/巡檢用例包括：

• 通用探測(cè)：模擬 pod / deployment / statefulset 生命周期探測(cè)集群整條管控鏈路。
• etcd 黑盒探測(cè)：模擬 etcd 的基本操作，探測(cè)元集群中各 etcd 狀態(tài)。
• 金絲雀探測(cè)（感謝質(zhì)量技術(shù)同學(xué)的大力支持）：模擬用戶使用 ASI 的部署場(chǎng)景，實(shí)現(xiàn)金絲雀應(yīng)用的全鏈路模擬發(fā)布/擴(kuò)容/縮容。
• Virtual cluster 探測(cè)：探測(cè) vc 虛擬集群的管控鏈路狀態(tài)。
• 聯(lián)邦鏈路探測(cè)：探測(cè)聯(lián)邦控制器相關(guān)鏈路的狀態(tài)。
• 節(jié)點(diǎn)通用探測(cè)：在集群每個(gè)節(jié)點(diǎn)上模擬調(diào)度一個(gè)探測(cè) pod，探測(cè)節(jié)點(diǎn)側(cè)鏈路狀態(tài)。
• ASI 客戶端/服務(wù)端證書(shū)巡檢：檢查客戶端/服務(wù)端證書(shū)有效性以及到期時(shí)間是否已超過(guò)告警閾值。
• 全局風(fēng)控限流巡檢：檢查各 ASI 集群是否已經(jīng)推平并開(kāi)啟 KubeDefender 全局限流風(fēng)控配置。
• ······

3. KubeProbe 中心端管控

編寫(xiě)完成探測(cè)/巡檢用例，并打包上傳好鏡像后，就需要在 KubeProbe 中心端注冊(cè)這個(gè)用例模版，即將鏡像注冊(cè)進(jìn) KubeProbe 中心端的數(shù)據(jù)庫(kù)中。

我們可以通過(guò)"渲染配置"參數(shù)傳入一些指定的 env 環(huán)境變量到巡檢/探測(cè) pod 中，用于執(zhí)行不同的業(yè)務(wù)邏輯，實(shí)現(xiàn)同一個(gè)用例模版生成多個(gè)用例。

最后通過(guò)統(tǒng)一的配置管控將用例和集群做綁定，配置對(duì)應(yīng)的參數(shù)，執(zhí)行各種下發(fā)邏輯。

同時(shí)，我們還在 KubeProbe 中心端做了大量權(quán)限安全管控，臟數(shù)據(jù)資源清理以及提效增速的工作（比如采用完全以 ownerreferences 的巡檢/探測(cè)用例資源自動(dòng)清理能力等等），這里不再贅述。

4. 打通發(fā)布?/ 變更阻斷

我們打通了 KubeProbe 探測(cè)與發(fā)布變更的關(guān)聯(lián)，當(dāng)對(duì)應(yīng)集群中有任何變更發(fā)生時(shí)（如某組件在做發(fā)布），我們會(huì)自動(dòng)通過(guò)相應(yīng)的事件觸發(fā)此集群綁定的所有巡檢/探測(cè)用例，檢查集群狀態(tài)是否正常。如果探測(cè)失敗，則會(huì)將變更阻斷，降低爆炸半徑，提升集群變更時(shí)穩(wěn)定性。

5. 為什么不使用 Kuberhealthy

社區(qū)有一個(gè) Operator 叫 Kuberhealthy 也可以做類(lèi)似的事情，我們?cè)?jīng)也考慮采用，并且深度使用過(guò) Kuberhealthy 和參與 kuberhealthy 的社區(qū)貢獻(xiàn)，最終得出不適合的結(jié)論，主要原因是對(duì)大規(guī)模集群的支持較弱，同時(shí)高頻調(diào)用時(shí)主流程卡死問(wèn)題比較嚴(yán)重，不支持事件/手動(dòng)單次觸發(fā)特性，不支持統(tǒng)一上報(bào)數(shù)據(jù)中心等等，最終選擇了自研自建的方式，目前來(lái)看是一個(gè)比較正確的選擇。

一點(diǎn)小結(jié)果

KubeProbe 上線以來(lái)，實(shí)現(xiàn)探測(cè)/巡檢用例幾十個(gè)，在集團(tuán)數(shù)百個(gè) ASI 集群中運(yùn)行千萬(wàn)余次，主動(dòng)發(fā)現(xiàn)集群故障和問(wèn)題百余次，其中某些小故障一旦沒(méi)有發(fā)覺(jué)很有可能升級(jí)成為大故障，有效降低了系統(tǒng)風(fēng)險(xiǎn)。同時(shí)打通了變更/發(fā)布系統(tǒng)，提升了變更穩(wěn)定性。并且在特殊故障時(shí)，多次先于業(yè)務(wù)方提前發(fā)現(xiàn)問(wèn)題，更早地推動(dòng)解決問(wèn)題，客觀降低了故障損失。

下面是一個(gè)具體例子:

• 我們會(huì)接收到每個(gè)集群中各個(gè)組件的發(fā)布事件，由發(fā)布事件觸發(fā)我們會(huì)在對(duì)應(yīng)集群中運(yùn)行相關(guān)的巡檢/探測(cè)，比如調(diào)度一個(gè)定向的 pod 到某個(gè)節(jié)點(diǎn)組件發(fā)布的節(jié)點(diǎn)上去。我們發(fā)現(xiàn) kube-proxy 的發(fā)布會(huì)導(dǎo)致節(jié)點(diǎn)的短暫不可用，調(diào)度上去的 pod 無(wú)法創(chuàng)建成功，從簡(jiǎn)單的返回/日志/集群事件上看不出具體的問(wèn)題，并且持續(xù)復(fù)現(xiàn)。經(jīng)過(guò)深入排查，得知是 kube-proxy 的問(wèn)題，存在 netns 泄露。運(yùn)行久了會(huì)泄露，當(dāng) kube-proxy 重啟的時(shí)候，內(nèi)核要清理 netns，會(huì)卡一段時(shí)間來(lái)清理，導(dǎo)致節(jié)點(diǎn)一段時(shí)間鏈路不通，pod 可以調(diào)度上去但是運(yùn)行不起來(lái)，從而后續(xù)推進(jìn)了 kube-proxy 的問(wèn)題修復(fù)。

發(fā)現(xiàn)問(wèn)題之后

1. KubeProbe 和數(shù)據(jù)監(jiān)控的告警區(qū)別

KubeProbe 所面對(duì)的場(chǎng)景和數(shù)據(jù)監(jiān)控不同，更多偏向于鏈路探測(cè)。

比如，監(jiān)控告警一般的告警可能如下：

• xx容器內(nèi)存使用率 99%
• webhook 雙副本全部掛掉了
• apiserver 三副本全部宕機(jī)了

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

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

這些 KubeProbe 的告警往往比較難從字面看出到底這次巡檢/探測(cè)是為什么失敗了，我們往往需要根據(jù)相關(guān)的用例返回日志，巡檢/探測(cè) pod 日志，KubeProbe 相關(guān)集群事件綜合排查，定位失敗原因。

2. 根因定位

我們以比較混沌的 KubeProbe 探測(cè)失敗告警作為線索，構(gòu)建了一套 KubeProbe 自閉環(huán)的根因定位系統(tǒng)，將問(wèn)題排查的專(zhuān)家經(jīng)驗(yàn)下沉進(jìn)系統(tǒng)中，實(shí)現(xiàn)了快速和自動(dòng)的問(wèn)題定位功能，一個(gè)簡(jiǎn)單的定位規(guī)則如下：

我們會(huì)通過(guò)普通的根因分析樹(shù)以及對(duì)失敗巡檢探測(cè)事件/日志的機(jī)器學(xué)習(xí)分類(lèi)算法（持續(xù)開(kāi)發(fā)投入中），為每一個(gè) KubeProbe 的探測(cè)失敗 Case 做根因定位，并通過(guò) KubeProbe 內(nèi)統(tǒng)一實(shí)現(xiàn)的問(wèn)題嚴(yán)重性評(píng)估系統(tǒng)（目前這里的規(guī)則仍比較簡(jiǎn)單），為告警的嚴(yán)重性做評(píng)估，從而判斷應(yīng)該如何做后續(xù)的處理適宜，比如是否自愈，是否電話告警等等。

3. Oncall 和 ChatOps

有了上面提到的根因定位以及告警嚴(yán)重性評(píng)估系統(tǒng)，我們使用了 nlp 告警機(jī)器人，實(shí)現(xiàn)了一套自動(dòng)化的 Oncall 系統(tǒng)以及 ChatOps，展示一些使用的 case 如下，通過(guò) ChatOps 和 Oncall 機(jī)器人，極大的降低了問(wèn)題處理的復(fù)雜度，盡量用技術(shù)的手段解決重復(fù)的問(wèn)題。

我們?nèi)栽诼飞?/h1>

以上是我們?cè)诠芾泶笠?guī)模 Kubernetes 集群中的一點(diǎn)經(jīng)驗(yàn)，也解決了一些常見(jiàn)的問(wèn)題，希望能對(duì)大家有所幫助。同時(shí)，這些工作在阿里云海量規(guī)模的場(chǎng)景下還需要持續(xù)打磨，我們?nèi)栽诼飞?#xff0c;并且將持續(xù)在路上。

總結(jié)

以上是生活随笔為你收集整理的面对大规模 K8s 集群，如何先于用户发现问题？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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