A transit engineer claims that installing a CNI plugin removes the need for Services and kube-proxy because CNI already load-balances ClusterIP traffic. What distinction should platform leads teach?
Select an answer to reveal the explanation.
Short Explanation
CNI lays the roads between Pods; Services and kube-proxy (or eBPF replacements) are the traffic signs and VIP routing for stable service IPs. Installing Calico does not mean you delete Service objects. Two layers, two jobs.
Full Explanation
Platform leads should teach transit engineers that CNI provides Pod networking while Services and kube-proxy (or a replacement datapath) remain a separate cluster concern. CNI lays roads between Pods; Services and kube-proxy are the VIP signs—installing Calico does not mean deleting Service objects. CNI and kube-proxy are not identical; either one alone does not fully implement the other’s job. CNI does not only manage PersistentVolumes; that claim confuses CNI with CSI. kube-proxy does not configure CSI drivers, and CNI still matters after Services exist. Exam caveat: Pod network fabric ≠ Service ClusterIP implementation. Operational check: With CNI healthy, create a Service, verify ClusterIP/endpoints, and confirm kube-proxy or replacement mode is intentional in the transit cluster. 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.