Public-health Services stop delivering traffic to healthy pods after kube-proxy DaemonSet pods begin crash-looping on several nodes. What should administrators conclude?
Select an answer to reveal the explanation.
Short Explanation
kube-proxy is the traffic clerk that writes the local rules sending Service hits to pod IPs. If that clerk's pods crash on a node, Services on that node go nowhere even when backends are healthy.
Full Explanation
kube-proxy (or an equivalent Service dataplane agent such as some eBPF replacements) programs how Service ClusterIPs and NodePorts map to pod endpoints on each node. When its DaemonSet pods crash-loop on several nodes, those nodes stop refreshing iptables/IPVS/eBPF rules correctly, so public-health Services stop delivering traffic to otherwise healthy pods on the affected nodes. kube-proxy is not primarily a certificate renewal agent for the apiserver; treating it as only a cert helper misses its dataplane role. Crash-looping kube-proxy does not prove cluster-wide etcd quorum loss; that is a separate control-plane failure mode with API symptoms, not a required conclusion from proxy crashes. CoreDNS implements DNS, not the full Service packet path; Service routing is not “solely” CoreDNS, so calling proxy crashes cosmetic is wrong when clients connect by ClusterIP or NodePort. Exam caveat: On nodes where proxy still runs, traffic may work—partial DaemonSet failure yields partial Service breakage. Also know if the cluster replaced kube-proxy with another dataplane; the concept (node-local Service programming) remains. Operational check: kubectl -n kube-system get ds,pods for kube-proxy; read crash logs (RBAC, config, iptables/nft conflicts); restore the DaemonSet; test Service access from the previously broken civic nodes to healthy backends.