Docker is relevant to Kubernetes primarily through container images and the container runtime that runs workloads on worker nodes. Kubernetes supports pluggable runtimes through the Container Runtime Interface (CRI), so the runtime is an implementation choice rather than the whole platform. section 1.6 section 2.4
Use these operational distinctions when inspecting a Kubernetes workload:
- The worker node contains a kubelet, kube-proxy, and container runtime; the kubelet ensures that pod containers run according to the declared YAML state. section 1.6
- A pod can expose both an image reference and a runtime-specific container ID, such as an image from docker.io and a containerd identifier. section 1.6
- Use pod status and events to diagnose runtime failures, including Pending, Running, Terminated, and Completed states. section 1.6
Inspect the runtime behind a pod
Run `kubectl describe po nginx` and inspect the `Image` and `Container ID` fields. The representative output shows `docker.io/library/nginx` as the image source and `containerd://...` as the runtime identifier. section 1.6
Figure 1.9 The role of the worker node is to run the application workloads. It also contains kubelet, kube-proxy, and the container runtime (e.g., containerd).
Use the worker-node diagram to locate the container runtime alongside kubelet and kube-proxy. section 1.6
