场景

某金融平台的 Kubernetes 集群托管了一个名为 ledger-sync 的微服务。在一次例行发布中，2.3.1 版本在后台 worker 中引入了内存泄漏。四小时内，集群开始出现内存压力：多个节点报告 MemoryPressure 条件，kubelet 开始驱逐低优先级 Pod 以回收内存。收到告警：KubeNodeMemoryPressure。

初始症状

• kubectl get nodes 显示多个节点在 CONDITION 列有 MemoryPressure。
• 多个 Pod（包括无关服务的 Pod）被驱逐或重启。
• kubectl get events -A 显示 FailedScheduling，原因是 Insufficient memory。
• Pod 指标显示 ledger-sync worker Pod 的内存使用量稳定攀升至其限制。

诊断步骤

1. 确定压力来源

使用 kubectl top nodes 确认内存使用情况。然后进一步深入工作负载：

kubectl top nodes
kubectl top pods -n production --sort-by=memory

ledger-sync worker Pod 很可能显示接近限制的内存。

2. 检查节点和 kubelet 事件

kubectl describe node <nodename> | grep -A10 Conditions
kubectl get events -n production --field-selector involvedObject.name=<pod-name> -o wide

寻找 SystemOOM 或 Evicted 原因。

3. 检查资源请求和限制

kubectl describe pod <pod-name> -n production | grep -A2 Requests

如果容器没有内存限制，泄漏会耗尽节点内存。如果存在限制，容器将被 OOMKilled。

4. 检查应用程序日志

kubectl logs <pod-name> -n production --previous | tail -50

寻找重复分配或错误模式，这可能是泄漏的迹象。

5. 验证 HPA 和扩缩容行为

kubectl get hpa -n production

如果 HPA 基于内存进行扩缩容，它可能已经增加了副本，使问题更严重。

风险控制和安全检查

• 不要在不了解影响的情况下随机删除 Pod。只有在确保工作负载可重新调度后，才使用 kubectl drain。
• 限制爆炸半径：在回滚前使用 kubectl scale 减少副本数，但请注意，如果现有 Pod 仍然累积内存，缩容可能不会释放内存。
• 保护关键服务：如果必须驱逐 Pod，使用 PodDisruptionBudget（PDB）确保可用性。
• 保留证据：在更改之前，保存当前部署规范：kubectl get deployment ledger-sync -n production -o yaml > ledger-sync-current.yaml。
• 准备回滚工件：在镜像仓库中保留上一个镜像版本。

回滚计划

1. 隔离有故障的工作负载 – 将部署缩小到零，以停止进一步资源消耗：

kubectl rollout undo deployment/ledger-sync -n production --to-revision=<previous-revision>

1. 验证镜像标签 – 确保旧镜像健康：

kubectl get deployment ledger-sync -n production -o jsonpath='{.spec.template.spec.containers[].image}'

1. 检查卡住的驱逐 – 如果节点仍然有压力，封锁受影响的节点并迭代地排空：

kubectl cordon <nodename>
kubectl drain <nodename> --ignore-daemonsets --delete-emptydir-data --disable-eviction

警告：drain 与 --delete-emptydir-data 会删除 emptyDir 数据。仅在确认数据不重要时使用。

1. 快速缓解压力 – 如果集群严重不平衡，临时删除已驱逐的 Pod 以释放元数据：

kubectl delete pods -n production --field-selector=status.phase=Succeeded

验证

• 节点健康：kubectl get nodes 应显示没有 MemoryPressure。
• Pod 稳定性：kubectl get pods -n production 应显示所有期望的 Pod 都处于 Running 和 Ready。
• 应用性能：监控 ledger-sync 服务的延迟和错误率，确保回滚恢复正常。
• 资源使用：在 24 小时内观察 kubectl top nodes，确认内存使用回到基线。

何时提交 OpsGlobal 工单

如果出现以下任何一种情况，请提交 OpsGlobal 工单： - 内存泄漏在多个版本中反复出现，需要代码级修复。 - 节点出现 SystemOOM 内核事件，这可能表明更深层的基础设施问题。 - 尽管尝试了回滚，集群仍处于降级状态超过 30 分钟。 - 您需要设计或实施资源配额、垂直 Pod 自动扩缩容或工作负载重新平衡。

OpsGlobal 提供 7×24 小时的事件响应、根本原因分析和集群加固服务，让您的团队专注于产品，而我们将确保控制平面稳定。