一、概述
在 spring boot 2.3 中引入了容器探針,也就是增加了 /actuator/health/liveness 和 /actuator/health/readiness 這兩個健康檢查路徑,對于部署在 k8s 中的應用,spring-boot-actuator 將通過這兩個路徑自動進行健康檢查。本文主要根據(jù)官方文檔的描述實踐并記錄使用流程,從如下幾個方面進行介紹:
k8s 中的健康檢查spring-boot-actuator 中的 k8s 探針spring boot 健康檢查在 k8s 中的實踐二、K8s 容器健康檢查
1、k8s 中的探針
kubernetes 提供了三種探針(支持exec、tcp和http方式)來探測容器的狀態(tài):
LivenessProbe:容器存活性檢查,用于判斷容器是否健康,告訴 kubelet 一個容器什么時候處于不健康的狀態(tài)。如果 LivenessProbe 探針探測到容器不健康,則 kubelet 將刪除該容器,并根據(jù)容器的重啟策略做相應的處理。如果一個容器不包含 LivenessProbe 探針,那么 kubelet 認為該容器的 LivenessProbe 探針返回的值永遠是 Success;ReadinessProbe:容器就緒性檢查,用于判斷容器是否啟動完成且準備接收請求。如果ReadinessProbe探針探測到失敗,Endpoint Controller 將從 Service 的 Endpoint 中刪除包含該容器所在 Pod 的 IP 地址的Endpoint條目。如果容器不提供就緒態(tài)探針,則默認狀態(tài)為 Success。startupProbe: 容器啟動檢查,指示容器中的應用是否已經(jīng)啟動。如果提供了啟動探針,則所有其他探針都會被禁用,直到此探針成功為止。如果啟動探測失敗,kubelet 將殺死容器,而容器依其重啟策略進行重啟。 如果容器沒有提供啟動探測,則默認狀態(tài)為 Success。startupProbe 是在k8s v1.16加入了alpha版,官方對其作用的解釋是:Indicates whether the application within the Container is started. All other probes are disabled if a startup probe is provided, until it succeeds. If the startup probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a startup probe, the default state is Success
2、k8s 的探針處理程序
Probe 探針檢查是由 kubelet 對容器執(zhí)行的定期診斷,kubelet 調用由容器實現(xiàn)的 Handler (處理程序),每一個探針都可以配置如下三種類型的處理程序:
ExecAction: 在容器內執(zhí)行指定命令,如果命令退出時返回碼為 0 則認為診斷成功。通過執(zhí)行命令的方式來檢查服務是否正常,比如使用 cat 命令查看 pod 中的某個重要配置文件是否存在,若存在,則表示pod健康,反之異常。Exec 探測方式的 yaml 文件語法如下:
spec: containers: - name: liveness image: k8s.gcr.io/busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5
TCPSocketAction: 對容器的 IP 地址上的指定端口執(zhí)行 TCP 檢查,如果端口打開,則診斷被認為是成功的。
這種方式與HTTPget的探測機制有些類似,tcpsocket健康檢查適用于TCP業(yè)務,tcpSocket探測方式的yaml文件語法如下:
spec: containers: - name: goproxy image: k8s.gcr.io/goproxy:0.1 ports: - containerPort: 8080 readinessProbe: tcpSocket: port: 8080 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 15 periodSeconds: 20
在上述的yaml配置文件中,兩類探針都使用了,在容器啟動5秒后,kubelet將發(fā)送第一個readinessProbe探針,這將連接容器的8080端口,如果探測成功,則該pod為健康,十秒后,kubelet將進行第二次連接。
除了readinessProbe探針外,在容器啟動15秒后,kubelet將發(fā)送第一個livenessProbe探針,仍然嘗試連接容器的8080端口,如果連接失敗,則重啟容器。
HTTPGetAction: 對容器的 IP 地址上指定端口和路徑執(zhí)行 HTTP Get 請求,如果響應的狀態(tài)碼大于等于 200 且小于 400,則診斷被認為是成功的。Httpget探測方式的yaml文件語法如下:
spec: containers: - name: liveness image: k8s.gcr.io/liveness livenessProbe: httpGet: scheme: HTTP path: /healthz port: 8080 initialDelaySeconds: 3 periodSeconds: 3
上述配置文件中,探測方式為項容器發(fā)送HTTP GET請求,請求的是 8080 端口下的 healthz 文件,返回任何大于或等于200且小于400的狀態(tài)碼表示成功,任何其他代碼表示異常。
每次探測都將獲得以下三種結果之一:
Success(成功):容器通過了診斷。Failure(失敗):容器未通過診斷。Unknown(未知):診斷失敗,因此不會采取任何行動。
3、k8s 探針的配置
Probe 有如下配置字段,可以使用這些字段精確的控制存活和就緒檢測的行為:
initialDelaySeconds:容器啟動后要等待多少秒后存活和就緒探測器才被初始化,默認是 0 秒,最小值是 0。periodSeconds:執(zhí)行探測的時間間隔(單位是秒)。默認是 10 秒。最小值是 1。timeoutSeconds:探測的超時后等待多少秒。默認值是 1 秒。最小值是 1。successThreshold:探測器在失敗后,被視為成功的最小連續(xù)成功數(shù)。默認值是 1。 存活和啟動探測的這個值必須是 1。最小值是 1。failureThreshold:當探測失敗時,Kubernetes 的重試次數(shù)。 存活探測情況下的放棄就意味著重新啟動容器。 就緒探測情況下的放棄 Pod 會被打上未就緒的標簽。默認值是 3。最小值是 1。說明:在 Kubernetes 1.20 版本之前,exec 探針會忽略 timeoutSeconds:探針會無限期地 持續(xù)運行,甚至可能超過所配置的限期,直到返回結果為止。這一缺陷在 Kubernetes v1.20 版本中得到修復。LivenessProbe配置例子:
livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 30 // 容器啟動30s后啟動第一次探測 periodSeconds: 10 // 每隔10s啟動一次探測 timeoutSeconds: 3 // 超時時間3s successThreshold: 1 // 成功1次即表示容器健康 failureThreshold: 5 // 連續(xù)5次失敗,則判定容器不健康,默認3次
4、何時使用
何時使用啟動探針
kubelet 使用啟動探測器可以知道應用程序容器什么時候啟動了。 如果配置了這類探測器,就可以控制容器在啟動成功后再進行存活性和就緒檢查, 確保這些存活、就緒探測器不會影響應用程序的啟動。 這可以用于對慢啟動容器進行存活性檢測,避免它們在啟動運行之前就被殺掉。
何時使用存活探針
kubelet 使用存活探測器來知道什么時候要重啟容器。 例如,存活探測器可以捕捉到死鎖(應用程序在運行,但是無法繼續(xù)執(zhí)行后面的步驟)。 這樣的情況下重啟容器有助于讓應用程序在有問題的情況下更可用。
何時使用就緒探針
kubelet 使用就緒探測器可以知道容器什么時候準備好了并可以開始接受請求流量, 當一個 Pod 內的所有容器都準備好了,才能把這個 Pod 看作就緒了。 這種信號的一個用途就是控制哪個 Pod 作為 Service 的后端。 在 Pod 還沒有準備好的時候,會從 Service 的負載均衡器中被剔除的。
參考文章:
官網(wǎng) k8s 容器探針