Kubernetes 探針詳解！

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

預設情況下，Kubernetes 會觀察 Pod 生命週期，並在容器從掛起（pending）狀態轉移到成功（succeeded）狀態時，將流量路由到 Pod。Kubelet 會監控崩潰的應用程式，並重新啟動 Pod 進行恢復。許多開發人員認為這樣的基本設定就足夠了，尤其是當 Pod 內的應用程式還配置了守護程式管理器（例如 Node.js 的 PM2）時。但有一種意外情況，當 Kubernetes 在所有容器啟動後，認為 Pod 是健康且可以接受請求時，但應用程式在實際準備就緒之前就已收到流量，比如應用程式在處理應用程式邏輯之前，初始化了一些狀態，建立了資料庫連線或載入了資料。當 Deployment 開始擴充套件時，未就緒的應用程式會接收流量並返回 500 錯誤，這造成了應用程式實際的準備就緒與 Kubernetes 認為的準備就緒之間的時間間隔問題。

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

K8sMeetup

Kubernetes 探針

Kubernetes 版本小於 v1.15 時支援 readiness 和 liveness 探針，在 v1.16 中新增了 startup 探針作為 Alpha 功能，並在 v1.18 中升級為 Beta。

這三種探針均具有以下引數：

initialDelaySeconds ：啟動 liveness、readiness 探針前要等待的秒數。

periodSeconds ：檢查探針的頻率。

timeoutSeconds ：將探針標記為超時（未透過執行狀況檢查）之前的秒數。

successThreshold ：探針需要透過的最小連續成功檢查數量。

failureThreshold ：將探針標記為失敗之前的重試次數。對於 liveness 探針，這將導致 Pod 重新啟動。對於 readiness 探針，將標記 Pod 為未就緒（unready）。

Readiness 探針readiness 探針可以讓 kubelet 知道應用程式何時準備接受新流量。 如果應用程式在程式啟動後需要一些時間來初始化狀態，要配置 readiness 探針讓 Kubernetes 在傳送新流量之前進行等待。readiness 探針的主要作用是將流量引導至 service 後的 deployment。

關於 readiness 探針有一點很重要，它會在容器的整個生命週期中執行。 這意味著 readiness 探針不僅會在啟動時執行，而且還會在 Pod 執行期間反覆執行。 這是為了處理應用程式暫時不可用的情況（比如載入大量資料、等待外部連線時）。 在這種情況下，我們不一定要殺死應用程式，可以等待它恢復。 readiness 探針可用於檢測這種情況，並在 Pod 再次透過 readiness 檢查後，將流量傳送到這些 Pod。Liveness 探針liveness 探針用於重新啟動不健康的容器。 Kubelet 會定期地 ping liveness 探針，以確定健康狀況，並在 liveness 檢查不透過的情況下殺死 Pod。liveness 檢查可以幫助應用程式從死鎖中恢復。如果不進行 liveness 檢查，Kubernetes 會認為死鎖中的 Pod 處於健康狀態，因為從 Kubernetes 的角度來看，Pod 的子程式仍在執行，是健康的。透過配置 liveness 探針，kubelet 可以檢測到應用程式處於不健康狀態，並重新啟動 Pod 以恢復可用性。 Startup 探針startup 探針與 readiness 探針類似，但它僅在啟動時執行，能針對啟動緩慢的容器或在初始化過程中有不可預測行為的應用程式進行最佳化。 藉助 readiness 探針，我們可以配置  initialDelaySeconds  來確定 readiness 探測在準備就緒前要等待多長時間。

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

K8sMeetup

配置探針

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

HTTPkubelet 將 HTTP GET 請求傳送到 endpoint，並檢查 2xx 或 3xx 響應。我們可以重複使用現有的 HTTP endpoint 或設定輕量級 HTTP 伺服器以進行探測（例如，具有  /healthz  endpoint 的 Express server）。HTTP 探針包含其他額外引數：

host ：要連線的主機名（預設值：pod 的 IP）。

scheme ：HTTP（預設）或 HTTPS。

path ：HTTP/S 伺服器上的路徑 。

httpHeaders ：自定義標頭（如果需要標頭用於身份驗證、CORS 設定等） 。

port ：訪問伺服器的埠名稱或埠號。