A parks-api Service suddenly includes unintended Pods from a batch Job that reused the label app=parks. What should the developer change so only the API Deployment Pods receive Service traffic?
Select an answer to reveal the explanation.
Short Explanation
Labels are membership badges—if Jobs wear the same badge as the API, the Service invites them too. Narrow the selector so only the real API Pods match. Traffic-policy tweaks and ExternalName do not fix an over-broad label match.
Full Explanation
If a parks-api Service suddenly includes unintended Pods from a batch Job that reused the label app=parks, tighten the Service selector so it matches only the intended Deployment Pods—for example add tier=frontend or app.kubernetes.io/name=parks-api and ensure the Deployment Pod template carries the same labels. Coarse shared labels are how Jobs accidentally join Service Endpoints and interfere with citizen traffic. Narrow selectors restore a precise backend roster for the API.
Deleting the Service and hard-coding Pod IPs in clients is fragile and operationally hostile. Setting externalTrafficPolicy to Local does not automatically exclude Job Pods that still match the selector. Changing the Service type to ExternalName turns the object into a DNS alias to an external name and does not safely filter in-cluster Pod backends for an API Service.
Exam caveat: adopt unique recommended labels (app.kubernetes.io/name, instance, component) on Deployments and matching Service selectors from the start of a city project. Operational check: kubectl get endpoints and observe Job Pod IPs present; kubectl get pods -l app=parks --show-labels; patch the Service selector to the tighter label set; confirm Endpoints list only API Pods. Add label ownership rules to the parks namespace contributing guide so batch Jobs stop reusing API identity labels.