The Container Runtime Interface (CRI) is the standard way kubelet communicates with a container runtime to pull images and start, manage, and stop containers. It lets Kubernetes use different runtimes without changing its core code. A node still needs a runtime to run its containers; containerd is the runtime used in the CKA examples. section 2.3.1 section 1.6
CRI is one of Kubernetes’ extension interfaces, alongside the Container Network Interface (CNI) and Container Storage Interface (CSI). Its concern is the runtime, not container networking or storage. The standard also avoids tying Kubernetes container management to Docker, on which it once relied. section 2.3 section 2.3.1
For a node-level check, identify the runtime and then use crictl on the node you are troubleshooting:
- Run kubectl get no -o wide and check the CONTAINER-RUNTIME column. section 2.1.4
- Run crictl ps for running containers or crictl ps -a to include stopped containers. Use a returned container ID with crictl inspect to check its state. section 2.3.1
- If kubectl logs is unavailable for a failing system component, run crictl logs followed by its container ID. crictl shows containers on the node where you run it, not on every cluster node. section 2.3.1
Check a kind node
In a kind cluster, kubectl get no -o wide shows containerd in the node’s CONTAINER-RUNTIME column. Enter the node with docker exec -it kind-control-plane bash, then run crictl ps to list containers inside it. The Docker container used to host the kind node and the runtime reported for that Kubernetes node are distinct parts of this setup. section 2.1.4
$ kubectl get no -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME kind-control-plane Ready control-plane 35s v1.31.0 172.18.0.2 <none> Debian GNU/Linux 12 (bookworm) 6.6.12-linuxkit containerd://1.7.18
The wide node listing shows where to verify the runtime: CONTAINER-RUNTIME reports containerd://1.7.18 for this kind node. section 2.1.4
