A service-mesh style proxy sidecar must reach the application container without Service DNS. Why does connecting to localhost work inside the Pod?
Select an answer to reveal the explanation.
Short Explanation
Think of the Pod as one network apartment with one phone line: every container picks up on localhost. That shared network namespace is why a proxy sidecar can dial the app on 127.0.0.1.
Full Explanation
A service-mesh style proxy sidecar reaches the application container without Service DNS because containers in a Pod share a network namespace: one Pod IP, shared localhost, shared ports table. The application can call 127.0.0.1 on the proxy port, and the proxy can reach the app on localhost as well. That shared network namespace is why ambassador and mesh sidecar patterns work for city services adopting in-Pod helpers.
Each container does not receive a unique Pod IP, so localhost is not “rewritten by kube-proxy” per container. localhost does not require creating a NodePort on the same node to function inside the Pod. Kubernetes does not inject a default Ingress rule that maps localhost to every container.
Exam caveat: Shared networking and optional shared volumes are the primary co-location benefits. Process namespaces are separate unless shareProcessNamespace is enabled; do not assume shared PIDs.
Operational check: kubectl exec -c app -- wget -qO- 127.0.0.1:15000; compare the Pod IP from kubectl get pod -o wide; confirm intra-Pod traffic works with no Service object involved. In municipal environments, document the chosen pattern in the service runbook so on-call engineers apply the same kubectl checks during incidents, and keep the change tied to the application Deployment or Job rather than ad-hoc node mutation.