Contents

Kubernetes Networking

Website Visitors:

Kubernetes Networking Fundamentals

Single-Node Networking

In a single-node Kubernetes cluster, the node possesses a physical or virtual IP address (e.g., 192.168.1.2) used for administrative access via SSH. In local environments like Minikube, this address refers to the virtual machine (VM) within the hypervisor, distinct from the host machine’s IP.

Unlike Docker, where IP addresses are assigned to individual containers, Kubernetes assigns a unique internal IP address to the Pod. A Pod acts as a logical host for one or more containers.

When a cluster is initialized, a private internal network (e.g., 10.244.0.0/16) is established. Each Pod is assigned a unique IP from this range (e.g., 10.244.0.2). While Pods can communicate via these IPs, this method is unstable because Pods are ephemeral; if a Pod is deleted or recreated, its IP address changes.

Multi-Node Networking and the IP Conflict Problem

In a multi-node scenario, nodes possess distinct physical IPs (e.g., 192.168.1.2 and 192.168.1.3). If each node independently managed its own internal Pod network using the same subnet (e.g., 10.244.0.0/24), IP conflicts would occur. Two Pods on different nodes would be assigned the same IP address, making cluster-wide communication impossible.

The Kubernetes Networking Model

Kubernetes does not provide a built-in network implementation. Instead, it defines a networking model that any implementation (Container Network Interface, or CNI) must satisfy:

  1. Pod-to-Pod Communication: All Pods must be able to communicate with all other Pods across all nodes without Network Address Translation (NAT).
  2. Node-to-Pod Communication: All nodes must be able to communicate with all Pods.
  3. Pod-to-Node Communication: All Pods must be able to communicate with all nodes.

Container Network Interface (CNI) Plugins

To fulfill these requirements, Kubernetes utilizes CNI plugins. These plugins manage the allocation of unique IP addresses across the entire cluster and handle the routing between nodes.

Common CNI providers include:

  • Flannel: A simple overlay network provider.
  • Calico: Provides high-performance networking and advanced network policy enforcement.
  • Cilium: Uses eBPF for high-performance networking, security, and observability.
  • VMware NSX-T: Optimized for VMware virtualized environments.
  • Weave Net: A distributed network that connects all pods.

Once a CNI is deployed, it assigns a unique subnet to each node, ensuring no two Pods in the cluster share the same IP address. This creates a virtual flat network enabling seamless communication between all components of the cluster.

Your inbox needs more DevOps articles.

Subscribe to get our latest content by email.