Kubernetes Service discovery: selectors, endpoints, and DNS

Operational decision

A receipt gateway calls the receipt-api Service in the accounting namespace. Verify the Service selector, Pod labels, EndpointSlices, target port, and readiness state in that order. A single label typo can create a Service with no endpoints while all Pods remain healthy. Cross-namespace clients should use a qualified service name rather than relying on a search path that may change. The manifest below maps port 80 to a named container port, making the port contract visible. It is a Service fragment that still needs a matching Deployment with a port named http. Test a rolling update while watching endpoint membership; the service should route only to ready replicas. If DNS succeeds but requests time out, inspect network policy and application listeners before changing DNS.

apiVersion: v1
kind: Service
metadata:
  name: receipt-api
  namespace: accounting
spec:
  selector: {app: receipt-api}
  ports:
    - name: http
      port: 80
      targetPort: http

Cost and verification

DNS caching and endpoint changes can delay the view seen by clients, but repeatedly bypassing the Service to use Pod IPs makes normal replacement brittle. Large endpoint sets consume control-plane resources; EndpointSlices are the current scaling mechanism. The Service does not authenticate a caller or enforce application authorization. Keep network policy and workload identity separate. When testing from a Pod, use a disposable diagnostic Pod with narrow permissions and remove it after the incident.

Common Mistakes

• Do not call a resolved Service healthy when it has no ready endpoints.
• Do not rely on Pod IPs as durable client addresses.
• Do not mistake a Service selector for an access-control policy.

Connected lessons

• DevOps: delivery, infrastructure, and reliable operations
• Kubernetes probes: startup, readiness, and liveness
• Kubernetes NetworkPolicy: permit only required flows
• DNS, TLS, and reverse-proxy failure boundaries

Advanced follow-up

• Gateway API routing: accepted route versus working request

Advanced follow-up

• Dual-stack rollout: prove IPv4 and IPv6 reach the same service contract