Kata Containers

Background and Origin

Kata Containers was formed in 2017 as a merger between two secure container projects:

• Intel Clear Containers, which focused on hardware-enforced isolation
• Hyper.sh’s runV, which used QEMU to run containers as lightweight VMs

These efforts merged under the OpenStack Foundation, now the OpenInfra Foundation, to form a community-driven project.

Its mission: enable secure containers without losing container agility.

Why Kata Containers Exist

Traditional containers are fast and efficient—but not always secure. They run directly on the host OS, using namespaces and cgroups for isolation. That’s fine in trusted environments, but dangerous when:

• You run multi-tenant apps on shared infrastructure
• You need strong kernel isolation
• You must comply with security or regulatory requirements

Kata Containers bridges the gap between:

• Performance of containers
• Security of VMs

The result: a sandboxed container that behaves like any other, but runs in a virtual machine for true isolation.

Architecture and How It Works

At its core, Kata Containers sits underneath your existing container runtime and launches every container (or pod) inside a lightweight VM. It supports:

• OCI runtime spec (works with containerd, CRI-O)
• Multiple hypervisors: QEMU, Cloud Hypervisor, Firecracker

Simplified architecture:

javaCopyEdit+------------------------------------------+
| Orchestrator (Kubernetes, Docker)        |
+----------------------+-------------------+
                       |
         Container Runtime (containerd, CRI-O)
                       |
                Kata Runtime (kata-shim-v2)
                       |
           Lightweight VM (QEMU, Firecracker)
                       |
     Guest OS + Containerized Application

Key Components

• kata-agent: runs inside the guest VM and handles syscalls and container lifecycle
• kata-runtime: interfaces with containerd or CRI-O to spawn VMs
• shim: connects the container process to the orchestrator

Each pod or container runs with its own kernel in the VM, creating a hard separation from the host.

Kata Containers in Kubernetes

Kubernetes supports RuntimeClass to define how pods should be run. Kata Containers can be used to selectively run pods in secure sandboxes.

Example: Run a pod using Kata in Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
annotations:
  io.kubernetes.cri.untrusted-workload: "true"
spec:
  runtimeClassName: kata
  containers:
  - name: sandboxed-app
    image: busybox
    command: ["sh", "-c", "echo Hello from Kata && sleep 3600"]
Copy Code

This pod will be launched in a microVM instead of a standard Linux namespace. Ideal for untrusted code or third-party services.

Performance and Isolation Tradeoffs

Kata Containers is a balancing act. Let’s break it down:

Note: With optimized Firecracker or Cloud Hypervisor setups, startup times are getting closer to native containers.

Kata Containers vs. Other Sandboxing Runtimes

Use Cases and Real-World Adoption

1. Multi-Tenant Kubernetes

Cloud providers like Alibaba use Kata to isolate customer workloads while keeping infrastructure costs low.

2. CI/CD Sandboxing

Secure your GitHub Actions, Jenkins, or GitLab jobs by running each in a microVM to limit potential damage from arbitrary code.

3. Edge and IoT Workloads

When deploying to devices where kernel isolation is essential (like medical devices or industrial systems).

4. Running Untrusted Third-Party Apps

E.g., SaaS platforms that let users upload and run code (Jupyter notebooks, ML models).

Challenges and Limitations

• Cold Start Latency: Although improving, booting VMs takes longer than containers
• Resource Usage: VMs have more overhead than namespace-based containers
• Operational Complexity: Requires understanding of VMs and guest OS management
• Storage Integration: Needs drivers for passing block devices between host and VM
• Network Tuning: Bridging VM and host network interfaces can introduce configuration overhead

Despite these, Kata has become much more production-ready, especially when paired with faster hypervisors like Firecracker.

Resources and Further Reading

• Containers Docs
• GitHub Repository
• CRI-O and Kata
• Open Container Initiative (OCI)
• OpenInfra Foundation