AWS环境下K8s Pod内存使用远超配置limit值原因咨询

默认你描述的内存单位为GiB，该现象常见成因如下：

• kubelet内存限制强制配置未生效
  K8s对Pod的内存Limit限制是通过Linux CGroup的memory子系统实现的，如果AWS环境下的K8s节点（含EKS托管节点）kubelet启动参数中--cgroups-per-qos设为false，或是--enforce-node-allocatable参数未包含pods枚举值，就会导致Pod对应的CGroup内存阈值不会实际生效，只要节点剩余内存充足，Pod就可以占用超过Limit的内存正常运行。
• 内存统计维度和OOM判定维度不一致
  你观测到的7.5GiB内存值大概率包含了page cache、磁盘缓存、tmpfs临时文件占用的可回收内存，而K8s判定Pod是否触发OOM Kill的核心指标是container_memory_working_set_bytes（工作集内存，会扣除所有可回收的缓存类内存）。如果你的Pod超量占用的内存多为可回收缓存，工作集实际未达到3.5GiB的Limit阈值，就不会被系统终止。

常见观测误区：在容器内部执行top、free命令统计的内存值会包含缓存，和K8s的OOM判定指标不一致，很容易出现看起来超了Limit但实际未触发驱逐的情况。

• AWS托管集群的特性或版本问题
  1. 如果你使用的是AWS EKS服务，部分旧版本的EKS优化AMI存在CGroup配置兼容性bug，尤其是使用CGroup v1的旧节点，会出现内存Limit不强制生效的问题；
  2. 如果Pod运行在AWS Fargate Serverless环境下，Fargate的资源计量逻辑和普通EC2节点不同，只要Pod实际占用内存没有超出Fargate为Pod分配的底层实例规格总内存，就不会触发终止，用户配置的Limit不会被严格强制执行。
• 节点无内存压力时Burstable QoS Pod不会被主动驱逐
  你的Pod配置memory request < limit，属于Burstable QoS等级，K8s只有在节点出现内存压力时才会按优先级驱逐超用资源的Burstable Pod，只要所在节点内存充足，哪怕Pod长期超过Limit运行，也不会被系统主动kill。

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