簡介
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：就緒檢查、存活檢查設定檢查時間會互相影響嗎？
兩個檢查的時間互相獨立，互不影響。