A public-health team notices that application clients lose connectivity after a Deployment recreates Pods, because clients were given Pod IPs. What should the administrator explain about Pod addressing?
Select an answer to reveal the explanation.
Short Explanation
Think of a Pod IP like a hotel room number — after checkout, the next guest gets a different room. Clients should call the front desk (a Service) for a stable number, not memorize the room.
Full Explanation
A public-health team noticing that application clients lose connectivity after a Deployment recreates Pods because clients were given Pod IPs should understand that Pod IPs are ephemeral and change when Pods are recreated, so clients should reach workloads through a Service for a stable virtual IP and DNS name. Services provide a stable ClusterIP and DNS identity while Endpoints track current Pod IPs underneath—essential for resilient municipal client configuration.
Pod IPs are not permanently reserved in etcd for the life of the Deployment. kube-proxy does not assign each Pod a cluster-scoped DNS AAAA record that outlives Pod recreation without a Service. NetworkPolicy objects do not freeze Pod IPs at creation time so clients can safely hard-code those addresses.
Exam caveat: even with a Service, clients should prefer DNS names over literal ClusterIPs when possible for portability. Operational check: create a Service in front of the public-health Pods, update clients to the Service DNS name, roll the Deployment, and confirm clients keep working as Pod IPs change. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.