2026 年 10 月 5 日，Kubernetes 官方博客发表《Scaling Kubernetes Workloads with Node Swap》，由 Ocean Xie 与 Yuan Wang 撰写。文章指出，内存往往是集群最先触顶的硬限制，而新一波智能体类 AI 负载让问题更突出：这类负载启动时需要大内存来运行不受信任的代码，随后进入长时间空闲等待下一次提示。作者用三类负载做了基准测试，发现以高速 NVMe 本地 SSD 作为交换空间时，节点容器密度最高可提升 3 倍，且多数情况下延迟代价很小。本文从云原生基础设施视角解读。
节点密度困境
Kubernetes 生态已触及一个物理资源约束：硬件内存的严格上限，与智能体时代突发型负载不断增长的需求之间的矛盾。历史上，管理员为内存密集型负载配置资源时常面临两难：内存上限设得过高，昂贵的闲置内存被浪费；设得过低，又可能出现 OOM 终止。使用 agent-sandbox 这类安全执行环境运行自主 AI 负载时，这一矛盾被进一步放大——这类 Pod 需要大内存来初始化并执行不受信任代码，但在活动爆发后往往进入长尾空闲，把闲置内存留在物理内存里会限制节点密度并推高云成本。
swap 为何曾被劝退
Kubernetes 对启用 swap 的节点支持已在 v1.34 达到正式可用（GA）。过去不建议在 Kubernetes 中使用 swap 主要有两个原因：一是内存记账，cgroup v1 把内存与 swap 视为合并上限，无法为磁盘交换单独设限，进程可把大量匿名内存换出到磁盘，使容器真实内存用量难以预测与隔离；二是慢速机械盘的换页延迟。随着 cgroup v2 提供独立的 swap 记账，以及快速 NVMe 本地 SSD 基本消除延迟问题，提升 Pod 密度、缓冲内存尖峰变得可行。
三类负载的基准数据
官方基准覆盖三类负载。传统 CI/CD 的 Linux 6.1.1 内核构建：无 swap 时防止 OOM 的最低内存上限为 600 MB，把 swap 路由到本地 SSD 后上限降到 300 MB（内存占用减少 50%），且没有变慢——实际以 374 秒完成，反而快于基线的 433 秒；但把上限进一步压到 200 MB 会把活跃工作集挤入 swap，导致执行时间增加超过 40%，说明 swap 是突发内存的“保险”而非活跃内存的替代。
高密度浏览器沙箱：在 c4-standard-32 节点（32 vCPU、120 GB 内存）上，未使用安全运行时的 runc 容器在无 swap 时超过 512 个 Pod 即耗尽物理内存，启用本地 SSD swap 后支持到 768 个并发 Pod；gVisor 环境无 swap 时上限为 80 个 Pod，启用后翻倍到 160 个（密度 +100%）；Kata Containers 微虚拟机无 swap 时在 40 个并发时耗尽内存，启用后扩展到 50 个（密度 +25%）。
隔离的 Python 沙箱：并发会话处理 MovieLens 20M 数据集的 500 万行数据，每次执行约需 375 MiB 常驻内存；无 swap 时在 80 个并发会话处触顶，启用本地 SSD swap 后可扩展到 240 个（密度提升 3 倍）。官方指出，峰值密度下的每 Pod 延迟上升主要来自 Pod 争抢 CPU，而非 swap I/O。
如何启用
在 Kubernetes v1.34 及以上，节点 swap 已正式可用，通过 kubelet 配置启用：把 failSwapOn 设为 false，并把 memorySwap.swapBehavior 设为 LimitedSwap。配合云厂商的高速本地盘即可获得动态内存平衡；Google Kubernetes Engine 已通过 Local SSD 上的 Node Memory Swap 原生支持。官方建议为负载配置 Burstable QoS，把容器内存上限设得高于请求，节点会依据空闲应用内存自动配给高速交换空间，同时保持活跃进程的响应性。
小结
Kubernetes 官方于 2026 年 10 月 5 日发布节点 swap 基准，以 v1.34 GA、本地 SSD 支撑、CI/CD 构建内存占用减半、gVisor 与 Python 沙箱密度翻倍乃至 3 倍为看点，是云原生基础设施领域面向智能体负载、缓解内存瓶颈与降低云成本的一次实践参考。