Kubernetes最佳實踐S01E03：Kubernetes叢集健康檢查最佳實踐

今天是Google Developer Advocate

Sandeep Dinesh

關于如何充分利用Kubernetes環境的七部分視訊和部落格系列的第三部分。

分布式系統很難管理。 一個重要原因是有許多動态部件都為系統運作起作用。 如果一個小部件損壞，系統必須檢測它，繞過它并修複它。 這一切都需要自動完成！

健康檢查（Health Check）是讓系統知道您的應用執行個體是否正常工作的簡單方法。 如果您的應用執行個體不再工作，則其他服務不應通路該應用或向其發送請求。 相反，應該将請求發送到已準備好的應用程式執行個體，或稍後重試。 系統還應該能夠使您的應用程式恢複健康狀态。

預設情況下，當Pod中的所有容器啟動時，Kubernetes開始向Pod發送流量，并在崩潰時重新啟動容器。 雖然這在開始時可以“足夠好”，但您還可以通過建立自定義運作狀況檢查來使部署更加健壯。 幸運的是，Kubernetes使這個相對簡單，是以沒有理由不去這麼幹！

在本期Kubernetes最佳實踐中，讓我們了解

readiness

和

liveness

探針的細節，何時使用哪種探針，以及如何在Kubernetes叢集中進行設定。

健康檢查的類型

Kubernetes為您提供兩種類型的健康檢查，了解兩者之間的差異及其用途非常重要。

Readiness

Readiness

探針旨在讓Kubernetes知道您的應用何時準備好其流量服務。 Kubernetes確定

Readiness

探針檢測通過，然後允許服務将流量發送到Pod。 如果

Readiness

探針開始失敗，Kubernetes将停止向該容器發送流量，直到它通過。

Liveness

Liveness

探針讓Kubernetes知道你的應用程式是活着還是死了。 如果你的應用程式還活着，那麼Kubernetes就不管它了。 如果你的應用程式已經死了，Kubernetes将删除Pod并啟動一個新的替換它。

健康檢查是如何提供幫助的？

讓我們看看兩個場景，

Readiness

探針和

Liveness

探針可以幫助您建構魯棒性更強的應用程式。

讓我們假設您的應用需要一分鐘的時間來預熱并開始。 即使該過程已啟動，您的服務在啟動并運作之前也無法運作。 如果要将此部署擴充為具有多個副本，也會出現問題。 新副本在完全就緒之前不應接收流量，但預設情況下，Kubernetes會在容器内的程序啟動後立即開始發送流量。 通過使用

Readiness

探針，Kubernetes等待應用程式完全啟動，然後才允許服務将流量發送到新副本。

讓我們假設另一種情況，你的應用程式有一個令人讨厭的死鎖情況，導緻它無限期挂起并停止提供請求服務。 因為該服務還在運作，預設情況下Kubernetes認為一切正常并繼續向已經broken的Pod發送請求。 通過使用

Liveness

探針，Kubernetes會檢測到應用程式不再提供請求并重新啟動有問題的Pod。

探針類型

下一步是定義測試

Readiness

Liveness

的探針。 有三種類型的探測：HTTP、Command和TCP。 您可以使用它們中的任何一個進行

Liveness

Readiness

檢查。

HTTP

HTTP探針可能是最常見的自定義

Liveness

探針類型。 即使您的應用程式不是HTTP服務，您也可以在應用程式内建立輕量級HTTP服務以響應

Liveness

探針。 Kubernetes去

ping

一個路徑，如果它得到的是200或300範圍内的HTTP響應，它會将應用程式标記為健康。 否則它被标記為不健康。

您可以在

此處

閱讀有關HTTP探針的更多資訊。

Command

對于

Command

探針，Kubernetes則隻是在容器内運作指令。 如果指令以退出代碼0傳回，則容器标記為健康。 否則，它被标記為不健康。 當您不能或不想運作HTTP服務時，此類型的探針則很有用，但是必須是運作可以檢查您的應用程式是否健康的指令。

閱讀有關Command探針的更多資訊。

TCP

最後一種類型的探針是TCP探針，Kubernetes嘗試在指定端口上建立TCP連接配接。 如果它可以建立連接配接，則容器被認為是健康的；否則被認為是不健康的。

如果您有HTTP探針或Command探針不能正常工作的情況，TCP探測器會派上用場。 例如，gRPC或FTP服務是此類探測的主要候選者。

閱讀有關TCP探針的更多資訊。

配置探針的初始化延遲時間

可以通過多種方式配置探針。 您可以指定它們應該運作的頻率，成功和失敗門檻值是什麼，以及等待響應的時間。 有關

配置探針的文檔

非常清楚地介紹了其不同的選項及功能。

但是，使用

Liveness

探針時需要配置一個非常重要的設定，就是

initialDelaySeconds

設定。

如上所述，

Liveness

探針失敗會導緻Pod重新啟動。 在應用程式準備好之前，您需要確定探針不會啟動。 否則，應用程式将不斷重新開機，永遠不會準備好！

我建議使用

p99延遲

啟動時間作為initialDelaySeconds，或者隻是取平均啟動時間并添加一個緩沖區。 随着您應用的啟動時間變得越來越快，請確定更新這個數值。

結論

大多數人會告訴你健康檢查是分布式系統的基本要求，Kubernetes也不例外。 使用健康檢查為您的Kubernetes服務奠定了堅實的基礎，更好的可靠性和更長的正常運作時間。 值得慶幸的是，Kubernetes讓您輕松做到這些！

本文轉自DockOne-

Kubernetes最佳實踐S01E03：Kubernetes叢集健康檢查最佳實踐