Understanding Docker’s Four Network Drivers and Kubernetes Flannel Networking

Docker Network Drivers

Docker provides four network drivers:

bridge – the default driver; creates a docker0 virtual bridge, assigns private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and connects each container to the bridge via a veth pair.

host – containers share the host’s network stack directly.

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

overlay – enables cross‑host container communication.

Bridge Network Details

When Docker is installed a virtual bridge named docker0 is created. You can view its configuration with ifconfig docker0 or docker network inspect bridge, which shows the subnet and gateway.

Running a container creates a pair of virtual Ethernet devices ( veth), one end placed inside the container as eth0 and the other attached to docker0. The pair forms a data channel between the container and the host.

Because the bridge is isolated from the external network, ports must be published when the container is started: docker run -P IMAGE – maps each exposed container port to a random host port. docker run -p HOST_PORT:CONTAINER_PORT IMAGE – maps a specific host port to a container port using NAT.

Kubernetes Network Communication

Kubernetes defines three basic communication scenarios:

Containers inside the same Pod share a network namespace and can reach each other via localhost. The pause container holds the shared network stack.

Pod‑to‑Pod communication: if pods reside on the same node, Docker’s bridge driver is used; if they are on different nodes, a CNI plugin such as Flannel is typically employed.

Pod‑to‑Service communication: services expose a stable virtual IP; traffic is routed to the backing pods.

All these communication paths rely on a CNI (Container Network Interface) plugin.

Kubernetes Network Plugins

Common CNI plugins include:

flannel – provides a cluster‑wide IP address space but does not implement network policies.

calico – provides IP addresses and supports network policies.

canal – combines Flannel for IP allocation with Calico for network policies.

A network policy defines how pods can communicate, enabling multi‑tenant isolation by controlling inbound and outbound traffic.

Flannel Overview

Flannel, originally created by CoreOS for Kubernetes, assigns each node a unique subnet and gives every container a globally unique virtual IP. It implements an overlay network that can encapsulate traffic using several back‑ends:

vxlan – overlay mode that encapsulates packets in VXLAN.

host‑gw – direct‑routing mode where the host acts as a gateway, using plain IP routing.

udp – a fallback for environments where VXLAN or host‑gw cannot be used.

directrouting – a variant of host‑gw that prefers direct routing when nodes share a subnet.

Flannel Deployment and Configuration

Deploy Flannel with the official manifest:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Verify the deployment: kubectl get pods -n kube-system -o wide Inspect the ConfigMap that stores the network configuration:

kubectl get configmap kube-flannel-cfg -n kube-system -o yaml

Typical net-conf.json content:

{
  "Network": "10.244.0.0/16",
  "Backend": { "Type": "vxlan" }
}

To switch the backend to directrouting, edit the ConfigMap (or the manifest) and set: "Backend": { "Type": "directrouting" } After modifying the manifest, delete the existing Flannel pods and re‑apply the manifest:

kubectl delete -f kube-flannel.yml
kubectl apply -f kube-flannel.yml

Confirm the new backend with:

kubectl get pods -n kube-system -o wide

Example Application Deployment

Deploy a sample application to test networking:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      release: canary
  template:
    metadata:
      labels:
        app: myapp
        release: canary
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        ports:
        - name: http
          containerPort: 80

Check that the pods are running: kubectl get pods -o wide Enter the pods and test connectivity:

kubectl exec -it myapp-deploy-xxxx -- /bin/sh
ping 10.244.0.6   # example pod IP

Capture traffic on the host interface to verify the data path: tcpdump -i ens160 -nn host 172.21.0.100 When using the host‑gw or directrouting backends, traffic flows over the physical host interface (e.g., ens160) instead of an overlay, improving performance. If nodes are on different subnets, Flannel falls back to the VXLAN overlay.

Performance Comparison

Both directrouting and host‑gw achieve similar performance because they use the host’s physical network.

VXLAN incurs additional encapsulation overhead but supports cross‑subnet communication.

Advantages and Limitations of Flannel

Advantages

Provides a unique IP address space for every container across the cluster.

Uses etcd to distribute subnet allocations and keep configuration consistent.

Limitations

Does not support pod‑to‑pod network isolation or network policies.