健康檢查
健康檢查（Health Check）可用于服務運行的狀態監控，比如騰訊旗下的DNSPOD的D監控，要求配置一個訪問路徑以判斷網站是否可以正常訪問實際上就是一個健康檢查，當發現健康檢查失敗時會發送一個郵件通知或者短信來告知網站管理員進行維修。
而在現代一些分布式系統中，用戶訪問不再是單臺主機，而是一個由成百上千臺實例組成的集群，用戶請求通過負載均衡器分發到不同的實例，負載均衡幫助解決單臺服務器的訪問壓力，同時提高了系統的高可用性，而健康檢查常常作為當前實例是否“可用”的判斷標準。即：當系統發現某臺實例健康檢查不通過，負載均衡器將不會把流量導向該實例。
現在的云服務廠商比如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健康檢查運行的頻率，檢查成功或失敗的條件，以及響應的超時時間?？蓞⒖?a target="_blank" rel="nofollow">有關配置探針的文檔。
存活探針探測失敗會導致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
參考資料
