County firewalls block TCP 6443 between worker nodes and the API server VIP. What breaks, and what should networking open?
Select an answer to reveal the explanation.
Short Explanation
Workers need a clear phone line to the API desk on 6443. If the firewall clips that path to the VIP, joins and kubelet heartbeats suffer. Open TCP 6443 from nodes to the control-plane endpoint—do not confuse it with VXLAN or etcd peer ports.
Full Explanation
When county firewalls block TCP 6443 between worker nodes and the API server VIP, workers cannot reach the Kubernetes API. Kubelets, bootstrap joins, and ongoing heartbeats depend on that clear phone line to the API desk. Networking teams must allow TCP 6443 from nodes to the control-plane endpoint—often a VIP or load balancer—so municipal workers can authenticate and register normally. Claiming only NodePort Services fail and that UDP 6443 must open between workers exclusively misstates both the protocol and the failure domain: apiserver clients use TCP 6443 toward the control plane, not a worker-mesh UDP NodePort path. etcd peer traffic uses different ports (commonly 2380); opening 6443 solely between etcd members does not repair kubelet-to-apiserver connectivity. CNI VXLAN ports such as UDP 4789 are overlay concerns and must never replace 6443 as the API port in firewall design. Exam caveat: separate API (6443), etcd peer, and CNI overlay ports when interpreting firewall tickets. Operational check: from a worker, test TCP connectivity to the API VIP on 6443, update firewall policy, re-run kubeadm join or restart kubelet, and confirm the Node reports Ready with successful apiserver communication in kubelet logs.