Kubernetes Networking Fundamentals
Kubernetes networking is designed to solve a core
challenge: how containers, pods, nodes, and external clients communicate
reliably in a distributed cluster.
Unlike traditional virtual machine networks that rely
heavily on Network Address Translation (NAT) and complex port-mapping rules,
Kubernetes uses a flat networking model governed by a few fundamental
principles.
1. The Core Principles of the Kubernetes Network Model
The official Kubernetes networking specifications
enforce strict requirements on any cluster setup:
- The IP-per-Pod Model: Every Pod gets its own unique
IP address. You do not need to map container ports to host ports.
- No-NAT Flat Network: Pods on any node can
communicate with all other pods across the cluster without NAT
(Network Address Translation).
- Node-to-Pod Communication: Agents on a node (like the
Kubelet) can communicate with all pods on that node.
2. The Four Fundamental Networking Scenarios
Kubernetes networking addresses four distinct types of
communication:
A. Container-to-Container Networking
- How it works: Containers within the same Pod
share a single Network Namespace, meaning they share the same IP
address, network interfaces, and port space.
- Communication: They talk to each other
directly via localhost (using different ports).
B. Pod-to-Pod Networking
- How it works: Every Pod has its own unique
cluster-wide IP.
- Same Node vs. Different Nodes:
o Same Node: Traffic moves through a Linux bridge
or virtual ethernet pairs (veth).
o Different Nodes: CNI (Container Network Interface)
plugins handle cross-node routing using encapsulation (like VXLAN) or direct
routing (BGP).
C. Pod-to-Service Networking (Service Abstraction)
- Pods are ephemeral; they
frequently get created, destroyed, and replaced, causing their IP
addresses to change dynamically.
- Services solve this: A Kubernetes Service
provides a single, stable Virtual IP (ClusterIP) and a DNS name
that front-ends a changing group of backend Pods.
- kube-proxy: A daemon running on each node
that maintains network rules, routing traffic sent to a Service IP
transparently to one of the healthy backend pods via load balancing.
D. Internet-to-Service Networking (Ingress &
External Traffic)
To expose your application to the outside world,
Kubernetes offers specific mechanisms:
- NodePort: Opens a specific static port
across all cluster nodes, forwarding incoming traffic to the Service.
- LoadBalancer: Provisions an external load
balancer (usually from a cloud provider) that routes external requests
into the cluster.
- Ingress: An API object that manages
external HTTP/HTTPS traffic, enabling path-based and host-based routing,
SSL termination, and centralized traffic management under a single public
IP.
3. Core Supporting Components
- CNI (Container Network
Interface):
Kubernetes doesn't implement networking natively. Instead, it relies on
CNI plugins (e.g., Cilium, Calico, Flannel, Antrea) to configure
network interfaces, assign IPs, and manage routing.
- CoreDNS: The cluster's built-in DNS
service. It automatically creates DNS records for Services and Pods so
applications can discover each other using domain names instead of
hardcoded IPs.
- Network Policies: Firewalls for your pods. By
default, all pods can talk to all other pods (non-isolated). NetworkPolicies
allow cluster operators to define rules specifying which pods are allowed
to communicate with each other or external endpoints.