How Container Networking Works
AdvancedContainer networking gives each container its own network identity while letting containers talk to each other, the host, and the outside world. It builds on Linux network namespaces — each container gets its own isolated network stack — connected by virtual interfaces to a bridge on the host. On a single host, a bridge network handles this; across many hosts, an overlay network makes containers appear on one flat virtual network. Kubernetes standardises all of it through the CNI plugin model.
Think of an office building phone system
Each office (container) has its own phone with its own extension (network namespace and IP). Inside the building, a switchboard (the bridge) connects any office to any other. To call outside, calls route through the front desk, which maps the building main number to your extension (port mapping/NAT). For a company across several buildings, a private network links them so everyone can dial internal extensions directly (an overlay network) as if in one building.
Step by Step
Key Concepts
Network Namespace
The Linux feature giving each container its own isolated network stack — interfaces, IP, routes, and ports — so containers do not clash and are separated from the host.
Bridge Network
A virtual switch on the host that connects containers on the same machine. The default Docker network; containers attached to it can reach each other by IP.
Overlay Network
A virtual network spanning multiple hosts by encapsulating container traffic, so containers on different machines communicate as if on one flat network — essential for clusters.
CNI (Container Network Interface)
The Kubernetes standard for pluggable networking. CNI plugins (Calico, Cilium, Flannel) implement the pod network, giving every pod a routable IP and enforcing network policy.
Key Facts
- Every container has its own IP via a network namespace; a veth pair plus a host bridge is what lets them talk on a single machine.
- The Kubernetes networking model demands each pod gets a unique IP reachable by all other pods without NAT — a flat network that CNI plugins provide.
- Overlay networks (VXLAN and similar) are the standard way to connect containers across hosts, trading a little encapsulation overhead for a simple flat address space.
Real-World Applications
Microservices on one flat network
In a Kubernetes cluster, a CNI plugin gives every pod a routable IP so services call each other directly by IP or DNS name, regardless of which node they land on.
Exposing a container locally
Running a database in Docker, you map host port 5432 to the container 5432 so your app on the host connects as if the database were local, while the container keeps its private IP.
Frequently Asked Questions
How do containers get their own IP addresses?
Each container is placed in its own Linux network namespace, which provides an isolated network stack with its own interfaces, IP address, routing table, and ports. A virtual ethernet (veth) pair connects that namespace to a bridge on the host, so the container has a private IP and can communicate with other containers and the host through the bridge.
What is a Docker bridge network?
A bridge network is the default Docker network on a single host — essentially a virtual switch. Containers attached to it each get an IP on that bridge and can reach each other directly. To reach a container from outside the host, you publish (map) a host port to a container port, and the host performs NAT to forward external traffic into the container.
What is an overlay network in containers?
An overlay network lets containers running on different physical hosts communicate as if they were on a single flat network. It works by encapsulating container traffic (commonly using VXLAN) so it can traverse the underlying host network transparently. Overlays are what make multi-host container clusters practical, since containers can address each other directly regardless of which machine they run on.
How does networking work in Kubernetes?
Kubernetes defines a networking model where every pod gets its own unique IP and can reach every other pod directly without NAT — a flat network. This is implemented by CNI (Container Network Interface) plugins such as Calico, Cilium, or Flannel, which handle pod IP allocation and routing, and often network policy enforcement. On top of that, Kubernetes Services provide stable virtual IPs and load balancing across the pods behind them.