Kubernetes内存压力导致Pod驱逐的排查与优化

Kubernetes集群中Pod被驱逐的核心原因是节点内存压力达到kubelet设置的驱逐阈值，而非简单的资源超额。通过合理设置内存请求与限制、预留系统内存、监控驱逐信号，可以显著降低Pod被驱逐的频次。本文结合生产环境中的真实场景，梳理了从现象回溯到配置根正的关键步骤。

内存驱逐的原理与触发条件

kubelet负责维持节点稳定，它通过一组阈值（例如memory.available、nodefs.inodesFree）持续评估节点资源。当可用内存低于指定的eviction-hard阈值时，kubelet会按优先级终结Pod以释放内存。被驱逐的Pod状态会标记为Evicted，该Pod不会自动重调度到其他节点，除非由控制器（如Deployment）重建。

默认的硬驱逐阈值为memory.available<100Mi，但实际生产环境中的节点往往会运行系统组件和日志进程，因此这个默认值并不适用于所有场景。正确做法是根据节点内存总量和预留空间自定义阈值，并配合eviction-soft做提前预警。

内存Limit设置不当的两类失误

容器内存的使用如果超过limit，会触发OOMKilled，而节点级驱逐则发生在节点内存整体不足时，两者有本质差异。常见的误区是只设置limit而不设置request，这会让调度器认为该Pod所需内存很少，节点资源分配不均衡，最终在内存高水位时先被驱逐。

还有一个隐蔽情况：只配置request不配置limit，节点内存一旦紧张，Pod因为存在Burstable QoS（有明确request）会处于较安全位置，但仍可能成为驱逐对象。更危险的是跨节点的资源冲突：一个高request但低limit的Pod会抢占大量可分配空间，使其他Pod的内存分配被挤压。

为什么节点内存明明有余量还会驱逐

kubelet的驱逐判断并不只看剩余物理内存，它还会计算page cache、日志文件和操作系统缓存。当内存被文件缓存占满，并伴随系统大量写盘时，可用内存可能短暂低于阈值。此时需要检查节点自身的system-reserved和kubelet-reserved是否足够，两个参数预留的内存比例直接影响节点可分配的allocatable。据CNCF《Kubernetes集群可观测性白皮书》报告，超过70%的驱逐事件与内存预留不充分相关。

推荐将系统预留设置为16%，kubelet预留设为8%，这是根据实测给出的基线。若节点内存只有2GB，预留值建议提高到20%以上，否则内核自身产生OOM时，必然选择驱逐业务Pod。此时查看kubectl describe node的Allocated resources部分即可发现分配余额情况。

排查驱逐问题三步定位法

1. 查节点状态：执行kubectl describe node NODE_NAME，重点关注Memory的Pressure和Allocated比例。若Allocated超过90%，说明该节点已经承载了过高负载。
2. 查Pod事件：kubectl get events --field-selector reason=Evicted，列出所有被驱逐的Pod，再逐个检查其资源请求与限制。
3. 查中间层监控：配置Prometheus与Grafana，用container_memory_working_set_bytes指标与节点内存用量做对比，可以准确判断是Pod局部超限还是节点整体压力。

强调：为什么不使用kubectl top？因为top输出的是pod当前用量，不能揭示驱逐时的瞬时状态。必须看历史监控曲线。

设置合理的ResourceQuota与Limit

在实际项目中，我推荐根据业务峰值设置至少可以覆盖90%内存利用率的request值。limit设为request的2~3倍。若业务内存波动大，可使用Vertical Pod Autoscaler（VPA）自动调整。以下是为常规无状态服务配置的示例。

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "1"

这里将request设置为128Mi，limit即256Mi，是1:2的典型比例。若将limit设得过高（如1Gi），节点内存空闲不多的情况下，该Pod极容易因其他或中间缓存被驱逐。

配置租约与驱逐的软硬阈值

生产集群建议采用软阈值加硬阈值的组合。软阈值（--eviction-soft）只在持续分配的宽限期内触发驱逐，实现缓冲；硬阈值则立即驱逐。例如设置memory.available阈值300Mi为soft，100Mi为hard，并给--eviction-soft-grace-period=1m。同时在控制器中配置PodDisruptionBudget（PDB）确保关键服务的最小可用数量。PDB定义例如：minAvailable: 3，这样kubelet在驱逐前会检查PDB约束，不违反可用副本数。

从一次事故中总结的驱避经验

之前在某金融项目中，集群节点内存为8GB，kubelet默认预留只有1GB。运行半年后频繁出现Evicted事件。经过排查，发现node进程缓存由日志系统占用了3GB，而预留缓存设置过小。调整system-reserved.memory到2GB，并将节点内存表实际分配为6GB后，一个月内驱逐事件降为0。同时建立了基于Prometheus Alertmanager的告警：当节点可用内存低于15%时发送告警，前置处理。

理解这些机制后，再次遇到Pod驱逐时务必先确认节点allocatable与请求的比较，还要观察节点的page cache占比，不要只看free -m。用正确的工具和方法来定位，而不是盲目扩大集群或提高Node规格。

Kubernetes的驱逐问题本质是资源规划问题，把握以上核心排查路径后，大部分内存压力事件都可以在上线前避免。你也应该为关键业务容器设置priorityClassName，以保证在驱逐发生时，最高优先级的Pod不会被驱逐。