Parks staff see pods on one rack fail to obtain network interfaces while other racks work, and the CNI DaemonSet shows unhealthy pods only on that rack. What is the right troubleshooting focus?
Select an answer to reveal the explanation.
Short Explanation
CNI agents ride along as a DaemonSet—one per node—so a single sick rack usually means those nodes' CNI pods or host net, not a whole-cluster etcd rebuild.
Full Explanation
CNI agents commonly run as a DaemonSet—one pod per node—programming interfaces and routes locally for parks and other workloads. When pods on one rack fail to obtain network interfaces while other racks work, and the CNI DaemonSet shows unhealthy pods only on that rack, treat it as node-local CNI agent failure: focus on those nodes’ CNI pods, host networking, or rack-level firewalling—not a whole-cluster etcd rebuild. Partial CNI DaemonSet failure does not prove etcd quorum loss; rebuilding etcd first would be a dangerous mis-prioritization for a rack-scoped networking symptom. Deleting all NetworkPolicies cluster-wide is not the first troubleshooting step and may worsen the security posture; inspect and restore CNI pods before blunt policy deletion. Scaling the kube-scheduler Deployment on the failing rack does not restore pod network interfaces; the scheduler assigns nodes, it does not implement CNI dataplane on workers. Exam caveat: Some overlays also need inter-rack UDP ports; still begin with the unhealthy DaemonSet pods on the affected nodes as the stem directs, then widen to fabric checks if agents are healthy but traffic fails. Operational check: List CNI pods with node IPs for the sick rack, read CNI logs, fix image pulls, privileges, or host routes, recreate a test pod, and confirm it receives a Pod IP on the municipal rack.