在 Kubernetes 中，探针（Probes） 是用于检测容器健康状态的核心机制，主要包括以下三种类型：Liveness Probe（存活性探针）、Readiness Probe（就绪性探针）和 Startup Probe（启动探针）。以下是它们的用途、典型使用场景及配置建议：

🌟 1. Liveness Probe（存活性探针）

核心作用

判断容器是否存活。若探测失败，Kubernetes 会重启该容器。

典型应用场景

  • 🔄 长期运行的服务：如 Web 服务器、数据库等，需确保进程未崩溃。
  • ⚠️ 死锁恢复：当应用因外部依赖卡住时，通过重启逃生。
  • ⏳ 资源耗尽：内存泄漏导致 OOM Killer 终止进程时触发重启。

常用方式

类型 示例场景 优点 缺点
HTTP GET /healthz 端点 轻量级，无需登录 依赖应用暴露接口
TCP 检查数据库端口（如 3306） 协议层检测快速 无法感知应用逻辑错误
Exec pgrep java 或 cat /tmp/alive 灵活自定义命令 需信任容器内环境

配置示例

livenessProbe:httpGet:path: /healthzport: 8080initialDelaySeconds: 30      # 等待应用启动完成periodSeconds: 10            # 每10秒检查一次failureThreshold: 3          # 连续失败3次后重启

🌟 2. Readiness Probe（就绪性探针）

核心作用

判断容器是否已准备好接收流量。若探测失败，Pod 不会被纳入 Service 的负载均衡池。

典型应用场景

  • 🌐 服务上线前准备：等待数据库连接池填充完毕、缓存预热完成。
  • 🔗 依赖关系校验：确保下游服务可用后再处理请求。
  • 📦 批处理任务：等待消息队列中有足够任务时才开始消费。

关键特点

  • ✅ 避免无效流量：防止请求打到未就绪的容器。
  • ⏱️ 动态调整：结合自动扩缩容（HPA），仅对就绪实例计数。
  • 🔄 不触发重启：与 Liveness 的最大区别！

配置示例

readinessProbe:httpGet:path: /readyport: 8080initialDelaySeconds: 5       # 更快进入就绪检查periodSeconds: 5             # 更频繁检查（适合快速就绪的场景）

🌟 3. Startup Probe（启动探针）

核心作用

区分“应用启动慢”和“应用故障”。解决传统双探针无法分辨这两种情况的问题。

典型应用场景

  • ⏳ 重型应用启动：Java 应用加载大堆内存、机器学习模型加载。
  • 🗃️ 复杂初始化：等待外部存储挂载、配置文件下载完成。
  • 🔄 减少误杀：避免因启动时间过长被 Liveness 误判为死亡。

工作机制

  1. 优先执行：在容器启动后立即开始探测。
  2. 成功条件：一旦成功，则停止 Startup Probe，转而由 Liveness/Readiness 接管。
  3. 失败处理：若超过 failureThreshold，则判定为死亡并重启。

配置示例

startupProbe:httpGet:path: /startupport: 8080initialDelaySeconds: 10     # 根据启动时间调整periodSeconds: 2            # 高频快速检测failureThreshold: 30        # 允许最多30次失败（适配长时间启动）
livenessProbe:                # 同时保留常规存活探针httpGet:path: /healthzport: 8080

📌 最佳实践总结

探针类型 是否必需 推荐组合 注意事项
Liveness ✔️ + Startup（对慢启动应用） 避免过于敏感导致频繁重启
Readiness ✔️ 根据业务需求配置 确保能准确反映服务就绪状态
Startup 📚 适用于启动时间长的应用 成功后自动禁用，不影响正常运维
无探针 ❌ 极小化部署除外 缺乏健康检查可能导致雪崩效应

🛠️ 选择指南

你的需求 推荐方案
简单快速验证容器基础功能 Liveness (httpGet)
确保服务完全就绪后才接收流量 Readiness (httpGet) + Liveness
应用启动需数分钟且易假死 Startup + Liveness + Readiness
传统单体应用迁移上云 Liveness (tcpSocket)
微服务架构中的多级依赖检查 Readiness (依赖下游服务)

💡 进阶技巧

  1. 差异化配置：对同一容器的不同探针使用不同端点（如 /healthz vs /ready）。
  2. 性能优化：对频繁探测的探针（如 Readiness）设置较短 periodSeconds。
  3. 安全考量：对于敏感端点，使用 httpHeaders 添加认证头信息。
  4. 调试利器：kubectl describe pod <pod> 可查看探针最后一次成功/失败的时间戳。

通过合理组合三种探针，可以显著提升应用的可靠性和服务稳定性，这也是云原生应用区别于传统部署的重要特征之一。