An open-data kubelet is still configured with an old API server VIP after a control-plane endpoint change. What is the likely result?
Select an answer to reveal the explanation.
Short Explanation
Kubelet has to phone home to the API. Point it at yesterday’s VIP and the call drops—NotReady follows.
Full Explanation
If an open-data kubelet is still configured with an old API server VIP after a control-plane endpoint change, the likely result is that the worker cannot reach the control-plane endpoint, so the node becomes or remains NotReady. Kubelet must phone home to the API—point it at yesterday’s VIP and the call drops for that municipal worker.
Pods do not schedule normally because kubelets never contact the API server—they must. The node does not always auto-rewrite kubeconfig from DNS PTR records within seconds. The failure is not limited to Ingress resources; node Ready status depends on kubelet API connectivity.
Exam caveat: update kubelet kubeconfig/server flags and any load balancer fronting the API. Certificate SANs must include the new endpoint name or IP or TLS will still fail after the VIP fix.
Operational check: on the worker, verify the configured API server URL, fix it to the new VIP/DNS name, restart kubelet, and watch the node regain Ready in the open-data cluster. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork. Prefer reversible steps and verify Ready or Bound state before closing the incident.