Containerization: Images, Container Runtimes, CRI and the OCI Explained

A container is not a small virtual machine. It is an ordinary Linux process, or group of processes, that the kernel has been told to isolate and constrain. Two kernel features do the work. Namespaces control what the process can see: the PID namespace gives it its own process tree, the network namespace its own interfaces and IP address, the mount namespace its own filesystem view, plus UTS (hostname), IPC and user namespaces. Control groups (cgroups) control what the process can use: how much CPU, memory and I/O it may consume. Add a layered image as its root filesystem and you have a container.

The decisive difference from a virtual machine is the kernel. Every container on a host shares that host's kernel; a VM runs on a hypervisor and carries its own complete guest operating system and kernel. That single fact explains all the trade-offs the exam asks about:

Because the kernel is shared, containers are lighter and faster to start but offer a weaker isolation boundary than VMs, which is why sensitive multi-tenant platforms sometimes wrap containers in lightweight VMs. For the exam, remember the one-liner: containers virtualize the operating system, VMs virtualize the hardware.

A container image is the packaged, portable artifact a container is started from: the application binary, its dependencies, and metadata such as the default command to run. An image is built as a stack of read-only layers, each recording a set of filesystem changes. Layers are content-addressed and shared: if ten images are built on the same base layer, that layer is stored and downloaded once. When a container starts, the runtime stacks the read-only layers and adds a thin writable layer on top using copy-on-write; anything the container writes there vanishes when the container is deleted, which is why containers are treated as ephemeral and state belongs in volumes.

Images live in registries, servers that store and serve them, such as Docker Hub, Quay.io, GitHub Container Registry and the managed registries of the cloud providers. A full image reference has the form registry/repository:tag, for example docker.io/library/nginx:1.27. When you omit parts, defaults fill in: Docker Hub as the registry and latest as the tag.

The distinction between tags and digests matters. A tag is a mutable, human-friendly pointer: whoever owns the repository can re-point myapp:latest at a completely different image tomorrow. A digest such as nginx@sha256:... is the immutable content hash of the image and always identifies exactly one build. That is why latest is discouraged in production manifests: two nodes pulling it at different times can silently run different software. Pulling is a single command:

docker pull nginx:1.27

Images are typically built from a Dockerfile, a plain-text recipe of instructions executed top to bottom. The exam expects recognition of the core instructions, not fluency in writing them. FROM names the base image the build starts from. RUN executes a command during the build, such as installing packages. COPY brings files from the build context into the image. EXPOSE documents the port the application listens on. CMD and ENTRYPOINT define what runs when a container starts from the image: ENTRYPOINT is the fixed executable, CMD supplies default arguments that are easy to override.

FROM node:20-alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Each instruction that changes the filesystem produces a new layer, and the builder caches layers: if an instruction and everything before it are unchanged, the cached layer is reused instead of rebuilt. That is why Dockerfiles copy dependency manifests and install packages before copying the frequently-changing application code, so edits to your code do not invalidate the expensive install layer.

You build and tag with docker build -t myapp:1.0 . and publish with docker push. Two size-reduction ideas are worth recognizing: small base images such as alpine or distroless images that omit shells and package managers, and multi-stage builds, where one stage compiles the application and a final minimal stage copies in only the finished binary, leaving compilers and build tools out of the shipped image. Smaller images pull faster and expose less attack surface.

The container runtime is the node-level software that actually pulls images and runs containers. Kubernetes does not run containers itself: on every node, the kubelet asks the runtime to do it, speaking a standard gRPC API called the Container Runtime Interface (CRI). The CRI defines operations like pull this image, create this sandbox, start this container, so any runtime that implements it can plug into Kubernetes without changes to the kubelet. This pluggability is the whole point: the interface decouples Kubernetes from any single vendor's runtime.

Two CRI runtimes dominate real clusters. containerd is a graduated CNCF project that began life inside Docker and was donated as a standalone runtime; it is the default in most managed Kubernetes services. CRI-O is a lighter runtime created specifically to serve the CRI for Kubernetes and nothing else; it is the default in Red Hat OpenShift. Functionally both do the same job for the kubelet.

One more layer completes the picture: these are high-level runtimes that manage images and container lifecycles, and they delegate the final step of creating the isolated process to a low-level runtime, almost always runc, which sets up the namespaces and cgroups and starts the process. Kubelet speaks CRI to containerd or CRI-O; they invoke runc.

Docker Engine predates the CRI and never implemented it. To keep supporting Docker as a runtime, the Kubernetes project maintained an adapter inside the kubelet called the Dockershim, which translated CRI calls into Docker Engine API calls. Maintaining a vendor-specific shim inside core Kubernetes was a growing burden, especially since Docker itself uses containerd underneath, so the shim added a hop that contributed nothing. Kubernetes deprecated the Dockershim in version 1.20 and removed it in version 1.24. Since 1.24, the kubelet only speaks CRI, and nodes use a CRI runtime such as containerd or CRI-O; teams that still want Docker Engine as the runtime can install cri-dockerd, an externally maintained adapter.

The exam's favorite follow-up: did this break images built with Docker? No, and understanding why is the point. An image built by docker build is an OCI-compliant image, the same standardized format every runtime consumes. containerd and CRI-O pull and run Docker-built images exactly as before. What was removed was Docker Engine's role as the node runtime that Kubernetes drives; the image format was never Docker-specific in any way that mattered, because it is governed by an open standard.

So the correct summary, and the one to recognize among wrong answers claiming Kubernetes dropped Docker support entirely, is: Kubernetes removed its adapter for Docker Engine as a runtime; developers still build images with Docker every day, push them to registries, and run them on Kubernetes clusters whose nodes use containerd or CRI-O.

The interoperability that made the Dockershim removal painless comes from the Open Container Initiative, an open governance project established in 2015 under the Linux Foundation to standardize container formats and runtimes. Docker seeded it by donating its image format and its runtime code, and the industry, including the major cloud providers and container vendors, maintains the specifications together. The OCI publishes three specifications the exam expects you to name:

• The image spec defines what a container image is: the layout of its filesystem layers, its manifest and its configuration metadata. Any OCI image can be built by one tool and run by another.
• The runtime spec defines how to run a container from an unpacked image: the configuration of namespaces, cgroups, mounts and process settings, and the lifecycle a runtime must implement.
• The distribution spec defines the registry API for pushing and pulling images, so any client can talk to any registry.

The reference implementation of the runtime spec is runc, the donated low-level runtime that containerd and CRI-O both use to create the actual isolated process. Alternative runtime-spec implementations exist for stronger isolation, such as sandboxed and lightweight-VM runtimes; because they honor the same spec, they slot in without changing Kubernetes.

Keep the two interface layers straight, because questions blur them deliberately: OCI standardizes the artifacts and the low-level runtime behavior, industry-wide; CRI is the Kubernetes-specific API the kubelet uses to talk to a high-level runtime. containerd sits in the middle, speaking CRI upward to the kubelet and driving an OCI runtime, runc, downward.

You should recognize the everyday commands of the two mainstream client tools. With Docker, docker run creates and starts a container from an image, with familiar flags: -d detaches it to run in the background, -p 8080:80 publishes container port 80 on host port 8080, -e sets an environment variable, and --name labels it. Supporting commands include docker ps to list running containers, docker logs to read output, docker exec to run a command inside a running container, and docker stop and docker rm to end and remove it.

docker run -d --name web -p 8080:80 nginx:1.27
docker ps
docker logs web
docker exec web nginx -v
docker stop web

Podman is the main alternative, and its differences are exactly what the exam probes. Docker uses a client-server design: the CLI talks to a long-running privileged daemon that owns every container. Podman is daemonless, running containers as ordinary child processes with no central daemon, and it emphasizes rootless operation, letting unprivileged users run containers, which shrinks the attack surface. Its command line is deliberately compatible with Docker's, so podman run, podman ps and podman build work as you would expect; both tools produce and consume the same OCI images. In the same Red Hat family, buildah specializes in building OCI images and skopeo in inspecting and copying them between registries.

For KCNA, the takeaways are recognition-level: these are developer-facing tools for building and running individual containers on a machine. On a Kubernetes node, the kubelet and the CRI runtime do that job; you do not run docker commands to operate Pods.

Kubernetes never runs a bare container; its smallest deployable unit is the Pod, which wraps one or more containers. Each container in a Pod names its image in the spec, and when the Pod is scheduled to a node, the kubelet instructs the CRI runtime to pull each image from its registry and start the containers. Private registries are handled with image pull secrets referenced by the Pod, so the runtime can authenticate.

The imagePullPolicy field controls when the node pulls: Always contacts the registry on every start (the default when a Pod uses the latest tag or no tag), IfNotPresent pulls only when the image is missing from the node's local cache (the default for specific tags), and Never uses only the local cache and fails if the image is absent. When a pull fails, because the tag does not exist, the registry needs credentials, or the network is down, the Pod's container reports ErrImagePull and then ImagePullBackOff as Kubernetes retries with increasing delays; recognizing that status as an image problem, not a scheduling or crash problem, is a standard exam discrimination.

Containers in the same Pod are more intimate than neighboring containers on a host: they share the same network namespace, meaning one IP address for the whole Pod and the ability to reach each other over localhost, and they can share storage volumes. The runtime holds those shared namespaces in a minimal infrastructure container, often called the pause container, that anchors the Pod so application containers can restart without the Pod losing its network identity. This is the mechanic behind the sidecar pattern, where a helper container, such as a log shipper or proxy, runs beside the main application container in one Pod.