Learn Kata Containers - History, Background & Why You Need It

#Introduction

Welcome back to the Learn Kata Containers series! In episode 0 you prepared a node with KVM, containerd, and the basic tooling. Now we'll step back for a moment to understand where Kata Containers comes from and what security problem it actually solves. Without this context, all the kata-runtime commands and RuntimeClasses in the upcoming episodes will feel like a black box.

Episode 1 covers three big things: the birth of Kata from the merger of two projects, the "the speed of containers, the security of VMs" philosophy, and who's already adopted it in production. Why does it matter? Because the decision to use Kata Containers is usually born from an understanding of the security limits of traditional containers.

#The Birth of Kata Containers: A Merger of Two Worlds

#Clear Containers and runV

Before Kata existed, there were two different approaches to securing containers. Intel Clear Containers (from Intel) focused on running containers inside virtual machines using KVM/QEMU technology. Hyper.sh runV (from the company Hyper.sh) did something similar with a slightly different approach but the same goal: containers with VM isolation.

Both projects realized they were chasing the same problem. In December 2017, they merged into a single project called Kata Containers, announced at KubeCon Austin. Kata means "words" — a metaphor that this project unites two different languages into one that everyone understands.

#The OpenInfra Foundation

Kata Containers then became a project under the OpenInfra Foundation — the same umbrella as OpenStack. Membership in this foundation means Kata development isn't controlled by a single vendor: Intel, Hyper.sh, and later many other companies contribute together. This is one reason Kata is trusted in production — no single party can halt its development unilaterally.

#Evolution to a Rust Runtime

Since the 3.x series, the most significant architectural change began: the main runtime moved from Go to Rust, with an implementation named runtime-rs. This move brought Rust's memory safety, speed, and lower resource consumption. It culminated in Kata Containers 4.0.0, released July 22, 2026: the Rust runtime became the default with a Rust-first architecture. We'll break down the full details in episode 17.

#Why You Need Kata Containers

#The Security Limits of Traditional Containers

runc-based containers share the host kernel. Namespaces and cgroups provide isolation, but that boundary is software — one kernel, thousands of processes, and a single kernel flaw means every tenant is affected. Imagine an apartment building built on a single shared foundation: comfortable and cheap, but one crack in the foundation is felt by every resident.

Kata Containers flips that logic: every pod gets its own kernel inside a microVM. The isolation boundary now lives in hardware — the hypervisor separates the guest kernel from the host kernel. A tenant that gets exploited can only damage its own VM, not the whole node.

#"The Speed of Containers, the Security of VMs"

This philosophy is the heart of Kata. Containers win on speed and convenience; VMs win on security and isolation. Kata designs the entire stack so a pod boots in 150-300 milliseconds — close to the speed of a regular container, but with full VM isolation:

• Speed of containers: the same OCI/CRI API, short boot times, low overhead per pod.
• Security of VMs: a separate guest kernel, hardware isolation, and compatibility with confidential computing.

This isn't marketing numbers. The architecture covered in episode 2 — from shim to guest kernel — is designed specifically to hit that boot time, including the optimizations done by the Rust runtime and Dragonball.

#Seamless Kubernetes Integration

Kata doesn't force you to change your tooling. Because it follows the OCI specification and works through CRI, Kubernetes recognizes it as a regular runtime. A pod uses Kata simply by setting spec.runtimeClassName — the RuntimeClass object you already know from episode 0. No changes to Deployments, Services, or NetworkPolicies.

To check the runtime version currently active on the node:

kata-runtime version

kata-runtime version prints the runtime version, the OCI protocol version, and the build commit. We'll use this command in full in episodes 3 and 4.

#Who Adopts Kata Containers

Production adoption proves Kata is more than research:

• AKS Pod Sandboxing (Microsoft Azure): Kata Containers as built-in sandboxing for untrusted workloads in Azure Kubernetes Service.
• OpenShift Sandboxed Containers (Red Hat): Kata as the runtime for sandboxed workloads in OpenShift.
• AWS EKS: support on bare-metal nodes for workloads that need microVM isolation.
• IBM Cloud and Alibaba Cloud: major cloud providers integrating Kata into their platforms.

The pattern across all these adoptions is the same: untrusted or multi-tenant workloads — sandboxes for external code, CI/CD running third-party artifacts, and AI agents executing tools from unknown sources.

#Practice: Checking Environment Readiness

First check that everything prepared in episode 0 is still intact, because episode 3 will use it all directly:

ls -l /dev/kvm
kubectl get nodes -o wide
kata-runtime version

ls -l /dev/kvm confirms hardware acceleration is available, kubectl get nodes -o wide confirms the cluster is healthy, and kata-runtime version confirms the runtime binary is installed. If the binary isn't there yet, don't worry — episode 3 will install it fully.

#Kata vs Other Approaches: An Early Overview

As an overview, here's where Kata sits among other isolation approaches:

• runc: regular container, shared kernel, lightweight, software isolation boundary.
• Kata Containers: container with a microVM, its own kernel, hardware isolation.
• gVisor: userspace kernel as a syscall intermediary, without a hypervisor.
• Firecracker/Cloud Hypervisor: VMMs (Virtual Machine Monitors) that act as Kata's backends.
• KubeVirt: runs native VMs in Kubernetes, not containers.

A deep comparison, including when to choose gVisor over Kata, will be covered in episode 22.

#Conclusion

Key takeaways:

• Kata was born in December 2017 from the merger of Intel Clear Containers and Hyper.sh runV.
• The project is governed under the OpenInfra Foundation, not a single vendor.
• "The speed of containers, the security of VMs": 150-300 ms boot with hardware isolation.
• Every Kata pod has its own kernel; the isolation boundary is hardware, not software.
• Seamless Kubernetes integration through OCI, CRI, and RuntimeClass.
• Adopted by AKS, OpenShift, AWS EKS, IBM Cloud, and Alibaba Cloud.

In the next episode, episode 2, we'll dissect the core concepts and main architecture of Kata Containers — the flow from containerd shimv2 to VMM to guest kernel to Kata agent, components like containerd-shim-kata-v2, kata-runtime, kata-runtime-rs, and kata-agent, and how virtio and VFIO connect host and guest. This is the architectural foundation used in every upcoming episode.