19.5 Containers & Networking

Understanding Containers in a Networking Context

Containers change how applications run and communicate on a network. Instead of running an entire operating system for each application, containers share the host OS kernel and run isolated processes. From a networking perspective, each container can have its own network stack, addresses, and virtual interfaces, while still running on a shared host.

In practice, you rarely interact with containers directly. You use tools such as Docker or container runtimes under Kubernetes. These tools create and manage virtual network interfaces, bridges, and routing rules on the host. Even though everything runs on the same machine, containers can appear to each other as if they were on a real network.

The key idea is that container networking is mostly about how to connect three things: containers to each other, containers to the host, and containers to the external world.

Network Namespaces and Virtual Interfaces

At the heart of Linux container networking are network namespaces. A network namespace gives a process its own view of the network stack. Each namespace can have its own interfaces, IP addresses, routing table, and firewall rules. A container typically lives in its own network namespace.

To connect a container to the host, the runtime usually creates a pair of virtual Ethernet interfaces. These are often called veth pairs. They behave like a virtual cable. One end of the veth pair stays in the host network namespace and the other end is placed inside the container's namespace.

You can think of a veth pair as a tunnel between two network stacks. Whatever packet goes in one end comes out the other end. By attaching the host side of many veth pairs to a virtual switch on the host, container platforms create an internal network that connects many containers together and optionally to the outside world.

Container Network Modes

Most container engines provide several basic network modes. Each mode decides what kind of network namespace and addresses the container will use.

Common modes include bridge mode, host mode, and none mode. Overlay and other advanced models often build on these foundations.

Bridge Mode

Bridge mode is the default in many environments such as Docker. In this mode, the container gets its own network namespace and virtual interface. The host connects these interfaces to a virtual bridge, which behaves like a simple switch running on the host.

The bridge has its own IP subnet, which is usually private and separate from the host's external network. The container receives an IP address in this subnet. When containers on the same bridge talk to each other, their traffic stays inside the host on the virtual switch.

If a container wants to talk to the outside world, the host performs NAT for it. Outbound packets are rewritten so that they appear to come from the host's IP address. For inbound connections, you typically configure port mappings. A port mapping makes the host listen on a chosen port and forward that traffic to a specific container's port on the bridge network.

Host Mode

In host mode the container does not get its own separate network namespace. Instead, it shares the host network stack. The container sees the same interfaces and IP addresses that the host has. When a process in the container listens on a port, it listens directly on the host IP.

This mode simplifies some network setups and removes one level of NAT, which can reduce overhead. However, it removes the isolation that bridge mode provides. Port conflicts between containers and the host become possible, and security boundaries are weaker.

None Mode

None mode gives the container its own network namespace but with no interfaces configured other than the loopback interface. The container cannot reach anything else by default. This mode is useful when you want to fully control how the container connects, for example by attaching it manually to a custom network using your own tools.

Docker Networking Basics as an Example

Although containers are not limited to Docker, Docker is a convenient example to understand basic container networking models.

By default, Docker creates a bridge interface on the host, usually called docker0. This bridge is assigned an internal IP range, often something like 172.17.0.0/16. Every new container in bridge mode receives an IP from this range and is connected to docker0 through a veth pair.

Docker also maintains iptables rules on the host. These rules implement NAT for outbound traffic and port forwarding for inbound traffic. When you specify something like -p 8080:80, Docker arranges that packets arriving on host port 8080 are redirected to port 80 on the container's internal IP.

You can also create custom Docker networks. For example, you can create a new bridge network with its own subnet. Containers that join this network can resolve each other by container name using Docker's internal DNS, and their traffic is isolated from containers on other user-defined networks.

Container Network Isolation and Security

Container network isolation comes primarily from network namespaces, separate IP subnets, and firewall rules on the host. In bridge mode, containers are isolated from the external network and reach it through NAT. This hides their internal IP addresses and limits unsolicited inbound connections.

Security can be strengthened by controlling which containers can talk to which other containers. On a single host, this is often done with iptables or higher-level rules defined by the container runtime. You can, for instance, allow web containers to talk to database containers, but block direct access from the internet to the database containers.

However, using host mode or exposing many ports on the host can weaken isolation. A compromised container in host mode has direct access to the host network stack. For that reason, host mode is often reserved for special cases such as network tools or performance-sensitive components.

Service Discovery and Naming for Containers

Since containers can appear and disappear rapidly, IP addresses are not stable. Hard coding IPs inside application configurations becomes unreliable. Instead, container environments often use simple internal DNS to map container names or service names to IP addresses.

In basic Docker networks, containers on the same user-defined bridge can resolve each other by name. If one container pings another by its container name, Docker's embedded DNS returns the correct internal IP.

In larger container platforms, the concept of a service appears. A service is a logical name that maps to one or more container instances. Service discovery ensures that when an application calls a service name, it is automatically directed to a healthy container that implements that service. The network layer cooperates with service orchestration to maintain this mapping as containers scale up and down.

Multi‑Host Container Networking

When containers run on multiple hosts, simple local bridges are not enough. Each host may reuse the same internal subnet and container IPs, which creates conflicts if you try to connect them directly. To create a unified network across many hosts, container platforms rely on additional techniques.

One common approach is an overlay network. An overlay virtual network sits on top of an existing underlay network. The underlay is the real physical or traditional IP network between hosts. The overlay uses tunneling protocols to carry container traffic between hosts while making remote containers appear as if they are on the same local subnet.

From the container's point of view, it has an IP on a virtual network that spans the cluster. Packets to another container on a different host are encapsulated inside another packet that travels over the underlay between the two hosts. The receiving host decapsulates and delivers the packet to the destination container's veth interface.

Overlay networks hide the complexity of the underlying physical layout and allow containers to move between hosts while keeping their addresses or at least their service names stable.

Container Networking in Kubernetes

Kubernetes uses a specific network model. Within a Kubernetes cluster every pod, which is often one or more tightly coupled containers, gets its own IP address. The model assumes that any pod can communicate with any other pod using this IP address without NAT inside the cluster.

To implement this, Kubernetes relies on Container Network Interface plugins. CNI is a standard that defines how container runtimes ask networking plugins to create and delete network interfaces, assign IPs, and set up routing. When a pod starts, Kubernetes instructs the CNI plugin to attach the pod to the cluster network. The plugin creates veth pairs, configures routes, and may set up overlay tunnels between nodes.

Different CNI plugins implement the Kubernetes network model in different ways. Some use pure routing and underlay addressing, others use overlays. Regardless of the internal details, the result is that every pod has an IP, and you can address it from any other pod within the cluster.

On top of pod networking, Kubernetes introduces services. A service gets a stable virtual IP inside the cluster. Traffic sent to the service IP is load balanced to one of the pods that provide that service. The cluster DNS resolves service names to service IPs, which hides pod IP changes from clients.

Load Balancing and Ingress for Containers

Containers often run in large numbers to handle variable load. Network traffic must be distributed across many instances. In single host setups, you may rely on port mappings and local reverse proxies to send traffic to specific containers.

In orchestrated environments, load balancing happens at multiple layers. Internal service discovery balances traffic between pods that implement the same service. External traffic from clients on the internet usually first hits an ingress component or a dedicated load balancer. This component terminates connections and then forwards them to the appropriate service inside the cluster.

An ingress can apply routing rules based on hostnames and paths. For example, it can send /api traffic to one set of containers and /static traffic to another. The containers themselves see client connections as coming from an internal virtual IP, and they typically do not need to be aware of external routing.

Observability and Troubleshooting in Container Networks

Container networking can be more complex than traditional host networking because many things are virtual and hidden behind layers of abstraction. When troubleshooting, you often have to examine both the host and the container views of the network.

On the host, you can inspect virtual bridges, veth interfaces, routing tables, and firewall rules. Inside a container, you can check which interfaces it sees, what IP addresses it has, and whether it can reach expected destinations. Tools such as ping, traceroute, and various packet capture tools work inside containers as they do on normal hosts, provided that the container has the necessary capabilities.

Since overlays and orchestration are involved, logs from CNI plugins, load balancers, and control planes become important as well. Network policies or firewalls at different layers can also block traffic in ways that are not visible from a single point. For this reason, a systematic approach that checks connectivity step by step from pod to pod, then from pod to service, then from outside to ingress is often necessary in containerized environments.