A 911 platform observes that Endpoints already list new Pod IPs after a rollout, yet a few connections still hit old backends for a short time. What should the administrator understand?
Select an answer to reveal the explanation.
Short Explanation
The directory can update before every hallway router gets the memo — Endpoints lead, kube-proxy/dataplane follows, sometimes with a short lag.
Full Explanation
A 911 platform observing that Endpoints already list new Pod IPs after a rollout, yet a few connections still hit old backends for a short time, should understand that Service traffic follows Endpoints updates through kube-proxy or the dataplane, and brief lag between control-plane Endpoints and dataplane programming can occur. The directory can update before every node proxy gets the memo—expect short windows of stale forwarding during emergency-platform rollouts rather than assuming instantaneous global remapping.
Once Endpoints update, every in-flight TCP connection is not atomically remapped by etcd within one millisecond guaranteed. kube-scheduler does not rewrite client sockets directly, so dataplane lag cannot be dismissed as impossible. Stale backends do not always mean CoreDNS is authoritative for Pod IPs and must be restarted after every rollout.
Exam caveat: connection draining, preStop hooks, and readiness gates reduce client impact during rollouts beyond raw Endpoints timing. Operational check: during a controlled rollout, watch Endpoints versus live traffic, tune readiness/preStop, and avoid blaming DNS first when ClusterIP traffic is briefly sticky to old Pods. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.