☸️ How /etc/resolv.conf Works in Kubernetes
How This Works in Kubernetes
Now that we understand /etc/resolv.conf on a laptop, let’s see how the same concept works inside Kubernetes.
Even inside a Kubernetes Pod, the system still uses
/etc/resolv.conf.
But instead of pointing to Google DNS or your router, it points to an internal DNS service.
Example Inside a Pod
Run this inside a Pod:
kubectl exec -it <pod> -- cat /etc/resolv.conf
You might see:
nameserver 1xx.xx.0.10 search default.svc.cluster.local svc.cluster.local cluster.local options ndots:5
What Changed?
- nameserver → now points to CoreDNS
- search → helps resolve internal service names
What is CoreDNS?
CoreDNS is the DNS server inside Kubernetes.
It knows how to resolve service names like
---
user-service.
Real Example in Kubernetes
App inside Pod
↓
Checks /etc/resolv.conf
↓
Finds nameserver (CoreDNS)
↓
Asks: "What is user-service?"
↓
CoreDNS responds:
user-service.default.svc.cluster.local → 10.x.x.x
↓
App connects to that IP
What is the "search" field?
The search field helps resolve short names automatically.
user-service
Kubernetes expands it to:
user-service.default.svc.cluster.local user-service.svc.cluster.local
This is why you can use short names like
user-service inside Kubernetes.
Why This Matters
- App cannot find services ❌
- Database connections fail ❌
- Health checks fail ❌
- Rollouts fail ❌
Connecting to Real Issues
Errors like:
connection refused connection reset by peer
can sometimes happen if DNS resolution is delayed or failing during startup.
Even small DNS delays can make a healthy app look "not ready" to Kubernetes.
Final Takeaway
Laptop → asks external DNS
Kubernetes Pod → asks CoreDNS
Same concept, different DNS server.
Kubernetes Pod → asks CoreDNS
Same concept, different DNS server.