Concept and mechanism
A Service separates consumers from Pod changes but needs consistent backends. When it uses a selector, compare that selector with actual labels and inspect corresponding EndpointSlices. Ready Pods with different labels can leave the Service without destinations. DNS resolving a name to ClusterIP does not demonstrate those destinations exist. A short Service name is interpreted in the client’s DNS context; use a suitable qualified name across namespaces. In a cluster with domain cluster.local, database.payments.svc.cluster.local identifies the database Service in payments. Always confirm the actual domain rather than assuming every cluster uses the same one.
Guided application
Distinguish internal access from external publication. ClusterIP alone does not create an internet path; exposure should follow approved requirements and controls. NetworkPolicy requires an implementation that enforces it. When source and destination are isolated in relevant directions, source egress and destination ingress must both permit the connection. A rule on one side does not create the other. In a fictional banking release, avoid solving missing backends by opening networking or broadening selectors to test Pods. Reconstruct source, namespace, name, Service, selector, endpoints, and policies. After the declared correction, confirm the functional transaction and continued denial of unauthorized destinations.
If selector app=funds finds no Pods labeled app=funds-v2, correct the approved match and verify backends; do not first edit a managed EndpointSlice.
Common pitfalls
DNS treated as service proof; port 443 treated as publication; overly broad selectors; NetworkPolicy without enforcement; permission on only one side.
Related topics: Persistent data and proportionate access · Delivery, GitOps, and release diagnosis
Each path stage needs its own evidence and an explicit access boundary.
Reference: Services · KCNA current four-domain curriculum; edition date unconfirmed