🖥️ Kata Containers — VM-Based Isolation

Kata Containers runs each Kubernetes Pod inside a lightweight virtual machine with its own dedicated Linux kernel. The hypervisor (QEMU, AWS Firecracker, or Cloud Hypervisor) provides hardware-enforced isolation. From the application's perspective it's a normal container; from the host's perspective it's a VM.

Kata Architecture

Kata vs gVisor — Key Differences

Installing Kata on a Node

# Using the Kata Containers installer (Ubuntu example)
bash -c "$(curl -fsSL https://raw.githubusercontent.com/kata-containers/kata-containers/main/utils/kata-manager.sh) install-packages"

# Add Kata handler to containerd config
cat >> /etc/containerd/config.toml <<EOF
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-qemu]
  runtime_type = "io.containerd.kata-qemu.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-fc]
  runtime_type = "io.containerd.kata-fc.v2"   # Firecracker variant
EOF
systemctl restart containerd

AWS Firecracker — Ultra-Fast MicroVMs

AWS Firecracker is the hypervisor powering AWS Lambda and Fargate. It boots a microVM in ~125ms with ~5MB memory overhead per VM (vs ~130MB for QEMU). Kata supports Firecracker as an alternative hypervisor, making it suitable for serverless-style workloads:

# RuntimeClass using Kata + Firecracker
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-fc
handler: kata-fc
overhead:
  podFixed:
    memory: "60Mi"
    cpu: "100m"

Choosing the Right Sandbox

🔍 Verifying Your Sandbox

After deploying a sandboxed pod, confirm it's using the expected runtime:

# Check which runtime a pod used
kubectl get pod sandboxed-workload -o jsonpath='{.spec.runtimeClassName}'
# → gvisor

# From inside the pod — confirm it sees gVisor's kernel
kubectl exec sandboxed-workload -- uname -r
# → 4.4.0  (gVisor reports a static kernel version)

# Kata: the guest kernel version differs from the host
kubectl exec kata-pod -- uname -r
# → 5.15.0-kata  (Kata guest kernel)

# On the node — see the shim processes
ps aux | grep -E 'runsc|kata-shim|containerd-shim-kata'

🔬 gVisor — User-Space Kernel

gVisor (open-sourced by Google, powers GKE Sandbox) implements a user-space kernel called runsc (run sandbox). Instead of container processes calling the host kernel directly, they call gVisor's Sentry — a Go process that intercepts syscalls and implements a large subset of the Linux kernel API in user space.

gVisor Architecture: Sentry + Gofer

• Sentry — the user-space kernel. Handles all system calls from the container. Runs in user space so a kernel exploit in Sentry can't directly compromise the host.
• Gofer — a file-proxy process that mediates filesystem access between the Sentry and the host. Sentry never directly opens host files.
• Two platforms: ptrace (portable, slower) and KVM (hardware virtualization, faster, requires nested virt or bare metal).

Installing gVisor on a Node

# Install runsc binary
curl -fsSL https://gvisor.dev/archive.key | gpg --dearmor -o /usr/share/keyrings/gvisor.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/gvisor.gpg] https://storage.googleapis.com/gvisor/releases release main" \
  | tee /etc/apt/sources.list.d/gvisor.list
apt-get update && apt-get install -y runsc

# Configure containerd to use runsc handler
cat >> /etc/containerd/config.toml <<EOF
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
  runtime_type = "io.containerd.runsc.v1"
EOF
systemctl restart containerd

What gVisor Cannot Sandbox

GKE Sandbox — Managed gVisor

On GKE, gVisor is production-ready via GKE Sandbox. Enable it by creating a node pool with --sandbox type=gvisor. Google runs gVisor in KVM mode for performance and it automatically configures the RuntimeClass.

gcloud container node-pools create sandbox-pool \
  --cluster my-cluster \
  --sandbox type=gvisor \
  --machine-type n2-standard-4 \
  --num-nodes 3

🧠 Knowledge Check