Kata Containers is an Open Infrastructure Foundation (OpenInfra Foundation) project that replaces the Linux namespace and cgroup isolation of a conventional container runtime with a full VM boundary, while remaining entirely compatible with the OCI runtime specification and the Kubernetes CRI. From the perspective of containerd, CRI-O, or the Kubernetes kubelet, a Kata pod is indistinguishable from a runc or crun pod — the same API calls, the same lifecycle verbs, the same pod spec — but instead of calling clone() to create a new namespace, Kata starts a lightweight virtual machine. The workload runs inside that VM with its own kernel, its own device model, and a hardware-enforced isolation boundary between itself and the host kernel. The premise is that Linux namespaces, while convenient, share the same kernel as the host: a kernel vulnerability exploitable from inside a container can affect the host and every other container running on the same node. A VM boundary means that even a full guest kernel compromise cannot directly affect the host.
The runtime component that sits between the CRI runtime (containerd or CRI-O) and the VM is the Kata shim (containerd-shim-kata-v2), which implements the containerd shimv2 API. When a pod is created, the shim instantiates a hypervisor — QEMU/KVM by default, with Cloud Hypervisor and Firecracker supported as lighter-weight alternatives — launches a minimal guest OS image, and starts the kata-agent inside the VM: a process that runs as pid 1 in the guest and implements a ttRPC API over a VSOCK socket. The Kata shim on the host side translates OCI container commands (create, start, exec, kill) into agent protocol messages sent over that socket, and elays stdio streams back to the CRI runtime. The guest filesystem is typically shared with the host via virtio-fs, a high-performance FUSE-over-virtio protocol that mounts the container’s rootfs and any volumes directly into the VM without copying. Network connectivity is provided by a TAP device on the host side connected to a virtio-net interface inside the guest; the pod’s network namespace is set up by the CNI plugin on the host before being passed into the VM. The result is a pod that has a private kernel, private devices, and an isolated network stack, while consuming typically 100–150 MB of memory overhead per pod and starting in under a second on modern hardware.
Kata Containers is the foundational runtime layer for CoCo (Confidential Containers). CoCo extends Kata by targeting TEE-capable hypervisors: instead of a conventional QEMU VM, the kata-agent runs inside a TDX Trust Domain or SEV-SNP confidential guest, giving the pod hardware-enforced memory encryption and attestability in addition to the VM isolation Kata already provides. The Attestation Agent and Confidential Data Hub that CoCo adds to the guest image run alongside the kata-agent, extending the standard Kata architecture with secret delivery and attestation capabilities. Peer Pods extends Kata in the other direction — replacing the local hypervisor call with a remote cloud API call via the Cloud API Adaptor, allowing Kata pods to run on cloud-provisioned CVMs even when the Kubernetes worker node is itself a VM. In both cases the core Kata architecture — shimv2 interface, kata-agent over VSOCK, virtio-fs rootfs — is preserved unchanged; CoCo and Peer Pods are specialisations of it, not replacements.