如何給容器化部署業務配置合適的探針?
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/
