一、概述

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

• 異常實例自動剔除，并重啟新實例

• 多種類型探針檢測，保證異常pod不接入流量

• 不停機部署，更安全的滾動升級

圖片

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

1）k8s中的探針種類

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

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

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

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

restartPolicy有三個可選值：

• Always：當容器終止退出后，總是重啟容器，默認策略。

• OnFailure：當容器異常退出（退出狀態(tài)碼非0）時，才重啟容器。

• Never：當容器終止退出，從不重啟容器。

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

• startupProbes 啟動檢查機制，應用一些啟動緩慢的業(yè)務，避免業(yè)務長時間啟動而被前面的探針kill掉。

• 判斷容器內的應用程序是否已啟動，主要針對于不能確定具體啟動時間的應用。如果匹配了 startupProbes 探測，則在 startupProbes 狀態(tài)為 Success 之前，其他所有探針都處于無效狀態(tài)，直到它成功后其他探針才起作用。

• 如果 startupProbe 失敗，kubelet 將殺死容器，容器將根據(jù) restartPolicy 來重啟。如果容器沒有配置 startupProbe，則默認狀態(tài)為 Success。其實一般主要是設置上面兩種即可。

就緒、存活兩種探針的區(qū)別：

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

• livenessProbe 當檢測失敗后，將殺死容器并根據(jù) Pod 的重啟策略來決定作出對應的措施。

• readinessProbe 當檢測失敗后，將 Pod 的 IP:Port 從對應的 EndPoint 列表中刪除。

2）k8s中的三種探測方式

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

• exec（自定義健康檢查）：在容器中執(zhí)行指定的命令，如果執(zhí)行成功，退出碼為 0 則探測成功。

• httpGet：通過容器的IP地址、端口號及路徑調用 HTTP Get方法，如果響應的狀態(tài)碼大于等于200且小于400，則認為容器 健康。

• tcpSocket：通過容器的 IP 地址和端口號執(zhí)行 TCP 檢 查，如果能夠建立 TCP 連接，則表明容器健康。

探針探測結果有以下值：

• Success：表示通過檢測。

• Failure：表示未通過檢測。

• Unknown：表示檢測沒有正常進行。

二、readinessProbe（就緒性探針）

• readiness probe 就緒性探針，用于判斷容器內的程序是否存活（或者說是否健康），只有程序(服務)正常， 容器開始對外提供網(wǎng)絡訪問（啟動完成并就緒）；

• 容器啟動后按照readiness probe配置進行探測，無問題后結果為成功即狀態(tài)為 Success；

• pod的READY狀態(tài)為 true，從0/1變?yōu)?/1。如果失敗繼續(xù)為0/1，狀態(tài)為 false；

• 若未配置就緒探針，則默認狀態(tài)容器啟動后為Success。對于此pod、此pod關聯(lián)的Service資源、EndPoint 的關系也將基于 Pod 的 Ready 狀態(tài)進行設置；

• 如果 Pod 運行過程中 Ready 狀態(tài)變?yōu)?false，則系統(tǒng)自動從 Service資源 關聯(lián)的 EndPoint列表中去除此pod，屆時service資源接收到GET請求后，kube-proxy將一定不會把流量引入此pod中，通過這種機制就能防止將流量轉發(fā)到不可用的 Pod 上。

• 如果 Pod 恢復為 Ready 狀態(tài)。將再會被加回 Endpoint 列表。kube-proxy也將有概率通過負載機制會引入流量到此pod中。

三、livenessProbe（存活性探針）

• liveness probe存活性探針，用于判斷容器是不是健康，如果不滿足健康條件，那么 Kubelet 將根據(jù) Pod 中設置的 restartPolicy （重啟策略）來判斷，Pod 是否要進行重啟操作；

• LivenessProbe按照配置去探測 ( 進程、或者端口、或者命令執(zhí)行后是否成功等等)，來判斷容器是不是正常；

• 如果探測不到，代表容器不健康（可以配置連續(xù)多少次失敗才記為不健康），則 kubelet 會殺掉該容器，并根據(jù)容器的重啟策略做相應的處理；

• 如果未配置存活探針，則默認容器啟動為通過（Success）狀態(tài)。即探針返回的值永遠是 Success。即Success后pod狀態(tài)是RUNING。

四、實戰(zhàn)演示
常用的探針可選參數(shù)：

image.png

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 在執(zhí)行第一次探測前應該等待 5 秒。

periodSeconds 字段指定了 kubelet 應該每 5 秒執(zhí)行一次存活探測。

kubelet 在容器內執(zhí)行命令 cat /tmp/healthy 來進行探測。

如果命令執(zhí)行成功并且返回值為 0，kubelet 就會認為這個容器是健康存活的。

如果這個命令返回非 0 值，kubelet 會殺死這個容器并重新啟動它。

當容器啟動時，執(zhí)行如下的命令：

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

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

創(chuàng)建 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

image.png

【現(xiàn)象】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 在執(zhí)行第一次探測前應該等待 1 秒。

periodSeconds 字段指定了 kubelet 每隔 3 秒執(zhí)行一次存活探測。

kubelet 會向容器內運行的服務（服務在監(jiān)聽 80 端口）發(fā)送一個 HTTP GET 請求來執(zhí)行探測。

如果服務器上/index.html路徑下的處理程序返回成功代碼，則 kubelet 認為容器是健康存活的。

如果處理程序返回失敗代碼，則 kubelet 會殺死這個容器并將其重啟。

返回大于或等于 200 并且小于 400 的任何代碼都標示成功，其它返回代碼都標示失敗。

執(zhí)行并查看

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

image.png

image.png

刪除 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 探測得到的狀態(tài)返回碼是 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：訪問容器的端口號或者端口名。如果數(shù)字必須在 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 秒后發(fā)送第一個就緒探測（livenessProbe）。

探測器會嘗試連接 goproxy 容器的 80 端口。 如果探測成功，這個 Pod 會被標記為就緒狀態(tài)，kubelet 將繼續(xù)每隔 10 秒運行一次檢測。

除了就緒探測，這個配置包括了一個存活探測（livenessProbe）。

kubelet 會在容器啟動 15 秒后進行第一次存活探測（livenessProbe）。

與就緒探測類似，活躍探測器會嘗試連接 goproxy 容器的 80 端口。 如果存活探測失敗，容器會被重新啟動。
執(zhí)行

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

image.png

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
  # 執(zhí)行探測頻率(秒) 【 每隔秒執(zhí)行一次 】
  periodSeconds: 10
  #  超時時間
  timeoutSeconds: 1
  # 處于成功狀態(tài)時，探測連續(xù)失敗幾次可被認為失敗。
  failureThreshold: 3
  # 處于失敗狀態(tài)時，探測連續(xù)成功幾次，被認為成功。
  successThreshold: 1

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

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

一般使用控制器去創(chuàng)建管理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
          # 執(zhí)行探測頻率(秒) 【 每隔秒執(zhí)行一次 】
          periodSeconds: 10
          #  超時時間
          timeoutSeconds: 1
          # 處于成功狀態(tài)時，探測連續(xù)失敗幾次可被認為失敗。
          failureThreshold: 3
          # 處于失敗狀態(tài)時，探測連續(xù)成功幾次，被認為成功。
          successThreshold: 1
        
        # livenessProbe，存活探針
        livenessProbe:
          httpGet:
            path: /index.html
            port: nginx
          # 延遲多久后開始探測
          initialDelaySeconds: 10
          # 執(zhí)行探測頻率(秒) 【 每隔秒執(zhí)行一次 】
          periodSeconds: 10
          #  超時時間
          timeoutSeconds: 1
          # 處于成功狀態(tài)時，探測連續(xù)失敗幾次可被認為失敗。
          failureThreshold: 3
          # 處于失敗狀態(tài)時，探測連續(xù)成功幾次，被認為成功。
          successThreshold: 1
        
        # startupProbe，啟動探針
        startupProbe:
          httpGet:
            path: /index.html
            port: nginx
          # 延遲多久后開始探測
          initialDelaySeconds: 10
          # 執(zhí)行探測頻率(秒) 【 每隔秒執(zhí)行一次 】
          periodSeconds: 10
          #  超時時間
          timeoutSeconds: 1
          # 處于成功狀態(tài)時，探測連續(xù)失敗幾次可被認為失敗。
          failureThreshold: 3
          # 處于失敗狀態(tài)時，探測連續(xù)成功幾次，被認為成功。
          successThreshold: 1

執(zhí)行查看

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

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