Kubernetes Networking & DNS

April 29, 2026

The short version

When your pod calls http://user-service, three things happen in sequence:

1. A DNS lookup resolves the name to a ClusterIP
2. kube-proxy intercepts traffic to that IP and picks a backend pod
3. The request lands on a pod

Pod networking: the foundation

Every pod in Kubernetes gets its own IP. Pods can talk to each other directly — no NAT, no port mapping. It’s a flat network.

The problem is that pods are ephemeral. They restart, get rescheduled, and get new IPs. Never hardcod a pod IP into your config. We don’t use pod IPs. We use Services.

Services: the stable layer

A Service gives you two things: a stable virtual IP (ClusterIP) and a stable DNS name. Even when every pod behind a service gets replaced, the Service stays the same.

user-service → 10.96.12.34 (ClusterIP)

This is what your application actually talks to.

DNS: where the name becomes an IP

Kubernetes runs CoreDNS inside the cluster. When your pod calls http://user-service, it first does a DNS lookup.

CoreDNS resolves that short name to a fully-qualified one:

user-service → user-service.<namespace>.svc.cluster.local

and returns the ClusterIP for that service.

If the request is for a different namespace, you need the full name: user-service.other-namespace.svc.cluster.local. For more details see: https://coredns.io/manual/toc/#what-is-coredns

kube-proxy: traffic routing

The ClusterIP doesn’t actually run anything. There’s no process listening on it.

Instead, kube-proxy programs iptables (or IPVS) rules on every node. When traffic hits the ClusterIP, those rules intercept it and forward it to one of the healthy pods behind the service.

When it breaks

DNS not resolving? CoreDNS might be down, or you’re calling the wrong name across namespaces.

kubectl exec -it <pod> -- nslookup user-service
kubectl logs -n kube-system -l k8s-app=kube-dns

Service exists but requests fail? Check if there are any endpoints. If this is empty, your pods aren’t matching the selector — usually a label mismatch or the pods aren’t passing their readiness probe.

kubectl get endpoints user-service

Intermittent failures? One of the pods behind the service is unhealthy. Load balancing is routing traffic to it some of the time.

Connection timeout? A NetworkPolicy is probably blocking the traffic. Check whether one exists and whether it allows the traffic you expect.

Every Kubernetes networking issue is one of:

• A DNS problem (name doesn’t resolve)
• A routing problem (no endpoints, NetworkPolicy)
• An application problem (pod is there, but broken)