Containers and runtimes

Exam tasks: 1.4 (Containerization: containers, images, registries, standards and runtimes)

The decision: at which layer does a tool or standard sit (build, image, registry, high-level runtime, low-level runtime), and which one does the question describe?

The stack from kubelet to kernelCopy Anchor Link

What a container isCopy Anchor Link

• A container is an ordinary process that the kernel isolates. There is no "container" object in Linux.
• Namespaces limit what the process can see: pid (its own process tree), net (its own interfaces and IP), mnt (its own filesystem view), uts (hostname), ipc, user (UID mapping) and cgroup.
• cgroups limit what it can use: CPU, memory, I/O, number of processes. Kubernetes requests and limits become cgroup settings.
• Containers share the host kernel. That's why they start in milliseconds and are small, and also why a kernel exploit can escape them. Virtual machines each boot their own kernel.

Images, layers, tags and digestsCopy Anchor Link

• An image is a stack of read-only layers plus a config (entrypoint, env, user). Each build step that changes files adds a layer; identical layers are shared between images and cached on the node.
• At run time the runtime adds a thin writable layer on top. Anything written there disappears with the container, so persistent data needs a volume.
• A tag (:3.2.0, :latest) is a movable pointer. A digest (@sha256:9f1c...) identifies exact content and never changes. Pin digests when you need to know exactly what runs.
• Smaller images (multi-stage builds, distroless or minimal bases) pull faster and expose less attack surface.

# Build stage
FROM golang:1.25 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /out/tidewatch ./cmd/tidewatch

# Run stage: only the binary ships
FROM gcr.io/distroless/static-debian12
COPY --from=build /out/tidewatch /tidewatch
USER 65532
ENTRYPOINT ["/tidewatch"]

The OCI specsCopy Anchor Link

• The Open Container Initiative (under the Linux Foundation) maintains these standards. runc is its reference runtime implementation.
• Because of the image spec, images built with Docker, Podman, Buildah or BuildKit run on any Kubernetes runtime.

RegistriesCopy Anchor Link

• A registry stores and serves images: Docker Hub, GitHub Container Registry, cloud registries, or self-hosted ones such as Harbor (a CNCF graduated project that adds scanning, signing and replication).
• Image names read registry/namespace/repository:tag. With no registry, Docker Hub (docker.io) is assumed.
• Private registries need credentials, which Pods reference through imagePullSecrets.

The CRI and high-level runtimesCopy Anchor Link

• The Container Runtime Interface is a gRPC API between the kubelet and the runtime. Any runtime that implements it can be plugged in without changing Kubernetes.
• containerd: CNCF graduated, widely used default on managed and kubeadm clusters. Also the runtime under Docker Engine.
• CRI-O: a CNCF graduated runtime built specifically for Kubernetes and nothing else. Default on OpenShift.
• Both use an OCI low-level runtime (runc or crun) to actually create the container.
• crictl is the CLI for talking to any CRI runtime on a node, for debugging.

Sandboxed runtimes and RuntimeClassCopy Anchor Link

• gVisor (runtime runsc) intercepts system calls in a user-space kernel, so the container never talks to the host kernel directly.
• Kata Containers runs each Pod inside a lightweight virtual machine with its own kernel.
• Both trade some performance for stronger isolation, for untrusted or multi-tenant code.
• A RuntimeClass object names a runtime handler configured on the nodes. Pods opt in with spec.runtimeClassName:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: sandboxed
handler: runsc          # must match the handler configured in containerd or CRI-O
---
apiVersion: v1
kind: Pod
metadata:
  name: plugin-runner
spec:
  runtimeClassName: sandboxed
  containers:
    - name: runner
      image: registry.example.com/plugin-runner:0.9.3

How the CRI, CNI and CSI compare is covered in CKA extension interfaces.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• Container runtimes
• Images
• Runtime Class
• Open Container Initiative specifications