Pod被OOM Killed与探针失败排查

一、紧急信息收集（5分钟内完成）

1. Pod状态快照

   # 获取Pod最后状态（Exit Code=137表示OOM）
   kubectl get pod item-api-597d7778c5-nhzs5 -n prod -o wide 
   kubectl describe pod item-api-597d7778c5-nhzs5 -n prod | grep -E 'Status:|Exit Code:|Last State:|Reason:'
   
   # 查看节点内存压力（关键指标：MemoryPressure=True?）
   kubectl describe node cn-hangzhou.10.2.0.110 | grep -i pressure 
   

2. 日志回溯

   # 获取OOM前日志（--previous获取已终止Pod日志）
   kubectl logs item-api-597d7778c5-nhzs5 -n prod --previous | grep -i 'outofmemory\|exception\|error' -A 20 
   
   # 查看K8s事件时间线（重点：OOM发生时间与探针失败顺序）
   kubectl get events -n prod --field-selector involvedObject.name=item-api-597d7778c5-nhzs5 --sort-by=.metadata.creationTimestamp 
   

---

二、根因定位与优先级排序

1. 内存溢出（OOM Killed）排查

• 场景A：容器内存超限

  # 检查Pod内存限制配置 
  kubectl get pod item-api-597d7778c5-nhzs5 -n prod -o jsonpath='{.spec.containers[0].resources.limits.memory}'
  
  # 常见问题：JVM堆内存（-Xmx）超过容器限制，或未启用容器内存感知 
  # 解决方案：添加JVM参数 `-XX:+UseContainerSupport`
  

• 场景B：内存泄漏（Memory Leak）

  # 检查是否生成Heap Dump（需预先配置JVM参数）
  kubectl exec item-api-597d7778c5-nhzs5 -n prod -- ls /dumps 
  # 若存在dump文件，立即归档分析 
  kubectl cp prod/item-api-597d7778c5-nhzs5:/dumps/heap.hprof ./oom_analysis/
  
  # 无Heap Dump时，通过监控数据推断：
  # 查看内存增长曲线（Prometheus查询）
  container_memory_working_set_bytes{container="item-api", namespace="prod"}
  

2. 探针失败分析（Liveness/Readiness Failed）

• 关联性结论：
  OOM导致容器进程退出 → 端口监听终止 → 探针检测到connection refused（结果性现象，非独立问题）

• 需排除的独立问题：

  # 检查网络策略是否拦截探针流量 
  kubectl describe networkpolicy -n prod | grep 'item-api'
  
  # 验证服务监听地址（是否绑定到0.0.0.0而非127.0.0.1）
  kubectl exec item-api-597d7778c5-nhzs5 -n prod -- netstat -tulnp | grep 18870 
  

---

三、分场景修复方案

1. 内存配置优化（立即生效）

• JVM容器化最佳实践：

  # Deployment配置示例 
  resources:
    limits:
      memory: "4Gi"   # 必须等于或大于JVM堆+非堆内存之和 
    requests:
      memory: "3Gi"
  env:
    - name: JAVA_OPTS 
      value: "-XX:+UseContainerSupport -Xmx3g -Xms3g -XX:MaxMetaspaceSize=512m -XX:MaxDirectMemorySize=512m"
  

• 防御性参数：

  livenessProbe:
    initialDelaySeconds: 30  # 适当延长等待时间，避免过早触发重启 
  readinessProbe:
    failureThreshold: 5     # 增加失败容忍次数 
  

2. 内存泄漏修复（中长期）

• Heap Dump分析流程：

  1. 使用MAT/Eclipse Memory Analyzer加载heap.hprof
  2. 定位Retained Heap最大的对象（通常为泄漏点）
  3. 检查可疑引用链（如静态集合类、未关闭的数据库连接）

• 代码级修复示例：

  // 错误示例：静态Map未清理导致对象累积 
  public class CacheManager {
      private static Map<String, Object> cache = new HashMap<>();
  }
  // 修复方案：改用WeakHashMap或定期清理策略 
  

---

四、验证与监控增强

1. 灰度发布验证

   # 分批发布，观察新Pod内存曲线 
   kubectl rollout restart deploy/item-api -n prod 
   watch -n 2 'kubectl top pod -l app=item-api -n prod'
   

2. 监控大盘配置

   • 关键指标：

     container_memory_working_set_bytes{container="item-api"}  # 内存使用量 
     jvm_memory_used_bytes{area="heap"}                         # JVM堆内存 
     probe_success{container="item-api"}                        # 探针状态 
     

   • 告警规则：

     - alert: PodOOMKilled 
       expr: kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1 
       for: 1m 
     

---

五、长效防御机制

1. 混沌工程测试

   # 使用Chaos Mesh模拟内存压力 
   kubectl apply -f memory-stress-test.yaml 
   # 观察Pod自愈能力与OOM防护效果 
   

2. CI/CD集成静态分析

   • 在流水线中添加SpotBugs或SonarQube内存泄漏检测
   • 阻断存在CI_MEMORY_LEAK标签的代码合并

---

通过此流程可系统性解决OOM及探针失败问题，并将风险防控前置到开发阶段。优先级建议：优先修复内存配置问题（1小时内），其次分析泄漏根源（1-3天），最后完善监控与防御体系（持续迭代）。