A frontend Deployment’s Pods are labeled app=web, but a NetworkPolicy that selects app=api only allows ingress from role=frontend. Clients still time out. What is the most likely policy cause?
Select an answer to reveal the explanation.
Short Explanation
Selectors are picky bouncers—they only wave through guests whose badges match exactly. If the allow rule looks for role=frontend but your Pods wear app=web without that role label, they never make the guest list. Fix the labels (or the selector) so the policy and the Pods agree.
Full Explanation
NetworkPolicy peer podSelectors must match the labels actually present on client Pods. When a frontend Deployment’s Pods are labeled app=web but a NetworkPolicy selecting app=api only allows ingress from role=frontend, clients time out because the allow rule’s podSelector does not match the frontend Pod labels—those clients never become permitted peers. Selectors are picky bouncers that only wave through guests whose badges match exactly.
ClusterIP Services do not ignore NetworkPolicy labels, so deleting the Service is not the fix. It is false that NetworkPolicies only evaluate namespace labels and never Pod labels on peers. Label mismatches are not confined to egress; ingress allows fail for the same reason when peer labels disagree, and same-namespace traffic is not always allowed under an isolating policy.
Exam caveat: align Deployment template labels with NetworkPolicy from/to selectors using shared conventions (for example app and tier). Operational check: kubectl get pods -l role=frontend (likely empty) versus kubectl get pods -l app=web; fix either the Pod labels or the policy selector; retest client connectivity to the api Pods. City incident checklists should include “diff policy selectors versus live Pod labels” early in NetworkPolicy outages.