[云原生] Kubernetes（k8s）健康檢查詳解與實戰演示（就緒性探針和存活性探針）

作者：liugp 2023-01-30 07:51:38

liveness probes? 在線檢查機制，檢查應用是否可用，如死鎖，無法響應，異常時將根據restartPolicy來設置 Pod 狀態會自動重啟容器，如果容器不提供存活探針，則默認狀態為 Success。

一、概述

Kubernetes中的健康檢查主要使用就緒性探針（readinessProbes?）和存活性探針（livenessProbes）來實現，service即為負載均衡，k8s保證 service 后面的 pod 都可用，是k8s中自愈能力的主要手段，主要基于這兩種探測機制，可以實現如下需求：

異常實例自動剔除，并重啟新實例
多種類型探針檢測，保證異常pod不接入流量
不停機部署，更安全的滾動升級

官方文檔：https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/Kubernetes（k8s）環境部署可以參考我這篇文章：Kubernetes（k8s）最新版最完整版環境部署+master高可用實現（k8sV1.24.1+dashboard+harbor）

1）k8s中的探針種類

1、就緒檢查（readinessProbe，就緒探針）

readiness probes? 準備就緒檢查，通過readiness是否準備接受流量，準備完畢加入到Endpoint，否則剔除。如果容器不提供就緒探針，則默認狀態為 Success。

2、存活檢查（livenessProbe，存活探針）

restartPolicy有三個可選值：

Always：當容器終止退出后，總是重啟容器，默認策略。
OnFailure：當容器異常退出（退出狀態碼非0）時，才重啟容器。
Never：當容器終止退出，從不重啟容器。

3、啟動檢查（startupProbe，啟動探針，1.17 版本新增）

startupProbes 啟動檢查機制，應用一些啟動緩慢的業務，避免業務長時間啟動而被前面的探針kill掉。
判斷容器內的應用程序是否已啟動，主要針對于不能確定具體啟動時間的應用。如果匹配了startupProbes 探測，則在 startupProbes 狀態為 Success 之前，其他所有探針都處于無效狀態，直到它成功后其他探針才起作用。
如果startupProbe 失敗，kubelet 將殺死容器，容器將根據 restartPolicy 來重啟。如果容器沒有配置 startupProbe，則默認狀態為 Success。其實一般主要是設置上面兩種即可。

就緒、存活兩種探針的區別：

readinessProbe 和 livenessProbe 可以使用相同探測方式，只是對 Pod 的處置方式不同。

livenessProbe 當檢測失敗后，將殺死容器并根據 Pod 的重啟策略來決定作出對應的措施。
readinessProbe 當檢測失敗后，將 Pod 的 IP:Port 從對應的 EndPoint 列表中刪除。

2）k8s中的三種探測方式

每種探測機制支持三種健康檢查方法，分別是命令行exec，httpGet和tcpSocket，其中exec通用性最強，適用與大部分場景，tcpSocket適用于TCP業務，httpGet適用于web業務。

exec（自定義健康檢查）：在容器中執行指定的命令，如果執行成功，退出碼為 0 則探測成功。
httpGet：通過容器的IP地址、端口號及路徑調用 HTTP Get方法，如果響應的狀態碼大于等于200且小于400，則認為容器健康。
tcpSocket：通過容器的 IP 地址和端口號執行 TCP 檢查，如果能夠建立 TCP 連接，則表明容器健康。

探針探測結果有以下值：

Success：表示通過檢測。
Failure：表示未通過檢測。
Unknown：表示檢測沒有正常進行。

二、readinessProbe（就緒性探針）

readiness probe 就緒性探針，用于判斷容器內的程序是否存活（或者說是否健康），只有程序(服務)正常，容器開始對外提供網絡訪問（啟動完成并就緒）；
容器啟動后按照readiness probe配置進行探測，無問題后結果為成功即狀態為 Success；
pod的READY狀態為 true，從0/1變為1/1。如果失敗繼續為0/1，狀態為 false；
若未配置就緒探針，則默認狀態容器啟動后為Success?。對于此pod、此pod關聯的Service資源、EndPoint 的關系也將基于 Pod 的 Ready 狀態進行設置；
如果 Pod 運行過程中Ready 狀態變為 false，則系統自動從 Service?資源關聯的 EndPoint?列表中去除此pod，屆時service資源接收到GET請求后，kube-proxy將一定不會把流量引入此pod中，通過這種機制就能防止將流量轉發到不可用的 Pod 上。
如果Pod 恢復為 Ready 狀態。將再會被加回 Endpoint? 列表。kube-proxy也將有概率通過負載機制會引入流量到此pod中。

三、livenessProbe（存活性探針）

liveness probe存活性探針，用于判斷容器是不是健康，如果不滿足健康條件，那么 Kubelet 將根據 Pod 中設置的 restartPolicy （重啟策略）來判斷，Pod 是否要進行重啟操作；
LivenessProbe按照配置去探測 (進程、或者端口、或者命令執行后是否成功等等)，來判斷容器是不是正常；
如果探測不到，代表容器不健康（可以配置連續多少次失敗才記為不健康），則 kubelet 會殺掉該容器，并根據容器的重啟策略做相應的處理；
如果未配置存活探針，則默認容器啟動為通過（Success）狀態。即探針返回的值永遠是 Success。即Success后pod狀態是RUNING。

四、實戰演示

常用的探針可選參數：

參數名稱	默認值	最小值	描述
initialDelaySeconds	0秒	0秒	探測延遲時長，容器啟動后多久開始進行第一次探測工作。
periodSeconds	10秒	1秒	探測頻度，頻率過高會對pod帶來較大的額外開銷，頻率過低則無法及時反映容器產生的錯誤。
timeoutSeconds	1秒	1秒	探測的超時時長。
failureThreshold	3	1	處于成功狀態時，探測連續失敗幾次可被認為失敗。
successThreshold	1	1	處于失敗狀態時，探測連續成功幾次，被認為成功。

1）exec方式

cat >exec-liveness.yaml<<EOF
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  # 為了測試方便，指定調度機器
  nodeName: local-168-182-110
  containers:
  - name: liveness
    image: registry.aliyuncs.com/google_containers/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
EOF

解釋：

initialDelaySeconds 字段告訴 kubelet 在執行第一次探測前應該等待 5 秒。
periodSeconds 字段指定了 kubelet 應該每 5 秒執行一次存活探測。
kubelet 在容器內執行命令cat /tmp/healthy 來進行探測。
如果命令執行成功并且返回值為 0，kubelet 就會認為這個容器是健康存活的。
如果這個命令返回非 0 值，kubelet 會殺死這個容器并重新啟動它。
當容器啟動時，執行如下的命令：

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"

這個容器生命的前 30 秒，/tmp/healthy 文件是存在的。所以在這最開始的 30 秒內，執行命令 cat /tmp/healthy 會返回成功代碼。 30 秒之后，執行命令 cat /tmp/healthy 就會返回失敗代碼。

創建 Pod：

# 最好先拉取鏡像，如果是使用docker，就換成docker就行
crictl pull registry.aliyuncs.com/google_containers/busybox

kubectl apply -f exec-liveness.yaml

【問題】ERRO[0000] unable to determine image API version: rpc error: code = Unavailable desc = connection error: desc = “transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory”【解決】原因：未配置endpoints

crictl config runtime-endpoint unix:///run/containerd/containerd.sock
crictl config image-endpoint unix:///run/containerd/containerd.sock

查看

kubectl describe pod liveness-exec

【現象】30s之后檢查失敗后就重啟pod了，又正常了。

2）httpGet 方式

cat >http-liveness.yaml<<EOF
apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget
  namespace: default
spec:
  # 為了測試方便，指定調度機器
  nodeName: local-168-182-110
  containers:
  - name: liveness-httpget-container
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: nginx
      containerPort: 80
    livenessProbe:
      httpGet:
        port: nginx
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10
EOF

解釋：

initialDelaySeconds字段告訴 kubelet 在執行第一次探測前應該等待 1 秒。
periodSeconds 字段指定了 kubelet 每隔 3 秒執行一次存活探測。
kubelet 會向容器內運行的服務（服務在監聽 80 端口）發送一個 HTTP GET 請求來執行探測。
如果服務器上/index.html路徑下的處理程序返回成功代碼，則 kubelet 認為容器是健康存活的。
如果處理程序返回失敗代碼，則 kubelet 會殺死這個容器并將其重啟。
返回大于或等于 200? 并且小于 400 的任何代碼都標示成功，其它返回代碼都標示失敗。

執行并查看

crictl pull nginx
kubectl apply -f http-liveness.yaml
kubectl describe pod liveness-httpget

刪除 Pod 的 index.html 文件

kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html
# 再查看
kubectl describe pod liveness-httpget
kubectl get pod liveness-httpget

重啟原因是 HTTP 探測得到的狀態返回碼是 404，Liveness probe failed: HTTP probe failed with statuscode: 404。
重啟完成后，不會再次重啟，因為重新拉取的鏡像中包含了 index.html 文件。

HTTP Probes 允許針對 httpGet 配置額外的字段：

host：連接使用的主機名，默認是 Pod 的 IP。也可以在 HTTP 頭中設置 “Host” 來代替。
scheme ：用于設置連接主機的方式（HTTP 還是 HTTPS）。默認是 "HTTP"。
path：訪問 HTTP 服務的路徑。默認值為 "/"。
httpHeaders：請求中自定義的 HTTP 頭。HTTP 頭字段允許重復。
port：訪問容器的端口號或者端口名。如果數字必須在 1～65535 之間。

你可以通過為探測設置 .httpHeaders 來重載默認的頭部字段值；例如：

livenessProbe:
  httpGet:
    httpHeaders:
      - name: Accept
        value: application/json

startupProbe:
  httpGet:
    httpHeaders:
      - name: User-Agent
        value: MyUserAgent

3）tcpSocket 方式

cat >tcp-liveness-readiness.yaml<<EOF
apiVersion: v1
kind: Pod
metadata:
  name: liveness-readiness-tcpsocket
  labels:
    app: liveness-readiness-tcpsocket
spec:
  # 為了測試方便，指定調度機器
  nodeName: local-168-182-110
  containers:
  - name: liveness-readiness-tcpsocket
    image: nginx
    ports:
    - containerPort: 80
    readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 20
EOF

解釋：

kubelet 會在容器啟動 5 秒后發送第一個就緒探測（livenessProbe）。
探測器會嘗試連接 goproxy 容器的 80 端口。如果探測成功，這個 Pod 會被標記為就緒狀態，kubelet 將繼續每隔 10 秒運行一次檢測。
除了就緒探測，這個配置包括了一個存活探測（livenessProbe）。
kubelet 會在容器啟動15 秒后進行第一次存活探測（livenessProbe）。
與就緒探測類似，活躍探測器會嘗試連接 goproxy 容器的 80 端口。如果存活探測失敗，容器會被重新啟動。執行

kubectl apply -f tcp-liveness-readiness.yaml
kubectl get pod liveness-readiness-tcpsocket
kubectl describe pod liveness-readiness-tcpsocket

4）使用命名端口

對于 HTTP 或者 TCP 存活檢測可以使用命名的 port。

ports:
- name: nginx
  containerPort: 80
  hostPort: 80

livenessProbe:
  httpGet:
    path: /index.html
    port: nginx

完整版配置

ports:
- name: nginx
  containerPort: 80
  hostPort: 80

# readinessProbe，就緒探針
livenessProbe:
  httpGet:
    path: /index.html
    port: nginx
  # 延遲多久后開始探測
  initialDelaySeconds: 10
  # 執行探測頻率(秒) 【 每隔秒執行一次 】
  periodSeconds: 10
  #  超時時間
  timeoutSeconds: 1
  # 處于成功狀態時，探測連續失敗幾次可被認為失敗。
  failureThreshold: 3
  # 處于失敗狀態時，探測連續成功幾次，被認為成功。
  successThreshold: 1

# livenessProbe，存活探針
livenessProbe:
  httpGet:
    path: /index.html
    port: nginx
  # 延遲多久后開始探測
  initialDelaySeconds: 10
  # 執行探測頻率(秒) 【 每隔秒執行一次 】
  periodSeconds: 10
  #  超時時間
  timeoutSeconds: 1
  # 處于成功狀態時，探測連續失敗幾次可被認為失敗。
  failureThreshold: 3
  # 處于失敗狀態時，探測連續成功幾次，被認為成功。
  successThreshold: 1

# startupProbe，啟動探針
startupProbe:
  httpGet:
    path: /index.html
    port: nginx
  # 延遲多久后開始探測
  initialDelaySeconds: 10
  # 執行探測頻率(秒) 【 每隔秒執行一次 】
  periodSeconds: 10
  #  超時時間
  timeoutSeconds: 1
  # 處于成功狀態時，探測連續失敗幾次可被認為失敗。
  failureThreshold: 3
  # 處于失敗狀態時，探測連續成功幾次，被認為成功。
  successThreshold: 1

一般使用控制器去創建管理pod，對k8s 控制器不清晰的小伙伴，可以參考我之前的文章：Kubernetes（k8s）Deployment、StatefulSet、DaemonSet、Job、CronJob五種控制器詳解

下面是一個完整版的示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-probe
spec:
  replicas: 3
  selector:
    matchLabels:
     app: deployment-probe
  template:
    metadata:
      labels:
        app: deployment-probe
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        
        # readinessProbe，就緒探針
        readinessProbe:
          httpGet:
            path: /index.html
            port: nginx
          # 延遲多久后開始探測
          initialDelaySeconds: 10
          # 執行探測頻率(秒) 【 每隔秒執行一次 】
          periodSeconds: 10
          #  超時時間
          timeoutSeconds: 1
          # 處于成功狀態時，探測連續失敗幾次可被認為失敗。
          failureThreshold: 3
          # 處于失敗狀態時，探測連續成功幾次，被認為成功。
          successThreshold: 1
        
        # livenessProbe，存活探針
        livenessProbe:
          httpGet:
            path: /index.html
            port: nginx
          # 延遲多久后開始探測
          initialDelaySeconds: 10
          # 執行探測頻率(秒) 【 每隔秒執行一次 】
          periodSeconds: 10
          #  超時時間
          timeoutSeconds: 1
          # 處于成功狀態時，探測連續失敗幾次可被認為失敗。
          failureThreshold: 3
          # 處于失敗狀態時，探測連續成功幾次，被認為成功。
          successThreshold: 1
        
        # startupProbe，啟動探針
        startupProbe:
          httpGet:
            path: /index.html
            port: nginx
          # 延遲多久后開始探測
          initialDelaySeconds: 10
          # 執行探測頻率(秒) 【 每隔秒執行一次 】
          periodSeconds: 10
          #  超時時間
          timeoutSeconds: 1
          # 處于成功狀態時，探測連續失敗幾次可被認為失敗。
          failureThreshold: 3
          # 處于失敗狀態時，探測連續成功幾次，被認為成功。
          successThreshold: 1

執行查看

crictl pull nginx:1.17.1
kubectl apply -f deployment-probe.yaml
kubectl get pod,deploy

Kubernetes（k8s）健康檢查詳解與實戰演示就先到這里了，健康檢查會伴隨所有k8s編排任務，所以非常重要，其實也不難，小伙伴有什么疑問，歡迎給我留言哦~

責任編輯：武曉燕來源：大數據與云原生技術分享

[云原生] Kubernetes（k8s）健康檢查詳解與實戰演示（就緒性探針 和 存活性探針）