健康检查与探针：Liveness、Readiness 与 Startup

在分布式系统中，自动检测并响应容器故障是保障服务高可用的基石。Kubernetes 通过探针（Probe） 机制，让平台能够实时感知容器内部状态，并执行相应的恢复或流量控制策略。本教程将深入解析三种核心探针：Liveness、Readiness 与 Startup，帮助你构建更加健壮的应用部署。

什么是 Kubernetes 探针？

Kubernetes 探针是由 kubelet 定期执行、用于诊断容器健康状况的检查。它们就像容器的“家庭医生”，持续监听并做出关键决策。

探针的作用

• 自动化故障恢复：无需人工介入，及时重启不健康的容器。
• 精细化流量控制：确保只有就绪的容器才能接收用户请求。
• 优雅启动：保护启动缓慢的应用不被误杀。

探针类型概述

Kubernetes 提供四种探针类型，这里我们聚焦于与容器生命周期健康直接相关的三种：

1. Liveness Probe：判断容器是否存活。
2. Readiness Probe：判断容器是否就绪以接收流量。
3. Startup Probe：判断容器内的应用是否已完成启动。

还有一种 Startup Probe 之外的旧式方法，即配置 initialDelaySeconds，但新设计推荐使用 Startup Probe。

三种关键探针详解

Liveness Probe（存活探针）

存活探针用于检查容器是否仍在正常运行。如果探测失败，kubelet 会认为容器已死，并依据重启策略（restartPolicy）将其杀死后重建。

• 失败动作：杀死容器，并触发重启。
• 典型用途：
  • 应用进入死锁状态，进程未退出但无法处理请求。
  • 内存泄漏导致 OOM 预兆，进程僵死。
• 设计原则：轻量级，仅验证应用是否还活着，不应依赖外部依赖（如数据库连接）。如果因外部依赖不可用就重启，可能引发级联故障。
• YAML 示例（使用 HTTP GET 检查）：

  livenessProbe:
    httpGet:
      path: /healthz
      port: 8080
    initialDelaySeconds: 15
    periodSeconds: 20
  

Readiness Probe（就绪探针）

就绪探针判断容器是否已准备好服务请求。如果探测失败，容器不会被杀死，而是从 Service 的端点列表中移除，停止向它转发流量。

• 失败动作：将该 Pod 的 IP 从所有匹配的 Service Endpoints 中移除。
• 典型用途：
  • 应用启动后需要预热（如加载缓存、建立连接池）。
  • 实例过载时主动“退避”，让负载均衡器暂时绕开自己。
  • 依赖的后端服务不可用，应用主动拒绝流量（需谨慎设计，避免全部实例同时不可用）。
• 与 Liveness 的关键区别：
  • Liveness 失败 → 重启容器，目的是恢复运行态。
  • Readiness 失败 → 停止流量，但不重启，容器保留进程状态，等待恢复。
• YAML 示例：

  readinessProbe:
    httpGet:
      path: /ready
      port: 8080
    initialDelaySeconds: 5
    periodSeconds: 10
  

Startup Probe（启动探针）

启动探针专门针对需要较长时间初始化的老应用或资源密集型服务。它保护慢启动容器，防止其在完成启动前被 Liveness Probe 误杀。

• 工作原理：当配置了 Startup Probe 时，所有其他探针都会被禁用，直到它首次成功为止。成功之后，Liveness Probe 和 Readiness Probe 才开始接手运行。
• 典型用途：
  • 加载大型数据集或缓存需要几分钟的应用。
  • 需要等待下游服务，但启动慢并不代表永久故障。
• 设计要点：给予足够长的 failureThreshold \* periodSeconds 覆盖最大启动时间。
• YAML 示例：

  startupProbe:
    httpGet:
      path: /startup
      port: 8080
    failureThreshold: 30
    periodSeconds: 10
  

  该配置允许 Pod 在 300 秒（30×10）内完成启动，期间不会触发 Liveness 或 Readiness 检查。

探针的配置方式

支持的检查方法

每种探针都可以选择以下四种探测方式之一：

• httpGet：对指定端口和路径发起 HTTP GET 请求，状态码 200–400 之间视为成功。
• tcpSocket：尝试与指定端口建立 TCP 连接，连接建立成功则通过。
• exec：在容器内执行命令，返回码为 0 即成功。
• gRPc（v1.24+）：执行 gRPC 健康检查协议。

通用参数

所有探针共享一套微调参数，精确控制检查行为：

配置示例：综合 YAML

以下 Deployment 为一个慢启动应用同时配置了三种探针：

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        image: your-app:1.0
        ports:
        - containerPort: 8080
        startupProbe:
          httpGet:
            path: /startup
            port: 8080
          failureThreshold: 30
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          periodSeconds: 15
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          periodSeconds: 10

最佳实践与注意事项

1. 明确职责分离

   • Liveness 只做生存判断，勿包含复杂依赖检查。
   • Readiness 可以暂时将自身从流量中摘除，但不应触发重启。
   • 如果你的应用会主动将自身标记为“不健康”但又能自愈，避免用 Liveness 去检测它，以免重启中断自愈过程。

2. 保护慢启动容器

   • 始终为启动时间超过 initialDelaySeconds + failureThreshold*periodSeconds 的应用配置 Startup Probe，避免 Liveness 误杀。
   • 设置 Startup Probe 的失败阈值相对宽松，覆盖最坏情况的启动时间。

3. 探测端点应保持轻量

   • 避免在探测接口执行重量级数据查询或复杂计算。Liveness 和 Startup 的端点最好只是返回一个固定状态，不依赖任何下游。
   • 避免把 Readiness 探针设计为与关键外部服务强耦合，防止因外部服务波动导致所有 Pod 从 Service 中移除，造成服务整体不可用。

4. 合理的探测频率与超时

   • 不要将 periodSeconds 设得过小，以免给控制平面和应用带来压力。
   • timeoutSeconds 应略高于应用正常响应时间，但不宜过大，否则造成无谓等待。

5. 使用命名端点

   • 分别为不同探针提供独立路径（如 /healthz、/ready、/startup），以便在应用内实现针对性的健康检查逻辑。

6. 测试探针行为

   • 在预生产环境模拟故障场景，验证 Liveness 是否及时重启，Readiness 是否正确摘流。

总结

Kubernetes 的 Liveness、Readiness 和 Startup 探针是一组精密的健康检查武器库。正确使用它们，能让你的服务从被动“盼着别挂”转变为主动“可观测、可自愈”的云原生形态。记住它们的核心口诀：

• Startup 给足耐心，Liveness 判生死，Readiness 断流量。
• 轻量、责任单一、不滥用外部依赖。

合理配置探针，是迈向生产级稳定性的关键一步。现在，你可以去重新审视自己服务的 Pod 定义了。