Kata Containers 4.0はOCI UXのままVM境界を使う
Kata Containersは、container orchestrationのUXを保ちながら、workloadを軽量VMの中で動かすsandbox runtimeである。
通常のLinux containerではsandboxed processとhostが同じkernelを共有する。一方Kataではguest kernelを持つVMが隔離境界になる。Kubernetesやcontainerdなどから見るとcontainerに近い操作体系を維持しながら、host kernelを直接共有しない構成を取れる。
2026年7月22日にKata Containers 4.0.0が公開され、Rustベースの runtime-rs がdefault runtimeになった。従来のGo runtimeはdeprecatedとなり、4.0ではRust-first architectureへの移行が大きな変更点になっている。
runtime-rs が対応する主なVMMとして、公式の4.0 overviewでは次が挙げられている。
- QEMU
- Cloud Hypervisor
- Dragonball
Dragonballはruntime-rsに組み込まれるdefault built-in VMMとして位置付けられている。
Kataの利点は、gVisorはユーザー空間カーネルでhost kernel syscall面を減らす のようなuserspace Linux互換層ではなく、実際のguest Linux kernelを使えることにある。Linux kernel機能へのcompatibilityを保ちながら、通常containerより強いkernel境界を作りやすい。
その代わり、VMを起動・管理するためのmemory overheadや起動コスト、virtualization support、device/filesystem sharingの設計が必要になる。特にhostとguestをまたぐ共有filesystemやdevice passthroughは、VMを使えば自動的に安全になるわけではなく、別途security boundaryとして検討が必要である。
AI生成コード、CI、multi-tenantな任意コード実行のように、host kernel共有を避けたい一方でKubernetes/OCIの運用体系を維持したい場合に有力な選択肢になる。
より直接的にmicroVMを管理する方式は Firecracker snapshotは状態を持つsandbox再開に向く、全体の隔離層の違いは Linuxサンドボックスの隔離境界をどう捉えるか を参照。