从一次线上故障看K8s健康检查探针配置的正确姿势

K8s健康检查探针配置不当是导致生产环境中Pod频繁重启、流量接入异常的直接原因。在一次线上事故中，一个部署了20个副本的Java微服务集群在发布后半小时内反复重启，造成大量5xx错误。经过排查，问题出在liveness probe的初始延迟设置过短，导致应用启动慢时被误判为失效并被强制重启。这个案例印证了一个核心结论：合理配置K8s健康检查探针的参数，尤其是initialDelaySeconds、periodSeconds和failureThreshold，是保障服务稳定性的关键。

三种探针的职责与典型配置误区

K8s提供三种探针：liveness probe（存活探针）、readiness probe（就绪探针）和startup probe（启动探针）。存活探针决定是否重启容器，就绪探针决定是否将Pod加入Service的endpoint，启动探针用于慢启动场景。常见误区包括：将存活探针与就绪探针使用相同的配置、忽略启动探针、超时时间设置过于严格等。

存活探针配置不当导致无限重启

存活探针的failureThreshold乘以periodSeconds决定了Pod被判定为不可用并重启的时间窗口。如果将failureThreshold设为2、periodSeconds设为5，则10秒内两次失败后即重启。对于启动需要20秒的Java应用，这个配置必然导致连续重启。正确的做法是使用startup probe先给足启动时间，或者将initialDelaySeconds设置为大于预期启动时间。

apiVersion: v1
kind: Pod
metadata:
  name: my-java-app
spec:
  containers:
  - name: app
    image: myapp:1.0
    startupProbe:
      httpGet:
        path: /health/startup
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
      failureThreshold: 3
    livenessProbe:
      httpGet:
        path: /health/live
        port: 8080
      periodSeconds: 10
      failureThreshold: 3

在上述配置中，startup probe会先运行，允许最多45秒（15+10*3）的启动时间，期间liveness probe不会生效。启动成功后，liveness probe以10秒间隔检查，连续3次失败（30秒）后触发重启。这个组合有效避免了启动阶段的误杀。

就绪探针配置不当导致流量提前导入

某电商团队在发布新版本时，就绪探针的httpGet路径为/health/ready但该接口在应用初始化完数据库连接前就返回200，导致Pod被标记为Ready后立即接收流量，实际业务请求却因为数据库连接池未就绪而超时。修复方式是将就绪探针的检查逻辑改为依赖业务就绪信号，例如检查缓存预热完成状态。

据CNCF《2023年云原生报告》数据显示：超过40%的K8s生产事故与应用健康检查配置不当有关，其中就绪探针配置错误的占比最高。

精细化配置的四个关键参数

合理调整探针的四个参数能够规避大部分故障。initialDelaySeconds应大于应用平均启动时间；periodSeconds设置过短会增加系统开销，建议大于等于10秒；failureThreshold不宜小于3，防止瞬态波动引发误判；timeoutSeconds默认1秒，对于响应慢的操作应适当增加到5秒以上。

某金融科技公司的实战经验：对Spring Boot应用，将liveness probe的failureThreshold设为5，periodSeconds设为15，同时配置startup probe的failureThreshold为6，periodSeconds为10，成功将因探针导致的Pod重启率从每月12次降为0。

从故障到规范：一套可复用的探针配置模板

基于上述教训，可以总结出一套标准配置模板。对于Java/Node.js等需要较长启动时间的应用，必须配置startup probe。对于Readiness probe，应检查业务关键依赖（如数据库、缓存、消息队列）的可用性。Liveness probe应检查轻量级的内部状态，避免依赖外部服务导致级联故障。

以下是一套适用于大多数微服务的推荐配置模板（需根据实际服务调整）：

apiVersion: v1
kind: Pod
metadata:
  name: sample-service
spec:
  containers:
  - name: svc
    image: sample:1.0
    startupProbe:
      httpGet:
        path: /health/startup
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      failureThreshold: 10   # 允许最多100秒启动
    livenessProbe:
      httpGet:
        path: /health/live
        port: 8080
      periodSeconds: 15
      failureThreshold: 4    # 允许最多60秒的连续失败
    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080
      periodSeconds: 10
      failureThreshold: 3
      initialDelaySeconds: 10

注意：readiness probe的initialDelaySeconds可以略大于startup probe的预期完成时间，或者在startup probe成功之前readiness probe自动被K8s忽略。K8s 1.18及以上版本中，startup probe运行期间liveness和readiness probe不会执行。

监控与告警：把健康检查纳入可观测体系

配置好探针之后，还需要监控探针的失败情况。通过kubectl describe pod可以查看最近探针事件。可以设置Prometheus告警规则，当某个Pod的探针失败次数在1小时内超过阈值时发出告警。据Google Cloud《容器化应用最佳实践》白皮书指出：将健康检查数据与日志、Metrics关联分析，能快速定位根因，平均故障恢复时间（MTTR）缩短50%。

总结与建议

K8s健康检查是一个看似简单但极易踩坑的环节。核心原则是：给应用充分的启动时间，检查真实就绪状态，避免外部依赖导致级联失效。建议团队建立探针配置检查清单，并纳入CI/CD流水线的合规检查。每一次线上故障都是优化的契机，将复盘结论固化为配置规范，才能持续提升K8s集群的稳定性。

如果你正在排查Pod反复重启的问题，不妨先从健康检查探针的配置参数入手，重点检查startup probe是否存在、initialDelaySeconds是否合理、liveness probe的检查逻辑是否轻量准确。这些细节决定了你的服务能否在K8s中稳定运行。