How Docker and Kubernetes Networking Really Work: From Bridge to Flannel

Docker Network Modes

Docker uses a plug‑in architecture for networking and provides several built‑in drivers: bridge, host, none, overlay, macvlan, and third‑party network plugins. The driver is selected with the --network flag when running a container.

bridge : default driver; creates a network namespace, assigns an IP, and connects the container to a virtual bridge (docker0).

host : container shares the host’s network stack.

none : disables networking; only the loopback interface is available.

overlay : enables communication between multiple Docker daemons, useful for Swarm services.

macvlan : assigns a MAC address to the container so it appears as a physical device on the network.

Network plugins : third‑party plugins that can be installed from Docker Store or other vendors.

The default mode is bridge , whose architecture is illustrated below.

Building the bridge network

When Docker is installed it creates a virtual bridge named docker0 with private address ranges 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.

Running a container creates a pair of virtual Ethernet devices (veth pair). One end is placed inside the container as eth0, the other end remains on the host and is attached to docker0. The brctl show command lists these interfaces.

External access

The docker0 bridge is not reachable from outside the host, so ports must be published with -p (specific host port) or -P (random host port) when the container is started. Docker performs NAT to map the container’s listening port to the host port.

$ docker run -P {image}

$ docker run -p {hostPort}:{containerPort} {image}

Kubernetes Network Model

Kubernetes networking must solve four problems: intra‑cluster container‑to‑container, Pod‑to‑Pod, Pod‑to‑Service communication, and external‑to‑Service communication.

Each Pod receives its own IP address, making a Pod behave like a virtual host. Communication between Pods on different nodes is provided by a CNI plugin; this article uses Flannel as an example.

Pod‑to‑Pod communication inside the same node

Kubernetes creates a pause container for each Pod, assigns a unique IP, and places all containers of the Pod in the same network namespace. Containers can therefore reach each other via localhost.

Pod‑to‑Pod communication across nodes (Flannel)

Flannel is a default L3 overlay CNI. It runs a flanneld agent on each node, which obtains a subnet lease from etcd and configures a virtual interface (e.g., flannel.1). Traffic is encapsulated in VXLAN, UDP, or host‑gateway tunnels.

Flannel deployment steps

Configure the cluster network in etcd.

Assign a subnet to each node.

Start flanneld on every node; it reads the configuration from etcd and writes lease information to /run/flannel/subnet.env.

Create the virtual interface flannel.1 on each node.

Configure Docker’s bridge ( docker0) with a unique CIDR using the --bip flag.

Update the routing table so that packets can be forwarded between nodes.

$ etcdctl ls /coreos.com/network/config

$ etcdctl ls /coreos.com/network/subnets

$ etcdctl ls /coreos.com/network/subnets/{IP_range}

$ ip addr show flannel.1

$ ip addr show docker0

$ route -n

Data path for a packet

When a container sends data, the packet first reaches docker0, then is handed to flannel.1, which encapsulates it in an Ethernet frame and forwards it to the host’s eth0. The kernel may add a second encapsulation (e.g., VXLAN) before the packet traverses the physical network. On the destination node, eth0 receives the packet, flannel.1 decapsulates it, passes it to docker0, and finally the target container receives the data.