健康檢查配置

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

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

K8S 支持三種健康檢查：

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

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

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

探測(cè)結(jié)果一定要真實(shí)反應(yīng)業(yè)務(wù)健康狀態(tài)?

首選 HTTP 探測(cè)?

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

備選腳本探測(cè)?

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

盡量避免 TCP 探測(cè)?

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

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

所有提供服務(wù)的 container 都要加上 ReadinessProbe?

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

謹(jǐn)慎使用 LivenessProbe?

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

探測(cè)條件要更寬松?

如果使用 LivenessProbe，不要和 ReadinessProbe 設(shè)置成一樣，需要更寬松一點(diǎn)，避免因抖動(dòng)導(dǎo)致 Pod 頻繁被重啟。

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

另外如果有必要，超時(shí)時(shí)間 (timeoutSeconds) 和探測(cè)間隔 (periodSeconds) 也可以根據(jù)情況適當(dāng)延長(zhǎng)。

保護(hù)慢啟動(dòng)容器?

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

對(duì)于這類(lèi)啟動(dòng)慢的容器，我們需要保護(hù)下，等待應(yīng)用完全啟動(dòng)后才開(kāi)始探測(cè):

如果 K8S 版本低于 1.18，可以設(shè)置 LivenessProbe 的初始探測(cè)延時(shí) (initialDelaySeconds)。 如果 K8S 版本在 1.18 及其以上，可以配置 StartProbe，保證等應(yīng)用完全啟動(dòng)后才開(kāi)始探測(cè)。

避免依賴(lài)導(dǎo)致級(jí)聯(lián)故障?

LivenessProbe 探測(cè)邏輯里不要有外部依賴(lài) (db, 其它 pod 等)，避免抖動(dòng)導(dǎo)致級(jí)聯(lián)故障。

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

反面教材?

突然無(wú)限重啟且流量異常?

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

原因：

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

總結(jié):

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

netstat 探測(cè)超時(shí)?

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

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

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

相關(guān)知識(shí)

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

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