How Kubernetes Connects Pods, Services, and the Internet – A Deep Dive

Kubernetes is designed for running distributed clusters, making networking a core component; understanding its network model enables correct operation, monitoring, and troubleshooting of applications.

All Pods can communicate with every other Pod without NAT.

All nodes can communicate with all Pods without NAT.

A Pod sees the same IP address as other Pods see.

These constraints lead to four networking challenges: container‑to‑container, pod‑to‑pod, pod‑to‑service, and internet‑to‑service.

Container‑to‑Container Network

Linux places each process in a network namespace, providing an isolated network stack with its own routing, firewall rules, and devices.

Namespaces can be created with the ip command, e.g.: $ ip netns add ns1 Namespaces appear under /var/run/netns and can be listed with ls /var/run/netns or ip netns.

By default, each process runs in the root network namespace, which provides external connectivity.

In Kubernetes, a Pod consists of multiple Docker containers sharing a network namespace, giving them the same IP address and port space. The containers join the namespace via the -net=container:sandbox-container option.

Pod‑to‑Pod Network

Each Pod has a real IP address and communicates directly with other Pods. On the same node, Pods are connected via veth pairs and a Linux bridge.

When a packet leaves pod1, it travels from eth0 to the veth pair, onto the bridge cbr0, and is forwarded to the peer veth of pod2, finally reaching pod2’s eth0. The bridge learns MAC addresses and forwards frames accordingly.

For cross‑node communication, each node is assigned a CIDR block for its Pods. Packets are routed based on the destination CIDR to the appropriate node, where the same bridge‑veth mechanism delivers them to the target Pod.

Pod‑to‑Service

Pods have mutable IPs; a Service provides a stable virtual IP (ClusterIP) that load‑balances traffic to the set of Pods backing the Service.

netfilter and iptables

Kubernetes uses Linux netfilter via iptables rules managed by kube‑proxy. When a Service’s VIP receives traffic, iptables rewrites the destination to a selected Pod IP.

IPVS

Newer clusters can use IPVS, a kernel‑level load balancer built on netfilter, offering higher scalability than iptables.

Pod‑to‑Service Communication Flow

Packets exit the Pod via eth0, traverse the bridge, hit iptables which rewrites the Service VIP to a concrete Pod IP, and are then delivered to the chosen Pod.

External‑to‑Service Traffic

Two main concerns: routing traffic from the Service to the Internet and routing inbound Internet traffic to the Service.

Outbound Traffic

In AWS VPC, nodes have private IPs; an Internet gateway with NAT translates node IPs to public IPs. Since Pods have their own IPs, iptables performs source NAT so packets appear to originate from the node, allowing the NAT gateway to handle them.

Inbound Traffic – LoadBalancer

When a Service of type LoadBalancer is created, the cloud provider provisions an external load balancer. Incoming traffic is distributed to cluster nodes, where iptables (via kube‑proxy) forwards it to the appropriate Pod.

Inbound Traffic – Ingress Controller

An Ingress runs at L7, mapping HTTP/HTTPS paths to Services. It typically uses a NodePort Service; each node forwards the Ingress port to the Service via iptables. In AWS, an ALB Ingress controller creates an Application Load Balancer, TargetGroups for each Service, and listeners that route traffic based on URL paths.

Summary

This article introduced the Kubernetes networking model and common networking tasks, providing a foundation for deeper exploration of topics such as CNI plugins, advanced routing, and cloud‑specific integrations.