Kubernetes 事件响应：处理内存压力与 Pod 驱逐

场景描述

假设你负责一个生产级 Kubernetes 集群，突然收到大量告警：多个节点出现 MemoryPressure，Pod 被驱逐，应用开始崩溃或无法访问。这种场景并不罕见，但如果不迅速正确处理，可能会导致服务中断。本文将通过一个真实案例，带你逐步完成事件响应流程，并给出可复用的命令和策略。

症状与告警

典型的症状包括：

• 节点状态变为 MemoryPressure 或 NotReady。
• Pod 被频繁驱逐，状态变为 Evicted 或 Failed。
• 应用健康检查失败，用户报障延迟增加。
• 告警系统（如 Prometheus + Alertmanager）发出 MemoryPressure、NodeNotReady 或 PodEvicted 事件。

诊断流程

1. 评估集群整体状态

首先，观察集群中节点和 Pod 的全局视图：

kubectl get nodes
kubectl get pods -A -o wide

如果大量节点处于 NotReady，则问题可能更严重，可能需要检查控制面。如果只是个别节点，则可能是节点级资源问题。

2. 检查节点状态与条件

使用 describe 查看详细状态：

kubectl describe node <node-name>

重点查看 Conditions 部分，注意 MemoryPressure 是否为 True。同时检查 Allocated resources，了解资源请求和限制的对比。

3. 查看节点和 Pod 的资源消耗

使用 top 命令获取实时数据：

kubectl top node
kubectl top pods -A --sort-by='memory'

找出内存占用最高的 Pod 和节点。如果某个 Pod 的内存使用远超其限制，则可能是内存泄漏导致。

4. 查看 Kubernetes 事件和 kubelet 日志

事件会记录驱逐原因：

kubectl get events --sort-by='.lastTimestamp' -A | grep -i evict

检查 kubelet 日志（注意系统路径可能不同）：

journalctl -u kubelet -n 100 --no-pager

这些日志会显示内存压力时的驱逐决策，通常包含 Evicting 和 MemoryPressure 关键字。

风险控制与缓解措施

1. 限制风险，避免二次伤害

• 不要同时删除多个副本：如果应用是无状态且多副本，尽量确保至少有一个可用副本。
• 使用 PodDisruptionBudgets (PDB)：如果尚未配置，在执行驱逐或 drain 前请先创建 PDB，限制自愿中断的副本数量。
• 备份关键配置：任何修改前，保存当前资源清单，以便回滚。

2. 立即缓解节点压力

如果某个节点内存紧张，可以尝试释放资源：

• 手动删除不必要的 Pod： bash kubectl delete pod <pod-name> -n <namespace>
• 如果有低优先级工作负载，可以考虑删除或暂停。
• 使用 kubectl drain 将节点上的 Pod 安全移走，但必须先确保 PDB 存在： bash kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data 安全提示：drain 会导致节点不可调度，务必在业务低峰操作，并在完成后 uncordon。

3. 调整工作负载的资源请求和限制

检查问题应用的资源规格。如果没有设置 requests 和 limits，那么调度器无法有效分配资源，kubelet 也容易因 OOM 而驱逐。调整 YAML：

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "1Gi"
    cpu: "1"

应用更新后，滚动重启 Pod：

kubectl rollout restart deployment/<app-name> -n <namespace>

4. 增加节点或缩小节点规模

如果集群整体资源不足，考虑增加节点（如果是托管 Kubernetes，可以调整节点池）。在公有云上，可能还需要检查自动扩缩容是否生效。

回滚策略

如果修改了工作负载的资源规格或调度配置，导致问题加重，应立即回滚：

• 回滚 Deployment： bash kubectl rollout undo deployment/<app-name> -n <namespace>
• 回滚配置：如果修改了 kubelet 参数或集群配置，需使用备份文件恢复，并重启对应组件。

如果对节点执行了 drain，在确认问题解决后恢复调度：

kubectl uncordon <node-name>

验证与事后复盘

1. 验证集群恢复

• 检查节点状态： bash kubectl get nodes 确认所有节点为 Ready 且无 Pressure。
• 检查 Pod 状态： bash kubectl get pods -A | grep -v Running 确保没有长时间处于 Pending 或 Evicted 的 Pod。
• 观察应用健康：通过监控仪表盘或实际请求测试。

2. 事后复盘

• 回顾事件时间线，找出根因。是部署变更、流量突增还是代码内存泄漏？
• 使用 kubectl describe node 和历史监控数据（如 Prometheus）进行分析。
• 制定改进措施：为关键组件添加合理的资源限额、配置 PDB、设置告警阈值、考虑集群自动扩缩容。

何时联系 OpsGlobal

作为远程 DevOps/SRE 支持服务，OpsGlobal 可以在以下情况助你一臂之力：

• 集群意外宕机，内部团队无法立即响应，需要 24/7 专家介入。
• 事件根因复杂，涉及内核、kubelet 或云提供商底层问题，缺乏深入排查经验。
• 需要快速恢复生产，同时避免因不熟悉操作而引发二次故障。
• 希望建立更完善的可靠性体系，例如制定 playbook、优化监控告警和进行故障演练。

当出现以上情况时，请立即提交 OpsGlobal 工单，我们将在几分钟内响应，并提供远程支持，确保您的集群恢复稳定。

结论

Kubernetes 事件响应需要在压力下保持冷静，并遵循系统化的诊断流程。本文介绍的内存压力与 Pod 驱逐场景只是冰山一角，但通过掌握这些核心步骤，您已经能应对大多数集群资源类事件。记住：快速缓解、安全操作、事后复盘是保持集群可靠性的关键。