K3s 节点内存压力大导致 eviction 但 free -h 看到大量 available

K3s中Pod被OOMKilled或驱逐的主因是kubelet依据cgroup内存统计和node allocatable判断压力，而非free -h显示的系统available内存；需通过cgroup指标、/proc/meminfo及kubectl describe nodes定位真实内存瓶颈。

这是 K3s 环境中非常典型的“内存看似充足，但 Pod 却被 OOMKilled 或触发 kubelet eviction”的现象。根本原因不是 free -h 显示的 available 值高就代表内核能随时分配内存——kubernetes（包括 K3s）的驱逐逻辑依赖的是 cgroup 内存统计 + kubelet 的 node allocatable 计算，而非用户态看到的 free 内存。

为什么 free -h 的 available 很高，但 kubelet 还是触发 eviction？

K3s 默认使用 cgroup v2 + systemd 驱动，而 free -h 统计的是整个系统的 page cache、slab、buffers 等可回收内存总量，它不反映：

• cgroup 内存限制已逼近上限：Pod 所在的 cgroup（如 /kubepods.slice）可能已用尽其配额（即使系统整体还有空闲页），kubelet 通过 cgroup.memory.stat 中的 working_set 和 memory.usage_in_bytes 判断压力；
• kubelet 的 memory.available 阈值基于 node allocatable：它从 /proc/meminfo 中读取 MemAvailable，再减去 system-reserved + kube-reserved，这个值往往远小于 free -h 显示的 available；
• page cache 滞后回收：linux 不会立刻释放大量 page cache，而 kubelet 的 eviction manager 每 10s 检查一次，若此时 cgroup usage 已超限或 memory.available 低于阈值（默认 100Mi），就会触发 soft/hard eviction。

快速定位真实内存压力来源

别只看 free -h，执行以下命令：

• kubectl describe nodes → 查看 Conditions 是否有 MemoryPressure，以及 Allocatable 和 Capacity 的差异；
• cat /var/lib/rancher/k3s/agent/etc/containerd/config.toml | grep -A5 "systemd_cgroup" → 确认是否启用 cgroup v2；
• cat /sys/fs/cgroup/memory.max（cgroup v2）或 cat /sys/fs/cgroup/memory/kubepods/memory.limit_in_bytes（v1）→ 查看 kubepods cgroup 实际内存上限；
• cat /sys/fs/cgroup/memory/kubepods/memory.current → 当前已用内存（单位 bytes），对比上面的 max；
• grep -i "memavailable|memfree" /proc/meminfo → 获取 kubelet 实际参考的 MemAvailable 值。

关键配置与调优建议

K3s 默认未显式设置资源预留，容易导致 kubelet 误判。需手动干预：

• 为 kubelet 设置合理的 memory-reserved：启动 K3s 时加参数 --kubelet-arg="system-reserved=memory=512Mi" --kubelet-arg="kube-reserved=memory=512Mi"，避免 kubelet 把系统进程和自身内存算进可分配池；
• 降低 eviction-hard 阈值（谨慎）：例如 --kubelet-arg="eviction-hard=memory.available，让驱逐更早发生，避免突发 OOM；
• 检查容器是否未设 memory limits：无 limit 的 Pod 可无限增长，抢占所有 cgroup 配额。用 kubectl get pods --all-Namespaces -o wide --sort-by=.status.phase | grep -v Running 找出异常终止的 Pod，并检查其 spec.resources.limits；
• 禁用 swap（K3s 要求）：确保 swapoff -a 且 /etc/fstab 中注释 swap 行，否则 kubelet 无法准确评估内存压力。

验证与监控建议

重启 K3s 后，持续观察：

• kubectl top nodes 和 kubectl top pods -A → 看实际 RSS 使用趋势；
• sudo crictl stats --no-trunc → 查看每个容器的实时 cgroup memory usage；
• 部署 metrics-server（K3s 默认不带，需手动安装）以支持 HPA 和更准的资源视图；
• 用 node_exporter + prometheus 监控 node_memory_MemAvailable_bytes 和 container_memory_working_set_bytes{container!="",namespace=~"default|kube-system"}。

问题本质是“可用内存”在不同层级有不同定义。K3s 的轻量不等于配置可省略——尤其在资源受限节点上，必须显式预留、设限、监控 cgroup 视角的真实用量。