配置 readiness、liveness 和 startup 探針可以處理不健康的 Pod，小編介紹了三種類型的探針、最佳實(shí)踐和有關(guān)工具，以檢測(cè)可能存在的配置問(wèn)題。

分布式系統(tǒng)和微服務(wù)體系結(jié)構(gòu)的挑戰(zhàn)之一是自動(dòng)檢測(cè)不正常的應(yīng)用程序，并將請(qǐng)求（request）重新路由到其他可用系統(tǒng)，恢復(fù)損壞的組件。健康檢查是應(yīng)對(duì)該挑戰(zhàn)的一種可靠方法。使用 Kubernetes，可以通過(guò)探針配置運(yùn)行狀況檢查，以確定每個(gè) Pod 的狀態(tài)。

同樣的，這也是 Kubernetes 探針用來(lái)定義容器何時(shí)準(zhǔn)備接受流量，以及何時(shí)重新啟動(dòng)容器的方式。從 Kubernetes v1.16 開(kāi)始，已經(jīng)支持三種類型的探針。在文中將介紹這三種類型的探針、最佳實(shí)踐和有關(guān)工具，以檢測(cè)可能存在的配置問(wèn)題。

Kubernetes 版本小于 v1.15 時(shí)支持 readiness 和 liveness 探針，在 v1.16 中添加了 startup 探針作為 Alpha 功能，并在 v1.18 中升級(jí)為 Beta。

• initialDelaySeconds ：?jiǎn)?dòng) liveness、readiness 探針前要等待的秒數(shù)。
• periodSeconds ：檢查探針的頻率。
• timeoutSeconds ：將探針標(biāo)記為超時(shí)（未通過(guò)運(yùn)行狀況檢查）之前的秒數(shù)。
• successThreshold ：探針需要通過(guò)的最小連續(xù)成功檢查數(shù)量。
• failureThreshold ：將探針標(biāo)記為失敗之前的重試次數(shù)。對(duì)于 liveness 探針，這將導(dǎo)致 Pod 重新啟動(dòng)。對(duì)于 readiness 探針，將標(biāo)記 Pod 為未就緒（unready）。

假設(shè)有一個(gè)偶爾需要下載大量數(shù)據(jù)的應(yīng)用程序，由于 initialDelaySeconds 是一個(gè)靜態(tài)數(shù)字，因此該應(yīng)用程序即使不需要那么長(zhǎng)的初始化等待時(shí)間，我們也必須設(shè)置最保守的等待時(shí)間。通過(guò) startup 探針，我們可以配置 failureThreshold 和 periodSeconds 來(lái)解決該問(wèn)題，例如設(shè)置 failureThreshold 為 15，periodSeconds 為 5，這意味著應(yīng)用程序在失敗之前會(huì)有 10x5=75s 的啟動(dòng)時(shí)間。

現(xiàn)在我們了解了不同類型的探針，下面是配置每種探針的三種不同方式。

• host ：要連接的主機(jī)名（默認(rèn)值：pod 的 IP）。
• scheme ：HTTP（默認(rèn)）或 HTTPS。
• path ：HTTP/S 服務(wù)器上的路徑 。
• httpHeaders ：自定義標(biāo)頭（如果需要標(biāo)頭用于身份驗(yàn)證、CORS 設(shè)置等） 。
• port ：訪問(wèn)服務(wù)器的端口名稱或端口號(hào)。

       

雖然說(shuō)探針的確切參數(shù)和使用方法取決于應(yīng)用程序，但也有一些常用的最佳實(shí)踐：

• 對(duì)于較舊的（≤v1.15）Kubernetes 集群，使用具有初始延遲的 readiness 探針來(lái)處理容器啟動(dòng)階段。
• 對(duì)于較新的（≥v1.16）Kubernetes 集群，如果是具有不可預(yù)測(cè)或可變啟動(dòng)時(shí)間的應(yīng)用程序應(yīng)使用 startup 探針。startup 探針與 readiness 和 liveness 探針共享相同的 endpoint（例如  /healthz ），但能將  failureThreshold  設(shè)置得比其他探針更高，以擁有更長(zhǎng)的啟動(dòng)時(shí)間，相對(duì)于 liveness 和 readiness 而言，設(shè)置的失敗時(shí)間會(huì)更合理。
• 如果 readiness 探針不用于其他信號(hào)目的，readiness 和 liveness 探針可以共享相同的 endpoint，但如果只有一個(gè) Pod（也就是使用 VPA）時(shí)，設(shè)置 readiness 探針來(lái)解決啟動(dòng)行為，使用 liveness 探針來(lái)確定運(yùn)行狀況。這種情況下，標(biāo)記 Pod 不健康意味著停機(jī)時(shí)間。
• readiness 檢查可以用各種方式來(lái)發(fā)出系統(tǒng)故障的信號(hào)。例如，當(dāng)應(yīng)用程序失去與數(shù)據(jù)庫(kù)的連接時(shí)，可以使用 readiness 探針暫時(shí)阻止新請(qǐng)求并允許系統(tǒng)重新連接。它還可以將繁忙的 Pod 標(biāo)記為未準(zhǔn)備，將工作負(fù)載平衡到其他 Pod。

簡(jiǎn)而言之，定義明確的探針通常會(huì)帶來(lái)更好的彈性和可用性。確保觀察啟動(dòng)時(shí)間和系統(tǒng)行為，在應(yīng)用程序更改時(shí)調(diào)整探針設(shè)置。

最后，鑒于 Kubernetes 探針的重要性，我們可以使用 Kubernetes 資源分析工具來(lái)檢測(cè)缺失的探針。這些工具可以在現(xiàn)有集群上運(yùn)行，也可以置入 CI/CD 流程中，可以在沒(méi)有正確配置資源的情況下自動(dòng)拒絕工作負(fù)載。

• polaris：一個(gè)具有儀表板的資源分析工具，也可以用作驗(yàn)證 webhook 或 CLI 工具。
• kube-score：一個(gè)靜態(tài)代碼分析工具，可用于 Helm、Kustomize 和標(biāo)準(zhǔn) YAML 文件。
• popeye：只讀的實(shí)用工具，用于掃描 Kubernetes 集群并報(bào)告配置中的潛在問(wèn)題。