從事云原生底層研發(fā)近3年，經(jīng)歷了大大小小的容器集群故障。記錄一下容器集群穩(wěn)定性建設(shè)心得。首先，集群狀態(tài)可以分為變更狀態(tài) + 正常

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

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

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

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

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

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

1. 變更狀態(tài)

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

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

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

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

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

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

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

• 搭建一個和線上業(yè)務(wù)方版本一直的k8s集群，模擬業(yè)務(wù)方跑一下代表性的pod和svc（例如設(shè)置就緒探針，開啟了驅(qū)逐，使用了volume等等）
• 實現(xiàn)穩(wěn)態(tài)告警，穩(wěn)態(tài)環(huán)境的svc 訪問超時，訪問不同，pod狀態(tài)異常都需要告警出來
• 自動化的反復(fù)變更測試
• 提前模擬業(yè)務(wù)變更。比如在變更kubelet之前，通過將穩(wěn)態(tài)環(huán)境的版本設(shè)置為線上一致，然后通過反復(fù)自動變更，觀察是否有異常，然后再迭代完善變更流程

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

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

2. 正常運行時狀態(tài)

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

（2）黑盒白盒的巡檢

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

• 檢查pod是否可以正常創(chuàng)建
• pod網(wǎng)絡(luò)是否正常
• 是否有pod長時間處于terminting
• 是否有控制面組件重啟次數(shù)過高
• etcd集群是否健康

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

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

• 元數(shù)據(jù)與event拆分，必要時pod數(shù)據(jù)也可以用獨立的etcd集群
  建議對組件產(chǎn)生的event進行梳理，減少不必要的event
• 設(shè)置event-tll=10min, 而不是使用默認的1h。這樣集群event爆炸的時候，可以快速恢復(fù)
• EventRateLimit機制
• kube-apiserver，kcm qps的合理設(shè)置
• APF機制，或者自研的優(yōu)先級限流機制
• 對其他自研組件，特別是需要ds部署組件的優(yōu)化
  該組件監(jiān)聽什么資源，一定要監(jiān)聽這么多對象，一定要全量監(jiān)聽嗎？部署方式是什么，大規(guī)模情況下會被打爆嗎，會引起連鎖反應(yīng)嗎？有么優(yōu)化空間？