Readiness与Liveness探针

Kubernetes健康检查双刃剑：深度解析Readiness与Liveness探针

在Kubernetes集群中，Pod的健康检查机制如同人体的免疫系统，而Readiness与Liveness探针则是这个系统的核心防线。本文将深入解析二者的差异，并分享生产环境中的最佳实践。

---

一、核心概念对比表

维度	Liveness Probe	Readiness Probe
检查目标	是否存活	是否就绪
失败后果	重启Pod	从Endpoint摘除
触发时机	持续检测	持续检测
典型检查项	进程存活状态	依赖服务可用性
恢复机制	重启容器	自动重新加入服务
默认行为	不配置则默认健康	不配置则默认就绪
生产使用频率	85%场景使用	95%场景使用

---

二、工作机制深度解析

1. Liveness Probe（存活探针）

作用机制：

livenessProbe:
  exec:
    command:
    - /app/healthcheck
  initialDelaySeconds: 30  # 容器启动后等待时间
  periodSeconds: 10        # 检查间隔
  timeoutSeconds: 5        # 超时阈值
  successThreshold: 1      # 成功阈值
  failureThreshold: 3      # 失败阈值

典型应用场景：

• 检测内存泄漏导致的服务僵死
• 监控因死锁无法响应的Java应用
• 发现文件描述符耗尽等资源问题

生产案例：某电商系统因未配置Liveness探针，导致订单服务假死后无法自动恢复，损失百万订单

2. Readiness Probe（就绪探针）

作用机制：

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
    httpHeaders:
    - name: X-Probe
      value: "k8s-ready-check"

典型应用场景：

• 等待数据库连接池初始化完成
• 确保缓存预热完成
• 灰度发布时的流量切换
• 依赖服务健康状态检查

血泪教训：某金融系统因Readiness检测点不当，导致服务未完全就绪接收流量，引发数据不一致

---

三、生产环境配置指南

1. 参数调优黄金法则

# 通用优化模板
probes:
  initialDelaySeconds: 容器启动时间 + 10s缓冲
  periodSeconds: 5-10s（关键服务）/30s（普通服务）
  timeoutSeconds: < periodSeconds的50%
  failureThreshold: 3（Liveness）/ 2（Readiness）
  successThreshold: 1（Liveness）/ 2（Readiness）

2. 检查方式选择策略

检查类型	适用场景	风险提示
HTTP	Web服务（85%场景推荐）	注意路径鉴权
TCP	非HTTP协议服务	无法验证业务逻辑
Command	复杂检测逻辑	注意命令执行性能影响

3. 高级联动配置

# 与PreStop Hook配合实现优雅终止
lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 30"]

---

四、故障排查工具箱

1. 探针状态诊断命令

# 查看探针详细状态
kubectl describe pod <pod-name> | grep -A 15 "Liveness"
kubectl get --raw /api/v1/namespaces/<ns>/pods/<pod>/status | jq '.status.containerStatuses'

# 模拟探针失败
kubectl exec -it <pod> -- curl -X POST http://localhost:15000/quitquitquit

2. 常见错误代码解析

状态码	含义	处理方案
137	Liveness失败触发重启	检查应用启动逻辑
503	Readiness失败被摘除	验证依赖服务可用性
ERR_CONN_TIMED_OUT	探针超时	调整timeoutSeconds参数

3. Prometheus监控方案

# 监控探针失败率
sum(rate(kubelet_probe_errors_total[5m])) by (probe_type)
# 检测僵尸Pod
kube_pod_status_ready{condition="false"} > 0

---

五、行业最佳实践

1. 渐进式就绪检查：某社交平台采用多级Readiness检查，将启动失败率降低70%
2. 熔断机制集成：配合Istio实现双维度健康检查，服务可用性提升至99.99%
3. 压力测试策略：在Load Testing阶段验证探针配置，避免误杀健康实例

关键指标建议：

• Liveness失败重启率应<0.1%/小时
• Readiness摘除恢复时间应<30秒
• 探针检测耗时P99<800ms

通过合理配置这对健康检查"双胞胎"，某物流平台成功将服务中断时间从月均30分钟降至30秒。掌握这些核心要点，您将构建出具备自愈能力的Kubernetes服务体系。