03 · Networking
Networking on the bridge
An address is not a working path. Check name resolution, routing destinations, and application readiness separately.
- 2-minute guide
- All field guides
The model
For a normal selector-backed Kubernetes ClusterIP Service, DNS supplies an address; the selector identifies pods; EndpointSlices describe destinations and readiness. Successful resolution does not prove that any destination can serve requests.
Running is not Ready. A failed readiness probe normally excludes a pod from traffic without restarting its container. Services configured to publish not-ready addresses are an exception.
Worked example
Three catalog pods are Running, but all show READY 0/1. Their three addresses appear in EndpointSlices with ready: false. DNS resolves correctly. There are zero ready destinations: inspect why the readiness checks fail before blaming DNS.
A refused connection and a timeout can have several causes. Empty slices call for different checks: pod existence and selector labels. A single error string cannot distinguish them.
Commands worth running
Use the caller’s namespace and substitute real workload names.
kubectl exec deployment/storefront -- nslookup catalogTest resolution from the caller’s environment, not your laptop. The pod needs nslookup installed. This tests DNS, not the entire application path.
kubectl get endpointslices \
-l kubernetes.io/service-name=catalog -o yamlRead addresses and conditions.ready. Selected but unready endpoints can remain listed; absence and unready are different observations.
kubectl describe pod catalog-exampleInspect the Ready condition, probe definition and recent events. Confirm the probe’s port and path match what the application serves.
Self-check
What would prove more than a successful DNS lookup?
Show answer
Ready destinations plus a successful real request through the Service. A direct pod request bypasses part of that path.
References
Practise it
Room availability cannot be checkedPurchases fail on the shop server