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連線。如果它可以建立連線，容器被認為是健康的; 如果它不能被認為是不健康的。這常用於對或FTP服務的探測。

更多關於TCP探測可參考。

初始探測延遲

我們可以配置K8S健康檢查執行的頻率，檢查成功或失敗的條件，以及響應的超時時間。可參考。

存活探針探測失敗會導致pod重新啟動，所以配置初始探測延遲initialDelaySeconds十分重要，要確保在應用準備之後探針才啟動。否則，應用將無限重啟！

我建議使用啟動時間作為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

作者：極客人
連結：