使用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」的更好的解決方法。有了合適的健康檢查，你就可以以任意順序配置你的應用程序，不須要擔憂相關性或者複雜的進入點腳本。當應用程序準備好的時候，他們會開始服務通訊，因此自動調度和滾動更新運行得十分順利。