Lesson 5: Container Runtimes & OCI Standards

1. OCI — Open Container Initiative

OCI is an open standard for containers, consisting of 3 specs:

Spec	Defines	Example
Image Spec	Container image format (layers, manifest, config)	Docker image → OCI image
Runtime Spec	How to run a container (filesystem, process, resources)	runc, crun, kata-containers
Distribution Spec	How to push/pull images to registries	Docker Hub, Harbor, ECR

Exam tip: OCI ensures interoperability — an image built with Docker can run on containerd, CRI-O, or any OCI-compliant runtime. KCNA often asks: "What ensures container portability?"

2. CRI — Container Runtime Interface

CRI is Kubernetes' standard interface for container runtimes. kubelet communicates with runtimes through this gRPC API.

Before CRI:                        After CRI:
  kubelet ──► Docker (hardcoded)    kubelet ──► CRI gRPC API ──► containerd
                                                              ──► CRI-O
                                                              ──► any CRI runtime

3. Container Runtimes Compared

Runtime	Type	Note
Docker	Deprecated (from K8s 1.24)	Used to go through dockershim → containerd. Direct CRI support removed
containerd	High-level CRI runtime	Default for most K8s distros (GKE, EKS, AKS). CNCF Graduated
CRI-O	High-level CRI runtime	Made for Kubernetes only (no docker CLI). Default for OpenShift
runc	Low-level OCI runtime	Actually runs the container process. Used by both containerd and CRI-O
kata-containers	Low-level OCI runtime	Runs containers in lightweight VMs for extra isolation

Runtime Hierarchy:
  kubelet → CRI → containerd (high-level) → runc (low-level) → container process
  kubelet → CRI → CRI-O     (high-level) → runc (low-level) → container process

Exam tip: "Docker is deprecated from K8s" doesn't mean Docker images won't work. Docker images = OCI images — they run fine on containerd/CRI-O. What was removed is the dockershim (the bridge between kubelet and Docker daemon).

4. Container Image Layers

Dockerfile → Image layers:
  FROM node:18       ← Base layer (read-only)
  COPY app/ .        ← Layer 2 (read-only)
  RUN npm install    ← Layer 3 (read-only)
  CMD ["node","app"] ← Metadata (entrypoint)

  Running container adds a thin writable layer on top
  ┌─────────────────────┐
  │  Writable layer     │ ← container writes (ephemeral)
  ├─────────────────────┤
  │  Layer 3: npm deps  │ ← read-only
  │  Layer 2: app code  │ ← read-only
  │  Layer 1: node:18   │ ← read-only (shared across containers)
  └─────────────────────┘

5. Container Registry

Registry	Type	Note
Docker Hub	Public	Default registry, rate limits for free tier
Harbor	Private (self-hosted)	CNCF Graduated, security scanning integrated
ECR / GCR / ACR	Cloud-managed	AWS/GCP/Azure private registries
ghcr.io	GitHub	GitHub Container Registry

6. Cheat Sheet

Exam question	Answer
Kubernetes standard API for container runtimes?	CRI (Container Runtime Interface)
Default runtime for most K8s distros?	containerd
Low-level runtime that actually starts containers?	runc
What ensures container image portability?	OCI standards
Docker deprecated means Docker images don't work?	No — Docker images follow OCI spec and work on any CRI runtime

7. Practice Questions

Q1: Since Docker was deprecated as a Kubernetes container runtime (v1.24+), what happens to existing Docker images?

• A) They can no longer run on Kubernetes
• B) They continue to work because Docker images comply with OCI standards ✓
• C) They need to be converted to a new format
• D) Only official Docker images from Docker Hub still work

Explanation: Docker images follow the OCI Image Specification, the same standard used by containerd and CRI-O. What was removed was the dockershim component (the bridge between kubelet and Docker daemon), not support for OCI images.

Q2: Which component in the container runtime stack is responsible for actually creating the container process at the OS level?

• A) containerd
• B) CRI-O
• C) runc ✓
• D) kubelet

Explanation: runc is the low-level OCI runtime that uses Linux kernel features (namespaces, cgroups) to create isolated container processes. containerd and CRI-O are high-level runtimes that manage container lifecycle and delegate the actual process creation to runc.

Q3: What is the role of the Container Runtime Interface (CRI) in Kubernetes?

• A) A container image format standard
• B) A gRPC API that allows kubelet to communicate with any container runtime ✓
• C) A tool for building container images
• D) A security standard for container isolation

Explanation: CRI is a standardized gRPC API that decouples kubelet from specific container runtimes. Any runtime implementing the CRI interface (containerd, CRI-O) can be used with Kubernetes — enabling runtime flexibility.