Kata Containers 在 2026 年 7 月 22 日釋出 4.0 版本，把預設 runtime 從 Go 寫的 runtime-go 換成 Rust 寫的 runtime-rs，同時把 Ant Group 貢獻的 Dragonball 定為預設 in-process VMM。看起來像一次「把 runtime 換個語言」的版本升級，實際上是把 microVM 這條路徑從 Kubernetes 多租戶隔離的傳統定位，明確擴充到 AI Agent 沙箱這個 2026 年才長出來的場景。理由很直接：跑在共用 kernel 上的 container 對付不了行為不可預期的程式碼，而 AI Agent 就是不可預期的程式碼。
Kata Containers 本來就是給每個 pod 分配一台輕量 VM 的執行時，但過去主要客群是 CSP（Cloud Service Provider）的多租戶 Kubernetes，跟一般開發者的距離不小。4.0 之後 runtime 記憶體占用往下砍、Dragonball 讓 microVM 冷啟動壓進次秒等級，加上 OpenAI 的 Realtime API、Claude Code、各種 coding agent 都在找「怎麼安全地讓 AI 執行 shell 指令」，Kata 這條技術棧突然在 VPS 尺度也變得有意義。
Container 只是一堆共用 kernel 的 process
Container 的隔離是拿 Linux 的 namespace 跟 cgroup 拼出來的：把 process 看到的檔案系統、網路、PID、user、mount 這幾個維度各自關進一個 namespace 裡，看起來像獨立系統，但底下的 kernel 是同一個。這件事平常沒差，但只要 kernel 出現 CVE，任何一個 container 都可能從 namespace 逃出去。這一年 Docker 的 AF_ALG copy_fail、futex PI use-after-free 已經連續兩次示範了 container escape 不是理論——kernel 面積夠大，攻擊面就永遠關不完。
AI Agent 讓這個問題變本加厲的地方在於「行為不可預測」。傳統 microservice 的 syscall pattern 是固定的：Web server 就那幾支 socket、accept、read、write；資料庫寫入路徑跑久了大家都認得。AI Agent 不一樣——它拿到 shell 就會亂試，會執行使用者根本沒想到的指令，會踩到工程師以為沒人會踩的 syscall。NVIDIA 的容器工程師 Zvonko Kaiser 在 Kata 4.0 的公告裡直接把這件事講白：agents are nondeterministic, a fancy word for unpredictable。
不可預測的 workload 對隔離的要求本質上跟多租戶 SaaS 一樣：不能假設對方會遵守你設計的 syscall 白名單，要用比 namespace 更硬的邊界去圈住它。KVM 提供的虛擬機邊界是 CPU 直接支援的硬體隔離，攻擊者要從 microVM 逃出去必須先打穿 hypervisor，這個攻擊面比 Linux kernel 小兩個數量級。這就是為什麼 2026 年開始，凡是要接不可信任程式碼的產品——不管是 AI Agent、雲端 IDE、還是無伺服器函數——幾乎都轉向 microVM 路徑。
runtime-rs 為什麼要把 Go 版整個換掉
Kata 的架構分兩層：跟 containerd 講話的 shim（叫做 runtime）、以及在 host 上真正把 microVM 拉起來的 VMM。3.x 版本的 shim 是 Go 寫的，這個選擇在 2018 年很合理——Kubernetes 生態幾乎全是 Go、跟 containerd 的整合成本最低。但 shim 這個角色隨著 pod 數量線性擴充，一台節點上跑一百個 pod 就要開一百個 shim process，Go runtime 每個 process 至少吃十幾 MB 記憶體、GC 停頓在延遲敏感的 pod 生命週期事件上是可測到的雜訊。
runtime-rs 是從頭用 Rust 寫的，這次改寫的目標很具體：把 shim 的記憶體占用往下砍到高密度部署也不心疼，把冷啟動時間拉近 microVM 本身能達到的下限，順便把 sandbox 資源會計做得更準確——runtime 自己吃的 CPU 跟記憶體也算進 pod 的 quota 裡，讓 Kubernetes 的排程判斷不會被 runtime overhead 誤導。
Rust 換過去還有一個沒被大聲講的動機：kata-shim 的漏洞就是 kata-shim 的漏洞，用 Rust 寫可以把整類 memory safety bug 從攻擊面上直接刪掉。當這個 shim 是「所有 microVM 對外的唯一控制平面」的時候，把它從 Go 換成 Rust 的安全紅利，比多數應用層改寫 Rust 都來得明確。
runtime-go 進入 deprecated 狀態，官方時間表講到 5.0 之前不會拿掉——保守估計 5.0 落在 2028 Q1。中間有一段共存期是給既有生產環境慢慢遷移用的，但新專案沒理由再從 Go runtime 起跑。
Dragonball 這隻 in-process VMM 換掉了什麼
Kata 2.x 時代的做法是 shim fork 出一支獨立的 VMM process，兩邊靠 RPC 講話。這條路徑上 shim 跟 VMM 之間每個訊息都要跨 process、跨記憶體複製、跨 context switch。Dragonball 把整件事塞進同一個 process：Rust 寫的 VMM 以 library 形式被 runtime-rs 引進去，直接操作 KVM 的 ioctl，不再有 RPC 這個中間人。
這個改動最有感的效益是冷啟動。傳統 QEMU 加上外部 VMM process 的架構，microVM 從無到能執行 container entrypoint 大概要接近一秒；Dragonball 把 fork/RPC 這段拿掉之後，同樣的路徑通常縮到幾百毫秒等級，跟 Firecracker 的 100-200 ms 冷啟動只差在腳趾頭。對於「使用者按下 Run 才啟動 sandbox」這種 AI Agent 常見的互動模式，這一秒跟兩百毫秒的差別是體感的差別。
Dragonball 還做了一件事叫 inline virtio-fs：把傳統上獨立跑的 virtiofsd process 塞進 VMM 的位址空間，host 跟 guest 之間的檔案共享不用經過 FUSE、不用跨 process 傳資料。對於 AI Agent 常常要在 host 跟 sandbox 之間搬檔案的場景，這個改動把 I/O 延遲跟記憶體複製都往下切了一刀。
要提醒的是 Dragonball 不是萬能取代品——它只支援 Linux guest、功能集比 QEMU 精簡很多、GPU passthrough 目前還是要走 QEMU。所以 Kata 4.0 的策略是「Dragonball 當預設，需要完整硬體支援時切回 QEMU」，兩條路徑並存。
Kata、gVisor、Firecracker 該用哪個
這三個東西經常被放在一起比較，但實際上解決的問題層級不同。
gVisor 是 Google 的 Sentry，做法是攔截 container 的 syscall，然後在 userspace 用 Go 重新實作一套精簡的 Linux ABI。優點是不需要 KVM，可以在沒有虛擬化能力的環境跑；缺點是 I/O 重的 workload 有 10% 到 30% 的效能損失，因為每個 syscall 都要跨 userspace 邊界。實務上 gVisor 適合「需要多一層防護但不能開 nested virt」的情境，例如某些託管 K8s 環境或 CI runner。對 AI Agent 沙箱來說，如果 agent 會執行大量檔案 I/O（讀資料集、寫產出），gVisor 的 overhead 會很明顯。
Firecracker 是 AWS 為 Lambda 寫的 microVM 監控器，特色是啟動快、功能極簡、單獨這一支不做 orchestration。要在生產環境用 Firecracker 就要自己寫 shim、自己管網路、自己接 Kubernetes——AWS 自己是拿它撐起 Fargate 跟 Lambda，這條路徑對一般團隊來說 assembly cost 很高。所以 Firecracker 幾乎只出現在兩種場景：內部平台團隊拿它從頭蓋 serverless、或是被 Kata 當成 VMM 選項之一使用。
Kata Containers 是把上面兩層整合起來：shim 那層做完整的 CRI 整合，讓 Kubernetes、Docker、nerdctl 直接跑；VMM 那層可以選 Dragonball（預設）、Cloud Hypervisor、QEMU、或 Firecracker。想要「container 開發體驗、microVM 的隔離強度」的團隊，Kata 是唯一預設可用的方案。
一個簡單的選擇建議：需要跨進 Kubernetes 生態、需要 GPU、需要成熟的多租戶部署，選 Kata 4.0 走 Dragonball 或 QEMU；只要一個極簡的 microVM 而且願意自己搭 orchestration，選 Firecracker；nested virt 開不了或者只想加一層 syscall 過濾，選 gVisor 當備案。三者不互斥，某些平台會混著用。
在 VPS 上真的跑起 Kata 4.0 要注意的事
Kata 依賴 KVM，這代表 VPS 必須支援 nested virtualization。臺灣的 VPS 供應商在這件事情上差距很大：Intel VT-x 硬體虛擬化本身多數方案都有，但真正把 kvm_intel.nested=1 打開、允許客戶在 VM 裡再開 KVM 的方案就少了。基於 KVM 的 VPS 通常可以開；基於 OpenVZ 或 LXC 的方案就完全沒戲。要跑 Kata 前先確認 /dev/kvm 存在而且 kvm-ok 給出綠燈。
CPU 世代影響冷啟動時間。Kata 拉一個 microVM 起來需要載入 mini rootfs、啟動 kernel、初始化 virtio 裝置，這條路徑對 CPU 單核效能敏感。Intel Gold 級別的 CPU 跑 Dragonball 冷啟動壓在 300 ms 左右不困難，用比較舊的 E5 v4 或 Bronze 世代常常會拉到 800 ms 以上。要拿 Kata 撐互動式 AI Agent 的 VPS，最好挑近三代的 Intel 或 AMD EPYC 世代的方案。
記憶體方面，Kata 4.0 的 shim 記憶體足跡在 20-30 MB 左右，比 Go 版少一半；每個 microVM 本身另外吃 guest kernel 跟 initramfs 大概 128 MB。要在 4 GB RAM 的 VPS 上跑十幾個 agent sandbox 是可行的，但要留意 memory ballooning 的設定——沒調好會讓 host 跟 guest 互相搶記憶體。
儲存路徑建議走 virtio-fs 而不是 9p，Kata 4.0 在 Dragonball 上的 inline virtio-fs 已經穩定，效能明顯好過 9p，尤其是密集小檔 I/O。網路那邊如果 VPS 只給 macvlan，需要在 Kata config 裡明確指定 internetworking_model=macvtap 之類的模式，預設的 tcfilter 在某些 bridge 網路下會撞到 host 的 iptables 規則。
從 runtime-go 遷到 runtime-rs 的實務步驟
現行 runtime-go 的部署遷移路徑不需要換 hypervisor、不需要重建 image。多數情況下把 /etc/containerd/config.toml 裡 Kata 的 runtime binary 指向 containerd-shim-kata-v2（4.0 起這支預設是 Rust 版）、把 kata configuration 檔換成 configuration-dragonball.toml，重啟 containerd 就完成切換。既有的 Kata pod annotation 例如 io.katacontainers.config.hypervisor.default_memory 全部沿用，語意沒變。
有幾個 corner case 值得先跑驗證：一是 host-guest 之間用 volume mount 大量小檔的 workload，virtio-fs 跟舊版行為有微差；二是 Kata 3.x 上自訂 hypervisor annotation 走 Firecracker 的部署，這批要確認 4.0 的 runtime-rs 對應設定沒有漏欄位；三是把 Kata 當 Kubernetes RuntimeClass 用的環境，需要重新確認 pod scheduling 的資源會計——runtime overhead 現在會被算進 pod 的 limit，之前擠得剛好的 pod 會被排到別的節點。
真正要小心的是 Firecracker 走 Kata 的部署：Kata 4.0 對 Firecracker 支援的優先度明顯降在 Dragonball 之後，某些 4.0 的新功能 Firecracker 路徑要慢一兩個 minor 版本才會補上。想要繼續走 Firecracker 的可以留在 3.x 一陣子等生態穩定，或者直接評估切到 Dragonball。
結論：AI Agent 沙箱這條路徑跟自架服務終於接上了
Kata Containers 4.0 的技術意義不只是「Rust 改寫成功」——它把 microVM 隔離的成本壓到 VPS 尺度的團隊也能負擔，讓「給每個不可信任的 workload 一個獨立 kernel」從超大規模平台的 exotic 選項，變成一般開發者部署 AI Agent、遠端 code interpreter、多租戶 sandbox 時的合理起點。共用 kernel 的 container 在 AI Agent 場景下已經是明顯不夠強的隔離，而 Kata 4.0 補上了那個缺口。
要在臺灣機房跑起 Kata 4.0，關鍵是 VPS 本身要支援 nested virtualization、CPU 世代夠新讓冷啟動可用、頻寬跟儲存能吃得住 microVM 的 I/O 模式。NCSE Network 的 VPS 產品線都基於 Intel Gold 世代 CPU 加 NVMe SSD、機房位於臺灣是方電訊，KVM 巢狀虛擬化預設開啟，適合把 Kata Containers 4.0、AI Agent sandbox、以及自架 microVM 相關的實驗跑在上面。想在正式環境評估這條技術棧的團隊，可以到 NCSE Network 看看目前的 VPS 方案。
