City platform runs kubeadm init and must pass a pod-network CIDR that will not clash with the civic WAN. What should admins do?
Select an answer to reveal the explanation.
Short Explanation
Pick a Pod neighborhood address block that does not collide with the city’s WAN streets. Pass that CIDR into kubeadm so the CNI can pave routes cleanly. Overlapping with WAN or with the Service range creates routing headaches.
Full Explanation
During kubeadm init for a city platform, administrators must choose a --pod-network-cidr (or ClusterConfiguration equivalent) that is unique relative to civic WAN routes and compatible with the chosen CNI. Pick a Pod neighborhood address block that does not collide with municipal streets of IP space so the CNI can pave routes cleanly. Reusing the WAN CIDR so Pods appear “native” without NAT creates routing ambiguity between Pod IPs and real civic networks. Omitting a pod CIDR and hoping Pods grab random public ISP addresses is not how kubeadm CNI planning allocates Pod networks. Setting the pod CIDR equal to the Service cluster IP range collapses two distinct virtual address spaces and breaks kube-proxy and routing assumptions. Exam caveat: Pod CIDR, Service CIDR, and physical/WAN ranges must remain disjoint. Operational check: Agree CIDRs with network engineering, pass the Pod CIDR into kubeadm init, install a matching CNI, and verify Pod IPs fall inside the planned block with kubectl get pods -A -o wide. In municipal platform operations, document this decision in the change record so the next on-call engineer understands why the chosen control exists and which failure modes the rejected options would introduce for city services that depend on this cluster behavior.