簡介
K8S服務健康檢查從兩個維度進行，分別爲：就緒狀態檢查(readiness)和存活狀態檢查(liveness)。
存活探針和就緒探針被稱作健康檢查。這些容器探針是一些週期性運行的小進程，這些探針返回的結果如（成功，失敗或者未知）反映容器在Kubernetes的狀態。基於結果Kubernetes會判斷如何處理每個容器，以保障集羣服務高可用性和業務與連續性。名詞解釋
readiness：用於探測HTTP是否就緒，是否可以接受業務請求。如果ReadinessProbe探針檢測到失敗，則Pod的狀態被修改。Endpoint Controller將從Service的Endpoint中刪除包含該容器所在Pod的Endpoint。
liveness：用於探測HTTP是否存活，如果LivenessProbe探針探測到容器不健康，則kubelet殺掉該容器，並根據容器的重啓策略做相應的處理。如果一個容器不包含LivenessProbe探針，則kubelet認爲該容器的LivenessProbe探針返回的值永遠是“Success”。使用場景
readiness 使用場景：
Pod對象啓動後，容器應用通常需要一段時間才能完成其初始化過程，例如加載配置或數據，甚至有些程序需要運行某類的預熱過程，若在此階段完成之前接入客戶端的請求，勢必會因爲等待太久而影響用戶體驗，這時就需要就緒探針。如果沒有將就緒探針添加到pod中，它們幾乎會立即成爲服務端點。如果應用程序需要很長時間才能開始監聽傳入連接，則在服務啓動但尚未準備好接收傳入連接時，客戶端請求將被轉發到該pod。因此，客戶端會看到"連接被拒絕"類型的錯誤。
liveness 使用場景：
Liveness探針讓Kubernetes知道你的應用程序是狀態是否健康。但是如果liveness檢查結果是fail就會直接kill container，當然如果你的restart policy 是always 會重啓pod。
備註：pod重啓策略：PodSpec 中有一個 restartPolicy 字段，可能的值爲 Always、OnFailure 和 Never 。默認爲
Always。
支持檢測類型：
Kubernetes 支持三種方式來執行探針：
exec：在容器中執行一個命令，如果命令退出碼返回0則表示探測成功，否則表示失敗;
tcpSocket：對指定的容IP及端口執行一個TCP檢查，如果端口是開放的則表示探測成功，否則表示失敗;
httpGet：
HTTP探測意味在特定時間間隔執行HTTP請求響,應的狀態碼用於決定需要對pod執行的操作。如果狀態代碼在區間 [200,300) 中，則一切正常。
如果存活探測器的狀態代碼是 4xx 或 5xx ，則代表pod已被重啓。
如果就緒探測器的狀態代碼是 4xx 或 5xx ，那麼pod會被標記爲不健康，並且Kubernetes爲了提高可靠性和正常運行時間將不會再將HTTP請求轉發給它。
探測執行返回結果類型
有以下三種返回結果，每次僅會返回一種：
Success：Container通過了檢查。
Failure：Container未通過檢查。
Unknown：未能執行檢查，因此不採取任何措施。探測(健康檢查)配置參數
通用配置，通過下面的配置能準確的控制 liveness 和 readiness 檢查時間策略：
initialDelaySeconds：容器啓動後第一次執行探測是需要等待多少秒。
periodSeconds：執行探測的頻率。默認是10秒，最小1秒。
timeoutSeconds：探測超時時間。默認1秒，最小1秒。
successThreshold：探測失敗後，最少連續探測成功多少次才被認定爲成功。默認是 1。對於 liveness 必須是 1。最小值是 1。
failureThreshold：探測成功後，最少連續探測失敗多少次才被認定爲失敗。默認是 3。最小值是 1。
HTTP probe 中可以給 httpGet設置其他配置項：
host：連接的主機名，默認連接到 pod 的 IP。您可能想在 http header 中設置 “Host” 而不是使用 IP。
scheme：連接使用的 schema，默認HTTP。
path: 訪問的HTTP server 的 path。
httpHeaders：自定義請求的 header。HTTP運行重複的 header。
port：訪問的容器的端口名字或者端口號。端口號必須介於 1 和 65525 之間。
健康檢查的最佳實踐列表：
建議應用程序開發人員遵循最佳實踐如下：
1：存活和就緒的結果處理程序需要是互相獨立的程序接口：
如前所述，對於在K8s中部署的每個產品服務，應該提供2個接口分別處理HTTP請求“存活”和“就緒”的健康檢查，確保接口能夠完成健康檢查使命。2：不要把“存活/就緒”探針的邏輯與你的程序解耦：
這適用於作業處理應用程序。對於K8s集羣確保服務容器內運行應用程序狀態正常非常重要，集羣能夠幫助我們對服務實施自動健康檢查。
如果存活/就緒邏輯被解耦了在新進程中運行，則結果不準確。
不要在“存活”處理程序裏實現任何邏輯判斷，如果進程正在運行，直接返回狀態200，如果不是，則返回5xx或者true、false。讓liveness健康檢查快速的獲取狀態代碼來做出決定，返回異常則Kubernetes會重新啓動pod。提高服務的可靠性。3：在“就緒”探針的處理程序中實現邏輯，以便提供有關應用程序準備情況的詳情：
就緒探針讓K8s知道pod是否已準備好接收HTTP請求。作爲開發人員，在此處實現一些邏輯來檢查應用程序的所有後端依賴的可用性非常重要。當實現就緒處理程序時，需要清楚的知道您的應用程序依賴於哪些功能。換句話說，在就緒處理程序裏，需要運行所有步驟以保證應用程序已準備好接收和處理http/https請求的。
例如:如果應用程序需要建立與數據庫的連接以準備處理HTTP請求，那麼在“ready（就緒）”程序中就必須檢查是否已建立與數據庫的連接並可以使用。
不要在就緒檢查接口邏輯內添加進程拉起或則進程處理邏輯，這些邏輯可能會與集羣的健康檢查服務拉起策略衝突。就緒檢查程序接口要能真實的反應程序的就緒狀態。這個就緒探針只是爲了檢查應用程序是否準備就緒，而不是應用健康檢查。
小疑問的驗證：
1：進程啓動後就緒檢查還會繼續執行嗎？
2：存活檢查時間可以單獨設置嗎？
3：就緒檢查、存活檢查設置檢查時間會相互影響嗎？測試環境介紹：
k8s 版本：1.6+
鏡像：nginx就緒檢查 5 秒一次；
readinessProbe:
failureThreshold: 3
httpGet:
httpHeaders:
- name: Host
value: localhost
path: /
port: 80
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 5存活狀態檢查 9 秒一次：
livenessProbe:
failureThreshold: 3
httpGet:
httpHeaders:
- name: Host
value: 127.0.0.1
path: /50x.html
port: 80
scheme: HTTP
initialDelaySeconds: 60
periodSeconds: 9
successThreshold: 1
timeoutSeconds: 200服務輸出日誌
可以看到服務輸出日誌如下：
[30/Mar/2020:12:26:16 +0000] "GET / HTTP/1.1" 200 612 "-" "kube-probe/1.16" "-" <===就緒檢查
[30/Mar/2020:12:26:21 +0000] "GET / HTTP/1.1" 200 612 "-" "kube-probe/1.16" "-" <===就緒檢查
#就緒檢查 5 秒一次： 2020:12:26:16s ~ 21s 正好5s
[30/Mar/2020:12:26:24 +0000] "GET /50x.html HTTP/1.1" 200 537 "-" "kube-probe/1.16" "-" <===健康檢查
[30/Mar/2020:12:26:26 +0000] "GET / HTTP/1.1" 200 612 "-" "kube-probe/1.16" "-" <===就緒檢查
[30/Mar/2020:12:26:31 +0000] "GET / HTTP/1.1" 200 612 "-" "kube-probe/1.16" "-" <===就緒檢查
[30/Mar/2020:12:26:33 +0000] "GET /50x.html HTTP/1.1" 200 537 "-" "kube-probe/1.16" "-" <===健康檢查
#存活狀態檢查 9 秒一次：2020:12:26:24s ~ 33s 正好9s！ 驗證結果如下：
1：進程啓動後就緒檢查還會繼續執行嗎？
進程啓動後就緒檢查會按照設置檢查時間策略繼續運行。
2：存活檢查時間可以單獨設置嗎？
存活健康檢查的時間策略可以單獨定義。
3：就緒檢查、存活檢查設置檢查時間會相互影響嗎？
兩個檢查的時間相互獨立，互不影響。參考文檔：
https://www.itsiv.com/2020/03/30/%e5%b0%b1%e7%bb%aa%e7%8a%b6%e6%80%81%e6%a3%80%e6%9f%a5readiness%e5%92%8c%e5%ad%98%e6%b4%bb%e7%8a%b6%e6%80%81%e6%a3%80%e6%9f%a5liveness/
https://www.jianshu.com/p/d87a50272310
https://www.codercto.com/a/40504.html
https://www.cnblogs.com/wangxu01/articles/11660599.html
https://blog.csdn.net/luanpeng825485697/article/details/84900620