Kubernetes Service Debugging Interview Questions: Selectors, EndpointSlices, and Ports

The Pods are Ready, but requests to orders.default.svc.cluster.local:80 time out. Is the Service broken? In a Kubernetes Service debugging interview, a useful answer traces one request path: DNS name, Service address and port, selected Pods, EndpointSlices, target port, then application listener. A green Pod status is only one link in that path. The best diagnosis narrows the failing hop with commands and direct tests rather than reciting every possible Kubernetes networking issue.

Kubernetes documentation supports the platform facts below. The names, port numbers, and failure sequence are original interview exercises, not reports of a particular employer's interview. To practice a related network path, see Debug and Improve a Load Balancer.

The path and the three most useful contracts

A Service with a selector identifies Pods through their labels. Kubernetes automatically creates EndpointSlices for matching backends; consumers such as kube-proxy or other data-plane implementations use those endpoints to route traffic. The Service's port is what a client connects to. Its targetPort is the port on the selected backend Pod; it can be a number or a named container port. Those are distinct values. A selectorless Service is different: Kubernetes does not automatically create its EndpointSlices, so an operator must manage compatible endpoints. The Service concept and EndpointSlice concept document these relationships.

EndpointSlices also carry conditions including ready, serving, and terminating. For ordinary routing, a Pod that is not Ready should not be treated as a healthy target. During termination, serving and terminating permit consumers to distinguish a still-serving terminating endpoint from a normal ready one. Do not assume every proxy uses every condition identically; inspect the cluster's actual data plane when behavior differs from the simple model. The Kubernetes debugging guide recommends checking Service definition, Pods, and endpoints in that order.

The three contracts to articulate are therefore: selector matches the intended Pods, EndpointSlice contains eligible addresses, and Service port maps to the application's listening targetPort and protocol. If any link is wrong, “Pods are Running” does not establish a working Service.

Interview question 1: The Service has no endpoints. What do you check first?

Read the Service selector: kubectl get svc orders -n default -o yaml. Then list Pods with that exact selector and show their labels, readiness, namespace, and owner. A common error is a Deployment template label changed from app: orders to app: order-api while the Service selector stayed app: orders. The Pods can be healthy but no longer selected. Another possibility is the Service and Pods are in different namespaces; a normal selector does not reach across namespaces.

Next inspect EndpointSlices labeled for the Service: kubectl get endpointslices -n default -l kubernetes.io/service-name=orders -o wide. If the selector is correct but endpoint conditions show not ready, inspect readiness probes and Pod conditions. If there are no matching Pod objects at all, investigate the Deployment, namespace, labels, and rollout. If there are matching Ready Pods but no expected EndpointSlices, investigate controller state and any selectorless or manual EndpointSlice design rather than changing ports blindly.

Do not use kubectl get endpoints as your only source of truth in modern clusters. EndpointSlices are the scalable API for Service backends, and the older Endpoints view can be limited or truncated for large Services. The interview answer should identify which API the routing components actually consume in the described cluster.

Interview question 2: Endpoints exist, yet traffic fails. How do you isolate the next hop?

First compare Service port, targetPort, and protocol with the endpoint port and the process that actually listens in the container. A Service exposing TCP port 80 with targetPort: 8080 requires the backend to accept TCP on 8080 at its Pod IP. A declared containerPort is useful metadata, especially for named ports, but declaring it does not start a listener. Test from a temporary Pod in the same cluster or namespace: resolve the Service name, connect to the Service IP and port, and separately connect to one selected Pod IP and target port. The difference localizes the failure.

If direct Pod IP:targetPort fails, inspect the application bind address, listener port, Pod logs, NetworkPolicy, and whether the Pod is still actually Ready. An application bound only to 127.0.0.1 in the container will not accept traffic addressed to the Pod IP even if a local process health check passes. If Pod IP works but Service IP fails, focus on Service port/protocol, EndpointSlice membership, and the cluster's Service proxy or network data plane. If the Service name fails to resolve but its ClusterIP works, focus on DNS before blaming endpoints.

Keep the test scope bounded. A request can fail at TLS, HTTP Host header, application auth, or a downstream database after TCP connects. “Curl failed” is not the same as “the Service had no backends”; record whether name resolution, connection establishment, TLS, and HTTP response each succeeded.

A worked 80-to-8080 failure

Suppose orders has selector app: orders, port 80, and targetPort 8080. Two Pods are Ready. Their labels match. EndpointSlices show the two Pod IPs and a TCP port of 8080. A client can resolve the Service name, but an HTTP request to port 80 gets a connection failure. A direct request to one Pod IP on 8080 also fails; a request to the same Pod IP on 3000 succeeds. The new image changed its listener to 3000, while the Service remained on 8080.

Evidence	What it rules in or out	Next step
Service selector matches both Pods	Label mismatch is unlikely	Inspect endpoint conditions and ports
EndpointSlices contain two ready Pod IPs, TCP 8080	The backend list exists, but its port may be wrong	Test direct Pod IP:8080
Pod IP:8080 fails; Pod IP:3000 succeeds	Application listener moved	Correct targetPort or restore listener contract
Service name resolves	Cluster DNS name exists	Avoid spending the incident on DNS tuning

This is an original inference exercise from documented Service and EndpointSlice semantics. In a real incident, verify the protocol, TLS requirements, and NetworkPolicy before changing production YAML. A direct Pod-IP test is a diagnostic comparison; it is not a permanent substitute for Service routing.

Interview question 3: Can a Ready Pod be absent from routing?

Yes. Readiness is necessary for ordinary endpoint eligibility but is not sufficient if the Service selector does not match the Pod labels, the Pod is in another namespace, the EndpointSlice is not associated with the Service, or the routing layer has not yet observed the update. Also, “Ready” is a Kubernetes signal defined by the configured probe and conditions; an overly shallow probe can admit an application that still fails real requests.

Check the EndpointSlice's kubernetes.io/service-name label and its addresses, ports, and conditions. If the Pod has a matching selector and is Ready but does not appear as expected, look at owner/controller events and watch for a brief propagation delay. Do not invent a fixed propagation SLA from a screenshot. If the Pod is terminating, inspect terminating and serving conditions and the workload's graceful shutdown behavior; a terminating backend may be handled differently by clients or proxies.

An interviewer may ask about publishNotReadyAddresses. That Service setting changes how not-ready endpoints are published and is often used for peer discovery in stateful systems. Do not apply it casually to a user-facing HTTP Service as a way to hide a broken readiness probe. State why the service needs discovery of unready peers before changing the normal traffic model.

Interview question 4: What changes with a selectorless Service?

A Service without a selector does not automatically discover backend Pods. EndpointSlices must be managed separately and associated with the Service. This is useful when targeting non-Pod backends or a deliberately controlled set, but it changes the debugging assumption. If a selectorless Service has no endpoints, listing Pods by a selector that does not exist is wasted effort. Instead, inspect the manually managed EndpointSlice objects, their kubernetes.io/service-name association, addresses, ports, and address type.

Be careful with expectations for kubectl port-forward service/<name> or API-server proxying when no selector maps the Service to Pods. The API server does not allow these flows to arbitrary non-Pod endpoints through a selectorless Service. That security boundary is separate from whether in-cluster Service routing to configured endpoints can work. The official Service documentation describes this distinction.

If the interviewer says “the Service used to work before migration to an external database,” ask whether its endpoints were updated to the new address and whether the data-plane route is allowed. A selectorless Service is a routing abstraction, not a health checker or automatic external discovery mechanism.

Interview question 5: How do named ports and multi-container Pods affect the diagnosis?

If targetPort is a name, Kubernetes resolves that name against the selected Pod's container port declarations. This supports different numeric target ports across Pods during a rollout, provided the named port contract is maintained. But it introduces another exact-match failure mode: a renamed or omitted port name can leave the Service pointing at no usable port for that Pod. Verify the EndpointSlice port value actually produced, not only the Service YAML's string.

For a multi-container Pod, make sure the listener you intend is in the correct container and binds to an address reachable on the Pod network. All containers in a Pod share the network namespace, so they can reach each other via localhost, but the Service sends traffic to the Pod IP and target port. A sidecar can accept or intercept traffic; know which process owns the port. An HTTP proxy sidecar returning 503 is not the same as the Service having zero endpoints.

Protocol is another easy miss. TCP and UDP are not interchangeable. If a request involves gRPC, TLS, or HTTP, determine which layer failed. Use network checks to establish transport, then inspect the application protocol. This makes the debugging story shorter and more credible than listing DNS, kube-proxy, CNI, and NetworkPolicy as equally likely from the first clue.

A bounded incident answer

“I would resolve the Service name, inspect its selector and ports, then list the EndpointSlices associated with that Service. I would compare selected Pod labels and readiness to the actual endpoint addresses and conditions. If endpoints exist, I would connect to both Service IP:port and a Pod IP:targetPort from an in-cluster client. That difference tells me whether to investigate DNS, backend selection, port mapping, policy, or application listener. I would verify the repair from the original client path.”

The sentence ends with verification because a local Pod-IP success does not prove the public ingress path, TLS, or application response is fixed. Conversely, failure from an external client can be upstream of the Service. Keep the request path explicit and move one hop at a time.

Practice question	What to rehearse
Debug and Improve a Load Balancer	Isolate a routing failure from backend health.
Explain Kubernetes autoscaling and traffic routing	Connect ready replicas to actual traffic distribution.
Explain How Microservices Run and Fail on Kubernetes	Trace a service-to-service request path.
Troubleshoot CPU, latency, and DNS issues	Separate name resolution from backend response time.
Describe how you use Kubernetes	Present evidence, fix, and verification in an incident story.

For timed practice, take Debug and Improve a Load Balancer and sketch the client-to-backend hops before choosing a command. The map makes unsupported guesses obvious.

Sources and further reading

• Kubernetes: Debug Services — stepwise Service and endpoint checks.
• Kubernetes: Service — selector, port, targetPort, and selectorless semantics.
• Kubernetes: EndpointSlices — backend discovery and conditions.
• Kubernetes: DNS for Services and Pods — Service-name resolution.