健康檢查配置

本文視頻教程: https://www.bilibili.com/video/BV16q4y1y7B9

本文分享 K8S 健康檢查配置的最佳實踐，文末也分享配置不當?shù)陌咐?/p>

K8S 支持三種健康檢查：

就緒檢查(readinessProbe): Pod啟動后，如果配了就緒檢查，要等就緒檢查探測成功，Pod Ready 狀態(tài)變?yōu)?True，允許放流量進來；在運行期間如果突然探測失敗，Ready 狀態(tài)變?yōu)?False，摘除流量。 存活檢查(livenessProbe): Pod 在運行時，如果存活檢查探測失敗，會自動重啟容器；值得注意的是，存活探測的結果不影響 Pod 的 Ready 狀態(tài)，這也是許多同學可能誤解的地方。 啟動檢查(startupProbe): 作用是讓存活檢查和就緒檢查的開始探測時間延后，等啟動檢查成功后再開始探測，通常用于避免業(yè)務進程啟動慢導致存活檢查失敗而被無限重啟。

三種健康檢查配置格式都是一樣的，以 readinessProbe 為例:

readinessProbe:
successThreshold: 1 # 1 次探測成功就認為健康
failureThreshold: 2 # 連續(xù) 2 次探測失敗認為不健康
periodSeconds: 3 # 3s 探測一次
timeoutSeconds: 2 # 2s 超時還沒返回成功就認為不健康
httpGet: # 使用 http 接口方式探測，GET 請求 80 端口的 "/healthz" 這個 http 接口，響應狀態(tài)碼在200~399之間視為健康，否則不健康。
port: 80
path: "/healthz"
#exec: # 使用腳本探測，執(zhí)行容器內(nèi) "/check-health.sh" 這個腳本文件，退出狀態(tài)碼等于0視為健康，否則不健康。
# command: ["/check-health.sh"]
#tcp: # 使用 TCP 探測，看 9000 端口是否監(jiān)聽。
# port: 9000

探測結果一定要真實反應業(yè)務健康狀態(tài)?

首選 HTTP 探測?

通常是推薦業(yè)務自身提供 http 探測接口，如果業(yè)務層面健康就返回 200 狀態(tài)碼；否則，就返回 500。

備選腳本探測?

如果業(yè)務還不支持 http 探測接口，或者有探測接口但不是 http 協(xié)議，也可以將探測邏輯寫到腳本文件里，然后配置腳本方式探測。

盡量避免 TCP 探測?

另外，應盡量避免使用 TCP 探測，因為 TCP 探測實際就是 kubelet 向指定端口發(fā)送 TCP SYN 握手包，當端口被監(jiān)聽內(nèi)核就會直接響應 ACK，探測就會成功:

當程序死鎖或 hang 死，這些并不影響端口監(jiān)聽，所以探測結果還是健康，流量打到表面健康但實際不健康的 Pod 上，就無法處理請求，從而引發(fā)業(yè)務故障。

所有提供服務的 container 都要加上 ReadinessProbe?

如果你的容器對外提供了服務，監(jiān)聽了端口，那么都應該配上 ReadinessProbe，ReadinessProbe 不通過就視為 Pod 不健康，然后會自動將不健康的 Pod 踢出去，避免將業(yè)務流量轉發(fā)給異常 Pod。

謹慎使用 LivenessProbe?

LivenessProbe 失敗會重啟 Pod，不要輕易使用，除非你了解后果并且明白為什么你需要它，參考 Liveness Probes are Dangerous 。

探測條件要更寬松?

如果使用 LivenessProbe，不要和 ReadinessProbe 設置成一樣，需要更寬松一點，避免因抖動導致 Pod 頻繁被重啟。

通常是失敗閾值 (failureThreshold) 設置得更大一點，避免因探測太敏感導致 Pod 很容易被重啟。

另外如果有必要，超時時間 (timeoutSeconds) 和探測間隔 (periodSeconds) 也可以根據(jù)情況適當延長。

保護慢啟動容器?

有些應用本身可能啟動慢(比如 Java)，或者用的富容器，需要起一大堆依賴，導致容器啟動需要的較長，如果配置了存活檢查，可能會造成啟動過程中達到失敗閾值被重啟，如此循環(huán)，無限重啟。

對于這類啟動慢的容器，我們需要保護下，等待應用完全啟動后才開始探測:

如果 K8S 版本低于 1.18，可以設置 LivenessProbe 的初始探測延時 (initialDelaySeconds)。 如果 K8S 版本在 1.18 及其以上，可以配置 StartProbe，保證等應用完全啟動后才開始探測。

避免依賴導致級聯(lián)故障?

LivenessProbe 探測邏輯里不要有外部依賴 (db, 其它 pod 等)，避免抖動導致級聯(lián)故障。

如上圖，Pod B 探測邏輯里查 DB，Pod A 探測邏輯里調(diào)用 Pod B，如果 DB 抖動，Pod B 變?yōu)椴唤】?，Pod A 調(diào)用 Pod B 也失敗，也變?yōu)椴唤】担瑥亩壜?lián)故障。

反面教材?

突然無限重啟且流量異常?

故障現(xiàn)象: Pod 突然不斷重啟，期間有流量進入，這部分流量異常。

原因：

Pod 之前所在節(jié)點異常，重建漂移到了其它節(jié)點去啟動。 Pod 重建后由于基礎鏡像中依賴的一個服務有問題導致啟動較慢，因為同時配置了 ReadinessProbe 與 LivenessProbe，大概率是啟動時所有健康檢查都失敗，達到 LivenessProbe 失敗次數(shù)閾值，又被重啟。 Pod 配置了 preStop 實現(xiàn)優(yōu)雅終止，被重啟前會先執(zhí)行 preStop，優(yōu)雅終止的時長較長，preStop 期間 ReadinessProbe 還會繼續(xù)探測。 探測方式使用的 TCP 探測，進程優(yōu)雅終止過程中 TCP 探測仍然會成功(沒完全退出前端口監(jiān)聽仍然存在)，但實際此時進程已不會處理新請求了。 LivenessProbe 結果不會影響 Pod Ready 狀態(tài)，是否 Ready 主要取決于 ReadinessProbe 結果，由于 preStop 期間 ReadinessProbe 是成功的，Pod 就變 Ready 了。 Pod Ready 但實際無法處理請求，業(yè)務就會異常。

總結:

Pod 慢啟動 + 存活探測 導致被無限重啟。需要延長 initialDelaySeconds 或 StartProbe 來保護慢啟動容器。 TCP 探測方式不能完全真實反應業(yè)務健康狀態(tài)，導致在優(yōu)雅終止過程中，ReadinessProbe 探測成功讓流量放進來而業(yè)務卻不會處理，導致流量異常。需要使用更好的探測方式，建議業(yè)務提供 HTTP 探活接口，使用 HTTP 探測業(yè)務真實健康狀態(tài)。

netstat 探測超時?

故障現(xiàn)象: 探測腳本經(jīng)常 2s 超時。

原因: 使用腳本探測，超時時間為 2s，腳本里使用了 netstat 檢測端口是否存活來判斷業(yè)務進程是否正常，當流量較大時，連接數(shù)多，netstat 運行所需時間就較長 (因為 netstat 會遍歷 /proc 下每個 pid 內(nèi)容來進行統(tǒng)計，執(zhí)行時長受連接數(shù)波動所影響)，所以在業(yè)務高峰時往往容易執(zhí)行超時，從而探測失敗。

總結: 這種探測方式比 TCP 探測方式更原始，強烈不推薦，參考最佳實踐優(yōu)化探測配置。

相關知識

配置健康檢查探測物理專線連通性
移動健康流動體檢車配置參數(shù)改裝大全
用微軟官方工具「電腦健康狀況檢查」來檢測你的電腦是否符合 Windows 11 最低配置
前置胎盤檢查圖片
前置胎盤的輔助檢查
前置胎盤的體格檢查
前置胎盤超聲檢查
Nginx被動健康檢查和主動健康檢查
k8s健康檢查 spring k8s健康檢查探針多個地址
前置胎盤多久能檢查出來

網(wǎng)址: 健康檢查配置 http://www.u1s5d6.cn/newsview556881.html