Context
A Kubernetes Service gives clients a stable destination while its backing Pods change. The Service does not search for a process by its application name. Its selector matches Pod labels, and the control plane publishes matching destinations in EndpointSlices. A running Pod can therefore sit beside a perfectly valid Service without ever becoming a destination.
Before starting, identify the namespace, Service name, expected workload, and one affected client. You need permission to read Services, Pods, and EndpointSlices. Use an approved diagnostic container only if your existing client lacks networking tools. The following commands read objects; they do not repair the configuration.
1. Compare the actual selector with Pod labels
Read the live Service rather than relying only on the deployment repository:
kubectl -n shop get service catalog -o yaml
kubectl -n shop get pods --show-labels
kubectl -n shop get pods -l app=catalog -o wide
Replace the illustrative namespace and selector with the values from your Service. A selector containing several labels requires every label to match. Also compare namespaces: a normal selector does not select Pods from a different namespace. Check the Pod template labels in the owning Deployment, because changing a Deployment's own metadata labels does not necessarily change its Pods.
2. Inspect every associated EndpointSlice
A Service may have several slices, so do not choose a single slice by a guessed name:
kubectl -n shop get endpointslices -l kubernetes.io/service-name=catalog -o yaml
Compare destination addresses with current Pod IPs. Inspect endpoint conditions and the published port. A destination can exist without being eligible for ordinary traffic. Conversely, a Service intentionally created without a selector needs a different ownership model; the standard controller does not automatically discover its backends. Determine who manages such slices before proposing changes.
3. Check the port translation separately
The Service's port is what its clients use. Its targetPort identifies the destination port, either numerically or through a named container port. Declaring containerPort does not make an application listen. Check the application's configured listener and logs, then use a permitted, harmless request from the affected client environment.
For an explicitly illustrative example, catalog exposes port 80 and targets the named port web. The new Pod template still has app=catalog, but its port is named http. Matching Pods alone cannot establish the intended named-port mapping. Align the Service reference and Pod port name in the reviewed manifests, then confirm that the resulting slice publishes the application listener.
Use the evidence to choose the correction
| Observation | Likely boundary | Next check |
|---|---|---|
| Selector returns no Pods | Labels or namespace | Compare the Pod template with the live selector |
| Slice exists with ineligible endpoints | Endpoint readiness or termination | Inspect conditions and workload events |
| Eligible addresses, unexpected port | targetPort mapping | Compare named ports and listener configuration |
| Correct slice, client still fails | Data path beyond discovery | Test the same destination from the affected client |
Avoid manually editing controller-owned EndpointSlices as a lasting repair. A controller can overwrite that edit, leaving the source problem unresolved. Correct the smallest responsible manifest, review its diff, and deploy through the normal process. Verify both the new destination list and a harmless application request; a populated slice alone does not prove useful service.
Record an operating check
Keep a compact service contract containing namespace, selector, client port, target port, and expected workload owner. During releases, compare this contract against the rendered Pod template. Monitor application request failures alongside sudden changes in eligible destinations. If endpoints disappear again, capture the Service and all slices before modifying labels, so the next investigation has a clear before-and-after record.
Explore Clouvenix containers kubernetes for implementation and operational handover.