編者語：這是 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健康检查如何做？官方推荐教程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。