Question

Users report that ClusterIP Services are unreachable from Pods running on worker node-3, while the same Services work fine from Pods on other nodes. You confirm the target Service has healthy Endpoints and CoreDNS resolves the Service name correctly on all nodes. Running 'kubectl get pods -n kube-system -o wide' shows the kube-proxy Pod on node-3 is in CrashLoopBackOff, while all other kube-proxy Pods are Running. What is the most likely reason Services fail specifically on node-3?

Accepted Answer

kube-proxy on node-3 is not programming the iptables/IPVS rules needed to redirect Service VIP traffic to backend Pods on that node

Answer

The Service selector no longer matches the backend Pods, so Endpoints are stale on node-3

Answer

CoreDNS is caching a stale ClusterIP that only affects node-3

Answer

The kubelet on node-3 is NotReady and cannot schedule the Service's backend Pods