Kubernetes 中的健康检查机制，是保障容器稳定运行的基石。通过探针，K8s 能够判断容器是否存活、是否可对外提供服务、是否已完成启动。
K8s 提供了三种类型的探针：
- Startup Probe（启动探针）
- Liveness Probe（存活探针）
- Readiness Probe（就绪探针）
它们看起来类似，实则各司其职。如果你曾经困惑于这些探针的配置逻辑、执行时机和组合方式，本文将为你一次性讲清楚。
一、三种探针的核心职责
| 探针类型 | 作用阶段 | 检查目的 | 检查失败后的处理方式 |
|---|---|---|---|
| Startup Probe | 容器启动期 | 应用是否启动完成 | 重启容器 |
| Liveness Probe | 运行期间 | 应用是否仍然活着 | 重启容器 |
| Readiness Probe | 运行期间 | 是否可对外提供服务 | 从服务列表中摘除，不重启容器 |
这三种探针的组合，像是守护程序生命周期的“三道防线”：
- Startup Probe：启动期间的“保命符” ；
- Liveness Probe：运行期间的“心跳监测器” ；
- Readiness Probe：服务可用性的“接待员” 。
二、执行时序一图搞懂
容器启动
│
├───> 执行 Startup Probe（若配置）
│ ├── 成功 → 启动完成 → 进入正常运行
│ └── 失败 → 超过阈值 → 重启容器
│
└───> 执行 Liveness Probe & Readiness Probe（若配置）
简而言之：
- 如果配置了
startupProbe，只有它通过后，K8s 才会开始执行其他两个探针； - 否则，
livenessProbe和readinessProbe会在容器启动一段延时后直接执行。
三、实际配置示例（综合使用）
我们以一个 Node.js 服务为例，配置三种探针。
livenessProbe:
httpGet:
path: /healthz/live
port: 3000
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /healthz/ready
port: 3000
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 2
startupProbe:
httpGet:
path: /healthz/startup
port: 3000
periodSeconds: 5
failureThreshold: 30
含义说明：
startupProbe：最多容忍 150 秒（5 × 30）时间用于启动。livenessProbe：确认服务是否挂死，失败超过 3 次后自动重启容器。readinessProbe：确认服务是否可以接收请求，失败时容器被摘除但不重启。
四、常见组合策略与建议
✅ 场景一：应用启动慢
推荐：使用 Startup Probe
startupProbe:
httpGet:
path: /healthz/startup
port: 8080
periodSeconds: 5
failureThreshold: 30
不要盲目调大 livenessProbe.initialDelaySeconds，那只是“拖延检查”，而不是解决问题。
✅ 场景二：服务运行中可能崩溃
推荐：使用 Liveness Probe
livenessProbe:
exec:
command: ["curl", "-f", "http://localhost:8080/health"]
periodSeconds: 10
failureThreshold: 3
若你服务可能因内存泄露、线程死锁、心跳丢失等挂死，配置 liveness 可以自动拉起容器，恢复正常。
✅ 场景三：服务初始化完成后才能对外
推荐：使用 Readiness Probe
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
failureThreshold: 2
适用于微服务注册中心、数据库初始化、缓存加载完成前不宜接收外部请求的场景。
五、调试建议
- ✅ 分别配置三个接口路径，便于开发调试与日志定位；
- ✅ 探针接口应尽量轻量快速，避免额外依赖或复杂逻辑；
- ❌ 不要混用探针含义，例如拿
readiness去判断“进程存活”； - ✅ 结合日志、Prometheus 等监控工具观察探针行为效果；
- ✅ 优先考虑 startup + readiness 的组合，提高服务部署鲁棒性；
六、常见误区汇总
| 误区描述 | 正确认识 |
|---|---|
把 initialDelaySeconds 设置得很长来“规避探针失败” | 正确方式是使用 startupProbe |
所有服务都配置 livenessProbe 就好 | 不一定，配置不当反而导致频繁重启 |
| 探针失败就一定要重启容器 | readinessProbe 失败是摘除，不重启 |
只配一个 /health 接口，供三个探针复用 | 建议拆分路径，更清晰 |
七、一句话总结三探针
Startup Probe 保证能启动，Liveness Probe 保证别挂，Readiness Probe 保证能接活。
八、结语
探针的配置看似简单，实则对系统稳定性有深远影响。合理使用探针，能有效提升容器服务的健壮性、稳定性和可观测性，也是高质量微服务部署的基础。
如果你曾因为容器“假死”、“起不来”而陷入排查地狱，不妨现在就试试合理配置三种探针组合，让你的服务更加稳定健壮！
