要想Pod好--健康檢查少不了

作者：不焦躁的程序員 2023-10-14 15:36:14

云計(jì)算

云原生 本文主要從以下六個(gè)方面介紹Pod的健康檢查：剛接觸K8S的糗事、Pod生命周期、重啟策略、健康檢查、如何選擇探針、實(shí)戰(zhàn)。

要想Kubernetes里每個(gè)服務(wù)的可用性更高，那么對(duì)Pod的健康檢查是少不了的。Pod生命周期和健康檢查是我們最常接觸的基礎(chǔ)知識(shí)，雖說是基礎(chǔ)吧，但如果理解不好，出現(xiàn)問題時(shí)很容易抓耳撓腮，揪頭發(fā)。

本文主要從以下六個(gè)方面介紹Pod的健康檢查：剛接觸K8S的糗事、Pod生命周期、重啟策略、健康檢查、如何選擇探針、實(shí)戰(zhàn)，最后還會(huì)有知識(shí)點(diǎn)的總結(jié)和排查Pod問題的總結(jié)。

一、剛接觸K8S的糗事

回想2019年我剛開始接觸Kubernetes時(shí)，碰到Pod一直起不來的情況，就開始抓瞎。后來漸漸地掌握了一些排查方法之后，這種情況才得以緩解。

隨著時(shí)間推移，又碰到了問題。有一天在部署某個(gè)springboot微服務(wù)時(shí)，在開發(fā)測(cè)試環(huán)境部署了好多次，只有幾次能成功啟動(dòng)，大部分的部署未能成功啟動(dòng)。但是生產(chǎn)環(huán)境卻每次都能成功部署。當(dāng)時(shí)這個(gè)問題困擾了我很久?，F(xiàn)在想來也是蠻有意思的。

相信很多你已經(jīng)猜出來答案了，對(duì)，跟我們今天要講的健康檢查有關(guān)。

二、Pod生命周期

談健康檢查之前，首先得一起回顧下Pod的生命周期 或者 說是Pod的狀態(tài)。

Pod 的生命周期，從 Pending 狀態(tài)開始， 如果Pod中至少有一個(gè)應(yīng)用容器正常啟動(dòng)，則進(jìn)入 Running狀態(tài)，之后，如果Pod中的容器正常退出則進(jìn)入 Succeeded狀態(tài)，如果Pod中的容器非正常終止則進(jìn)入 Failed 狀態(tài)。

• Pending狀態(tài)：此時(shí)Pod已經(jīng)被K8S接受并且創(chuàng)建，但是Pod內(nèi)還沒有容器被創(chuàng)建，這個(gè)過程包括：等待Pod被調(diào)度的時(shí)間、下載鏡像的時(shí)間。
• Running狀態(tài)：此時(shí)Pod已經(jīng)運(yùn)行在某個(gè)節(jié)點(diǎn)上，Pod內(nèi)所有容器都已經(jīng)創(chuàng)建，并且有容器處于如下狀態(tài)：運(yùn)行狀態(tài)、正在啟動(dòng)狀態(tài) 或 正在重啟狀態(tài)。
• Succeeded狀態(tài)：此時(shí)Pod內(nèi)所有容器都成功執(zhí)行并且退出。
• Failed狀態(tài)：此時(shí)Pod內(nèi)所有容器都已終止，但是有容器是非正常終止的。
• Unknown狀態(tài)：無法獲取Pod狀態(tài)，通常是因?yàn)镻od與所在主機(jī)通信失敗，也可能是別的原因。

三、重啟策略

Pod的重啟是由該P(yáng)od所處的Node節(jié)點(diǎn)上的kubelet 進(jìn)行判斷和控制的。kubelet會(huì)根據(jù)重啟策略進(jìn)行相應(yīng)操作。

Pod的重啟策略有3個(gè)：Always、OnFailure、Never，默認(rèn)是Always。

• Always：重啟策略是Always時(shí)，那么當(dāng)容器運(yùn)行狀態(tài)是失效時(shí)，kubelet會(huì)自動(dòng)重啟該容器，比如：存活探針檢測(cè)到應(yīng)用不健康了，就會(huì)自動(dòng)重啟Pod。
• OnFailure：重啟策略是OnFailure時(shí)，那么當(dāng)容器是Failed狀態(tài)時(shí)，kubelet會(huì)自動(dòng)重啟該容器。
• Never：不論容器運(yùn)行狀態(tài)怎樣，kubelet都不會(huì)重啟該容器。

四、健康檢查

健康檢查功能可以保障應(yīng)用的可用性，以及控制何時(shí)可對(duì)外的訪問。

K8S有3種檢查探針：LivenessProbe存活探針、ReadinessProbe就緒探針、StartupProbe啟動(dòng)探針。

• LivenessProbe存活探針判斷容器是否存活（Running狀態(tài)），如果存活探針檢測(cè)到容器不健康，則kubelet將kill掉該容器，并根據(jù)容器的重啟策略做相應(yīng)的處理。
• ReadinessProbe 就緒探針判斷容器是否可用（Ready狀態(tài)），達(dá)到Ready狀態(tài)的Pod才可以接收請(qǐng)求。kubelet 使用就緒探針檢測(cè)容器什么時(shí)候可以接受請(qǐng)求。
• StartupProbe啟動(dòng)探針某些應(yīng)用啟動(dòng)比較慢，例如某個(gè)大的單體應(yīng)用啟動(dòng)時(shí)間長(zhǎng)達(dá)3分鐘，此時(shí)如果只使用存活探針 或者 就緒探針，很可能應(yīng)用還沒起來，就被kill掉了。這種情況可以通過啟動(dòng)探針來解決。如果配置了啟動(dòng)探針，在存活探針和就緒探針成功之前不會(huì)重啟容器。說白了就是只要配置了啟動(dòng)探針，那么在應(yīng)用沒成功啟動(dòng)之前，存活探針和就緒探針就不生效。

以上3種探針，每種都有3種實(shí)現(xiàn)方式：

• ExecAction：在容器內(nèi)運(yùn)行一個(gè)命令，如果該命令的返回碼為 0，則說明容器是健康的。
• TCPSocketAction：通過容器的 IP 地址和端口號(hào)進(jìn)行TCP檢查，如果能夠建立TCP 連接，則說明容器是健康的。
• HTTPGetAction：通過容器的IP 地址、端口號(hào)以及路徑，發(fā)起HTTP請(qǐng)求，如果HTTP響應(yīng)的狀態(tài)碼大于等于200且小于400，則說明容器是健康的。

在部署Java微服務(wù)應(yīng)用時(shí)，我一般選用HTTPGetAction方式。

五、如何選擇探針

既然有3種探針，那么如何選擇呢？

• 如果你希望容器在檢測(cè)到失敗時(shí)，讓它被kill掉并且自動(dòng)重啟，那就選擇存活態(tài)探針。
• 如果你希望在檢測(cè)成功時(shí)Pod才能接受請(qǐng)求，那就需要就緒態(tài)探針。如果某個(gè)應(yīng)用A  依賴 應(yīng)用B的啟動(dòng)才能接受請(qǐng)求，那也需要就緒探針。
• 如果某個(gè)應(yīng)用啟動(dòng)時(shí)間較長(zhǎng)，那就需要加入啟動(dòng)探針。

成年人的世界不做選擇題，3個(gè)字，全都要，比如：應(yīng)用場(chǎng)景是Spring微服務(wù)時(shí)，3種探針其實(shí)都會(huì)用上。

一個(gè)應(yīng)用啟動(dòng)分3個(gè)階段：開始啟動(dòng) → 成功啟動(dòng)（存活） → 可對(duì)外訪問。

那對(duì)應(yīng)的探針使用順序?yàn)椋簡(jiǎn)?dòng)探針 → 存活探針 → 就緒探針。如下圖：

如果只選擇存活探針，就很尷尬：

• 如果配置的存活檢測(cè)時(shí)間太短，那么碰到啟動(dòng)慢的應(yīng)用，就徹底起不來了，因?yàn)閼?yīng)用還沒起來就被kill掉了。
• 如果配置的存活檢測(cè)時(shí)間太長(zhǎng)，那么應(yīng)用真到了出現(xiàn)問題的時(shí)候，又無法及時(shí)被重啟，從而影響了整體的可用性。

如果不配置就緒探針的話，也很尷尬：

• 比如有的場(chǎng)景下本身應(yīng)用起來了，但是依賴的應(yīng)用還沒起來，那么此時(shí)還無法對(duì)外提供訪問能力，此時(shí)就不能讓請(qǐng)求流量進(jìn)來。

所以不做選擇題，全都要，需要在每個(gè)階段用上對(duì)應(yīng)的探針。

六、實(shí)戰(zhàn)

1.模擬不健康的應(yīng)用場(chǎng)景

(1) 編排yaml

比如：對(duì)Pod進(jìn)行存活檢測(cè)，30S之后，如果不存活則kill掉，然后重啟。

apiVersion: v1
kind: Pod
metadata:
  name: pod-lifecycle
  namespace: demo
  labels:
    app: pod-lifecycle
spec:
  containers:
    - name: pod-lifecycle
      image: busybox
      args:
        - /bin/sh
        - -c
        - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
      livenessProbe:
        exec:
          command:
            - cat
            - /tmp/healthy
        # 等待5秒執(zhí)行第一次探測(cè)
        initialDelaySeconds: 5
        # 探針連續(xù)失敗了 3 次之后，K8S認(rèn)為檢查已失敗，然后觸發(fā)重啟
        failureThreshold: 3
        # 每5秒執(zhí)行一次存活探測(cè)
        periodSeconds: 5

可以看到Pod被重啟多次

(2) 排查異常

出現(xiàn)問題時(shí)也不用慌，可以通過kubectl get pods -n demo -o wide 和kubectl describe pod pod-lifecycle -n demo排查。可以清晰的看到異常的原因：存活檢查失敗。

2.模擬啟動(dòng)慢的應(yīng)用

(1) 編排yaml

比如：對(duì)Pod進(jìn)行存活檢測(cè)，30S之后，如果不存活則kill掉，然后重啟。由于模擬了啟動(dòng)比較耗時(shí)，所以在容器還未成功啟動(dòng)，就直接被kill掉了，緊接著反復(fù)被kill掉。

apiVersion: v1
kind: Pod
metadata:
  name: pod-lifecycle-2
  namespace: demo
  labels:
    app: pod-lifecycle-2
spec:
  containers:
    - name: pod-lifecycle-2
      image: busybox
      args:
        - /bin/sh
        - -c
        - sleep 20; touch /tmp/healthy; sleep 600
      livenessProbe:
        exec:
          command:
            - cat
            - /tmp/healthy
        # 等待5秒執(zhí)行第一次探測(cè)
        initialDelaySeconds: 5
        # 探針連續(xù)失敗了 2 次之后，K8S認(rèn)為檢查已失敗，然后觸發(fā)重啟
        failureThreshold: 2
        # 每5秒執(zhí)行一次存活探測(cè)
        periodSeconds: 5

執(zhí)行yaml之后，可以看到，Pod重復(fù)這樣的動(dòng)作：健康檢查失敗被重啟。

(2) 引入startupProbe解決此問題

apiVersion: v1
kind: Pod
metadata:
  name: pod-lifecycle-3
  namespace: demo
  labels:
    app: pod-lifecycle-3
spec:
  containers:
    - name: pod-lifecycle-3
      image: busybox
      args:
        - /bin/sh
        - -c
        - sleep 20; touch /tmp/healthy;  sleep 600
      startupProbe:
        exec:
          command:
            - cat
            - /tmp/healthy
        # 等待5秒執(zhí)行第一次探測(cè)
        initialDelaySeconds: 5
        # 探針連續(xù)失敗了 10 次之后，K8S認(rèn)為檢查已失敗，然后觸發(fā)重啟
        failureThreshold: 5
        # 每5秒執(zhí)行一次存活探測(cè)
        periodSeconds: 5
      livenessProbe:
        exec:
          command:
            - cat
            - /tmp/healthy
        # 等待5秒執(zhí)行第一次探測(cè)
        initialDelaySeconds: 5
        # 探針連續(xù)失敗了 2 次之后，K8S認(rèn)為檢查已失敗，然后觸發(fā)重啟
        failureThreshold: 2
        # 每5秒執(zhí)行一次存活探測(cè)
        periodSeconds: 5

七、總結(jié)

要想Kubernetes里每個(gè)服務(wù)的可用性更高，那么對(duì)Pod的健康檢查是少不了的。本文重點(diǎn)如下：

• Pod生命周期：Pending 、Running、 Succeeded或 Failed 、UnKnown。
• Pod重啟策略：Always、OnFailure、Never。
• 3種探針類型：?jiǎn)?dòng)探針、存活探針、就緒探針。
• 如何選擇探針：一般情況下全都要。
• 排查Pod問題：搭配使用kubectl get pods -n demo -o wide 和kubectl describe pods webapp -n demo。

講到這里，文章開頭我碰到的問題，你肯定也知道答案了。由于應(yīng)用啟動(dòng)時(shí)間較長(zhǎng)，但是只配置了存活探針，沒有配置啟動(dòng)探針。再加上存活探針配置的整體時(shí)間又太短了，每臺(tái)機(jī)器的性能又不同，所以導(dǎo)致有時(shí)候能啟動(dòng)成功，有時(shí)候啟動(dòng)失敗。

分享題目：要想Pod好--健康檢查少不了
文章轉(zhuǎn)載：http://www.5511xx.com/article/cdhggih.html