Mastering Docker and Kubernetes Networking: From Bridge to Flannel

Docker Network Modes

Before discussing Kubernetes networking, Docker uses a plug‑in architecture that provides several network drivers: bridge, host, none, overlay, macvlan, and third‑party network plugins. Containers can select a driver with the --network flag.

bridge : The default driver creates a network namespace and IP for each container and connects it to a virtual bridge (docker0). If no driver is specified, this one is used.

host : Uses the host’s network stack directly.

none : No network is created; the container only has a loopback interface (127.0.0.1).

overlay : Enables multiple Docker daemons to connect and communicate across Swarm services.

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

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

The default bridge driver 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).

1.1 Building the Bridge Network

When Docker is installed, it creates a virtual bridge docker0. The bridge can be inspected with ifconfig or docker network inspect bridge to view its subnet and gateway.

When a container starts, Docker creates a pair of virtual Ethernet devices (veth pair). One end (named eth0 ) is placed inside the container, the other end is attached to docker0 on the host.

1.2 External Access

Because docker0 is internal, external traffic must be mapped to host ports using -p or -P. Docker performs NAT to bind container ports to host ports.

$ docker run -P {image}

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

Kubernetes Network Modes

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

Container‑to‑container communication

Pod‑to‑pod communication

Pod‑to‑service communication

External application‑to‑service communication

Kubernetes assumes each Pod has a unique IP address, making Pods behave like physical hosts for port mapping, service discovery, load balancing, and migration.

2.1 Communication Within the Same Pod

When a Pod is created, Kubernetes first launches a pause container that reserves a network namespace and IP. All other containers in the same Pod share this namespace, allowing them to communicate via localhost.

2.2 Communication Between Different Pods

Cross‑Pod communication is handled by network plugins such as Flannel or Calico. Flannel, the default CNI, uses an L3 overlay model where each node receives a subnet and Pods on different nodes belong to different subnets.

2.3 Flannel Operation in Kubernetes

1) Set up the cluster network in etcd: $ etcdctl ls /coreos.com/network/config 2) Allocate a subnet for each node based on the etcd configuration.

Retrieve Subnet List

$ etcdctl ls /coreos.com/network/subnets

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

3) Start flanneld on each node; it reads the subnet lease from etcd.

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

$ ip addr show flannel.1

5) Create the Docker bridge docker0 with a unique CIDR across the cluster (using the --bip flag).

$ ip addr show docker0

6) Modify the routing table so that packets can traverse nodes.

$ route -n

2.4 Data Transfer Process

Source container sends data to docker0, which forwards it to flannel.1. Flannel encapsulates the packet (VXLAN/UDP) and sends it out via the host’s eth0. The destination node’s eth0 receives the packet, flannel decapsulates it, passes it to flannel.1, which forwards it to docker0, and finally to the target container.

Key header information includes MAC addresses of the virtual interfaces and IP addresses of the host nodes.