# How pod to pod communication inside cluster ?

# 🧠 Kubernetes DNS Demystified — How Pods Talk Using Names Instead of IPs

Kubernetes is known for its **powerful service discovery** mechanism. Ever wondered **how a pod like** `frontend` magically connects to `backend.default.svc.cluster.local` without knowing its IP?

Let’s break down the **role of CoreDNS**, the **resolv.conf file**, and **how Kubernetes networking makes all this possible**.

---

## 🧩 1. Every Pod Has a DNS Configuration

When a pod is created in Kubernetes, it automatically gets a file at:

```powershell
/etc/resolv.conf
```

This file looks something like:

```powershell
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
```

### 🔍 What Does This Do?

* `nameserver 10.96.0.10`: This is the **ClusterIP of the CoreDNS service** in the `kube-system` namespace.
    
* All DNS queries from the pod go through this **internal DNS server**.
    

---

## 📦 2. What is CoreDNS?

CoreDNS is Kubernetes’ **internal DNS server**. It runs as a deployment under the `kube-system` namespace and usually has 2+ pods for high availability.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1749260187809/b9db4156-9999-4ac7-b31f-7669d0fcce6a.png align="center")

You can check it with:

```powershell
kubectl get pods -n kube-system -l k8s-app=kube-dns
```

CoreDNS is backed by a ConfigMap named `coredns`, which contains its behavior settings:

```powershell
53 {
    errors
    health
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
}
```

---

## 🔗 3. How DNS Works Inside Kubernetes

Let’s say PodA wants to talk to `myapp.default.svc.cluster.local`.

Here’s what happens:

1. **PodA** checks `/etc/resolv.conf` and sends a DNS query to `10.96.0.10` (CoreDNS).
    
2. CoreDNS checks if this name exists using its **Kubernetes plugin**, which queries the Kubernetes API.
    
3. If the service `myapp` exists, CoreDNS returns its **ClusterIP**.
    
4. PodA then talks directly to that IP.
    

🔁 This makes communication **dynamic and resilient** — even if the actual pod behind `myapp` changes, DNS will always resolve the correct IP.

---

## 🌍 4. What About External Domains?

Want to `curl` [`google.com`](http://google.com) from your pod? That works too.

When CoreDNS doesn’t recognize a domain, it uses this line:

```powershell
coredns . /etc/resolv.conf
```

This means:

* Forward unknown requests to the **host node’s DNS resolver**.
    
* Typically, this is your cloud provider’s or system DNS like 8.8.8.8.
    
* So external names like [`google.com`](http://google.com) get resolved just like on a regular machine.
    

---

## 🛠️ Real-World Example

```powershell
$ kubectl exec -it mypod -- cat /etc/resolv.conf

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
```

If you `curl myapp.default.svc.cluster.local`, it goes like this:

1. DNS query → CoreDNS
    
2. CoreDNS → Kubernetes API → finds service
    
3. CoreDNS replies with IP (e.g., 10.244.1.12)
    
4. Pod connects to IP directly
    

---

## 🧠 TL;DR

| Component | Role |
| --- | --- |
| `/etc/resolv.conf` | Tells the pod where to send DNS queries |
| CoreDNS | Resolves internal service and pod names |
| Kubernetes Plugin | Lets CoreDNS query the Kubernetes API |
| Forward plugin | Forwards external queries to public DNS |

---

## 🎯 Final Thoughts

Kubernetes DNS is one of those invisible-yet-critical systems. CoreDNS, backed by the Kubernetes API, **enables microservices to communicate reliably** — even if pods move, restart, or scale dynamically.

Understanding this system helps debug networking issues and build more resilient clusters.