什么是健康檢查？
對於部署成功的應用來說，通過訪問接口、執行特定命令等方式判斷應用是否存活、正常的方式稱為健康檢查。
在 OpenShift 或 Kubernetes 中，健康檢查都有兩個探針，分別是 就緒探針(Readiness Probe) 與 存活探針(Liveness Probe)：
- 就緒探針(Readiness Probe)，即指收集應用已經准備好接收流量狀態的探針。通過就緒狀態判斷Pod是否可以納入到Service的負載均衡列表中。當Pod處於未就緒狀態時，會被自動移出Service負載均衡列表。
- 存活探針(Liveness Probe)，即指收集應用存活狀態，確保應用在某種特定狀態時重啟Pod的探針。通過捕獲特定狀態，重啟Pod以提高可用性。
以上兩種探針可獨立使用，亦可配合使用。
本文以OpenShift 3.9版本舉例，新版本類似，Kubernetes 1.16以后新增的Startup Probe復用了Liveness Probe功能類似，其先於Liveness Probe執行，以防止慢啟動服務誤殺，此處不做細說（因為OpenShift低版本里還沒有）
使用健康檢測場景舉例
以下示例均為未設置健康檢測探針時的場景
- 場景一：Pod內應用未就緒，Pod處於Running狀態，Pod納入到Service負載均衡列表中，當有流量進入時，返回服務不可用狀態，如Connection Refuse。
- 場景二：Pod內應用在某次請求中，出現異常，暫時無法提供服務，處於未就緒狀態，但其仍在負載均衡列表中，當流量負載到此節點時，應用返回超時、網關異常或Connection Refuse等，Service無法感知此Pod異常，無法故障轉移。
- 場景三：Pod內應用出現死鎖、假死狀態，重啟Pod可臨時解決的場景。
- 場景四：滾動更新，僅當服務啟動完成后才能提供服務能力
- 場景五：擴容與縮容，流量只發到就緒的應用上
針對場景一、二、四、五，使用就緒探針即可解決；針對場景三，使用存活探針即可解決。
為OpenShift上的應用添加健康檢查
以下使用目前公司生產環境OpenShift 3.9環境舉例，只是簡單列出方法
進入Deployments進入待添加健康檢查的應用，Actions-> Edit Health Checks
就緒探針與存活探針設置方式一致，都有三種探針實現類型，以就緒探針配置舉例，存活探針可參考配置。
使用 容器內命令(Container Command) 類型
使用 HTTP GET請求 類型
使用 TCP Socket 類型
添加健康檢查后
添加完成后，在應用具體部署版本模板中會有健康檢查探針的體現，只有健康檢查通過的Pod才會提示Ready狀態
OpenShift中對Kubernetes的健康檢查進行了簡單封閉，通過oc命令行工具查看pod，如圖
period為健康檢測間隔時間，OpenShift注掉了成功與失敗數
注意事項
使用Web界面添加健康檢測探針時，TCP Socket 與 HTTP GET 類型的探針只能使用模板的端口號，相對而言 Container Command類型的自由度更高些。
注：經過實踐及線上出現的問題，發現容器命令方式如果是curl訪問的內部服務，可能會出現探針報錯，而不是不健康狀態。此時Service處匹配的Pod列表不會下線並更新！
這個問題源於k8s對這個情況的判斷，所以這里推薦使用HTTP GET 與 TCP Socket 類型探針，如果端口號不同時，可在添加探針后同步修改Deployment yaml探針定義即可。
參考文檔
https://docs.openshift.com/container-platform/3.9/dev_guide/application_health.html
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes