Week 10 - CRI-O and the Kubernetes CRI¶

10.1 Conceptual Core¶

CRI (Container Runtime Interface) is Kubernetes's gRPC API for talking to a container runtime. Two implementations dominate: containerd (with its CRI plugin) and CRI-O (built specifically for Kubernetes, Red Hat's choice).
CRI is narrower than full container management: it covers what kubelet needs and nothing else. No image-build, no high-level operations.
CRI-O philosophy: minimum daemon surface, OCI-spec-only, no Docker compatibility.

CRI services: RuntimeService (containers, sandboxes, exec/attach/portforward) + ImageService (pull, list, remove). Defined in cri-api/pkg/apis/runtime/v1alpha2/api.proto.
The pause container (every k8s pod has one): holds the network namespace alive while application containers are restarted. CRI-O and containerd both use this pattern.
crictl - direct CRI client for debugging.crictl ps,crictl images,crictl inspect. Different fromkubectl`; talks to kubelet's runtime, not to the API server.

Install CRI-O on a clean machine (or use containerd with its CRI plugin).
Use crictl runp (run pod), crictl create, crictl start to manually launch a pod-equivalent without Kubernetes. Inspect with crictl inspect.
Add an OCI hook (e.g., a pre-start hook that logs every container) by configuring CRI-O's hooks_dir.

Set CRI-O's default seccomp to runtime/default, AppArmor to runtime/default (Ubuntu) or SELinux to container_t (RHEL). These are the same defaults Kubernetes applies; understanding them at the runtime level demystifies pod-level errors.

Set up cri-tools/critest against your runtime; the suite verifies CRI compliance. A non-compliant runtime is a recipe for kubelet bugs in production.