Tracing DNS to Pod in Kubernetes

Troubleshoot contracts, not objects

1. DNS answer
2. Load-balancer address
3. Ingress route
4. Service mapping
5. EndpointSlice backend
6. Pod network
7. Application response

The misconception occurs because Kubernetes presents each abstraction as an independently reconciled resource. Green status nearby is easy to mistake for end-to-end health. A better model treats the path as ordered contracts: the client resolves the intended address; that address reaches the correct ingress; host and path rules choose the Service; its port maps to the intended target port; the EndpointSlice selects an eligible pod; policy and the dataplane carry the connection; the TLS peer proves the expected identity; and the application answers a meaningful request.

Locate the first broken handoff

Start with declared intent and walk in request order, comparing each output with the next input. Query DNS from the same resolver context as the affected client; split-horizon zones and stale caches can make a correct answer elsewhere irrelevant. Match the answer to the advertised load-balancer address, then match ingress host, path, Service name, and port. Resolve a named targetPort against the container declaration and inspect EndpointSlices. Consider this illustrative report: these Kubernetes objects agree, but no active request or handshake was made. Calling the application healthy here would skip three untested contracts.

Example: illustrative and sanitized
Service → EndpointSlice → Pod: PASS
Ready endpoints: 1 · targetPort: 3000
Cilium agents: 5/5 ready
Observed flow: NOT COLLECTED
TLS handshake: NOT RUN
Application probe: NOT RUN
Conclusion: backend relation declared; application result unknown

Three boundaries matter most

EndpointSlice readiness means an endpoint is eligible to receive Service traffic; it is not a verdict on application correctness. A shallow readiness probe may pass while a database-backed operation fails. Likewise, a NetworkPolicy object describes intended connectivity under the cluster’s policy implementation. Static analysis can reveal selectors and apparent allowances, but it is not observed traffic; Cilium L7 conclusions require relevant Hubble flows or another runtime observation. Finally, a Certificate resource, cert-manager Ready condition, or TLS Secret proves neither what ingress serves nor what a client accepts. Full TLS proof requires connecting with the intended SNI, inspecting the served chain and hostname, checking validity and trust, and completing the negotiated handshake. Even a successful HTTP probe covers only that route, protocol, source, and moment.

Practical checks for a bounded diagnosis

• Record the client location, resolver, expected host, path, protocol, and port before interpreting cluster state.
• Walk DNS, load-balancer allocation, ingress selection, Service mapping, EndpointSlice, and pod in that order.
• Separate declared NetworkPolicy from observed flows, and state when Hubble or equivalent runtime data is absent.
• Distinguish certificate presence from the certificate actually served for the requested SNI and accepted by the client.
• Use time-limited HTTP or TLS probes deliberately, and preserve “not inspected” instead of turning missing access into success.