Kubernetes 事件响应：处理 OOMKilled Pod 与集群可靠性

场景

您的 Kubernetes 集群报告大量 Pod 重启，原因是内存不足（OOMKilled）。多个微服务出现超时，部分节点进入压力状态。开发团队确认近期发布了更改，但不确定是否相关。作为 SRE，您必须快速响应以恢复服务并防止数据丢失。

症状

• 用户报告 502 错误或请求缓慢。
• kubectl get pods 显示大量 Pod 处于 CrashLoopBackOff 状态。
• kubectl describe pod <name> 显示 Exit Code: 137 或消息 OOMKilled。
• 节点指标（如 kubectl top node）显示内存使用率接近 100%。
• Kubernetes 事件（kubectl get events）显示 FailedKillPod 或 OOMKilling。

诊断

1. 检查 Pod 状态：使用 kubectl get pods --all-namespaces | grep -E 'CrashLoopBackOff|OOMKilled'。
2. 查看 Pod 事件：kubectl describe pod <pod-name> -n <namespace> 查找 Reason: OOMKilled。
3. 检查节点资源：kubectl top nodes 和 kubectl describe node <node-name> 查看内存在压力下的情况。
4. 查看容器日志：kubectl logs <pod-name> --previous 获取崩溃前日志。
5. 检查资源配置：kubectl get deployment <deployment-name> -o yaml 查看 resources.requests 和 limits.memory。

命令（安全注释）

# 列出所有崩溃的 Pod
kubectl get pods --all-namespaces --field-selector=status.phase=Failed | grep -v Completed

# 获取特定 Pod 的详细信息
export POD_NAME=$(kubectl get pods -n production -l app=myapp -o jsonpath='{.items[0].metadata.name}')
kubectl describe pod $POD_NAME -n production

# 查看前一个容器的日志（重要）
kubectl logs $POD_NAME -n production --previous

# 获取节点资源使用情况（需要 metrics-server）
kubectl top node

# 增加 Deployment 的内存限制（谨慎，避免节点过载）
kubectl set resources deployment myapp -n production --limits=memory=512Mi --requests=memory=256Mi

安全注意：增加资源限制前，请确认节点有足够容量。使用 kubectl describe node 查看可分配内存。`

风险控制

• 立即操作：如果服务不可用，考虑临时增加副本数（kubectl scale deployment myapp --replicas=5）分布负载。
• 限制并发：使用 PodDisruptionBudget 防止同时中断。
• 暂停自动回滚：如果问题由近期变更引起，暂停 CI/CD 管道以避免进一步部署。
• 监控警报：设置基于 OOMKilled 事件和节点内存压力的 Prometheus 警报。

回滚

1. 确定有问题的发布：检查最近部署的版本。kubectl rollout history deployment/myapp -n production。
2. 回滚到上一个稳定版本：kubectl rollout undo deployment/myapp -n production --to-revision=<previous-revision>。
3. 验证回滚：监控 Pod 状态和错误率。
4. 如果快速回滚不可行，则调整资源限制（如上所述）作为临时缓解措施。

验证

• Pod 应稳定运行，无崩溃循环：kubectl get pods --field-selector=status.phase=Running。
• 节点内存使用率下降（例如 kubectl top node 显示 <80%）。
• 应用程序端点返回 200 状态：curl -I https://myapp.example.com/health。
• 检查事件是否停止：kubectl get events --all-namespaces | grep -i OOM。

何时提交 OpsGlobal 工单

如果发生以下情况，请提交 OpsGlobal 工单： - 根本原因不明（例如，内存泄漏在代码中，需要开发分析）。 - 即使调整资源后问题仍持续，表明需要扩容或架构变更。 - 需要集群级性能优化或自动化事件响应。 - 涉及节点故障或控制平面问题，可能需要外部专业知识。

OpsGlobal 工程师可以协助进行深度分析、实施可靠模式和自动扩展策略，以提高集群弹性。