Don't Panic: Container Networking

Container networking is the machinery that lets an isolated process exchange packets without accidentally acquiring the entire host as a close personal friend. A container sees an interface, an address, routes, ports, and DNS. These are ordinary network objects. The runtime or orchestrator arranges them from outside the container, which is where the interesting consequences wait.

The first useful idea is the network namespace, a separate network view with its own interfaces, routes, firewall rules, and port space. Think of it as a small, determinedly private office with a network cable. The cable is often a veth pair, two virtual Ethernet ends joined together. One end lives with the container. The other can join a host bridge, which behaves like a local switch. Suddenly the packet has somewhere to go, which is progress by the standards of packets.

The second idea is that attachment is not reachability. A bridge connects local endpoints, but traffic to another network needs a route and usually host forwarding. Traffic to an external service may also pass through network address translation, so the remote service sees the host address rather than the container address. A cross-host design adds an underlay, the existing network between hosts, and perhaps an overlay carried across it. That extra wrapping costs packet space, so the maximum transmission unit matters even when every configuration file looks polite.

The third idea is that a listening process is not automatically public. A published port creates a host address and port that lead inward to a container port. This is an access decision, not a decorative annotation. DNS is similarly useful but not magical: a correct name-to-address answer says nothing about the listener, route, policy, translation, or return path. Networking offers many ways to be half right.

The Container Network Interface, or CNI, is the attachment contract used by compatible runtimes and plugins. It can connect an interface, allocate an address, add routes, and later remove the attachment. It does not, despite the temptation of its official-sounding name, supply a complete application network. Kubernetes adds Pods, Services, DNS, and NetworkPolicy above that foundation.

Read the intro when you need the full packet path and the distinction between bridge, host, overlay, and routed designs. Use the slides for the component map. Keep the cheatsheet nearby when a connection fails, then work inside out: listener, interface, route, DNS, forwarding, policy, translation, and finally the underlay. The packet has not become mystical. It has merely collected paperwork.