從事云原生底層研發(fā)近3年，經(jīng)歷了大大小小的容器集群故障。記錄一下容器集群穩(wěn)定性建設(shè)心得。

首先，集群狀態(tài)可以分為變更狀態(tài) + 正常運(yùn)行狀態(tài)。

0. 監(jiān)控指標(biāo)+告警的完善

無論是變更時(shí)，還是平時(shí)。監(jiān)控指標(biāo)的完善必不可少，通過監(jiān)控指標(biāo)可以提前發(fā)現(xiàn)異常情況。apisever, kcm, kubescheduler, kubelet, etcd組件的監(jiān)控指標(biāo)必須到位

https://docs.datadoghq.com/integrations/kube_apiserver_metrics/

https://docs.datadoghq.com/integrations/kube_controller_manager/

1. 變更狀態(tài)

變更狀態(tài)是人為發(fā)起的，因?yàn)榻M件更新，bug修復(fù)，功能上線等需求而對(duì)集群的apiserver, kcm, kubelet, etcd等等核心組件進(jìn)行的主動(dòng)變更。

這個(gè)過程保證集群的穩(wěn)定性，個(gè)人認(rèn)為核心是變更流程，變更規(guī)范的建設(shè)。

（1）對(duì)于核心組件（apiserver, kubelet, kcm等）變更而言，一定要規(guī)范變更流程，千萬不要馬虎。

例如，某個(gè)node節(jié)點(diǎn)需要調(diào)整一個(gè)kubelet參數(shù)，這個(gè)時(shí)候運(yùn)維同學(xué)A手動(dòng)調(diào)整，將Kubelet重啟。但是由于kcm開啟了污點(diǎn)驅(qū)逐，導(dǎo)致這臺(tái)kubelet上所有pod全部被驅(qū)逐，業(yè)務(wù)方找上門來了。。。

所以kubelet變更流程就應(yīng)該為：

停止kcm -> 停止kubelet -> 修改配置參數(shù) -> 啟動(dòng)kubelet -> kubectl 觀察nodeReady后啟動(dòng)kcm

（2）穩(wěn)態(tài)環(huán)境的搭建

• 搭建一個(gè)和線上業(yè)務(wù)方版本一直的k8s集群，模擬業(yè)務(wù)方跑一下代表性的pod和svc（例如設(shè)置就緒探針，開啟了驅(qū)逐，使用了volume等等）

• 實(shí)現(xiàn)穩(wěn)態(tài)告警，穩(wěn)態(tài)環(huán)境的svc 訪問超時(shí)，訪問不同，pod狀態(tài)異常都需要告警出來

• 自動(dòng)化的反復(fù)變更測(cè)試

• 提前模擬業(yè)務(wù)變更。比如在變更kubelet之前，通過將穩(wěn)態(tài)環(huán)境的版本設(shè)置為線上一致，然后通過反復(fù)自動(dòng)變更，觀察是否有異常，然后再迭代完善變更流程

（3）變更過程小批量灰度進(jìn)行，并時(shí)刻觀察監(jiān)控指標(biāo)是否異常

在大規(guī)模集群中，特別要注意kubelet或者其他deamonset組件的變更。ds/kubelet組件大部分場景都是對(duì)集群的某些資源進(jìn)行l(wèi)ist-watcher。這個(gè)時(shí)候大規(guī)模的更新可能會(huì)給apiserver一瞬間造成巨大的壓力。所以這類組件的變更一點(diǎn)要注意按批次，小規(guī)模變更

2. 正常運(yùn)行時(shí)狀態(tài)

（1）監(jiān)控告警體系的完善

（2）黑盒白盒的巡檢

監(jiān)控體現(xiàn)的完善并不能發(fā)現(xiàn)所有的問題。巡檢可以模擬業(yè)務(wù)場景，實(shí)現(xiàn)整個(gè)鏈路上的檢查。比如定期凌晨在線上集群進(jìn)行一波巡檢。包括但不限于

• 檢查pod是否可以正常創(chuàng)建

• pod網(wǎng)絡(luò)是否正常

• 是否有pod長時(shí)間處于terminting

• 是否有控制面組件重啟次數(shù)過高

• etcd集群是否健康

（3）核心組件的cpu, mem監(jiān)控

（4）k8s組件穩(wěn)定性建設(shè)

• 元數(shù)據(jù)與event拆分，必要時(shí)pod數(shù)據(jù)也可以用獨(dú)立的etcd集群

  建議對(duì)組件產(chǎn)生的event進(jìn)行梳理，減少不必要的event

• 設(shè)置event-tll=10min, 而不是使用默認(rèn)的1h。這樣集群event爆炸的時(shí)候，可以快速恢復(fù)

• EventRateLimit機(jī)制

• kube-apiserver，kcm qps的合理設(shè)置

• APF機(jī)制，或者自研的優(yōu)先級(jí)限流機(jī)制

• 對(duì)其他自研組件，特別是需要ds部署組件的優(yōu)化

  該組件監(jiān)聽什么資源，一定要監(jiān)聽這么多對(duì)象，一定要全量監(jiān)聽嗎？部署方式是什么，大規(guī)模情況下會(huì)被打爆嗎，會(huì)引起連鎖反應(yīng)嗎？有么優(yōu)化空間？