Cloud Parts

Kata Containers, gVisor or Firecracker?

DimensionKata ContainersgVisorFirecracker
In one lineContainers that each get their own small VMContainers that talk to a user-space kernel instead of the host’sA tiny VM monitor that other platforms build sandboxes on
What it isAn OCI runtime that boots a VM per pod, using QEMU, Cloud Hypervisor, Firecracker or the built-in DragonballAn application kernel written in Go (the Sentry) plus runsc, an OCI runtimeA virtual machine monitor in Rust: one process runs one microVM, configured through a REST API
Isolation boundaryHardware virtualisation: a separate guest kernel for each podSoftware: the Sentry serves system calls itself and runs under a seccomp filter; no hardware boundaryHardware virtualisation: a separate guest kernel per microVM, with the jailer sandboxing the monitor process
Where it plugs incontainerd or CRI-O as the shim v2 runtime containerd-shim-kata-v2; Docker with --runtime io.containerd.kata.v2Docker with --runtime=runsc; containerd through containerd-shim-runsc-v1; CRI-OYour own code, over the API socket; containers only through Kata or firecracker-containerd
KubernetesYes, as a RuntimeClass; managed in AKS Pod Sandboxing and GKE Sandbox microVMsYes, as a RuntimeClass named gvisor; managed in GKE Sandbox, on by default in AutopilotNot by itself: only underneath Kata or another runtime
Host requirementsLinux with KVM: bare metal, or VMs with nested virtualisationAny Linux host, including cloud VMs without nested virtualisation; the KVM platform is faster on bare metalLinux with KVM; on EC2 that means .metal instances
Start-up and overheadOn GKE (with Cloud Hypervisor): about 1 to 2 s to start and a fixed 250 mCPU and 130 MiB per podOn GKE: under 200 ms to start and memory that grows with the app, but every system call costs more than on LinuxUnder 125 ms to boot and under 5 MiB of overhead; up to 150 microVMs per second on one host
CompatibilityA real Linux kernel inside, so almost anything runs; gaps are at the VM edge, such as no host networking or subPath mounts290 of 352 amd64 system calls and not every /proc or /sys file; no privileged containers on GKELinux guests (and OSv) with a handful of virtio devices; you supply the kernel and root filesystem
GPUsYes, with QEMU, which also supports confidential computing (Intel TDX, AMD SEV-SNP)Some NVIDIA GPUs through nvproxy; specific GPUs and TPUs on GKENo: device passthrough (VFIO) is still an open feature request
Who runs it in productionAzure (AKS Pod Sandboxing), Google (GKE Sandbox microVMs), BaiduGoogle (GKE Sandbox, Cloud Run first generation, App Engine), Ant Group, OpenAI, Anthropic, CloudflareAWS Lambda, Fly.io Machines, E2B sandboxes

Rule of thumb

These aren’t three rival products. Firecracker is a building block, and Kata can use it as its hypervisor, so “Kata or Firecracker” is often “Kata with Firecracker”. The real choice is the boundary: a VM with its own kernel (Kata on any hypervisor, or Firecracker under a platform you build yourself) or gVisor’s user-space kernel. Pick gVisor when your nodes have no KVM, or when start-up time and density matter and your software fits its system-call coverage. Pick Kata when you need a full Linux kernel, privileged containers or GPUs, and can run on bare metal or nested virtualisation. Use Firecracker directly only if you’re building your own sandbox or functions platform and are ready to supply the kernel, root filesystem, networking and scheduler.

Sources