Public-works brings up a new kubeadm cluster but forgets to install a CNI plugin. What typically happens to workloads?
Select an answer to reveal the explanation.
Short Explanation
Without a CNI, the cluster is like a building with rooms but no hallway wiring—Pods show up on the work order (Pending / not Ready) and never get a usable network. etcd does not hand out Pod IPs. Install the CNI early.
Full Explanation
If public-works brings up kubeadm but forgets CNI, Pods often stay Pending or not Ready because networking is not configured—rooms without hallway wiring. etcd does not hand out Pod IPs, and auth does not substitute for node Pod networking. Pods do not receive IPs from etcd directly and run normally without a CNI. Services do not fully save you while only DaemonSets schedule; lack of CNI affects general networking readiness broadly. The API server does not refuse all authentication until Calico is present. Exam caveat: Install CNI early after init; Pending/network events are the classic symptom. Operational check: Apply CNI, wait for plugin Pods Ready, confirm nodes Ready, and verify a test Pod gets an IP in the public-works namespace. 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.