Understanding Kubernetes’ Core Network Model: From Pods to Policies

Kubernetes Basic Network Model

Kubernetes does not prescribe a specific network implementation, but it defines a container‑network model that any solution must satisfy. The model is built around three fundamental constraints (the “three rules”) and four design goals (the “four objectives”).

Three Core Constraints

Any two Pods must be able to communicate directly without explicit NAT.

Nodes must be able to communicate with Pods directly without address translation.

A Pod sees the same IP address as other entities; no intermediate conversion is allowed.

Four Design Goals

Define how external users reach a Service.

Explain how a Service forwards traffic to its backend Pods.

Describe Pod‑to‑Pod communication.

Detail intra‑Pod container communication.

Interpretation of the Constraints

The constraints stem from the fact that a container network sits on top of the host network. Implementations fall into two broad families:

Underlay : Uses the same IP range and network devices as the host. Pods share the host’s subnet and may require coordination with the underlying IaaS network.

Overlay : Provides an independent IP space that does not require allocation from the host network, typically using encapsulation (e.g., VXLAN) or routing tricks.

Network Namespace (Netns) Overview

A network namespace gives a process its own network stack – separate interfaces, IP addresses, routing tables, iptables, and IPVS state. Each Pod gets a unique Netns, while containers inside the same Pod share that Netns. The host’s root Netns is a special namespace with PID 1.

Pod and Netns Relationship

Each Pod owns an independent Netns; the Pod’s network container shares this namespace, and all containers in the Pod use the Pod’s IP to communicate externally. Loopback is typically used for intra‑Pod container traffic.

Typical Container Network Implementations

Several CNI projects implement the model with different trade‑offs:

Flannel : Provides multiple backends (UDP, VXLAN overlay, host‑gateway) and is widely used.

Calico : Uses BGP‑based routing and rich network policy features; requires MAC‑level connectivity.

Cilium : Combines Flannel’s simplicity with Calico’s policy engine, leveraging eBPF.

WeaveNet : Offers encrypted overlay networking for environments that need traffic confidentiality.

Flannel Details

Flannel creates a bridge on each node to connect containers to the host. Its backends include:

User‑space UDP (early implementation).

Kernel‑mode VXLAN (overlay with better performance, kernel support required).

Host‑gateway (layer‑2 broadcast routing for small, same‑LAN clusters).

Network Policy Basics

NetworkPolicy is a Kubernetes API object that lets you whitelist traffic based on pod selectors, namespaces, IP blocks, ports, and protocols. It does not implement enforcement itself; the underlying CNI must support it (e.g., Calico, Cilium).

Configuration Steps

Select the target Pods or namespaces via podSelector or namespaceSelector.

Choose the traffic direction(s) to control: ingress, egress, or both.

Define the allowed flows using selectors, IP blocks, ports, and protocols – effectively describing the five‑tuple of network traffic.

Key Takeaways

The core identifier in pod networking is the IP address; it must be consistent inside and outside the cluster.

Understanding the topology (how packets travel from container to host and beyond) is essential for performance and security.

For a generic, widely compatible solution, Flannel with VXLAN is a safe default; for environments with layer‑2 connectivity, Calico or host‑gateway Flannel may be preferable.

NetworkPolicy provides fine‑grained traffic control, but its effectiveness depends on CNI support.