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