本篇是Google Developer Advocate Sandeep Dinesh關於如何充分利用Kubernetes環境的七部分視訊和部落格系列的第三部分。
第一篇：如何構建儘可能小的容器映象？第二篇：如何使用名稱空間管理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讓您輕鬆做到這些！
相關連結：

1. https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-http-request

2. https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command

3. https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-tcp-liveness-probe

4. https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes

5. https://www.quora.com/What-is-p99-latency

原文連結：https://cloudplatform.googleblog.com/2018/05/Kubernetes-best-practices-Setting-up-health-checks-with-readiness-and-liveness-probes.htmlKubernetes應用實戰培訓

Kubernetes應用實戰培訓將於2018年9月14日在上海開課，3天時間帶你係統掌握Kubernetes。本次培訓包括：容器特性、映象、網路；Docker特性、架構、元件、概念、Runtime；Docker安全；Docker實踐；Kubernetes架構、核心元件、基本功能；Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則；Kubernetes的實踐、執行時、網路、外掛已經落地經驗；微服務架構、DevOps等，點選下方圖片檢視詳情。