Understanding the Kubernetes Networking Model

Kubernetes networking enables communication between containerization components. The main advantage of this networking model is that it eliminates the need to map ports between hosts and containers. However, configuring a Kubernetes networking model is not an easy task. In this article, you will learn what Kubernetes networking is, explore common implementations, and discover key Kubernetes networking variations.

What Is Kubernetes Networking?

Kubernetes (k8s) is an open-source container orchestration platform. You can use it to automate deployments, updates, and operations of containers on-premises or in the cloud. With k8s, you can manage containerized workloads across multiple infrastructures without worrying about operating systems or environments.

Kubernetes networking is a model that k8s employs to enable communication between its components. It is based on a flat network structure and does not require you to map ports between hosts and containers. Although Kubernetes networking can be a challenge to set up, it is an essential part of any k8s operation and one that you need to understand for successful deployment.

Common Kubernetes Networking Implementations

When using Kubernetes, the platform enforces a network model that requires third-party tools to implement. There are many third-party tools you can choose from, but the three below are popular options.

Kubernetes Networking Variations

In a standard Kubernetes deployment, there are several networking variations you should be aware of. Below are the most common networking situations to know.

Container-to-Container Networking

A high-level view of networking describes a device or virtual machine communicating directly with an Ethernet device. However, in reality (at least with Linux), each process on your machine communicates inside a network namespace.

This namespace creates a logical networking stack with its own network devices, firewall rules, and routes. When you run a process, it is assigned by default to your root network namespace. This provides the process with external access.

In Kubernetes, your containers are grouped into pods, each with a shared namespace. Within this pod, all containers have the same port and IP address and port space. To communicate, containers within a pod can use localhost since all operate in the same namespace. If containers in different pods need to communicate, you are using the pod-to-pod networking process described below.

Pod-to-Pod Networking

Pod-to-pod networking can occur for pods within the same node or across nodes. Each of your nodes has a classless inter-domain routing (CIDR) block. This block is a defined set of unique IP addresses that are assigned to pods within that node. This ensures that each pod is provided a unique IP regardless of which node it is in.

When pods need to communicate, a virtual ethernet device (VED) or a veth pair is used to connect the pods. Veth pairs are coupled network interfaces that are spread across namespaces. One of the pair is assigned to the root namespace and the other to the pod namespace. Then, the VED is used as an intermediary connection between the two namespaces.

Pod-to-Service Networking

Kubernetes is designed to allow pods to be replaced dynamically, as needed. This means that pod IP addresses are not durable unless special precautions are taken, such as for stateful applications. To address this issue and ensure that communication with and between pods is maintained, Kubernetes uses services.

Kubernetes services manage pod states and enable you to track pod IP addresses over time. These services abstract pod addresses by assigning a single virtual IP (a cluster IP) to a group of pod IPs. Then, any traffic sent to the virtual IP is distributed to the associated pods.

This service IP enables pods to be created and destroyed as needed without affecting overall communications. It also enables Kubernetes services to act as in-cluster load balancers, distributing traffic as needed among associated pods.

Internet-to-Service Networking

The final networking situation that is needed for most deployments is between the Internet and services. Whether you are using Kubernetes for internal or external applications, you generally need Internet connectivity. This connectivity enables users to access your services and distributed teams to collaborate.

When setting up external access, there are two techniques you need to use — egress and ingress. These are policies that you can set up with either whitelisting or blacklisting to control traffic into and out of your network.

Egress: Egress is a process that routes traffic from your node to an outside connection. It is often accomplished via an Internet gateway attached to your virtual private cloud (VPC). This gateway uses network address translation (NAT) to map IPs between your users and the machine your node is hosted on. It cannot, however, map to the individual pods on your node. For this step, Kubernetes uses IP tables and cluster-IPs to finalize communications.

Ingress: Ingress is an opposite process to egress and involves communications from external clients to your Kubernetes services. It operates as a set of rules defining what connections are allowed and which are blocked from communicating with your services.

Conclusion

Kubernetes networking enables you to configure communication within your k8s network. It is based on a flat network structure, which eliminates the need to map ports between hosts and containers. However, to enforce this network model, you need to use third-party tools (of the open-source or paid variety), such as Flannel, Project Calico, and Weave Net.

Additionally, when configuring your Kubernetes network, you need to account for certain networking aspects, which you will not encounter in traditional networking. These include container-to-container networking, pod-to-pod networking, pod-to-service networking, and Internet-to-service networking. Be sure to plan your network well, because misconfiguration can result in vulnerabilities.