Kubernetes networking is a complex and essential part of understanding how Kubernetes clusters deploy. Besides allowing communication between containerized components, Kubernetes networking eliminates the need to map ports between containers and hosts.
This article shows the essentials of Kubernetes networking and how communication between various Kubernetes components works.
What Is Kubernetes Networking?
Kubernetes networking is the interconnection of Kubernetes components. The process allows interactive operations and communication between inner and external elements.
How Does Networking Work in Kubernetes?
Kubernetes uses a flat network structure to reduce maintenance and costs by eliminating the port mapping process between containers and hosts.
A Kubernetes network connects the following components:
- Containers are similar to lightweight virtual machines with a shared operating system and networking resources. The containers reside in pods and connect to other containers, a host, or an external network.
- A pod is the smallest deployment unit in Kubernetes. Pods group containers together and serve as wrappers, allowing containers to share storage and networking resources. Each pod receives an IP address, which the containers within the pod share.
- Nodes or worker nodes group multiple pods together. Nodes are physical or virtual machines that further combine into clusters.
Note: For a detailed overview of Kubernetes architecture, see Understanding Kubernetes Architecture With Diagrams.
When two (or more) containers reside on the same pod, the containers share a network namespace.
A hidden container called the Pause container holds the network namespace for a pod. The Pause container sets up the namespace, creating shared resources for all containers in a pod.
Due to the shared network namespace, containers in the same pod can communicate through localhost and port numbers. Each container in the same pod should have a unique communication port to avoid port conflicts.
Every pod has an IP address and network namespace. Each pod has a virtual ethernet connection, which looks like a standard
eth0 connection to the pod. The
eth0 devices connect to the virtual ethernet device on the node.
The virtual ethernet device acts as a tunnel for the pod's network inside the node. The connection on the node's side is
x represents a pod's number (
veth2, and so on).
When a pod sends a request to another pod, the request goes through the node's
eth0 interface, which tunnels to the
Next, the request needs a way to connect to the receiving pod. The element that connects the two pod networks is the network bridge (
cbr0), which resides on the node. The bridge connects all pods on a node.
When a request gets to the bridge, the pods check whether the IP address corresponds to their own, store the bridge's information, and accept the call. The bridge also forwards the confirmation of a successful request back to the original pod.
Once the request goes to the correct pod, the request resolves on the pod level.
The bridge (
cbr0) cannot resolve the request when two pods are on a different node. The communication goes up to the cluster level to establish node-to-node communication.
The process further varies on the cloud provider and networking plugins. A cluster stores a routing table with IP address ranges mapped to nodes in most cases.
The routing table checks the IP address range against mapped nodes when a bridge cannot resolve a request. The matched content maps to the adequate node, and the resolution continues on the node level.
A Kubernetes service maps a single IP address to a pod group to address the issue of a pod's changing address. The service creates a single endpoint, an immutable IP address and hostname, and forwards requests to a pod in that service.
kube-proxy process runs in every node, mapping a service's virtual IP addresses to pod IP addresses. Services enable implementing load balancing techniques and exposing a deployment for external connections.
Kubernetes clusters have a specialized service for DNS resolution. A service automatically receives a domain name in the form
<service>.<namespace>.svc.cluster.local. Exposing the service makes the cluster reachable from the outside world.
The DNS resolves the domain name request to the service's IP address. The kube-proxy process further resolves the service's IP address to a pod's IP address. Connecting and discovering a service's IP address is known as service discovery.
Note: Simplify Kubernetes network connectivity with Calico. Learn how to run Kubernetes with Calico.
Kubernetes networking addresses many communication concerns. By automating link creation between various elements, Kubernetes simplifies the overall networking model, reducing management and costs.