After kubeadm init, county control-plane components look healthy, but Pods stay Pending without network. What admin step is still missing?
Select an answer to reveal the explanation.
Short Explanation
The control plane can be up while the neighborhood streets are still unpaved. Install a CNI add-on so Pods get addresses and nodes finish becoming Ready. Skipping networking phases or pointing DNS at the public internet does not replace CNI.
Full Explanation
After kubeadm init, county control-plane components can look healthy while Pods stay Pending without network because a CNI plugin has not been installed yet. Install a pod-network add-on so nodes can become fully Ready for workloads—the control plane may be up while neighborhood streets are still unpaved. The correct approach is: Install a CNI plugin (pod network add-on) so nodes can become fully Ready for workloads. Deleting etcd and re-init with --skip-phases=addons worsens the situation and still does not install Pod networking. Converting every application Pod into a static Pod under /etc/kubernetes/manifests bypasses normal scheduling and does not replace cluster CNI. Pointing --cluster-dns at an unused public resolver while skipping node networking fails to provide Pod IPAM and interface setup. Exam caveat: kubeadm init does not complete cluster networking; CNI is a deliberate follow-on step. Operational check: Apply the chosen CNI manifests or Helm release, wait for CNI Pods to be Ready, confirm nodes report Ready, and verify a test Deployment receives Pod IPs. 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.