--fail-swap-on=false 会放大oom风险，因其使kubelet忽略swap启用状态而继续运行，但内核oom killer仍工作，且cgroup无法准确统计swap内存，导致驱逐决策失准、page reclaim变慢、监控失真。
为什么 --fail-swap-on=false 在内存压力下会放大 OOM 风险
这个参数不是“禁用 swap”，而是让 kubelet 忽略系统启用了 swap 的事实，继续启动。但内核的 OOM killer 仍照常工作——只是它现在要面对一个更混乱的内存视图：容器内存用量被 cgroup v1/v2 统计，而 swap 页面却在全局 swap 区里游荡，cgroup 很难准确判断某个 pod 真实占用了多少可回收内存。
- 当物理内存耗尽时，内核可能先 swap 出部分匿名页（比如 Go 程序的堆），但这些页没绑定到具体 pod 的 memory cgroup，kubelet 就无法据此做驱逐决策
- swap 活动本身会显著拖慢 page reclaim 速度，导致 OOM killer 触发延迟变长，期间更多 pod 可能被卷入连锁崩溃
- 某些 runtime（如 containerd + runc）在 cgroup v1 下甚至不统计 swap 使用量，
kubectl top pods显示的内存完全失真
--fail-swap-on=false 和 cgroup 版本的关系很关键
cgroup v1 基本不支持 swap accounting，启用 --fail-swap-on=false 后，kubelet 会彻底放弃对 swap 内存的感知；cgroup v2 虽支持 memory.swap.max，但默认关闭，且需内核开启 swapaccount=1 参数（现代发行版大多已弃用该参数，改用 systemd.unified_cgroup_hierarchy=1）。
- 检查当前 cgroup 版本：
stat -fc %T /sys/fs/cgroup—— 输出cgroup2fs表示 v2 - 确认 swap accounting 是否生效：
cat /sys/fs/cgroup/memory.max（v1 下无此文件；v2 下若存在memory.swap.current才算可用） - 即使 v2 开启了 swap accounting，kubelet 也不会用它做驱逐依据——它只看
memory.usage_in_bytes，不看memory.swap.current
生产环境真要开 swap，得绕过 kubelet 的限制逻辑
硬设 --fail-swap-on=false 是最省事但最危险的做法。如果确实需要 swap（例如容忍短时突发、避免立即 OOM），应该让 swap 只服务于宿主机 OS 层，而非容器工作负载。
- 设置极低 swappiness：
sysctl vm.swappiness=1，让内核只在极端缺页时才 swap - 用
zram替代磁盘 swap：压缩内存页，避免 I/O 成为瓶颈，systemctl enable systemd-zram-generator（多数新版 systemd 支持） - 确保所有 pod 设置
resources.limits.memory，并开启--eviction-hard=memory.available，让 kubelet 在真正耗尽前就驱逐，别等 swap 拉胯
常见误判：以为关掉 --fail-swap-on 就等于“允许 swap”
这个 flag 只控制 kubelet 启动校验，和 swap 是否实际起作用毫无关系。swap 开不开，取决于 swapon -s 输出、/proc/swaps 内容，以及内核是否加载 swap 模块。
- 错误现象：
kubelet --fail-swap-on=false启动成功，但swapon -s为空 → 实际根本没 swap，flag 白配 - 更隐蔽的问题：swap 分区存在但被
noauto挂载选项屏蔽，或/etc/fstab中 swap 行被注释 → kubelet 不报错，swap 也压根没激活 - 验证方式永远是：
free -h看Swap:行，不是看 kubelet 日志有没有报错
swap 在 Kubernetes 里从来就不是“弹性缓冲”，而是故障放大器。只要 cgroup 对 swap 的可见性不完整，任何依赖它的资源决策都会失效。这点比参数开关本身重要得多。
