Master Docker & Kubernetes Networking: From Bridge to Flannel Explained

Before discussing Kubernetes networking, let’s review Docker networking. Docker uses a plugin architecture and provides several network drivers by default: bridge, host, none, overlay, macvlan, and network plugins. The --network flag selects the driver when running a container.

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

host : uses the host’s network stack directly.

none : provides no network, only the loopback interface.

overlay : connects multiple Docker daemons for swarm services.

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

Network plugins : third‑party plugins available from Docker Store or other vendors.

By default Docker uses the bridge driver; the following diagram illustrates it.

1.1 Building a 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. The ifconfig command shows docker0 details, and docker network inspect bridge reveals its subnet and gateway.

Running a container creates a veth pair; one end (named eth0) is placed inside the container, the other remains in the host’s docker0 namespace. The brctl show command lists the veth devices.

1.2 External access

The docker0 bridge is not reachable from outside, so ports must be published with -p or -P. -P maps container ports to random host ports, while -p hostPort:containerPort maps to a specific host port.

$ docker run -P {image}

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

Kubernetes Network Model

Kubernetes networking differs from Docker and must solve four problems: communication between containers, between Pods, between Pods and Services inside the cluster, and between external applications and Services.

Container‑to‑container communication

Pod‑to‑Pod communication

Pod‑to‑Service communication

External: application‑to‑service communication.

Kubernetes assumes each Pod has its own IP, making Pods behave like physical hosts for port mapping, service discovery, load balancing, etc. This article focuses on container‑to‑container and Pod‑to‑Pod communication; see other articles for Pod‑to‑Service and external access.

2.1 Communication between containers in the same Pod

Kubernetes creates a pause container for each Pod, assigns a unique IP, and places other containers in the same network namespace (using --net=container:xxx). All containers in the Pod share the namespace and can reach each other via localhost.

2.2 Communication between containers in different Pods

Cross‑Pod communication relies on network plugins such as Flannel or Calico. Flannel, the default CNI, uses an L3 overlay where Pods on the same host share a subnet, while Pods on different hosts belong to different subnets.

Each node runs a flanneld agent that allocates a subnet and assigns IPs to Pods. Flannel stores configuration in etcd and forwards packets via VXLAN, UDP, or host‑gw backends.

2.3 Flannel operation in Kubernetes

1) Set the cluster network in etcd: $ etcdctl ls /coreos.com/network/config 2) Allocate subnets for each node:

$ etcdctl ls /coreos.com/network/subnets

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

3) Start flanneld on each node; it reads the etcd config, obtains a subnet lease, and writes details to /run/flannel/subnet.env.

$ cat /var/run/flannel/subnet.env

4) Create the virtual interface flannel.1 on the node:

$ ip addr show flannel.1

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

$ ip addr show docker0

6) Adjust the routing table so that packets can traverse nodes:

$ route -n

2.4 Data path

When a source container sends data, it first reaches the docker0 bridge, which forwards it to the flannel.1 virtual NIC. The NIC encapsulates the packet (e.g., VXLAN) and sends it out via the host’s eth0. The Ethernet header contains source and destination MAC addresses, and the IP header contains source and destination IPs. The packet traverses the physical network to the destination node, where eth0 receives it, the kernel decapsulates it, and flannel.1 passes it back to docker0, which finally delivers it to the target container.