[[k8s中三种探针的作用和应用场景1.0]]

前言

在使用 Kubernetes（K8s）时，通常会创建大量 Pod 来承载不同的业务服务。这些 Pod 内运行的容器数量多、类型复杂，人工实时监控每个容器的运行状态既不现实，也不高效。

因此，Kubernetes 提供了 探针（Probe）机制，用于对容器进行周期性健康检查，从而实现自动化的状态诊断与恢复。

Pod 探针的种类

Kubernetes 提供了三种类型的探针，用于从不同维度判断容器状态：

• startupProbe（启动探针）：容器是否完成启动？
• livenessProbe（存活探针）：容器是否仍然存活？
• readinessProbe（就绪探针）：容器是否已准备好对外提供服务？

探针的探测方式与结果

探针通过以下三种方式对容器进行检测：

• ExecAction：在容器内部执行指定命令
  • 返回码为 0 表示成功，否则为失败
• TCPSocketAction：对容器指定端口进行 TCP 检测
  • 端口可连接则认为成功
• HTTPGetAction：向容器指定端口和路径发起 HTTP 请求
  • 返回状态码在 200–399 之间视为成功

每次探测会得到三种结果之一：

• Success（成功）：容器通过检测
• Failure（失败）：容器未通过检测
• Unknown（未知）：检测未能得出明确结果（通常不会触发任何操作）

livenessProbe（存活探针）

用于判断容器是否仍然处于“健康运行”状态。如果探测失败，Kubernetes 会重启该容器。

• 适用场景：

  • 应用进程卡死（如死循环）
  • 无响应（如内存泄漏、线程阻塞等）

• 常见探测方式：

  • HTTP 请求
  • TCP 端口检测
  • exec 执行命令

readinessProbe（就绪探针）

用于判断容器是否已经准备好接收外部流量。如果探测失败，Pod 会被从 Service 的 Endpoints 中移除，不再接收请求，但容器本身不会被重启。

• 适用场景：

  • 应用尚未完成初始化（如配置加载、数据库连接等）
  • 避免未准备好的容器接收请求

• 常见探测方式：

  • HTTP 请求
  • TCP 端口检测
  • 执行命令

startupProbe（启动探针）

用于解决启动时间较长的容器被 livenessProbe 误判的问题。在启动阶段，只有 startupProbe 生效，livenessProbe 和 readinessProbe 会被暂时禁用。

当 startupProbe 检测成功后，其他探针才开始工作。

• 适用场景：

  • 启动耗时较长的应用（如大型 Java 应用）
  • 避免因启动时间过长被 livenessProbe 判定为失败并反复重启

• 典型问题：

  • 未配置 startupProbe 时，livenessProbe 可能在应用尚未启动完成前触发重启，导致容器陷入重启循环

总结

三种探针的职责可以概括为：

• startupProbe：解决“能不能正常启动”的问题
• livenessProbe：解决“运行过程中是否异常”的问题
• readinessProbe：解决“是否可以对外提供服务”的问题

合理配置三种探针，可以显著提升系统的稳定性与自愈能力。