A Service selector is app=billing, but the Deployment Pods are labeled app=invoice. The Pods are Ready. What do you expect for Endpoints?
Select an answer to reveal the explanation.
Short Explanation
The Service is calling out “billing” and the Pods answer to “invoice”—so nobody shows up on the roster. Ready doesn’t help if the labels don’t match. Align selector and Pod labels and Endpoints will populate.
Full Explanation
Endpoints membership is driven by the Service selector matching Pod labels. If the Service selector is app=billing but Deployment Pods are labeled app=invoice, Endpoints stay empty because the selector matches no Pods—even when those Pods are Ready. The Service is calling out “billing” and the Pods answer to “invoice,” so nobody shows up on the roster. Ready status does not override a label mismatch; citizens curling the Service get connection failures or empty backends despite healthy Pods in the namespace.
Endpoints do not auto-rewrite selectors to match the Deployment name. They do not list every Ready Pod in the namespace regardless of labels. They also do not fill from the container image name when labels disagree. Label alignment between Service selector and Pod template metadata.labels is the entire selection mechanism Kubernetes uses here.
Exam caveat: a common CKAD failure mode is creating a working Deployment and then a Service with a slightly different label key or value (billing vs invoice, app vs app.kubernetes.io/name). Always diff them explicitly. Operational check: kubectl get endpoints or kubectl get endpointslice and observe empty subsets; kubectl get pods --show-labels; align the Service selector with the Pod labels (or vice versa); confirm Endpoints populate and curls to the Service succeed. Add a selector/label checklist to the municipal billing release procedure so drift is caught before citizens notice outages.