K8S使用就緒和存活探針配置健康檢查

健康檢查

健康檢查（Health Check）可用於服務運行的狀態監控，好比騰訊旗下的DNSPOD的D監控，要求配置一個訪問路徑以判斷網站是否能夠正常訪問實際上就是一個健康檢查，當發現健康檢查失敗時會發送一個郵件通知或者短信來告知網站管理員進行維修。

K8S流量轉發

而在現代一些分佈式系統中，用戶訪問再也不是單臺主機，而是一個由成百上千臺實例組成的集羣，用戶請求經過負載均衡器分發到不一樣的實例，負載均衡幫助解決單臺服務器的訪問壓力，同時提升了系統的高可用性，而健康檢查經常做爲當前實例是否「可用」的判斷標準。即：當系統發現某臺實例健康檢查不經過，負載均衡器將不會把流量導向該實例。

如今的雲服務廠商好比AWS通常都爲負載均衡配備了健康檢查，而Kubernetes提供了兩種探針來檢查容器的狀態，Liveliness和Readiness，根據官方文檔，Liveliness探針是爲了查看容器是否正在運行，翻譯爲存活探針（livenessProbe），Readiness探針是爲了查看容器是否準備好接受HTTP請求，翻譯爲就緒探針（readinessProbe）。
在Kubernetes中，Pod是Kubernetes建立及管理的最小的可部署的計算單元，一個Pod由一個或者多個容器（Docker，rocket等等）組成，這些容器共享內存，網絡以及運行容器的方式。

在Kubernetes上下文中存活探針和就緒探針被稱做健康檢查。這些容器探針是一些週期性運行的小進程，這些探針返回的結果（成功，失敗或者未知）反映了容器在Kubernetes的狀態。基於這些結果，Kubernetes會判斷如何處理每一個容器，以保證彈性，高可用性和更長的正常運行時間。

就緒探針

就緒探針旨在讓Kubernetes知道你的應用是否準備好爲請求提供服務。Kubernetes只有在就緒探針經過纔會把流量轉發到Pod。若是就緒探針檢測失敗，Kubernetes將中止向該容器發送流量，直到它經過。

存活探針

Liveness探測器是讓Kubernetes知道你的應用是否活着。若是你的應用還活着，那麼Kubernetes就讓它繼續存在。若是你的應用程序已經死了，Kubernetes將移除Pod並從新啓動一個來替換它。

工做過程

讓咱們看看兩個場景，來看看就緒探針和存活探針怎樣幫助咱們構建更高可用的的系統。

就緒探針

一個應用每每須要一段時間來預熱和啓動，好比一個後端項目的啓動須要鏈接數據庫執行數據庫遷移等等，一個Spring項目的啓動也須要依賴Java虛擬機。即便該過程已啓動，您的服務在啓動並運行以前也沒法運行。應用在徹底就緒以前不該接收流量，但默認狀況下，Kubernetes會在容器內的進程啓動後當即開始發送流量。經過就緒探針探測，直到應用程序徹底啓動，而後才容許將流量發送到新副本。

 

就緒探針的工做過程

存活探針

讓咱們想象另外一種狀況，當咱們的應用在成功啓動之後由於一些緣由「宕機」，或者遇到死鎖狀況，致使它沒法響應用戶請求。
在默認狀況下，Kubernetes會繼續向Pod發送請求，經過使用存活探針來檢測，當發現服務不能在限定時間內處理請求（請求錯誤或者超時），就會從新啓動有問題的pod。

存活探針的工做過程

探針類型

探針類型是指經過何種方式來進行健康檢查，K8S有三種類型的探測：HTTP，Command和TCP。
HTTP
HTTP探測多是最多見的探針類型。即便應用不是HTTP服務，也能夠建立一個輕量級HTTP服務器來響應探測。好比讓Kubernetes經過HTTP訪問一個URL，若是返回碼在200到300範圍內，就將應用程序標記爲健康狀態，不然它被標記爲不健康。
更多關於HTTP探測可參考這裏。

命令
對於命令探測，是指Kubernetes在容器內運行命令。若是命令以退出代碼0返回，則容器將標記爲正常。不然，它被標記爲不健康。
更多關於命令探測可參考這裏。

TCP
最後一種類型的探測是TCP探測，Kubernetes嘗試在指定端口上創建TCP鏈接。若是它能夠創建鏈接，容器被認爲是健康的; 若是它不能被認爲是不健康的。這經常使用於對gRPC或FTP服務的探測。

更多關於TCP探測可參考這裏。

初始探測延遲

咱們能夠配置K8S健康檢查運行的頻率，檢查成功或失敗的條件，以及響應的超時時間。可參考有關配置探針的文檔。

存活探針探測失敗會致使pod從新啓動，因此配置初始探測延遲initialDelaySeconds十分重要，要確保在應用準備以後探針才啓動。不然，應用將無限重啓！

我建議使用p99啓動時間做爲initialDelaySeconds，或者取平均啓動時間外加一個buffer。同時根據應用程序的啓動時間更新這個值。

舉例

如下面的一個K8S的配置代碼爲例，

• K8S將在Pod開始啓動後120s(initialDelaySeconds)後利用HTTP訪問8080端口的/actuator/health，若是超過10s或者返回碼不在200~300內，就緒檢查就失敗
• 相似的，在Pod運行過程當中，K8S仍然會每隔5s(periodSeconds檢測8080端口的/actuator/health

apiVersion: apps/v1beta1
kind: Deployment
...
...
        readinessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 120
          timeoutSeconds: 10
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 60
          timeoutSeconds: 10
          periodSeconds: 5

參考資料

• 【Kubernetes best practices: Setting up health checks with readiness and liveness probes】
• 【Kubernetes存活探針和就緒探針的最佳實踐】