City architects evaluating Calico- or Cilium-style plugins ask which Kubernetes extension interface provides Pod network connectivity?
Select an answer to reveal the explanation.
Short Explanation
Pods need a network “road crew” on each node—that crew is the CNI plugin (Calico, Cilium, and friends). CSI is disks; CRI is how kubelet talks to the container runtime. Different bays in the same garage.
Full Explanation
City architects evaluating Calico- or Cilium-style plugins should know CNI is the extension interface that supplies Pod networking for connectivity and addressing. Pods need a network road crew on each node; that crew is CNI—not CSI disks or CRI container starts. CSI attaches block or file volumes; it does not provide the Pod network fabric. CRI starts containers on behalf of kubelet; it is not the Pod networking plugin interface. The Endpoints API consumes networking results but does not replace node-level CNI plugins. Exam caveat: CNI vs CSI vs CRI is a frequent CKA mapping question—keep the lanes straight. Operational check: Confirm a CNI DaemonSet/Pods are Running, check a Pod has an IP, and document which CNI product the municipality standardized on. 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.