Kubernetes节点内存统计与系统内存使用存在差异，未耗尽内存却触发内存限制告警求助

嗨，太懂这种明明看系统内存还有大把余量，但Kubernetes却一个劲弹内存告警的糟心感了！咱们来好好捋捋这个问题~

先看看你给出的实际统计数据：
系统层面的free -h输出：

root@ftt:local-storage :) $ free -h
               total        used        free      shared  buff/cache   available
Mem:            46Gi        16Gi       2.4Gi       439Mi        28Gi        29Gi
Swap:             0B          0B          0B

Kubernetes层面的kubectl top node输出：

root@ftt:local-storage :) $ kubectl top node
NAME   CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
ftt    552m         13%    33815Mi         70%   

从数据能明显看出两边的统计差异，核心原因主要是Kubernetes和系统工具的内存统计逻辑完全不一样，咱们一个个拆解：

• 节点内存预留（Node Allocatable）是关键
  Kubernetes默认会给节点本身预留一部分内存，专门给kubelet、内核、系统进程这些“基础设施”用，这部分内存不会被调度给业务Pods。比如你的节点总内存是46Gi，假设预留了12Gi左右，那实际可分配给Pods的内存就只有34Gi上下——现在你的Pods已经用了33Gi，接近可分配上限的97%，这时候Kubernetes自然会触发内存告警，哪怕系统的available还有29Gi（这部分包含了可回收的缓存和预留的节点内存）。

• 统计维度的差异
  free里的used包含了系统缓存、缓冲区这些可以随时回收的内存，而kubectl top统计的是Pods实际占用的“工作集内存”（就是不能被换出、正在使用的内存），同时还会把K8s系统组件的内存开销算进去，这就导致两边的数字看起来差很多。

接下来给你几个具体的排查和解决步骤：

1. 查看节点的可分配内存
   运行kubectl describe node ftt，找到Allocatable区块，看看memory字段的值。如果这个值是34Gi左右，那当前Pods的33Gi使用率确实已经接近阈值，告警是合理的。
2. 检查系统级内存开销
   用top或者ps aux --sort=-%mem看看kubelet、containerd这些节点组件的内存占用，确认预留的内存是否足够。如果预留太少，可以调整kubelet的--eviction-hard或者--node-allocatable参数来调整预留值。
3. 验证metrics-server的准确性
   有时候metrics-server的统计会有延迟或者偏差，你可以在节点上用crictl stats查看容器的实际内存使用，和kubectl top pod的结果对比，看看是不是统计数据出了问题。如果是，重启metrics-server pod试试。
4. 排查内存异常的Pods
   用kubectl top pod --sort-by=memory找出内存占用最高的Pods，看看是不是有应用内存泄漏，或者配置的内存限制不合理。如果是个别Pods占用过高，调整它们的内存请求和限制，或者优化应用本身。

备注：内容来源于stack exchange，提问作者xeruf