Docker networking.

Try it yourself · the unboxed version

Everything we just showed is exposed in the standard Linux tooling. From the host:

• ip netns list — Docker does not register its namespaces with the standard netns mountpoint by default, but a quick symlink (ln -s /proc/<pid>/ns/net /var/run/netns/<name>) lets you treat them like any namespace.
• ip link show — see docker0 and all the veth* interfaces.
• ip link show master docker0 — see which veths are attached to the bridge.
• iptables -t nat -L -n -v — see the MASQUERADE and DNAT rules Docker installs.
• conntrack -L — watch NAT\'d connections (install conntrack-tools).
• nsenter -t <container-pid> -n ip addr — peek inside the container\'s network namespace from the host.

User-defined networks · DNS for free

The default bridge has a famously poor feature: containers can\'t reach each other by name, only by IP. The fix is to create a user-defined network: docker network create mynet, then docker run --network mynet --name api .... Containers on a user-defined bridge get their own embedded DNS server at 127.0.0.11. ping api from another container on mynet just works — Docker maintains the name → IP mapping.

User-defined networks also isolate by default: containers on different networks can\'t reach each other unless you attach them to both. The default bridge network is more permissive (legacy reasons). Production setups always use user-defined networks.

Network modes side by side

• bridge (default). What we walked through. Container has its own netns, attached to a bridge via veth, gets NAT for outbound. Isolated, port mapping required for ingress.
• host. --network host. Container shares the host\'s netns. No NAT, no veth, no isolation. Faster (especially for high packet rates) but the container can grab any port and see all host interfaces. Useful for proxies and load balancers.
• none. --network none. Empty netns — only loopback. No network at all. Batch jobs, sandboxes.
• container:<name>. Share another container\'s netns. Sidecar pattern (Kubernetes pods are built on this: all containers in a pod share one netns).
• overlay. Multi-host. Wraps container packets in VXLAN UDP, ships them across the underlay. Used by Docker Swarm and many Kubernetes CNI plugins.
• macvlan. Container gets a unique MAC address and looks like a real device on your LAN. No NAT, full L2 visibility. Good when you need containers to appear on the same broadcast domain as other LAN hosts.

Performance · what the abstraction costs

Bridge networking adds a few microseconds of latency per packet and a few percent of CPU at moderate rates. At very high packet rates (1M+ pps) the bridge and iptables start to show — kernel CPU time for forwarding and conntrack table maintenance climbs sharply. Host networking eliminates all of it. SR-IOV (giving the container direct hardware access to a NIC virtual function) goes further still.

conntrack table size is a sneaky production issue. Default is a few hundred thousand entries. A busy reverse proxy can fill it; new connections then get dropped silently. Bumping net.netfilter.nf_conntrack_max is one of those Linux tuning knobs every SRE eventually learns about.

How Kubernetes builds on all this

A Kubernetes Pod is roughly "a group of containers sharing one network namespace." That\'s the same --network container:<name> mode Docker has. The Pod gets one IP; all containers inside share it and talk via localhost. Cross-Pod networking is the job of a CNI plugin (Calico, Cilium, Flannel, Weave, AWS VPC CNI). Most of them work by giving each Pod a routable IP from a cluster CIDR, then making sure those IPs are reachable across nodes — sometimes with overlays (VXLAN), sometimes with native routing (BGP), sometimes by piggy-backing on cloud provider VPC routes.

Services in Kubernetes (the virtual IPs that load-balance across Pods) are implemented by kube-proxy writing iptables rules — or by IPVS for high-scale clusters — that DNAT service IPs to one of the backing Pod IPs. Same mechanism as -p 8080:80, just programmatically maintained as Pods come and go.

What this simplifies

• No firewall rules. Real Docker also writes FORWARD chain rules in the filter table to permit container traffic through the bridge.
• No IPv6. Docker can do IPv6 with its own subnet and rules; the visual would double in size.
• No DNS. The embedded DNS server at 127.0.0.11 inside user-defined networks is its own little ARP-rewriting trick that needs its own diagram.
• Single host. Multi-host (overlay, macvlan, swarm) brings VXLAN headers and extra hops we didn\'t draw.
• Linux only. Docker on Mac and Windows runs the container inside a small Linux VM. The networking story we showed is happening inside that VM; another layer of port forwarding bridges to your laptop.