After joining a new county worker, nodes show Ready but pods on different racks cannot reach each other. Firewall review shows VXLAN or CNI overlay ports between racks are closed. What does this pattern indicate?

Node Ready mainly reflects kubelet’s ability to heartbeat and satisfy node conditions toward the API server. Pod-to-pod traffic across racks depends on the CNI dataplane—often VXLAN, Geneve, or vendor overlay ports—and host firewalls between county buildings. When those overlay ports are closed, kubelet heartbeats can still succeed (nodes stay Ready) while east-west pod packets fail. That split-brain pattern—healthy nodes, broken pod networking—is classic blocked CNI dataplane. A down kube-scheduler leaves new pods Pending without nodeName; it does not keep nodes Ready while selectively breaking only cross-rack pod connectivity for already-scheduled pods. etcd quorum loss typically makes the API unavailable or inconsistent; it does not specifically present as VXLAN ports closed between racks with nodes still Ready and overlay packets dropped only on the fabric path. metrics-server absence breaks kubectl top and HPA; CNI plugins do not generally refuse to program routes solely because CPU metrics are missing, so this distractor conflates observability with dataplane. Exam caveat: Also consider NetworkPolicies, asymmetric routing, and MTU issues, but the stem’s firewall review naming overlay ports is decisive for CNI dataplane blockage versus control-plane component myths. Operational check: From pods on different racks, test connectivity; on hosts, verify the CNI DaemonSet is Running, confirm overlay ports/security groups between racks, review CNI logs, and open the required UDP/TCP ports so civic workloads can reach each other while nodes remain Ready.