Kubernetes 節點 swap 實測：gVisor 沙箱 pod 密度最高提升 3 倍
Kubernetes Blog · 2026-10-05
Kubernetes 不再把 swap 當成要關掉的東西：搭配 NVMe 本機 SSD，節點可以把閒置的記憶體換出去，同一台機器塞進更多 pod。這個功能在 v1.34 已進入 GA，Kubernetes 官方部落格在 2026-10-05 公布了三組 benchmark，最高密度提升 3 倍。
作者是 Ocean Xie 與 Yuan Wang，測試涵蓋 Linux 核心編譯、無頭瀏覽器沙箱與 Python 沙箱，並附上 KubeletConfiguration 的設定範例。
原本的問題
Kubernetes 長期不鼓勵開 swap，文章列出兩個原因。第一是記憶體計量：cgroup v1 把記憶體與 swap 當成單一合併上限，容器可以把大量匿名記憶體換到磁碟，真實用量因此難以預測與隔離。第二是延遲：換到旋轉式硬碟太慢。
現在的 swap 支援改用 cgroup v2，swap 有獨立計量；NVMe 本機 SSD 則大幅降低換頁延遲。另一方面，agent 工作負載讓問題更明顯：沙箱 pod 啟動與執行不受信任的程式碼時需要大量記憶體，之後卻長時間閒置等下一個 prompt，這些閒置但常駐的記憶體限制了每個節點能放的 pod 數。
三組測試結果
| 工作負載 | 無 swap | 本機 SSD swap | 變化 |
|---|---|---|---|
| Linux 核心編譯 | 記憶體上限 600 MB | 300 MB | 記憶體用量 -50% |
| Headless Chrome（Kata） | 40 個 pod | 50 個 pod | +25% |
| Headless Chrome（gVisor） | 80 個 pod | 160 個 pod | +100% |
| Python 沙箱（gVisor） | 80 個 pod | 240 個 pod | +200%（3 倍） |
核心編譯用的是 Linux 6.1.1。不開 swap 時，要避免 OOM，記憶體上限最低是 600 MB；開 swap 後降到 300 MB，編譯反而是 374 秒，基準為 433 秒。但再壓到 200 MB，活躍的工作集被迫進入 swap，執行時間增加超過 40%。文章的結論是：swap 是應付突發記憶體的保險，不是活躍記憶體的替代品。
無頭瀏覽器在 c4-standard-32 節點（32 vCPU、120 GB RAM）上測試。不加安全沙箱的 runc 容器，不開 swap 時在超過 512 個 pod 後失敗，開了 swap 可以到 768 個。gVisor 與 Kata 這類強隔離 runtime 本來記憶體開銷較大，swap 剛好吸收這部分：gVisor 從 80 個變成 160 個，Kata 從 40 個變成 50 個（之後受 CPU 飽和限制）。
Python 沙箱同時執行對 MovieLens 20M 資料集 500 萬列資料的分析，每個 session 常駐約 375 MiB。不開 swap 時節點在 80 個並行 session 就撞到記憶體上限，開了之後可到 240 個。文章也指出，換出閒置匿名記憶體還保住了 page cache。
延遲與設定方式
在最高密度下，每個 pod 的延遲上升主要來自 pod 之間搶 CPU，而不是 swap 的 I/O。若有明確的延遲目標，就應該跑在比峰值更低的密度，延遲代價也會等比例變小。
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
failSwapOn: false
memorySwap:
swapBehavior: LimitedSwap文章同時要求工作負載使用 Burstable QoS：容器的 memory limit 設得比 request 高，節點才會依閒置記憶體比例分配 swap 空間。GKE 已透過本機 SSD profile 上的 Node Memory Swap 原生支援這個做法。
影響範圍
- 跑 agent 沙箱的平台團隊：gVisor、Kata 這類強隔離 runtime 的密度上限常由記憶體決定，這是最直接的受益對象。
- CI/CD runner 維運者：核心編譯的結果顯示記憶體上限可以減半，但要實際量測自己的 job，找出會讓工作集進入 swap 的臨界點。
- 叢集管理員：需確認節點用 cgroup v2、有 NVMe 本機磁碟，再檢查 pod 是否為 Burstable QoS。
這些數字全部來自作者自己的測試環境（GCP 的 c4-standard-32 與本機 SSD），文章未說明在其他雲或自建硬體上的結果，採用前建議用自己的 workload 重跑一次。
原始來源：Kubernetes Blog：Scaling Kubernetes Workloads with Node Swap