Pod的健康检查方式

Kubernetes健康检查实战手册：让Pod学会"自愈"的三种神器

在生产环境中，健康检查是保障Kubernetes应用稳定性的第一道防线。本文将深入解析三种探针的运作机制，并分享经过100+集群验证的实战经验。

---

一、健康检查三剑客

1. 存活探针（Liveness Probe） - 应用"心脏监护仪"

   • 作用：持续监测应用存活状态，发现问题立即重启容器
   • 典型场景：
     • 检测应用死锁
     • 发现内存泄漏导致的假死
     • 处理文件系统损坏等异常
   • 危险操作：配置不当可能导致"死亡循环重启"

2. 就绪探针（Readiness Probe） - 流量"智能开关"

   • 作用：控制服务是否接收流量，保障平滑上线
   • 关键用途：
     • 新Pod启动完成前屏蔽流量
     • 临时过载时自动熔断
     • 数据库主从切换时隔离异常节点

3. 启动探针（Startup Probe） - 慢热应用的"暖宝宝"

   • 作用：保护初始化耗时长的应用
   • 经典案例：
     • Java应用冷启动耗时3分钟
     • 大数据组件加载海量配置
     • 机器学习模型预加载

---

二、探针配置的六脉神剑

所有探针支持三种检测方式：

检测类型	适用场景	生产建议
HTTP检查	Web服务、REST API	使用专用健康检查端点
TCP检查	数据库、缓存等非HTTP服务	避免直接检测业务端口
Exec命令	复杂状态检测（如文件锁存在性检查）	确保命令执行时间<timeout设置

完整参数配置模板：

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
    - name: X-Custom-Header
      value: "ProbeCheck"
  initialDelaySeconds: 30  # 必须大于应用启动时间
  periodSeconds: 5         # 检测间隔不宜过短
  timeoutSeconds: 3        # 超时时间需小于间隔
  successThreshold: 1      # 成功阈值
  failureThreshold: 3      # 失败阈值

---

三、生产环境黄金法则

1. 参数调优四原则

   • initialDelaySeconds ≥ 应用冷启动时间 × 1.2
   • periodSeconds ≥ 预期检测耗时 × 3
   • failureThreshold 根据业务容忍度设置（建议3-5）
   • timeoutSeconds ≤ 1/3 periodSeconds

2. 安全防护三板斧

   startupProbe:
     httpGet:
       path: /healthz
       port: 8080
     failureThreshold: 30  # 30次×10秒=5分钟
     periodSeconds: 10
   

   • 启动阶段禁用存活探针
   • 单独配置健康检查端口
   • 敏感检查接口需要身份验证

3. 监控告警配置
   Prometheus关键指标：

   - record: container:probe_failures:rate5m
     expr: |
       rate(kubelet_prober_probe_total{result!="success"}[5m])
       / 
       rate(kubelet_prober_probe_total[5m])
   

   推荐告警规则：

   - alert: HighProbeFailureRate
     expr: container:probe_failures:rate5m > 0.3
     for: 10m
   

---

四、经典故障排查案例

案例1：健康检查导致雪崩

• 现象：流量高峰时段Pod大规模重启
• 根因：periodSeconds=2且timeoutSeconds=3，检测间隔小于超时时间
• 解决方案：调整periodSeconds=5，timeoutSeconds=2

案例2：文件锁引发的血案

• 现象：Pod频繁重启但日志无异常
• 排查：
  1. 添加exec探针检查锁文件

  livenessProbe:
    exec:
      command:
      - test
      - -f
      - /var/lock/.healthy
  

  2. 发现文件锁未及时清理
  3. 优化清理机制后恢复正常

案例3：内存泄漏伪装大师

• 现象：Pod每天凌晨重启
• 诊断：

  kubectl describe pod | grep 'Last State' -A 5
  # 显示OOMKilled
  

• 解决方案：调整内存limits并添加分析工具

---

五、高阶技巧：动态健康检查

1. 分级健康检查

   readinessProbe:
     httpGet:
       path: /health?level=basic
   livenessProbe:
     httpGet: 
       path: /health?level=full
   

2. 流量染色检查

   httpHeaders:
   - name: X-Probe-Type
     value: "k8s-healthcheck"
   

3. 压力感知型检查

   // 示例Go实现
   func HealthHandler(w http.ResponseWriter, r *http.Request) {
       if system.Load > 0.8 {
           w.WriteHeader(503)
       }
   }
   

---

六、避坑指南

1. 绝对禁止的操作

   • 使用同一端点配置就绪和存活探针
   • 在健康检查中实现复杂业务逻辑
   • 检测时间超过应用SLA要求

2. 必须遵守的军规

   # 正确示例
   readinessProbe:
     httpGet:
       path: /ready
   livenessProbe:
     httpGet:
       path: /live
   startupProbe:
     httpGet:
       path: /started
   

3. 混沌工程测试清单

   • 随机终止健康检查进程
   • 模拟网络延迟（tc命令）
   • 注入IO异常（faulty驱动）

掌握这些核心要点，您的Kubernetes应用将获得真正的"自愈"能力。记住：好的健康检查策略应该像优秀的消防系统——平时默默守护，关键时刻力挽狂澜。