Kubernetes 学习总结（42）—— Kubernetes 之 pod 健康检查详解

Kubernetes 入门

回想 2017 年刚开始接触 Kubernetes 时，碰到 Pod一直起不来的情况，就开始抓瞎。后来渐渐地掌握了一些排查方法之后，这种情况才得以缓解。随着时间推移，又碰到了问题。有一天在部署某个 springboot 微服务时，在开发测试环境部署了好多次，只有几次能成功启动，大部分的部署未能成功启动。但是生产环境却每次都能成功部署。当时这个问题困扰了我很久。由于应用启动时间较长，但是只配置了存活探针，没有配置启动探针。再加上存活探针配置的整体时间又太短了，每台机器的性能又不同，所以导致有时候能启动成功，有时候启动失败。现在想来也是蛮有意思的。要想 Kubernetes 里每个服务的可用性更高，那么对 Pod 的健康检查是少不了的。

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 都不会重启该容器。

健康检查

健康检查功能可以保障应用的可用性，以及控制何时可对外的访问。Kubernetes 有 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 掉了。

如果配置的存活检测时间太长，那么应用真到了出现问题的时候，又无法及时被重启，从而影响了整体的可用性。

如果不配置就绪探针的话，也很尴尬：

比如有的场景下本身应用起来了，但是依赖的应用还没起来，那么此时还无法对外提供访问能力，此时就不能让请求流量进来。

所以不做选择题，全都要，需要在每个阶段用上对应的探针。

实战

6.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被重启多次

排查异常

出现问题时也不用慌，可以通过 kubectl get pods -n demo -o wide 和kubectl describe pod pod-lifecycle -n demo 排查。可以清晰的看到异常的原因：存活检查失败。

6.2、模拟启动慢的应用

编排 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 重复这样的动作：健康检查失败被重启。

引入 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。