要想Kubernetes里每個服務的可用性更高，那么對Pod的健康檢查是少不了的。Pod生命周期和健康檢查是我們最常接觸的基礎知識，雖說是基礎吧，但如果理解不好，出現問題時很容易抓耳撓腮，揪頭發。

本文主要從以下六個方面介紹Pod的健康檢查：剛接觸K8S的糗事、Pod生命周期、重啟策略、健康檢查、如何選擇探針、實戰，最后還會有知識點的總結和排查Pod問題的總結。

一、剛接觸K8S的糗事

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

隨著時間推移，又碰到了問題。有一天在部署某個springboot微服務時，在開發測試環境部署了好多次，只有幾次能成功啟動，大部分的部署未能成功啟動。但是生產環境卻每次都能成功部署。當時這個問題困擾了我很久。現在想來也是蠻有意思的。

相信很多你已經猜出來答案了，對，跟我們今天要講的健康檢查有關。

二、Pod生命周期

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

Pod 的生命周期，從 Pending 狀態開始， 如果Pod中至少有一個應用容器正常啟動，則進入 Running狀態，之后，如果Pod中的容器正常退出則進入 Succeeded狀態，如果Pod中的容器非正常終止則進入 Failed 狀態。

• Pending狀態：此時Pod已經被K8S接受并且創建，但是Pod內還沒有容器被創建，這個過程包括：等待Pod被調度的時間、下載鏡像的時間。
• Running狀態：此時Pod已經運行在某個節點上，Pod內所有容器都已經創建，并且有容器處于如下狀態：運行狀態、正在啟動狀態 或 正在重啟狀態。
• Succeeded狀態：此時Pod內所有容器都成功執行并且退出。
• Failed狀態：此時Pod內所有容器都已終止，但是有容器是非正常終止的。
• Unknown狀態：無法獲取Pod狀態，通常是因為Pod與所在主機通信失敗，也可能是別的原因。

三、重啟策略

Pod的重啟是由該Pod所處的Node節點上的kubelet 進行判斷和控制的。kubelet會根據重啟策略進行相應操作。

Pod的重啟策略有3個：Always、OnFailure、Never，默認是Always。

• Always：重啟策略是Always時，那么當容器運行狀態是失效時，kubelet會自動重啟該容器，比如：存活探針檢測到應用不健康了，就會自動重啟Pod。
• OnFailure：重啟策略是OnFailure時，那么當容器是Failed狀態時，kubelet會自動重啟該容器。
• Never：不論容器運行狀態怎樣，kubelet都不會重啟該容器。

四、健康檢查

健康檢查功能可以保障應用的可用性，以及控制何時可對外的訪問。

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

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

以上3種探針，每種都有3種實現方式：

• ExecAction：在容器內運行一個命令，如果該命令的返回碼為 0，則說明容器是健康的。
• TCPSocketAction：通過容器的 IP 地址和端口號進行TCP檢查，如果能夠建立TCP 連接，則說明容器是健康的。
• HTTPGetAction：通過容器的IP 地址、端口號以及路徑，發起HTTP請求，如果HTTP響應的狀態碼大于等于200且小于400，則說明容器是健康的。

在部署Java微服務應用時，我一般選用HTTPGetAction方式。

五、如何選擇探針

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

• 如果你希望容器在檢測到失敗時，讓它被kill掉并且自動重啟，那就選擇存活態探針。
• 如果你希望在檢測成功時Pod才能接受請求，那就需要就緒態探針。如果某個應用A  依賴 應用B的啟動才能接受請求，那也需要就緒探針。
• 如果某個應用啟動時間較長，那就需要加入啟動探針。

成年人的世界不做選擇題，3個字，全都要，比如：應用場景是Spring微服務時，3種探針其實都會用上。

一個應用啟動分3個階段：開始啟動 → 成功啟動（存活） → 可對外訪問。

那對應的探針使用順序為：啟動探針 → 存活探針 → 就緒探針。如下圖：

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

• 如果配置的存活檢測時間太短，那么碰到啟動慢的應用，就徹底起不來了，因為應用還沒起來就被kill掉了。
• 如果配置的存活檢測時間太長，那么應用真到了出現問題的時候，又無法及時被重啟，從而影響了整體的可用性。

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

• 比如有的場景下本身應用起來了，但是依賴的應用還沒起來，那么此時還無法對外提供訪問能力，此時就不能讓請求流量進來。

所以不做選擇題，全都要，需要在每個階段用上對應的探針。

六、實戰

1.模擬不健康的應用場景

(1) 編排yaml

比如：對Pod進行存活檢測，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秒執行第一次探測
        initialDelaySeconds: 5
        # 探針連續失敗了 3 次之后，K8S認為檢查已失敗，然后觸發重啟
        failureThreshold: 3
        # 每5秒執行一次存活探測
        periodSeconds: 5

可以看到Pod被重啟多次

(2) 排查異常

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

2.模擬啟動慢的應用

(1) 編排yaml

比如：對Pod進行存活檢測，30S之后，如果不存活則kill掉，然后重啟。由于模擬了啟動比較耗時，所以在容器還未成功啟動，就直接被kill掉了，緊接著反復被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秒執行第一次探測
        initialDelaySeconds: 5
        # 探針連續失敗了 2 次之后，K8S認為檢查已失敗，然后觸發重啟
        failureThreshold: 2
        # 每5秒執行一次存活探測
        periodSeconds: 5

執行yaml之后，可以看到，Pod重復這樣的動作：健康檢查失敗被重啟。

(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秒執行第一次探測
        initialDelaySeconds: 5
        # 探針連續失敗了 10 次之后，K8S認為檢查已失敗，然后觸發重啟
        failureThreshold: 5
        # 每5秒執行一次存活探測
        periodSeconds: 5
      livenessProbe:
        exec:
          command:
            - cat
            - /tmp/healthy
        # 等待5秒執行第一次探測
        initialDelaySeconds: 5
        # 探針連續失敗了 2 次之后，K8S認為檢查已失敗，然后觸發重啟
        failureThreshold: 2
        # 每5秒執行一次存活探測
        periodSeconds: 5

七、總結

要想Kubernetes里每個服務的可用性更高，那么對Pod的健康檢查是少不了的。本文重點如下：

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

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