Container Networking

Containers run isolated processes, but useful applications still need to exchange data. Container networking gives each workload a network view and connects that view to selected peers.

The central idea is simple. A container sees familiar network objects: interfaces, addresses, routes, ports, and DNS settings. The host or orchestrator builds and manages those objects outside the container.

The Linux mental model

A Linux network namespace is an isolated network stack. It has its own interfaces, routes, firewall rules, and port space.

A virtual Ethernet pair, or veth pair, acts like a cable with two ends. A common design places one end in the container's network namespace. The other end stays on the host and joins a bridge.

container process
      |
network namespace
      |
  veth pair
      |
host bridge ---- host routing and firewall ---- external network

The bridge connects endpoints on one host. Routing connects different IP networks. Network address translation can let private container addresses reach external networks through the host address.

This model is common, but it is not universal. Host networking removes the separate network boundary. Macvlan and ipvlan connect containers differently. Overlay networks carry traffic between hosts through an additional virtual network.

Four jobs that must happen

Container networking is not one mechanism. It combines four jobs:

1. Isolation: choose which network stack the workload uses.
2. Attachment: create an interface and connect it to a network.
3. Addressing and routing: assign addresses, gateways, and routes.
4. Reachability and policy: resolve names, publish services, translate addresses, and filter traffic.

The runtime may perform these jobs itself. An orchestrator may delegate them to a network plugin. The Container Network Interface, or CNI, standardizes that delegation for compatible runtimes and plugins.

Traffic paths

Always trace a packet from source to destination. Do not treat “the network” as one opaque box.

Container to container on one host

Traffic usually leaves one virtual interface, crosses a host bridge, and enters the peer's virtual interface. Both endpoints need compatible addresses and routes.

Container to an external service

Traffic follows the container's default route to a gateway. The host forwards it. A bridge network commonly applies source network address translation, so the external service sees the host address.

External client to container

Isolation does not automatically expose an application. A published port maps a host address and port to a container address and port. Firewall and translation rules implement that path.

Publishing is an access decision. Binding a service inside a container and publishing it outside are separate actions.

Container to service by name

DNS converts a service name into an address. A user-defined Docker network provides name resolution for attached containers. Orchestrators provide their own service discovery models.

Single-host and multi-host networking

A bridge can connect containers on one host. Multi-host systems also need a path between hosts.

An overlay network encapsulates workload traffic across an existing underlay network. A routed design instead advertises workload routes through the underlay. Both designs must address routing, maximum transmission unit, policy, and failure handling.

The underlay is the physical or virtual network that already connects the hosts. The overlay is the logical network built across it.

CNI and orchestration

CNI defines a configuration format and a protocol between a runtime and network plugins. The runtime creates the network namespace first. It then asks plugins to add, check, or delete an attachment.

Plugins can divide the work. One plugin may connect an interface. An IP address management plugin may return an address, gateway, and routes. Another plugin may apply port mappings.

CNI does not define application service discovery or a complete cluster network. It defines the attachment contract. The selected plugins and orchestrator supply the wider behavior.

Kubernetes gives each Pod a network namespace. Containers in the same Pod share the Pod address and port space. Cluster networking, Services, DNS, and NetworkPolicy add higher-level behavior beyond basic attachment.

Security boundaries

A network namespace separates network resources. It is not a complete security policy.

Ask these questions for every workload:

• Which peers can initiate a connection?
• Which host addresses are published?
• Does outbound traffic need unrestricted access?
• Where are firewall rules enforced?
• Can the workload change its interfaces or routes?
• Does encryption protect traffic between hosts?

Broad port publication can expose a service beyond the intended audience. Shared host networking also removes the separate container port space. Treat both as explicit design choices.

Troubleshooting by layer

Start inside the workload and move outward:

1. Is the application listening on the expected address and port?
2. Does the network namespace have the expected interface and address?
3. Is the destination local, directly connected, or reached through a route?
4. Does DNS return the intended address?
5. Can the host forward the packet?
6. Do firewall or policy rules allow it?
7. Does address translation match the intended direction?
8. For multi-host traffic, can the underlay carry the packet size and reach the remote host?

This order separates application failures from attachment, routing, name resolution, policy, and underlay failures.

When container networking fits

Use isolated container networks when workloads need repeatable attachment, controlled reachability, and replaceable addresses. Use host networking only when its reduced isolation and port coordination are acceptable.

Container networking does not repair a poor application protocol. It also does not remove normal network work. You still manage address space, routes, DNS, firewalls, observability, and capacity.

Learning path

First, learn interfaces, subnets, routing, DNS, and firewalls. Next, inspect a single-host bridge path. Then study CNI attachment and IP address management. Finally, compare overlay, routed, policy, and service-discovery designs in an orchestrator.