Introduction
Ask a room of Kubernetes beginners “what actually runs your container?” and most will say “Docker.” For years that was close enough to true that nobody questioned it. Then Kubernetes 1.24 removed something called Dockershim, headlines screamed “Kubernetes is deprecating Docker,” and a lot of people panicked for no reason. Understanding why that headline was misleading is one of the cleanest ways to prove you actually understand how containers work — which is exactly why the Kubernetes and Cloud Native Associate (KCNA) exam tests it.
The KCNA exam devotes a full domain to Container Orchestration, and inside it sits the Container Runtime Interface (CRI) and the broader container ecosystem. These questions are conceptual, not hands-on — KCNA is 60 multiple-choice questions in 90 minutes with no live cluster — but they reward candidates who can untangle the layers: standards (OCI), the interface Kubernetes talks to (CRI), high-level runtimes (containerd, CRI-O), and low-level runtimes (runc). Get those layers straight and every runtime question on the exam becomes a matter of matching a description to the right box.
This guide walks the container runtime landscape the way KCNA frames it. If you want the wider view of this domain first, pair it with the Container Orchestration Fundamentals guide and the Kubernetes Architecture Fundamentals guide, then use this article to go deep on the runtime layer.
What a Container Runtime Actually Does
A container runtime is the software responsible for running containers. That sentence hides a lot of work. To start a container, something has to:
- Pull the container image from a registry.
- Unpack the image layers onto the local filesystem.
- Set up isolation using Linux kernel features — namespaces (so the container gets its own view of processes, network, and mounts) and cgroups (so it gets bounded CPU and memory).
- Start the process inside that isolated environment and manage its lifecycle (stop, pause, delete).
A container is not a lightweight virtual machine. It is an ordinary Linux process that the kernel has fenced off using namespaces and cgroups. The runtime is the tool that arranges that fencing. This is a favorite KCNA framing: containers share the host kernel; VMs each run their own kernel on a hypervisor. That single distinction explains why containers start in milliseconds and pack far more densely than VMs.
The Layer Cake: Standards, Interface, and Runtimes
The single biggest source of confusion — and the thing the exam quietly tests — is that “runtime” refers to several different layers. Here is the mental model to lock in:
| Layer | What it is | Examples |
|---|---|---|
| Standards (OCI) | Specifications everyone agrees to follow | OCI Image Spec, Runtime Spec, Distribution Spec |
| CRI | The interface Kubernetes uses to talk to a runtime | Container Runtime Interface (a gRPC API) |
| High-level runtime | Manages images, pulls, and delegates execution | containerd, CRI-O |
| Low-level runtime | Actually creates the container process using the kernel | runc, crun, gVisor, Kata |
Read that table top to bottom and the ecosystem stops being alphabet soup. Standards define the shape; CRI is the plug Kubernetes uses; a high-level runtime handles the heavy lifting of images and lifecycle; and it hands the final “create this isolated process now” step to a low-level runtime. Let’s take them one at a time.
OCI: The Standards That Hold It All Together
The Open Container Initiative (OCI) is a Linux Foundation project that publishes the open standards making the whole ecosystem interoperable. For KCNA you should recognize three specs:
- Image Specification — defines the format of a container image (its layers and configuration) so an image built by one tool runs anywhere.
- Runtime Specification — defines how to run a “filesystem bundle” as a container, so any compliant runtime can start it.
- Distribution Specification — defines how images are pushed to and pulled from registries.
The exam idea: because of OCI, you are not locked into any one vendor’s tools. An image you build with one tool can be stored in any compliant registry and run by any compliant runtime. Standards are what let Kubernetes swap runtimes underneath without applications noticing. When a question mentions “open standards for container images and runtimes,” OCI is the answer.
CRI: How Kubernetes Talks to Runtimes
The Container Runtime Interface (CRI) is the plugin API — a gRPC interface — that the kubelet (the Kubernetes agent on every node) uses to manage containers. Introduced back in Kubernetes 1.5, CRI exists to solve one problem: Kubernetes should not have to hard-code support for any single container runtime. Instead, it defines a standard interface, and any runtime that implements CRI can plug in.
Here is the flow the exam wants you to picture:
kubelet ──(CRI, gRPC)──▶ container runtime (e.g. containerd) ──▶ runc ──▶ running containerThe kubelet says “start this pod’s containers” over CRI. The CRI-compatible runtime pulls the images, sets things up, and delegates the actual process creation to a low-level runtime. Because the kubelet only speaks CRI, the runtime behind it is pluggable — this is the architectural decision that made removing Dockershim possible without breaking Kubernetes.
High-Level Runtimes: containerd and CRI-O
High-level runtimes (also called container engines or CRI runtimes) handle everything above the raw process: pulling and managing images, managing storage and networking hooks, and exposing the CRI so the kubelet can talk to them. The two you must know for KCNA:
- containerd — a graduated CNCF project, originally extracted from Docker. It is now the most widely used runtime in production Kubernetes and the default in most managed offerings (EKS, GKE, AKS). It implements CRI natively.
- CRI-O — a lightweight runtime built by the community specifically for Kubernetes. It implements only what the CRI needs and nothing more, which makes it minimal and purpose-built. It is the default in some OpenShift-derived platforms.
Both are CNCF projects, both implement CRI, and both delegate the final step to a low-level runtime. For the exam, the takeaway is that these are the runtimes the kubelet actually talks to today — Docker is no longer in that direct path.
Low-Level Runtimes: runc and Friends
A low-level runtime does the narrow, privileged job of actually creating the container: it takes an OCI bundle and uses Linux namespaces and cgroups to spin up the isolated process. The reference implementation is runc, the OCI-compliant tool that containerd and CRI-O both call under the hood.
The exam may also nod to sandboxed or alternative low-level runtimes that offer stronger isolation than plain runc:
- gVisor — intercepts and handles syscalls in user space, adding a security boundary between the container and the host kernel.
- Kata Containers — runs each container inside a lightweight virtual machine for VM-grade isolation while keeping a container-like workflow.
You do not need deep detail here for KCNA, but recognize the pattern: high-level runtimes are pluggable at the bottom too, so you can swap runc for a sandboxed runtime when you need stronger isolation — a theme that connects to the security material in the KCSA security fundamentals if you continue onto that track.
The Dockershim Story: What Actually Happened
Now the headline that confused everyone. When Kubernetes was young, Docker was the only container tool that mattered, but Docker did not implement CRI — it predated it. So Kubernetes shipped a compatibility adapter called Dockershim that translated between the kubelet’s CRI calls and Docker’s own API. It worked, but it was extra code the Kubernetes project had to maintain forever just for one runtime.
Meanwhile, Docker itself is not a single thing — internally it uses containerd, which does implement CRI. So the kubelet was calling Dockershim, which called Docker, which called containerd, which called runc. That is a lot of hops when the kubelet could just call containerd directly.
In Kubernetes 1.24 (2022), the project removed Dockershim from the codebase. Here is what that did and did not mean, and it is exactly what the exam probes:
- It did not mean your Docker-built images stop working. Images are OCI-compliant, so an image built with Docker runs perfectly on containerd or CRI-O. “Docker images” are just OCI images.
- It did not mean you can’t use Docker on your laptop to build and test. Docker as a developer tool is unaffected.
- It did mean Kubernetes clusters that were using Docker as the node runtime needed to switch the node’s runtime to a CRI-native one like containerd or CRI-O.
The clean exam answer to “did Kubernetes deprecate Docker?” is: Kubernetes removed the Dockershim adapter, not support for containers or images. Images keep working; nodes now talk to a CRI runtime like containerd directly.
| Myth | Reality |
|---|---|
| ”Docker images won’t run on Kubernetes anymore” | They run fine — images follow the OCI standard |
| ”You must rebuild all your images” | No rebuild needed; OCI images are portable |
| ”Docker is banned from the workflow” | Docker is still fine for building images locally |
| ”Kubernetes has no runtime now” | Nodes use containerd or CRI-O directly via CRI |
How This Maps to the KCNA Exam
Runtime questions on KCNA are recognition questions. Anchor these associations and you will pick the right option fast:
- “Open standard for image and runtime format” → OCI.
- “Interface the kubelet uses to talk to the runtime” → CRI.
- “Default production runtime, from the Docker project, CNCF graduated” → containerd.
- “Lightweight runtime built specifically for Kubernetes” → CRI-O.
- “Reference low-level runtime that creates the container process” → runc.
- “Kubernetes 1.24 removed this compatibility layer” → Dockershim.
- “Containers share the host ___; VMs each run their own ___” → kernel.
Notice how each answer lives in a different layer of the cake. If you can place a term on the standards / interface / high-level / low-level ladder, you can answer almost any runtime question the exam throws at you — including the distractor-heavy ones that mix layers on purpose.
A Quick Study Routine for This Topic
- Draw the layer cake from memory — OCI at the top, then CRI, then high-level (containerd, CRI-O), then low-level (runc). If you can reproduce that diagram, you understand the domain.
- Explain the Dockershim removal out loud in two sentences without notes. If you can teach it, you own it.
- Rehearse the kernel-vs-hypervisor distinction between containers and VMs — it appears constantly across the KCNA syllabus.
- Practice under time pressure. These are fast recognition questions, and the exam’s tight 90-minute window rewards instant recall over deliberation.
Conclusion
Container runtimes look intimidating until you see the layers. OCI defines the standards that make everything portable. CRI is the pluggable interface the kubelet speaks. High-level runtimes like containerd and CRI-O manage images and lifecycle, then hand the final step to a low-level runtime like runc. And the great Dockershim scare was never about your images breaking — it was Kubernetes shedding a maintenance burden and talking to containerd directly. Hold that structure in your head and this entire slice of the Container Orchestration domain becomes some of the easiest, most reliable points on the exam.
KCNA is a timed, conceptual exam — 60 questions in 90 minutes — and the surest way to confirm you can place every runtime term on the right layer under pressure is to practice with realistic questions. Start with the free KCNA practice questions to test your recall, and when you want full-length, timed mock exams with detailed explanations across every KCNA domain, the KCNA Mock Exam Bundle gives you five complete practice exams to find and close your gaps before exam day. For the full preparation roadmap, follow the KCNA study guide and the KCNA exam guide for 2026.
Frequently Asked Questions
Does Kubernetes still support Docker after removing Dockershim?
Kubernetes removed Dockershim, the adapter that let the kubelet talk to Docker as a node runtime — it did not remove support for containers or images. Container images built with Docker follow the OCI standard and run perfectly on containerd or CRI-O. You can still use Docker to build and test images locally; only the node’s runtime changed to a CRI-native one.
What is the difference between a high-level and low-level container runtime?
A high-level runtime (containerd, CRI-O) manages images — pulling, unpacking, storage, and lifecycle — and exposes the CRI so the kubelet can talk to it. A low-level runtime (runc) does the narrow job of actually creating the isolated container process using Linux namespaces and cgroups. High-level runtimes delegate that final step to a low-level runtime.
What is the Container Runtime Interface (CRI)?
CRI is a gRPC-based plugin API that the kubelet uses to manage containers on a node. It lets Kubernetes work with any compliant runtime without hard-coding support for a specific one, which is why runtimes are pluggable and Dockershim could be removed without breaking clusters.
What role does OCI play in the container ecosystem?
The Open Container Initiative (OCI) publishes open standards — the Image, Runtime, and Distribution specifications — that make container images and runtimes interoperable. Because of OCI, an image built by one tool can be stored in any compliant registry and run by any compliant runtime, avoiding vendor lock-in.
Is containerd or CRI-O better for KCNA?
For the exam, you don’t rank them — you recognize both as CNCF, CRI-compatible high-level runtimes. containerd originated from the Docker project and is the most common default in managed Kubernetes; CRI-O was built specifically and minimally for Kubernetes. Both delegate to a low-level runtime like runc.
How deeply is container runtime knowledge tested on KCNA?
It is tested conceptually within the Container Orchestration domain — recognizing the layers (OCI, CRI, containerd/CRI-O, runc), understanding the Dockershim change, and knowing the container-versus-VM distinction. KCNA does not ask you to configure runtimes hands-on, so focus on the vocabulary and the relationships between layers rather than command syntax.