What is a Docker Container Bridge, Host, and Overlay Network?

What is container networking?

Containerized applications have revolutionized software deployment by providing lightweight, portable, and scalable environments. However, for containers to function efficiently, they need to communicate with each other and the outside world, hence the need for container networking.

Container networking defines how containers interact within a system, whether on the same host, across different hosts, or with external services. Read on to explore various networking models, common challenges, and best practices for managing networked containers.

The basics of container networking

Containers share the host's kernel but operate in isolated environments. Networking in containers is typically implemented through network namespaces, which provide a separate network stack for each container.

Each container has its own:

• IP address (if using a dedicated network namespace)
• Network interface (virtual Ethernet interfaces)
• Routing table (determining packet flow)
• Firewall rules (via iptables or similar tools)

By default, containers rely on network bridges or other networking drivers to facilitate communication. Below are the different networking models used in containerized environments.

Bridge networking (default Docker network)

In Docker, the bridge network is the default mode. A bridge network is a private internal network that allows containers on the same host to communicate.

Here’s how it works:

• The Docker daemon creates a virtual bridge (e.g., docker0) on the host.
• Each container is assigned a virtual Ethernet interface (veth) that connects to the bridge.
• Containers can communicate with each other via their assigned IPs on the bridge network.
• The bridge uses Network Address Translation (NAT) to allow external communication.

Consider the following example of running containers on a bridge network:

docker network create my_bridge

This command creates a custom Docker network named my_bridge.

docker run -d --name container1 --network my_bridge nginx

This command runs an nginx container in detached mode (-d), assigns it the name container1, and connects it to the my_bridge network.

docker run -d --name container2 --network my_bridge alpine ping container1

This command runs an alpine container in detached mode, assigns it the name container2, and connects it to my_bridge. container2 continuously pings container1. In this setup, container2 can ping container1 using its container name because Docker provides an internal DNS resolver.

Host networking

Host networking removes network isolation and allows a container to share the host’s network stack. This mode improves performance but reduces security and flexibility. Additionally, the container does not receive a separate IP address and instead shares the host’s IP. This networking method is useful for performance-sensitive applications but is not ideal for applications requiring isolation.

Here is an example of running a container in host network mode:

docker run --network host -d nginx

Here, the Nginx container runs on the host network, meaning it listens on the host’s IP and ports.

Overlay networking (multi-host communication)

Overlay networks enable containers on different hosts to communicate securely. However, they require an orchestrator like Docker Swarm or Kubernetes for setup. These networks use a distributed key-value store (like etcd or Consul) to manage container IP mappings. Virtual Extensible LAN (VXLAN) tunnels route packets between containers on different hosts.

Using overlay networks in Docker Swarm and Kubernetes

In Docker Swarm, overlay networks allow services to communicate seamlessly across multiple nodes. Swarm manages service discovery and ensures that all nodes can reach each other securely.

In Kubernetes, overlay networks are implemented via CNI (Container Network Interface) plugins such as Flannel, Calico, and Cilium. These plugins manage cross-node communication and ensure that Pods have unique IPs across the cluster:

• Flannel (simplistic overlay networking)
• Calico (networking with security policies)
• Cilium (eBPF-based high-performance networking)

For example, here is how to create an Overlay Network in Docker Swarm.

docker network create -d overlay my_overlay

This command creates an overlay network named my_overlay.

docker service create --name web --network my_overlay nginx

This command creates a new Docker service named web, assigns it to the my_overlay network, and runs an nginx container within it.

In Kubernetes, overlay networks are set up automatically by the selected CNI plugin. For example, when using Flannel, network communication is handled via UDP encapsulation or VXLAN.

Macvlan networking (direct MAC addresses)

Macvlan networking allows containers to appear as physical devices on the network by assigning them unique MAC addresses. The containers function as separate physical devices on the network. This is useful for legacy applications requiring direct network access.

Here is how to create a Macvlan network in Docker. First, you can create a Macvlan network named my_macvlan with a subnet of 192.168.1.0/24:

docker network create -d macvlan --subnet=192.168.1.0/24 my_macvlan

Then, here is an example of running an nginx container and connecting it to the my_macvlan network so it can communicate like a traditional network device:

docker run --rm --network my_macvlan nginx

Kubernetes container networking

Kubernetes employs a more sophisticated networking model that ensures each pod has a unique IP address and can communicate with other pods seamlessly. Kubernetes follows these main networking principles:

1. All pods can communicate with each other without NAT.
2. All Nodes can communicate with all pods without NAT.
3. Containers within the same pod share the same network namespace.

Example of deploying a pod with a specific network policy:

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
  labels:
    app: web
spec:
  containers:
  - name: web
    image: nginx
  networkPolicy:
    podSelector:
      matchLabels:
        app: web

This YAML configuration deploys an nginx Pod with a network policy that restricts traffic to only selected Pods labeled as app: web. This enforces a basic network policy ensuring that only selected pods can communicate with the web-pod.

Security considerations

Container networking introduces security challenges that must be addressed to prevent vulnerabilities. For instance, it is best to use separate networks for different application tiers and implement firewall rules between containerized services.

Additionally, avoid running containers in host networking mode unless necessary and only expose required ports in Docker. For instance, -p 80:80 instead of -p 80-10000:80-10000.

Importantly, also ensure that container communication is encrypted using mutual TLS (mTLS) and leverage service mesh technologies like Istio for secure communication.

Conclusion

Container networking is a fundamental aspect of modern cloud-native applications. Whether using bridge, host, overlay, or Macvlan networks, each has trade-offs regarding performance, security, and scalability. Kubernetes networking further extends container networking by enabling seamless multi-host communication through CNIs.

By understanding these networking models and best practices, developers can build robust, secure, and scalable containerized applications.