Mastering Container Cloud Network Architecture: From Basics to Kubernetes

1 Container Platform Network Model

Containers have short lifecycles, high density, and rapid cluster changes, requiring a network design that supports high‑speed communication between nodes and secure multi‑tenant isolation.

Traditional physical networks cannot meet these requirements, so a new architecture has emerged, leading to two co‑existing models: Docker‑driven CNM and the CNI model used by Kubernetes.

Protocol Stack

Layer 2 (bridge, ARP+MAC)

Layer 3 (routing)

Layer 2 + Layer 3 (intra‑node L2, inter‑node L3)

Traversal Methods

Overlay (tunnel over underlying infrastructure)

Underlay (directly use underlying infrastructure)

Isolation Methods

VLAN

VXLAN

1.2 Container Network Classification

1.2.1 Protocol Stack

Layer‑2 solutions are common in traditional data centers; they suffer from broadcast storms and scale limits. Layer‑3 solutions based on BGP provide IP transparency and scalability but may be restricted by enterprise policies. A hybrid Layer‑2+3 approach combines the advantages of both.

1.2.2 Traversal Methods

Underlay networks rely on Ethernet and standard routing; they lack a global view and require each device to learn routes independently.

Overlay networks use encapsulation technologies such as VXLAN, GRE, NVGRE, or TRILL to build virtual networks on top of the physical fabric.

1.2.3 Infrastructure‑Based Isolation

VLANs separate broadcast domains at Layer 2. VXLAN extends this concept to Layer 3, supporting up to 16 million virtual networks, eliminating the 4094‑VLAN limit, and enabling multi‑tenant isolation without NAT.

1.3 Summary

Choosing a protocol stack, traversal method, and isolation technique depends on business scenarios, hardware support, and security requirements.

2 Docker Network Fundamentals and Implementation

Docker’s networking model originated from the OpenStack solution and later split into CNM (Container Network Model) and CNI (Container Network Interface) for Kubernetes.

CNM Model

CNM defines three components: Sandbox (network namespace), Endpoint (typically a veth pair), and Network (often a Linux bridge). A Sandbox can contain multiple Endpoints from different Networks.

Docker supports four network modes:

host

container

none

bridge (default)

In bridge mode each container receives an IP address and a virtual Ethernet pair that connects to the host’s bridge device.

3 Kubernetes Network Scenario Analysis

Kubernetes must handle four communication scenarios:

Container‑to‑container within the same Pod

Pod‑to‑Pod (same node and cross‑node)

Pod‑to‑Service

External‑to‑internal access

3.1 Container‑to‑Container Communication

Containers in the same Pod share a network namespace, allowing them to communicate via localhost without port conflicts.

3.2 Pod‑to‑Pod Communication

Each Pod receives a unique IP address. Same‑node Pods communicate directly through the Linux bridge; cross‑node Pods route traffic via the node’s physical NIC and the cluster’s overlay or routing layer.

3.3 Pod‑to‑Service Communication

Services expose a virtual ClusterIP and are implemented by kube‑proxy on each node, which performs load‑balancing (Round‑Robin) and optional session affinity.

3.4 External‑to‑Internal Access

Kubernetes offers NodePort and LoadBalancer Service types. NodePort opens a static port on every node; LoadBalancer provisions an external LB (cloud provider) that forwards traffic to the Service’s ClusterIP. Custom external LBs can watch Service objects via the API server and program their own forwarding rules.

4 Kubernetes Network Components

4.1 CNI (Container Network Interface)

CNI provides a lightweight plug‑in model with two commands (ADD, DEL) and no daemon. It is the de‑facto standard for Kubernetes networking.

4.2 CNI‑Supported Solutions

Flannel

Flannel assigns non‑overlapping IPs to each node and builds an overlay network (default UDP) to carry traffic between Pods.

OVS (Open vSwitch)

OVS is a virtual switch that can create GRE tunnels for L3‑to‑L3 connectivity. It requires manual configuration of bridges, GRE ports, and routing rules.

Calico

Calico implements a pure L3 solution using BGP routing; it provides network policy via iptables and integrates with service meshes such as Istio.

Summary

The article reviews container‑cloud networking fundamentals, Docker and Kubernetes network models, and compares popular CNI implementations (Flannel, OVS, Calico) to help architects select the appropriate solution for their environment.