Learn Kata Containers - Core Concepts & Main Architecture

#Introduction

In episode 1 we understood why Kata Containers exists: hardware isolation for containers. Episode 2 answers the next question: how does the architecture work? We'll dissect the journey of a pod creation request — from kubelet to the process running inside the microVM — and get to know every component involved.

Understanding this architecture isn't just theory. When a pod fails to boot later, you'll need to know which layer the problem is in: CRI, shim, VMM, or the Kata agent inside the guest. Episode 12 on troubleshooting will feel much lighter if this architecture is already second nature.

#Main Flow: From Kubelet to MicroVM

A Kata pod's journey passes through several layers. Here's the full path:

1. kubelet calls containerd through CRI (gRPC) to create a pod sandbox.
2. containerd detects that the pod uses the Kata RuntimeClass, then calls the Kata shim — not the usual runc shim.
3. containerd-shim-kata-v2 talks to the Kata runtime and asks the VMM to build the microVM.
4. The VMM (QEMU, Cloud Hypervisor, Firecracker, or Dragonball) boots the guest kernel.
5. Inside the guest, the first process started is the Kata agent — the process that manages containers inside the VM.
6. The Kata agent receives requests from the shim to create containers, prepares the filesystem, and starts the application process.

The key takeaway of this flow: containerd shimv2 → Kata runtime → VMM → guest kernel → Kata agent.

#Why This Pattern Matters

The host never runs application processes directly. Application processes are born inside the guest kernel, managed by the Kata agent, and isolated by the VMM. The host only sees one VMM process per microVM — that's why the isolation is VM-equivalent, while the API Kubernetes sees remains the container API.

The interesting consequence: kubelet, containerd, and CNI work exactly as usual. Kata disguises itself as a standard container runtime in Kubernetes' eyes. This is what makes integration (episode 4) so seamless.

#Main Kata Containers Components

#containerd-shim-kata-v2

containerd-shim-kata-v2 is the shim v2 implementation for containerd. It replaces the two processes used by the old container architecture (shim + runtime) with a single process. Its job: translate CRI requests from containerd into instructions Kata understands, and maintain the connection between containerd and the microVM.

#kata-runtime and kata-runtime-rs

kata-runtime is the OCI runtime that manages the entire microVM lifecycle. It can be used standalone with containerd + the CRI plugin, or through shim v2. In modern versions, kata-runtime-rs — the Rust version — is the main runtime and has been the default since Kata 4.0.0. Both provide subcommands like check, list, and exec that you'll use often.

#kata-agent

kata-agent is the process that runs inside the guest. It plays a role similar to containerd on the host, but confined to the microVM: it receives requests from the shim to create containers, manages mounts, process execution, signals, and container lifecycle inside the guest. Because it's the only entry point into the guest, its security is critical (episode 13).

#kata-deploy and Hypervisor Plugins

kata-deploy is the tooling that automates Kata installation to a Kubernetes cluster. It works as a DaemonSet or Helm chart and handles the runtime binary, shim, hypervisor, and guest kernel on every node. The VMM itself is a plugin chosen through configuration: QEMU, Cloud Hypervisor, Firecracker, or Dragonball.

#How Host and Guest Communicate

A microVM can't share memory with the host just like that. Communication between the shim (on the host) and the Kata agent (in the guest) runs through vsock — a virtual socket communication mechanism provided by the hypervisor, without going through physical networking. Through this vsock, the shim sends container creation requests, and the agent responds with execution status.

For I/O devices, Kata uses two main mechanisms:

• virtio: the paravirtualization standard where the guest knows it's virtualized and cooperates with the VMM. virtio-blk for disks, virtio-net for networking, virtio-fs for filesystem sharing.
• VFIO: passthrough of physical devices from host to guest — GPUs or NICs that are detached from the host and accessed directly by the guest. This is covered in depth in episodes 8 and 10.

Think of virtio as a paravirtual employee who knows its job is backed by virtual devices; VFIO is handing the real physical device over to the guest.

#Architecture by Platform

Kata Containers is designed to be cross-architecture:

• x86_64: the most common, fully supported with KVM (VT-x).
• aarch64: ARM64 with ARM Virtualization Extensions, used at the edge and on ARM servers.
• ppc64le and s390x: IBM POWER and IBM Z, for enterprise environments.

Each platform has different hypervisor support — s390x, for example, uses KVM with characteristics different from x86. Always check the release documentation for the support matrix per architecture.

#Verifying the Components Present

Before moving on, make sure the following components are installed on the node:

which containerd-shim-kata-v2
which kata-runtime
kata-runtime version

which containerd-shim-kata-v2 and which kata-runtime confirm the binaries are on PATH. In a tarball installation, both are usually in /usr/local/bin. If they're not there yet, episode 3 will install everything.

#Conclusion

What you should take away:

• The full flow: containerd shimv2 → Kata runtime → VMM → guest kernel → Kata agent.
• containerd-shim-kata-v2 replaces the role of the classic shim + runtime.
• kata-runtime (and kata-runtime-rs, the Rust version) manages the microVM lifecycle.
• kata-agent runs inside the guest and manages containers from within.
• Host and guest communicate through vsock; I/O through virtio or VFIO.
• The architecture is supported on x86_64, aarch64, ppc64le, and s390x.

In the next episode, episode 3, we'll do the Kata Containers installation & setup — downloading the release tarball, running kata-deploy via Helm chart, building from source, then verifying the installation with kata-runtime check and kata-runtime kata-check. All the architecture we just learned will start to come alive on your node.