Kubernetes中ZooKeeper Pod频繁被驱逐：内存占用低却触发内存回收报错

以下是针对该问题的具体排查方向和操作步骤：

1. 验证节点层面内存实际使用与可分配逻辑 #

• 查看节点内存分配详情：执行kubectl describe node <目标节点名称>，对比Capacity（节点总内存）和Allocatable（Kubernetes可分配给Pod的内存），确认系统预留内存是否过高，导致可分配内存远低于预期。
• 登录节点查看真实内存占用：通过ssh连接节点，执行free -h查看主机整体内存使用，同时用top或htop检查系统进程（如kubelet、containerd、系统守护进程）的内存消耗，确认是否是系统进程占用过多导致节点可用内存触达驱逐阈值。

2. 检查Kubelet驱逐阈值配置 #

• 查看kubelet驱逐参数：执行ps aux | grep kubelet，检查--eviction-hard或--eviction-soft参数的配置值，比如是否设置了memory.available<100Mi这类过于严格的阈值。也可以查看kubelet配置文件（通常路径为/var/lib/kubelet/config.yaml）中的evictionHard/evictionSoft字段。
• 确认kubelet感知的可用内存：在节点上执行cat /sys/fs/cgroup/memory/memory.available，这个值是kubelet判断节点内存是否充足的依据，和free命令的统计可能存在差异，需确认该值是否触达了驱逐阈值。

3. 排查ZooKeeper内存特性导致的统计偏差 #

• 检查直接内存占用：ZooKeeper会使用JVM直接内存（Direct Memory），这部分内存可能未被容器运行时正确统计到Pod的内存使用中。进入ZooKeeper Pod，执行jcmd <ZK进程ID> VM.native_memory（需Pod内安装JDK），查看直接内存的占用情况，确认是否存在超出预期的内存消耗。
• 核对Pod内存限制配置：确认Pod的resources.limits.memory是否设置合理，即使日常占用低，ZooKeeper在生成快照、处理大请求时可能出现短暂内存峰值，若限制设置过低可能触发驱逐（结合你的描述，这条作为补充排查项）。

4. 排查容器运行时内存统计问题 #

• 对比内存统计数据：执行kubectl top pod <ZK-Pod名称>获取Kubernetes统计的Pod内存，同时进入Pod执行free -h或jstat -gc <ZK进程ID>查看JVM内存使用，确认两者数据是否一致。若存在明显偏差，可能是容器运行时（Docker/containerd）的统计bug，可尝试重启容器运行时或升级到稳定版本。

5. 检查节点内存碎片化问题 #

• 查看内存碎片情况：在节点上执行cat /proc/buddyinfo，检查不同阶的内存块数量，若高阶内存块（大内存块）数量极少，说明存在严重内存碎片化。此时即使节点整体可用内存充足，也可能因无法分配连续内存块导致OOM，进而触发Pod驱逐。可尝试重启节点缓解碎片问题，或调整内核参数优化内存分配。

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