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探針可以幫助您構建魯棒性更強的應用程式。

Readiness

讓我們假設您的應用需要一分鐘的時間來預熱並開始。 即使該過程已啟動，您的服務在啟動並執行之前也無法執行。 如果要將此部署擴充套件為具有多個副本，也會出現問題。 新副本在完全就緒之前不應接收流量，但預設情況下，Kubernetes會在容器內的程式啟動後立即開始傳送流量。 透過使用Readiness探針，Kubernetes等待應用程式完全啟動，然後才允許服務將流量傳送到新副本。

Liveness

讓我們假設另一種情況，你的應用程式有一個令人討厭的死鎖情況，導致它無限期掛起並停止提供請求服務。 因為該服務還在執行，預設情況下Kubernetes認為一切正常並繼續向已經broken的Pod傳送請求。 透過使用Liveness探針，Kubernetes會檢測到應用程式不再提供請求並重新啟動有問題的Pod。

探針型別

下一步是定義測試Readiness和Liveness的探針。 有三種型別的探測：HTTP、Command和TCP。 您可以使用它們中的任何一個進行Liveness和Readiness檢查。

HTTP

HTTP探針可能是最常見的自定義Liveness探針型別。 即使您的應用程式不是HTTP服務，您也可以在應用程式內建立輕量級HTTP服務以響應Liveness探針。 Kubernetes去ping一個路徑，如果它得到的是200或300範圍內的HTTP響應，它會將應用程式標記為健康。 否則它被標記為不健康。

您可以在此處[1]閱讀有關HTTP探針的更多資訊。

Command

對於Command探針，Kubernetes則只是在容器內執行命令。 如果命令以退出程式碼0返回，則容器標記為健康。 否則，它被標記為不健康。 當您不能或不想執行HTTP服務時，此型別的探針則很有用，但是必須是執行可以檢查您的應用程式是否健康的命令。

您可以在此處[2]閱讀有關Command探針的更多資訊。

TCP

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

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

您可以在此處[3]閱讀有關TCP探針的更多資訊。

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

可以透過多種方式配置探針。 您可以指定它們應該執行的頻率，成功和失敗閾值是什麼，以及等待響應的時間。 有關配置探針的文件[4]非常清楚地介紹了其不同的選項及功能。

但是，使用Liveness探針時需要配置一個非常重要的設定，就是initialDelaySeconds設定。

如上所述，Liveness探針失敗會導致Pod重新啟動。 在應用程式準備好之前，您需要確保探針不會啟動。 否則，應用程式將不斷重啟，永遠不會準備好！

我建議使用p99延遲[5]啟動時間作為initialDelaySeconds，或者只是取平均啟動時間並新增一個緩衝區。 隨著您應用的啟動時間變得越來越快，請確保更新這個數值。

結論

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

相關連結：

原文連結：https://cloudplatform.googleblog.com/2018/05/Kubernetes-best-practices-Setting-up-health-checks-with-readiness-and-liveness-probes.html