共計 1597 個字符，預計需要花費 4 分鐘才能閱讀完成。

丸趣 TV 小編給大家分享一下如何使用 Kubernetes 健康檢查，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

Liveness Probes

Kubernetes 健康檢查被分成  liveness 和 readiness probes。liveness probes 是用來檢測你的應用程序是否正在運行。通常情況下，你的程序一崩潰，Kubernetes 就會看到這個程序已經終止，然后重啟這個程序。但是 liveness probes 的目的就是捕捉到當程序還沒有終止，還沒有崩潰或者還沒陷入死鎖的情況。所以一個簡單的 HTTP 回應能夠滿足。

以下是一個我使用的為 Go 應用程序使用健康檢查的例子。

在配置中

上圖就是告訴 Kubernetes，應用程序正在運行。initialDelaySeconds  告訴 Kubernetes 在看到 pod 啟動之后要延遲開啟健康檢查，并說清楚延遲幾秒。如果你的應用程序需要一些時間來啟動，你可以用這個設置來幫助它。timeoutSeconds 會告訴 Kubernetes 應該為健康檢查等待多長時間。對于 liveness probes，這個時間不能太長，但是萬一有欠載的情況，你就真的需要給你的應用足夠的時間來回應。

如果應用程序從未啟動，或者回應過來一個 HTTP 錯誤代碼，那么之后 Kubernetes 就會重新啟動 pod。你最好不要在 liveness probes 中進行太炫酷的什么動作，想都不要想，因為一旦 liveness probes 功能開始失效的話，這會引起你的應用程序錯誤

Readiness Probes

Readiness Probes 跟 liveness probes 十分相似，只有失效檢測的結果是不一樣的。Readiness Probes 是用來檢查你的應用程序是否可以為通信服務。這跟 liveness 有些微妙的不同。比如，你的應用程序取決于數據庫與 memcached。如果上面兩個都在良好狀態，為你的應用提供通信，然后你就可以說這兩個都是你的應用的“readiness”。

如果你的應用的 readness probe 運行失敗，那么 pod 就會從組成 service 的端點被刪除。這樣的話，沒有準備好的 pods 就不會有流量通信通過 Kubernetes 服務發現機制來發送給他們。當遇到 service 的新 pod 啟動時；拓展 events 時，滾動更新等狀態的時候，這個狀態十分有幫助。Readiness probes 確認在 pods 開啟的時候 pods 沒有被發通信，還有他們處于待服務通信的時候也沒有。

Readiness probe 的定義跟 liveness probes 的定義一樣。Readiness probes 被定義為 Deployment 的一部分，比如像這樣：

你是不是想要檢驗一下是否可以在你的 readiness probe 中連接到你的應用程序的依賴。以我們依賴數據庫為例，我們想要檢查我們是否能夠連接到兩者。

情況看起來應該是這樣的（下圖所示）。我檢查 memcached 和數據庫，如果有一個不可得，那么我就會回復一個 503 回應狀態。

更穩定的應用程序

Liveness 和 Readiness probes 對增加應用程序的穩定性很有幫助。他們幫助確認通信是否只流通到為它準備的實例上，當應用變得無反應的時候，自我治愈也是一樣。他們就是我同事所說的叫做“12 Fractured Apps”的更好的解決方法。有了合適的健康檢查，你就能夠以任意順序配置你的應用程序，不需要擔心相關性或者復雜的進入點腳本。當應用程序準備好的時候，他們會開始服務通信，所以自動調度和滾動更新運行得十分順利。

以上是“如何使用 Kubernetes 健康檢查”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！