Kubernetes Foundational Network Model

Mastering Kubernetes networking requires understanding how traffic flows at multiple layers from inside a single Pod all the way out to the public internet. Kubernetes intentionally abstracts away traditional networking complexities (like port mapping) in favor of a “flat” network model, but understanding the machinery beneath that abstraction is critical for advanced troubleshooting and architecture.

Let’s imagine a bustling, modern smart city.

• Pods are the houses in this city.
• Containers are the people living in those houses. People inside the same house can talk to each other easily by just speaking across the room (this is localhost communication).
• IP Addresses are the unique street addresses assigned to every single house.
• CNI (Container Network Interface) is the city’s road development authority. It lays down the roads and assigns addresses to new houses.
• Services are the local post offices or call centers. If a family moves to a new house (a Pod is recreated and gets a new IP), you don’t need to find their new address. You just call the permanent post office number (Service IP), and they route your call to the right house.
• Ingress is the city’s main reception gate that checks a visitor’s pass and directs them to the exact building based on what they are looking for.
• Network Policies are the strict security guards at each house deciding who is allowed to enter and who is not.

Kubernetes enforces three strict rules for any cluster network. These rules ensure that developers do not have to worry about port conflicts or NAT translation when deploying applications.

• Rule 1: Every Pod gets its own unique IP address across the entire cluster.
• Rule 2: Pods can communicate with all other Pods without Network Address Translation (NAT).
• Rule 3: Nodes can communicate with all Pods without NAT (and vice versa).

Key Characteristics to Remember

• “Every Pod gets its own unique, cluster-wide IP address.”
• “Containers inside the exact same Pod share the same network namespace and communicate via localhost.”
• “All Pods can communicate with all other Pods across all Nodes without needing NAT (Network Address Translation).”
• “Services provide a stable, permanent IP address to access your constantly changing (ephemeral) Pods.”
• “CNI plugins are the actual software doing the heavy lifting to wire the network together.”

Networking Concept	What it is	Primary Purpose
Container-to-Container	Communication within a single Pod	Share resources and talk directly via localhost.
Pod-to-Pod	Communication between different Pods	Direct communication using unique Pod IP addresses.
Pod-to-Service	Routing traffic to a group of Pods	Load balancing and providing a stable IP for clients.
External-to-Service	Traffic coming from outside the cluster	Accessing applications via NodePort, LoadBalancer, or Ingress.
CNI Plugin	Container Network Interface	The third-party tool that configures the network and assigns IPs.

How traffic actually flows:

• Container-to-Container: Inside a single Pod, containers share the exact same network namespace. They communicate via localhost:<port>. There is zero routing overhead here.
• Pod-to-Pod (Same Node): Traffic flows from Pod A’s virtual ethernet interface (eth0) through a virtual cable (veth pair) to the Node’s root network bridge (cbr0). The bridge sees the destination IP is local and instantly forwards it to Pod B.
• Pod-to-Pod (Different Nodes): Traffic hits the bridge, realizes the destination IP is on another building (Node), and goes out the Node’s physical eth0 interface. The network plugin ensures the routing table knows exactly which Node holds the destination Pod IP.
• Services: Because Pods die and restart frequently, their IPs change. A Service provides a stable Virtual IP (VIP). kube-proxy writes rules in the Linux kernel (iptables nat table) to intercept traffic meant for the Service VIP and silently rewrite the destination to a currently healthy Pod IP.

---

---

6. Service Discovery (CoreDNS)

Kubernetes runs an internal DNS server (typically CoreDNS). When a Service is created, CoreDNS automatically generates a DNS record for it.

• Format: service-name.namespace.svc.cluster.local
• If Pod A and Pod B are in the same namespace, Pod A can reach Pod B’s service simply by calling service-name.
• If they are in different namespaces, Pod A must use the Fully Qualified Domain Name (FQDN): service-name.target-namespace.svc.cluster.local.

---