如何給容器化部署業務配置合適的探針?
readinessprobe簡介
readinessprobe,就緒探針,是k8s中的一個概念。當 readinessprobe 檢查通過,表示服務就緒,可以接受流量。當 readinessprobe 檢查不通過,表示服務沒有就緒,不具備提供服務流量的能力。和我們使用的consul agent的對服務的探活是類似的。
可以使用這些欄位精確的控制存活和就緒檢測的行為:
initialDelaySeconds
:容器啟動後要等待多少秒後存活和就緒探測器才被初始化,預設是 0 秒,最小值是 0。periodSeconds
:執行探測的時間間隔(單位是秒)。預設是 10 秒。最小值是 1。timeoutSeconds
:探測的超時後等待多少秒。預設值是 1 秒。最小值是 1。successThreshold
:探測器在失敗後,被視為成功的最小連續成功數。預設值是 1。 存活和啟動探測的這個值必須是 1。最小值是 1。failureThreshold
:當探測失敗時,Kubernetes 的重試次數。 存活探測情況下的放棄就意味著重新啟動容器。 就緒探測情況下的放棄 Pod 會被打上未就緒的標籤。預設值是 3。最小值是 1。
目前 readinessprobe 支援三種探測方式:
- http
- tcp
- exec
這三種我們建議使用http方式,更加準確反應服務的健康狀態。
http 探測 demo:
|
tcp demo:
|
最佳實踐
對於探針的配置,有一定的最佳實踐。
有以下幾點:
- ReadinessProbe 要反應業務的真實健康狀況。如果有預熱邏輯,預熱後再讓ReadinessProbe 通過檢查。
- LivenessProbe 要慎用,LivenessProbe 失敗會重啟 Pod,不要輕易使用,除非你瞭解後果並且明白為什麼你需要它,參考 Liveness Probes are Dangerous 。
- LivenessProbe 相對ReadinessProbe 條件要更寬鬆。
如果配置LivenessProbe,注意設定合適的 initialDelaySeconds 值,建議180s或更長,具體根據自己業務啟動情況配置。尤其java 應用。
線上配置可以參考如下規則:
|
|
如何檢查
readinessprobe通過之前,在ones看到例項的狀態為HealthChecking的狀態,如果長時間處於HealthChecking狀態,需要在pod詳情中檢視是否有健康檢查失敗的事件,通常為:Readiness probe failed: xxx
舉例:
Readiness probe failed: dial tcp 192.168.158.87:8080: connect: connection refused
參考:https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/