Cloud Parts

Kata Containers

A container runtime that starts each pod inside its own lightweight VM, so Kubernetes and Docker keep working but every pod gets its own kernel.

What it is
MicroVMs
Used for
Containers
Type
Open source
Made by
OpenInfra Foundation (part of the Linux Foundation since July 2025)
License
Apache 2.0
Facts checked
6 October 2026
Website Source code

What it is

Kata Containers looks like an ordinary container runtime from the outside and runs a virtual machine on the inside. When containerd or CRI-O asks it to start a pod, Kata boots a small VM with its own Linux kernel, and an agent inside the VM (kata-agent) creates the pod’s containers there. All containers of one pod share that VM, so the hardware boundary sits between pods rather than between a container and its host. Kata implements containerd’s shim v2 API: one containerd-shim-kata-v2 process per pod talks to the container manager over a socket, instead of the separate shim and proxy processes the 1.x design needed. In Kubernetes you register it as a RuntimeClass and set runtimeClassName: kata on the pods that should be isolated; everything else keeps the default runtime.

Kata doesn’t include one hypervisor; it drives several. QEMU is the best supported, and the one to use for NVIDIA GPUs and confidential computing (Intel TDX, AMD SEV-SNP). Cloud Hypervisor and Firecracker are smaller Rust monitors, and Dragonball, written by Ant Group, is built into the Rust shim process itself. Version 4.0 (July 2026) made that Rust runtime (runtime-rs) the default and deprecated the original Go runtime. Microsoft’s AKS Pod Sandboxing and Google’s GKE Sandbox microVMs both run Kata with Cloud Hypervisor. The project began in December 2017 as a merger of Intel Clear Containers and Hyper’s runV, under what is now the OpenInfra Foundation.

Why teams pick it

  • A separate guest kernel per pod, while images, kubectl and container tooling stay the same
  • Pick the hypervisor per runtime class: QEMU for GPUs and confidential computing, Cloud Hypervisor, Firecracker or the built-in Dragonball for a small footprint
  • Privileged containers become safer: on GKE they get root only inside the pod’s VM, not on the node
  • Offered as a managed option by AKS (Pod Sandboxing) and GKE (Sandbox microVMs)

Watch out for

  • Needs KVM: bare metal, or cloud VMs with nested virtualisation (GKE microVMs run only on node types that support it)
  • A fixed cost per pod: GKE documents 250 mCPU and 130 MiB of overhead and about one to two seconds to start, against under 200 ms for gVisor
  • Some container features don’t cross the VM boundary: no host networking, no Kubernetes subPath volume mounts, and Kata’s docs list Podman as unsupported
  • Each hypervisor has its own gaps: GPUs and TDX/SEV-SNP only with QEMU, and Firecracker needs a block-device storage driver (containerd’s devmapper snapshotter)

Alternatives

What all microvms have in common →
FirecrackerOpen sourceThe open-source microVM monitor AWS built for Lambda: a full VM boundary that boots in under 125 ms.smolvmOpen sourceA young, embeddable microVM runtime that boots any OCI image as a real VM on a Mac, Linux or Windows laptop, and can save, branch and pack running machines.

How it fits with other technologies

Register Kata as a RuntimeClass and opt one pod in · yaml

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata          # the runtime name in containerd's config
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx-kata
spec:
  runtimeClassName: kata   # this pod gets its own VM and kernel
  containers:
    - name: nginx
      image: nginx

See it in a real stack

No architecture uses Kata Containers yet. Drop it into the playground and wire it up yourself.Open playground →

Compared side by side

Kata Containers, gVisor or Firecracker?
Where it came from2017–2026

By 2017 two projects were running containers inside small virtual machines to get a hardware boundary without giving up container workflows: Intel’s Clear Containers and Hyper’s runV. JD.com already sold a container service built on runV. On December 5, 2017 the OpenStack Foundation announced Kata Containers, which combined the two code bases under open governance. Intel contributed Clear Containers, Hyper contributed runV, and companies including Google, Huawei, Red Hat, Canonical and SUSE backed the launch. The name is meant to suggest a Greek word for “trust something to someone”.

The first design had six parts: an agent, a runtime, a proxy, a shim, a guest kernel and a QEMU 2.9 package. Version 1.0 shipped in May 2018, and 1.5 (January 2019) added Firecracker as a hypervisor and a new way to integrate with containerd. Kata 2.0 (October 2020) rewrote the in-VM agent in Rust and kept only the containerd shim v2 interface, dropping the per-container shim and proxy processes.

Kata 3.0 (October 2022) added a runtime written in Rust with an optional built-in VMM, Dragonball. In 2025 the foundation behind Kata, by then called the Open Infrastructure Foundation, became part of the Linux Foundation. Kata 4.0 (July 2026) made the Rust runtime the default and deprecated the Go one.

Why it’s built this way

One VM per pod, not per container
Containers in a Kubernetes pod already share network and storage, so the pod is the natural unit to wall off. Kata represents a pod as a VM and runs its containers inside it.
Speak the existing container interfaces
From the start Kata targeted the OCI runtime spec and Kubernetes’ CRI, so containerd, CRI-O and Docker could use it without new tooling. Users switch per pod with a RuntimeClass instead of adopting a new platform.
Hypervisor-agnostic
No single monitor fits every workload: QEMU emulates the devices GPUs and confidential computing need, while Firecracker and Cloud Hypervisor trade features for size. Kata configures each runtime class for one hypervisor and lets operators choose.
A single shim v2 process per pod
The 1.x design called the runtime binary repeatedly and needed a shim per container plus a proxy, which was slow and made it hard to track state. With containerd’s shim v2 API one long-lived process serves the whole pod over a gRPC socket.

Timeline

  1. 2017

    Announced December 5, merging Intel Clear Containers and Hyper runV

  2. 2018

    Kata Containers 1.0 released in May

  3. 2019

    1.5 adds Firecracker as a hypervisor

  4. 2020

    2.0: Rust agent, shim v2 only, virtio-fs by default

  5. 2022

    3.0 adds a Rust runtime and the built-in Dragonball VMM

  6. 2025

    The OpenInfra Foundation joins the Linux Foundation

  7. 2026

    4.0 makes the Rust runtime the default

Sources13 · facts checked 6 October 2026

Improve this page on GitHub