When orchestrating multi-container applications with tools like Podman Compose or Docker Compose, understanding how containers talk to each other is crucial. This article breaks down the universal container networking model based on the Container Network Interface (CNI) specification, answering key questions about connectivity, isolation, and architecture.
1. CNI: The Universal Networking Standard
The Container Network Interface (CNI) is not a specific networking tool, but a specification (a set of rules) that defines the standard mechanism for configuring network interfaces for Linux containers.
Whether you use Podman (daemonless) or Docker (daemon-based), both adhere to CNI. This means the actual networking topology created on the host machine is functionally identical, ensuring high compatibility.
| Feature | Podman (Daemonless) | Docker (Daemon-based) |
|---|
| Network Management | Delegates tasks directly to CNI plugins; no central daemon. | Relies on a single, central daemon process for all network tasks. |
| Topology | Identical to Docker (veth pairs, virtual bridges). | Identical to Podman (veth pairs, virtual bridges). |
2. The Bridge Network Model
The most common CNI plugin used for local multi-container environments is the Bridge Plugin, which creates a private, isolated network segment on the host.
A. The Virtual Switch (Bridge)
For every user-defined network (e.g., app_network), the container runtime (Podman or Docker) creates one dedicated Virtual Bridge (a software-defined switch) on the host machine.
- This bridge isolates the network traffic. For example, traffic on
app_network never flows onto the separate public_gateway bridge.
- The bridge also manages Internal DNS, allowing containers to resolve each other by their service names (e.g., a backend container simply looks up the hostname
postgres).
B. The Virtual Cable (Veth Pair)
To connect a container to this bridge, the CNI plugin uses a Virtual Ethernet Pair (veth pair). Think of a veth pair as a virtual cable with two ends:
- Container End: Placed inside the container's isolated network namespace, appearing as a standard interface (e.g.,
eth0).
- Host End: Plugs into the Virtual Bridge on the host machine.
3. Multi-Network Connectivity: N Networks, N Interfaces
A crucial architectural point is that a single container can belong to multiple networks simultaneously. This is the foundation of network security and service segmentation.
How Multi-Networking Works (The N Principle)
If a container needs to connect to N different networks, it follows the N Principle:
- The container runtime gives that container
N separate virtual network interfaces (e.g., eth0, eth1, eth2).
- For each interface, a unique veth pair is created.
- Each of those N host-side veth ends is plugged into a separate, dedicated Virtual Bridge (one bridge for each network).
| Scenario | Inside the Container | On the Host Machine | Resulting Security |
|---|
| Private DB Network | Interface eth0 | Connects to db_network Bridge | Only containers on this bridge can see the database. |
| Public API Network | Interface eth1 | Connects to public_network Bridge | Traffic is separated and exposed via host port mapping. |
The container is now multi-homed, allowing it to send traffic based on the destination IP range: traffic meant for the database leaves via eth0, and traffic meant for an external API gateway leaves via eth1.
Communication Flow (Multiple Containers)
When multiple containers (C_1, C_2, C_3) join the same network (N_1):
- Only one Virtual Bridge (B_1) is created for N_1.
- C_1 gets a unique veth pair plugged into B_1.
- C_2 gets a unique veth pair plugged into B_1.
- C_3 gets a unique veth pair plugged into B_1.
All three containers are effectively plugged into the same private switch, allowing them to communicate freely and reliably within that isolated network segment.
This model guarantees strong network isolation, ensuring that services only communicate with necessary neighbors, which is paramount for a secure production environment.