How ShimV2 Bridges Containerd and KataContainers for Secure Kubernetes Pods

Kubernetes Interface Design and CRI

Kubernetes is evolving toward exposing more extensible interfaces so that community contributors can implement new features. The most mature and critical interface is the Container Runtime Interface (CRI). In 2018 the containerd community introduced the shimv2 API, which builds on CRI to provide a more robust way for users to plug in custom container runtimes.

Core Kubernetes Architecture

The control plane (often called the Master) receives workloads via the API server, which stores objects in etcd. The controller manager runs control loops that create Pods, while the scheduler watches new Pods and assigns them to Nodes by writing the chosen Node name back to the Pod object. Kubelet runs on each node, watches Pod objects, and invokes the local container runtime (e.g., containerd) to start the containers that belong to the Pod.

Linux Containers Basics

A Linux container consists of two parts: the container runtime, which provides namespaces and cgroups to isolate processes, and the container image, which is a compressed bundle of the program, its dependencies, and filesystem layers. When the image is mounted via a union‑mount, it becomes the container’s rootfs.

KataContainers – VM‑Based Containers

KataContainers implements a container runtime using hardware virtualization. Each Kata Pod runs inside a lightweight virtual machine that has its own Linux kernel, offering VM‑level isolation while retaining container‑like agility. Image handling is identical to Docker; Kata uses standard OCI images.

Security‑focused workloads (finance, encryption, blockchain) benefit from this strong isolation. Common hardening techniques—dropping Linux capabilities, read‑only mounts, SELinux/AppArmor policies, and seccomp filters—are still applicable, but each additional filtering layer can introduce performance overhead.

Integrating KataContainers with Kubernetes

Kubernetes expects a CRI shim that translates CRI calls into runtime‑specific actions. For Docker, the shim creates an “infra” container; for Kata, it must launch a lightweight VM (the sandbox). The sandbox concept means that a Pod‑level shim should manage the entire sandbox rather than spawning a shim per container, reducing overhead.

Because CRI is container‑centric and does not include a Pod concept, the design aims to keep the API stable even as Pod‑level features evolve.

Problems with Per‑Container Shims

Creating a shim for every container in a Kata or gVisor sandbox adds unnecessary latency and complexity. Moreover, many CRI implementations (e.g., cri‑o, Docker‑shim) assume a one‑to‑one mapping between containers and shims, which does not align with sandbox‑based runtimes.

Containerd ShimV2 – A New Layer

ShimV2 introduces an intermediate API between the CRI shim and the underlying runtime. Instead of the flow CRI → containerd → runC, the new flow is CRI → containerd → ShimV2 → runC/Kata. This allows a pod‑specific shim to be started and stopped explicitly, and the same shim can be reused for all container operations within that pod.

When a sandbox is created, the Kata maintainer can start a containerd‑shim‑v2 instance. Subsequent create/start/stop container calls are routed through this shim, eliminating the need for a separate CRI shim for each runtime.

Practical Integration Steps

Deploy containerd with the standard CRI plugin (still using runC).

Install KataContainers on the host.

Implement a Kata‑specific containerd‑shim‑v2 that handles sandbox creation, starts the shim, and forwards container lifecycle requests to the Kata VM.

Configure Kubernetes to use the existing CRI plugin; the shimv2 layer will automatically route Kata Pods through the new shim.

Benefits and Community Adoption

This approach decouples Kubernetes from the specifics of each runtime, reducing maintenance burden. Projects such as KataContainers, gVisor, Firecracker, and PouchContainer have already adopted shimv2 to integrate their VM‑based runtimes with Kubernetes more cleanly.

By leveraging ShimV2, developers can focus on runtime features rather than writing and maintaining separate CRI shims for every container engine.

Conclusion

Kubernetes’ strategy of interface‑driven and plugin‑oriented design enables complex runtime integrations without polluting the core codebase. ShimV2 extends this philosophy by providing a standardized bridge between CRI and sandbox‑based runtimes, facilitating secure, multi‑tenant container deployments at scale.