Container runtime in Kubernetes

What is a container runtime in Kubernetes?

A container runtime is the software on a node that actually runs your containers. Kubernetes decides what should run and where, but it doesn’t run containers itself. It hands that job off to a container runtime installed on each node.

kubelet talks to the container runtime through a standard interface, so Kubernetes doesn’t care which runtime you use, as long as it follows the rules.

What a container runtime actually does

• Pulls container images: Downloads the image your pod spec references, from a registry like Docker Hub.
• Starts and stops containers: Creates the actual running container from that image, and stops or removes it when told to.
• Manages container resources: Enforces the CPU and memory limits you set in your pod spec.
• Reports container status: Tells kubelet whether a container is running, stopped, or has failed.

How kubelet talks to the runtime

Kubernetes uses a standard called the Container Runtime Interface (CRI). Any runtime that supports CRI can plug into kubelet without Kubernetes needing custom code for each one. This is why you can switch container runtimes without changing how you write pod specs or deployments.

Kubernetes default container runtime

containerd is the default and most widely used container runtime in current Kubernetes clusters. It’s what most managed Kubernetes services, including EKS, GKE, and AKS, run by default. Docker itself is no longer used directly as the runtime, Kubernetes dropped built-in Docker support (dockershim) back in version 1.24, though containerd is actually the same runtime Docker used under the hood.

List of container runtimes

• containerd: Lightweight, CRI-native, the current default across most clusters.
• CRI-O: Built specifically for Kubernetes, minimal by design, used often in OpenShift.
• gVisor: Adds an extra sandboxing layer for stronger container isolation.
• Kata Containers: Runs each container inside a lightweight VM for extra security.

Container runtime vs Docker

This is a common point of confusion. Docker is a full platform, it builds images, runs containers, and provides a CLI. A container runtime is just the piece that actually runs the container. containerd, in fact, started as a component inside Docker itself before becoming its own standalone project. So when someone says “Kubernetes doesn’t use Docker anymore,” it means Kubernetes talks directly to containerd (or another CRI runtime) instead of going through the full Docker platform, not that containers stopped working the way they did before.

A simple example

You can check which container runtime a node is using with:

kubectl get nodes -o wide

This shows a CONTAINER-RUNTIME column, something like containerd://1.7.2, telling you the runtime and version running on that node.

Choosing a container runtime

For most teams, containerd is the right default. It’s stable, CRI-native, and what every major managed Kubernetes service uses out of the box. CRI-O or sandboxed runtimes like gVisor and Kata Containers are worth considering only if you have specific isolation or compliance requirements.

Where it fits in the cluster

The container runtime works directly with kubelet on each node. kubelet decides what should be running, based on instructions from kube-scheduler, and the container runtime carries that out.