知識星球編者語：這是 Google 開發者佈道師 Sandeep Dinesh[1]的影片[2]和部落格系列 “如何充分利用 Kubernetes 環境” 的第三部分。
分散式系統管理比較困難。很重要的原因是系統正常工作依賴很多不同的元件。任何一個元件出了問題，系統必須要能發現出問題的元件，繞開並且修複它，所有的這些都要自動完成。
健康檢查是發現你的應用實體是否正常工作的簡單方式。如果應用的某個實體不能工作，其他的服務不應該訪問或者請求該實體。請求應該傳送給應用的其他正常實體，過一段時間再嘗試異常實體。系統應該保證應用處於正常狀態。
預設情況下，Kubernetes 在容器內的 Pod 啟動後開始向 Pod 傳送流量，併在容器崩潰時重新啟動容器。雖然這已經“足夠好”，然而你可以透過自定義的健康檢查讓部署過程更加完美。Kubernetes 非常容易實現自定義健康檢查，所以沒有理由不去用它。
我們詳細介紹一下如何在 Kubernetes 叢集中選擇和設定 Readiness 和 Liveness 探針[3]。
健康檢查型別
Kubernetes 提供了2種健康檢查的方式。下麵我們來瞭解一下這兩種健康檢查的區別和使用。
READINESS
設計 Readiness 探針的目的是用來讓 Kubernetes 知道你的應用何時能對外提供服務。在服務傳送流量到 Pod 之前，Kubernetes必須確保 Readinetes 探針檢測成功。如果 Readiness 探針檢測失敗了，Kubernetes 會停掉 Pod 的流量，直到 Readiness 檢測成功。
LIVENESS
Liveness 探針能讓 Kubernetes 知道你的應用是否存活。如果你的應用是存活的，Kubernetes 不做任何處理。如果是掛掉的，Kubernetes 會移除異常的 Pod，並且啟一個新的 Pod 替換它。
健康檢查的作用
我們來看兩種場景下，如何使用Readiness 和 Liveness 探針幫助你構建更健壯的應用。
READINESS
假設你的應用需要時間進行預熱和啟動。即便行程已經啟動，你的服務依然是不可用的，直到它真的執行起來。如果想讓你的應用橫向部署多實體，這也可能會導致一些問題。因為新的複本在沒有完全準備好之前，不應該接收請求。但是預設情況下，只要容器內的行程啟動完成，Kubernetes 就會開始傳送流量過來。如果使用 Readiness 探針， Kubernetes 就會一直等待，直到應用完全啟動，才會允許傳送流量到新的複本。
LIVENESS
我們設想另外一種場景，你的應用產生了死鎖，導致行程一直夯住，並且停止處理請求。因為行程還處在活躍狀態，預設情況下， Kubernetes 認為一切正常，會繼續向異常Pod 傳送流量。透過使用 Liveness 探針， Kubernetes 會發現應用不再處理請求，然後重啟異常的 Pod 。
探針型別
接下來就是如何定義 Liveness 和 Readiness 探針了。有3種型別的探針實現方式可以選擇，分別是：HTTP、Command、TCP。你可以使用任何一種方式實現 Liveness 和 Readiness 探針。
HTTP
HTTP 可能是 Liveness 探針的最常用的實現方式。即便你的應用不是一個 HTTP 服務，你也可以透過在應用內部整合一個輕量級的HTTP 服務，以支援 Liveness 探針。Kubernetes 透過 ping 一個路徑，如果 HTTP 響應的狀態碼是 2xx 或者 3xx ，說明該應用是健康狀態，否則就是不健康狀態。
更多 HTTP探針資訊[4]
COMMAND
對於命令列探針，kubernetes 在容器內執行命令，如果傳回0，說明服務是健康狀態，否則就是不健康狀態。當你不能或者不想提供額外的 HTTP 服務，但是能使用命令列的時候，透過命令列來進行健康檢查很有用的。
更多 Command探針資訊[5]
TCP
最後一種是 TCP 探針。Kubernetes 嘗試跟某個埠建立一個 TCP 連線。如果能建立連線，表示容器是健康狀態，否則是不健康狀態。
假如 HTTP 和命令列都不能使用的情況下， TCP 的方式就派上用場了。例如 gRPC[6]或者 FTP 服務中，TCP 型別就是首選。
更多 TCP探針資訊[7]
配置探針啟動的延遲
探針有多種配置。你能指定探針多久執行一次、成功和失敗的閾值、多長時間的響應等待等等。 探針配置檔案[8]非常清楚的介紹了這些不同的配置的作用。
當你使用 Liveness 探針的時候，initialDelaySeconds 是你需要設定的非常重要的配置。
如前面說的，Liveness 探針檢查失敗會導致 Pod 重啟。你必須確保 Liveness 探針在應用準備好之後生效。否則，應用會一直不停被重啟。
我推薦使用 p99[9]作為 initialDelaySeconds 的生效時間，或者簡單的使用平均啟動時間加一個緩衝時間。如果應用的啟動時間變長或者變短了，確保更新了這個配置。
總結
很多人都會告訴你，分散式系統必須有健康檢查，Kubernetes 也不例外。Kubernetes 提供了非常方便的健康檢查，為你Kubernetes 中的服務提供更穩定的、更可靠的、更高的正常執行時間。
本文作者Sandeep Dinesh，由鄧啟明翻譯。轉載譯文請註明出處，技術原創及架構實踐文章，歡迎透過公眾號選單「聯絡我們」進行投稿。
參考連結
[1] https://twitter.com/sandeepdinesh?lang=en
[2] https://www.youtube.com/playlist?list=PLIivdWyY5sqL3xfXz5xJvwzFW_tlQB_GB
[3] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/
[4] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-http-request
[5] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command
[6] https://grpc.io/
[7] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-tcp-liveness-probe
[8] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes
[9] https://www.quora.com/What-is-p99-latency
相關閱讀：
Kubernetes大叢集怎麼管?基於監控的彈性伸縮方法
管理數萬個實體，服務上百個業務：kubernetes在騰訊遊戲的使用及演進歷程
活動預告：
6 月 1 ~ 2 日，GIAC 全球網際網路架構大會將於深圳舉行。GIAC 是高可用架構技術社群推出的面向架構師、技術負責人及高階技術從業人員的技術架構大會。今年的 GIAC 已經有騰訊、阿裡巴巴、百度、今日頭條、科大訊飛、新浪微博、小米、美圖、Oracle、鏈家、唯品會、京東、餓了麼、美團點評、羅輯思維、ofo、曠視、LinkedIn、Pivotal等公司專家出席。
本期 GIAC 大會上，部分精彩的議題如下：
參加 GIAC，盤點2018最新技術。點選“閱讀原文”瞭解大會更多詳情
