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

分布式系統和微服務體系結構的挑戰之一是自動檢測不正常的應用程序，并將請求（request）重新路由到其他可用系統，恢復損壞的組件。健康檢查是應對該挑戰的一種可靠方法。使用 Kubernetes，可以通過探針配置運行狀況檢查，以確定每個 Pod 的狀態。

同樣的，這也是 Kubernetes 探針用來定義容器何時準備接受流量，以及何時重新啟動容器的方式。從 Kubernetes v1.16 開始，已經支持三種類型的探針。在文中將介紹這三種類型的探針、最佳實踐和有關工具，以檢測可能存在的配置問題。

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

• initialDelaySeconds ：啟動 liveness、readiness 探針前要等待的秒數。
• periodSeconds ：檢查探針的頻率。
• timeoutSeconds ：將探針標記為超時（未通過運行狀況檢查）之前的秒數。
• successThreshold ：探針需要通過的最小連續成功檢查數量。
• failureThreshold ：將探針標記為失敗之前的重試次數。對于 liveness 探針，這將導致 Pod 重新啟動。對于 readiness 探針，將標記 Pod 為未就緒（unready）。

假設有一個偶爾需要下載大量數據的應用程序，由于 initialDelaySeconds 是一個靜態數字，因此該應用程序即使不需要那么長的初始化等待時間，我們也必須設置最保守的等待時間。通過 startup 探針，我們可以配置 failureThreshold 和 periodSeconds 來解決該問題，例如設置 failureThreshold 為 15，periodSeconds 為 5，這意味著應用程序在失敗之前會有 10x5=75s 的啟動時間。

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

• host ：要連接的主機名（默認值：pod 的 IP）。
• scheme ：HTTP（默認）或 HTTPS。
• path ：HTTP/S 服務器上的路徑 。
• httpHeaders ：自定義標頭（如果需要標頭用于身份驗證、CORS 設置等） 。
• port ：訪問服務器的端口名稱或端口號。

       

雖然說探針的確切參數和使用方法取決于應用程序，但也有一些常用的最佳實踐：

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

簡而言之，定義明確的探針通常會帶來更好的彈性和可用性。確保觀察啟動時間和系統行為，在應用程序更改時調整探針設置。

最后，鑒于 Kubernetes 探針的重要性，我們可以使用 Kubernetes 資源分析工具來檢測缺失的探針。這些工具可以在現有集群上運行，也可以置入 CI/CD 流程中，可以在沒有正確配置資源的情況下自動拒絕工作負載。

• polaris ：一個具有儀表板的資源分析工具，也可以用作驗證 webhook 或 CLI 工具。
• kube-score ：一個靜態代碼分析工具，可用于 Helm、Kustomize 和標準 YAML 文件。
• popeye ：只讀的實用工具，用于掃描 Kubernetes 集群并報告配置中的潛在問題。