Kata Containers (compatible with Magnum clusters)

[!WARNING] Specialized Setup Required Kata Containers utilize lightweight virtual machines to isolate pods. This is an advanced feature and is not required for standard Kubernetes workloads. Only proceed if your use case specifically demands higher isolation (e.g., untrusted code, multi-tenant security).

Kata Containers is an open-source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.

For more information, visit the official Kata Containers documentation.

This document describes how to deploy and use Kata Containers as an additional workload runtime in Kubernetes clusters (e.g., OpenStack Magnum clusters).

Kata provides VM-isolated pods using lightweight virtual machines instead of standard Linux containers.

1. Architecture Overview

Component	Role
Kubernetes	Schedules pods
containerd	Container runtime
Kata Containers	VM-based runtime (io.containerd.kata-qemu.v2)
RuntimeClass	Selects Kata runtime for pods

• Normal pod: process on host kernel
• Kata pod: pod runs inside a lightweight VM (QEMU)

2. Installation

Kata should be installed using the official kata-deploy Helm chart. For more details, see the official repository: https://github.com/kata-containers/kata-containers/tree/main/tools/packaging/kata-deploy/helm-chart

Install via Helm

Install directly from the official ghcr.io OCI registry. Update the VERSION to your needs or just use the latest.

export VERSION=$(curl -sSL https://api.github.com/repos/kata-containers/kata-containers/releases/latest | jq .tag_name | tr -d '"')
export CHART="oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy"

helm install kata-deploy "${CHART}" --version "${VERSION}"

# See everything you can configure
helm show values "${CHART}" --version "${VERSION}"

The Helm chart deploys a DaemonSet that:

• Installs Kata binaries on each node
• Configures containerd runtime handlers
• Labels nodes capable of running Kata
• Creates Kubernetes RuntimeClasses

3. Verify Installation

Check RuntimeClasses

kubectl get runtimeclass

Expected output (example):

NAME                            HANDLER                         AGE
kata-clh                        kata-clh                        52m
kata-cloud-hypervisor           kata-cloud-hypervisor           52m
kata-dragonball                 kata-dragonball                 52m
kata-fc                         kata-fc                         52m
kata-qemu                       kata-qemu                       52m
kata-qemu-cca                   kata-qemu-cca                   52m
kata-qemu-coco-dev              kata-qemu-coco-dev              52m
kata-qemu-coco-dev-runtime-rs   kata-qemu-coco-dev-runtime-rs   52m
kata-qemu-nvidia-gpu            kata-qemu-nvidia-gpu            52m
kata-qemu-nvidia-gpu-snp        kata-qemu-nvidia-gpu-snp        52m
kata-qemu-nvidia-gpu-tdx        kata-qemu-nvidia-gpu-tdx        52m
kata-qemu-runtime-rs            kata-qemu-runtime-rs            52m
kata-qemu-se                    kata-qemu-se                    52m
kata-qemu-se-runtime-rs         kata-qemu-se-runtime-rs         52m
kata-qemu-snp                   kata-qemu-snp                   52m
kata-qemu-snp-runtime-rs        kata-qemu-snp-runtime-rs        52m
kata-qemu-tdx                   kata-qemu-tdx                   52m
kata-qemu-tdx-runtime-rs        kata-qemu-tdx-runtime-rs        52m

kata-qemu is the runtime used in this environment, but you may need to use a different one.

Check Kata-enabled nodes

kubectl get nodes --show-labels | grep katacontainers.io/kata-runtime

Nodes prepared by kata-deploy are labeled: katacontainers.io/kata-runtime=true

4. Deploying a Workload with Kata Runtime

To run a pod in a Kata VM, specify runtimeClassName.

Example: NGINX Deployment Using Kata

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-kata
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-kata
  template:
    metadata:
      labels:
        app: nginx-kata
    spec:
      runtimeClassName: kata-qemu
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80
        # Important! Use resources to utilize resources optimally on K8s nodes.
        # Otherwise, default values are used. This is different from "normal" containers.
        resources:
          requests:
            memory: "3072Mi"
            cpu: "500m"
          limits:
            memory: "3584Mi"

Apply:

kubectl apply -f nginx-kata.yaml

5. How It Works

When this pod is scheduled:

1. Scheduler selects a node labeled for Kata
2. Kubelet reads runtimeClassName: kata-qemu
3. containerd starts runtime handler io.containerd.kata.v2
4. Kata launches a QEMU virtual machine
5. The container runs inside that VM

6. Verifying That a Pod Is Running in Kata (No Node Access Required)

Exec into the pod:

kubectl exec -it <pod> -- sh

Check VM indicators

uname -r
cat /proc/cpuinfo | grep hypervisor
free -h

Typical Kata VM signs:

Check	Expected in Kata
Kernel version	Different from node kernel
CPU flags	hypervisor present
Memory	Only VM-assigned memory visible

These confirm the workload runs inside a VM, not as a host container.

7. When to Use Kata Runtime

Use Kata for workloads requiring:

• Stronger isolation than runc containers
• Multi-tenant security boundaries
• Running untrusted workloads
• Compliance-driven environments

8. When NOT to Use Kata

Avoid for:

• Ultra-low-latency workloads
• Pods requiring host-level device access
• High pod density scenarios

Kata pods have higher memory and CPU overhead due to VM isolation.

9. Summary

Feature	runc	Kata
Isolation	Process	VM
Kernel shared	Yes	No
Security boundary	Weaker	Stronger
Overhead	Low	Higher

Kata Containers allow Magnum clusters to run VM-isolated Kubernetes workloads while preserving standard Kubernetes workflows.