如何让Kubernetes优雅处理内存过载，避免Pod被OOMKilled或节点崩溃？

一、EC2实例添加Swap的可行性 #

• 技术上可行，但需结合EC2特性调整：
  • 优先用EBS卷创建Swap（实例存储重启后Swap数据会丢失，可靠性差），但EBS的网络IO延迟会导致高内存任务性能下降（和本地Swap逻辑一致，但速度更慢）。
  • 必须修改Kubernetes配置：kubelet需添加--fail-swap-on=false参数，并在kubelet配置中启用memorySwap（设置swap使用比例或阈值），否则K8s默认会标记有Swap的节点为不可调度。
• 核心价值：避免高内存任务因突发内存溢出被OOMKilled，但会牺牲任务执行速度，且可能增加节点整体负载延迟。

二、Kubernetes Swap支持的稳定性 #

• K8s 1.20引入Swap支持（beta），1.22正式转正，但目前仍存在部分未解决的边缘问题：
  • Guaranteed QoS等级的Pod内存限制与Swap的协同逻辑存在歧义，部分场景下可能出现超出Limit仍使用Swap的情况；
  • 节点内存压力触发驱逐时，Swap的使用状态会影响驱逐策略的准确性。
• 适用场景：如果你的任务以Burstable/BestEffort为主，且对执行延迟容忍度较高，当前Swap支持足够稳定；若有严格SLA的核心任务，建议先在测试集群完成全场景验证后再上线。

三、更轻量化的鲁棒性提升方案 #

1. 差异化配置Pod的Request和Limit #

• 针对80%+的常规任务（~800MB内存）：设置resources.requests.memory: 800Mi，resources.limits.memory: 6Gi——调度器基于Request分配节点，能最大化节点Pod密度；Limit则限制任务的内存上限，避免单个常规任务占用过多资源。
• 针对少数高内存任务：单独配置resources.requests.memory: 6Gi，resources.limits.memory: 10Gi（根据实际峰值内存调整），确保这类任务被调度到有足够空闲资源的节点。

2. 节点级内存预留 #

• 通过kubelet配置实现两种层面的内存预留：
  • 系统预留：用systemReserved参数预留10GB内存给节点操作系统和kube-system组件，避免业务Pod耗尽节点基础资源。配置示例：

    systemReserved:
      memory: 10Gi
    

  • 驱逐阈值：用evictionHard设置内存触发驱逐的阈值，当节点可用内存低于10GB时，kubelet会主动驱逐低优先级Pod，防止节点崩溃。配置示例：

    evictionHard:
      memory.available: 10Gi
    

3. 配置Pod优先级与抢占 #

• 给高内存任务设置更高的priorityClassName，当节点资源不足时，K8s调度器会自动抢占低优先级的非关键Pod资源，保证高内存任务能正常启动，同时避免节点因过载崩溃。

总结 #

优先推荐差异化Request/Limit配置+节点内存预留的方案：无需依赖Swap，资源利用率和稳定性更可控，能直接支持2-3倍的任务并行扩展；Swap方案仅作为兜底选项，适合对任务存活优先级高于执行速度的场景。

内容的提问来源于stack exchange，提问作者markfickett