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 视角的真实用量。
