How Docker and Kubernetes Networking Works: 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, selectable with the --network flag.

bridge : the 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 multiple Docker daemons to communicate, supporting Swarm services and inter‑container traffic.

macvlan : assigns a MAC address to the container, allowing it to appear as a physical device on the network.

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

The default bridge mode creates a virtual bridge named docker0 with private address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

When a container starts, Docker creates a veth pair; one end is placed inside the container as eth0, the other remains on the host attached to docker0. Port mapping with -p or -P exposes container services to the external network.

$ docker run -P myimage

$ docker run -p 8080:80 myimage

Kubernetes Network Model

Kubernetes must solve four communication problems: container‑to‑container, pod‑to‑pod, pod‑to‑service within the cluster, and external application‑to‑service.

Each pod receives a unique IP, making it behave like a virtual machine; thus intra‑pod communication works without NAT.

Communication Inside a Single Pod

Kubernetes creates a pause container that holds the network namespace for the pod; all containers in the pod share this namespace and can reach each other via localhost.

Communication Between Different Pods

Inter‑pod traffic is handled by network plugins such as Flannel, which uses an L3 overlay. Flannel runs a flanneld agent on each node, allocates a subnet from etcd, and assigns IPs to pods.

Flannel Operation Steps

Configure the cluster network in etcd. $ etcdctl ls /coreos.com/network/config Allocate a subnet for each node. $ etcdctl ls /coreos.com/network/subnets Start flanneld on each node; it reads the subnet lease from etcd.

Create the virtual interface flannel.1 on the node. $ ip addr show flannel.1 Configure Docker's bridge docker0 with a unique CIDR using the --bip flag. $ ip addr show docker0 Update the routing table so that packets can be forwarded across hosts.

$ route -n

Data Flow Between Containers

When a source container sends data, it first reaches the docker0 bridge, which forwards it to flannel.1. Flannel encapsulates the packet (e.g., VXLAN) and sends it out through the host's eth0. The destination node's eth0 receives the packet, flannel decapsulates it, passes it to flannel.1, which then forwards it to the destination docker0 bridge and finally to the target container.

Source container can inspect its routing table with:

$ kubectl exec -it -p {PodID} -c {ContainerID} -- ip route

Destination node can view its routes with: $ ip route The encapsulation adds Ethernet and IP headers; after the second encapsulation the packet traverses the physical network and is finally delivered to the target container.