Understanding how containers get network connectivity clarifies a lot of otherwise-confusing Docker and Kubernetes networking behavior — it’s all built from the same basic Linux networking primitives.
# Each container gets: # 1. Its own network namespace (isolated network stack) # 2. A veth pair connecting it to a bridge on the host # 3. An IP address on that bridge's subnet # 4. iptables NAT rules for outbound internet access and port forwarding # Inspect a running Docker container's actual network setup docker inspect <container> | grep -A 10 NetworkSettings # See the bridge and veth pairs directly on the host ip link show type bridge ip addr show docker0
Why Containers on the Same Network Can Reach Each Other by Name
Docker runs an embedded DNS server for each user-defined network, resolving container names to their internal IPs automatically — this is why http://database:5432 works from an application container without hardcoding an IP address, as long as both containers are on the same explicitly created Docker network (not the default bridge, which doesn’t provide this DNS resolution).
Port Publishing
-p 8080:80 creates an iptables NAT rule forwarding traffic from the host’s port 8080 to the container’s internal port 80 — the container itself has no idea its port is “published” at all; from its own perspective, it’s simply listening on port 80 like normal.