Library cluster nodes run containerd as the low-level runtime that kubelet talks to when starting Pod containers. Which interface defines that kubelet-to-runtime contract?
Select an answer to reveal the explanation.
Short Explanation
kubelet does not speak every runtime’s private dialect—it speaks CRI, and containerd (or another runtime) answers. That is the clean socket between “schedule this Pod” and “run these containers.” CNI and CSI plug in elsewhere.
Full Explanation
Library cluster nodes running containerd use CRI as the kubelet-to-runtime contract. kubelet speaks CRI; containerd answers—that is the clean socket between “schedule this Pod” and “run these containers,” separate from CNI and CSI plugs. CNI does not start pause and app containers without kubelet; it configures networking for sandboxes kubelet/CRI create. CSI does not pull images or create network namespaces as its primary job; it manages volumes. IngressClass selects Ingress controllers, not how kubelet configures containerd sockets. Exam caveat: CRI is the runtime API; do not confuse it with CNI/CSI. Operational check: Verify kubelet runtime endpoint, crictl info/ps, and that Pod sandboxes appear via the CRI runtime on library workers. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the cluster’s current minor version and addon revisions used by the civic platform team. Keep the verification evidence—command output or config snippets—with the municipal runbook so audits can prove the control was applied as designed.