健康检查：存活探针与就绪探针

Pod 的生命周期阶段（如 Running 或 Failed）提供了容器状态的高层视图，但它们并不总是能反映应用程序的运行状况。例如，一个处于 Running 状态的容器内部，应用程序可能已经死锁、陷入死循环，或者无法连接数据库。从外部看，进程似乎正在运行，但对用户来说，应用程序已经失效。Kubernetes 通过健康检查（health probes）解决了这一问题，它允许 Kubelet 从 Pod 内部主动检查应用程序的健康状况。

通过配置探针，您可以让 Kubernetes 直接询问您的应用程序：“你还好吗？”。根据返回的结果，Kubernetes 可以自动重启出现故障的容器，或暂时停止向其发送流量，从而构建出更具弹性且具备自愈能力的系统。

您可以为容器配置两种主要的探针类型：存活探针（liveness probes）和就绪探针（readiness probes）。

存活探针：应用程序是否还在运行？

存活探针用于检查容器是否仍在运行并有响应。如果存活探针失败达到指定次数，Kubelet 会认为应用程序处于无法恢复的状态（如死锁）。其处理方式虽然果断但也有效：直接杀死该容器。根据 Pod 的 restartPolicy（重启策略），通常会启动一个新容器来替换它。这是实现自动化恢复的核心机制。

以一个存在内存泄漏的应用程序为例。它可能在运行数小时内表现正常，但最终会变得无响应。存活探针可以检测到这种无响应状态并触发重启，从而在无需人工干预的情况下使应用程序恢复到健康状态。

下面是一个包含简单 HTTP 存活探针的 Pod 配置清单示例：

apiVersion: v1
kind: Pod
metadata:
  name: liveness-probe-pod
spec:
  containers:
  - name: my-app
    image: nginx
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10

在此配置中：

• httpGet：Kubelet 将向容器 80 端口的 / 路径发送 HTTP GET 请求。返回码在 200 到 399 之间被视为成功。
• initialDelaySeconds: 5：Kubelet 会在容器启动 5 秒后执行第一次探针检查。这为应用程序提供了初始化时间。
• periodSeconds: 10：探针将每 10 秒执行一次。

就绪探针：应用程序是否已准备好接收流量？

就绪探针用于确定容器是否已准备好开始接收网络流量。一个 Pod 可能处于存活状态，但尚未就绪。例如，应用程序可能需要在启动时加载大型配置文件或预热缓存。在此期间，它正在运行（并且能通过存活探针检查），但向其发送用户流量会导致错误。

如果就绪探针失败，Kubelet 不会 重启容器。相反，它会向 Kubernetes 控制平面发出信号，表明该 Pod 尚未就绪。随后，Endpoints 控制器会将该 Pod 的 IP 地址从指向它的所有 Service 中移除。在就绪探针再次成功之前，流量不会被路由到该 Pod。这对于实现零停机部署和更新非常有用。

存活探针和就绪探针的决策流程。存活探针失败会导致容器重启，而就绪探针失败会导致流量从该 Pod 移开。

探针机制

Kubernetes 提供了三种实现探针检查的方法：

1. httpGet：对容器 IP 地址上的特定路径和端口执行 HTTP GET 请求。这是 Web 应用程序最常用的探针类型。

   livenessProbe:
     httpGet:
       path: /healthz
       port: 8080
   

2. tcpSocket：尝试在指定的端口上打开 TCP 套接字。如果能建立连接，则探针成功。这适用于非 HTTP 类型的应用程序，例如数据库。

   readinessProbe:
     tcpSocket:
       port: 5432
   

3. exec：在容器内执行命令。如果命令退出的状态码为 0，则探针成功。这为编写自定义健康检查脚本提供了极大的灵活性。

   livenessProbe:
     exec:
       command:
       - cat
       - /tmp/health
   

   仅当容器内 /tmp/health 文件存在且可读时，此 exec 探针才会成功。

配置探针行为

通过几个参数，您可以微调探针的时间设置，以匹配应用程序的行为。配置不当可能会导致容器被不必要地重启，或者流量被发送到尚未准备就绪的应用程序。

• initialDelaySeconds：容器启动后，在执行第一次检查之前等待的秒数。将其设置得足够长以允许应用程序完成启动非常重要。
• periodSeconds：执行检查的频率（以秒为单位）。默认为 10。
• timeoutSeconds：探针超时后的秒数。默认为 1。如果探针超时，则被视为失败。
• failureThreshold：探针失败后，Kubernetes 在将容器标记为不健康（针对存活探针）或未就绪（针对就绪探针）之前将重试的次数。默认为 3。
• successThreshold：探针失败后，被视为成功所需的连续成功最小次数。默认为 1。

下面是一个更完整的示例，展示了同时包含存活探针和就绪探针的详细配置：

apiVersion: v1
kind: Pod
metadata:
  name: fully-probed-pod
spec:
  containers:
  - name: api-server
    image: my-company/api-server:1.2.0
    ports:
    - containerPort: 8080

    # 检查应用是否存活；如果不存活，则重启它
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      timeoutSeconds: 2
      periodSeconds: 20
      failureThreshold: 3

    # 检查应用是否准备好接收流量
    readinessProbe:
      httpGet:
        path: /readyz
        port: 8080
      initialDelaySeconds: 5
      timeoutSeconds: 1
      periodSeconds: 10
      failureThreshold: 2

在此清单中，就绪探针比存活探针更早开始检查（initialDelaySeconds: 5）且频率更高（periodSeconds: 10）。这使得 Kubernetes 能够快速确定应用程序是否可以接收流量。存活探针则设置得更宽松（initialDelaySeconds: 15），在决定重启之前给应用程序更多时间从临时问题中恢复。通过使用不同的 /healthz 和 /readyz 端点，应用程序可以独立报告其存活状态和就绪状态。

合理配置健康探针是在 Kubernetes 上构建可靠应用程序的基础。它们将您的部署从简单的进程管理器转变为一个能够自动处理常见应用程序故障的自愈系统。