Container Runtimes and Kubernetes
Kubernetes runs containers, yet it contains no code for actually starting one. It delegates. Knowing who does the real work explains error messages such as ImagePullBackOff, and a famous 2022 headline that scared many teams for no reason.
The rule
Kubernetes asks; the runtime runs; the image stays standard.
On every node, the kubelet does not start containers itself. It talks to a container runtime through a standard plug, the Container Runtime Interface (CRI). The two common runtimes are:
- containerd — widely used, and the default in most managed clusters.
- CRI-O — a runtime built just for Kubernetes.
The runtime pulls the image, unpacks its layers and starts the process with namespaces and cgroups.
Images follow the OCI (Open Container Initiative) standard. Any OCI image works with any OCI runtime. An image built with Docker on your laptop runs fine under containerd in the cluster.
That is why the news "Kubernetes removes dockershim" (version 1.24) changed nothing for images. Kubernetes stopped using Docker Engine as its node runtime; it did not stop running images that Docker built.
Kubernetes also adds a wrapper: it never schedules a bare container. It always schedules a pod that holds one or more containers.
spec:
containers:
- name: web
image: ghcr.io/example/notes-web:1.2When something fails, the pod status tells you where:
kubectl get pods -n notes
# notes-web-7c9d-abcde 0/1 ImagePullBackOffImagePullBackOff means the runtime could not fetch the image — a wrong name, a missing tag, or no credentials for a private registry.
The shortcut
When a pod will not start, walk the chain kubelet → runtime → image, and ask at each link: did the request arrive, could the image be pulled, did the process start?
kubelet
The pod has a node, so the kubelet received it. This link is fine.
The trap is blaming Kubernetes for image problems. The cluster only relays the request; a missing tag or a private registry without credentials is almost always the cause.
Drills
Answer fast — trust the rule.
Through which interface does the kubelet talk to containerd or CRI-O?
After dockershim was removed, can a cluster run images built with Docker?
What is the smallest thing Kubernetes schedules?
A pod shows ImagePullBackOff. Which cause is most likely?
Remember
- Kubernetes asks (kubelet), the runtime runs (containerd, CRI-O), the image stays standard (OCI).
- Walk kubelet → runtime → image when a pod will not start.
- Trap:
ImagePullBackOffis an image or credentials problem, not a cluster bug.