Kubernetes Networking Guide {Definition & How to Implement}

Introduction

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.

Implementing networking with Kubernetes allows administrators to transport workloads across hybrid cloud, public cloud and private cloud infrastructures.

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.

Container-to-Container Communication

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.

Pod-to-Pod Communication

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 vethx, where x represents a pod’s number (veth1, 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 vethx interface.

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.

Node-to-Node Communication

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.

Pod-to-Service Communication

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.

The 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.

External-to-Service Communication

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.

Conclusion

Kubernetes networking addresses many communication concerns. By automating link creation between various elements, Kubernetes simplifies the overall networking model, reducing management and costs.