Quick overview
Kubernetes Networking: What You Should Know About It
When you’re working with containers, enabling communication between them can be a challenge. But a good understanding of Kubernetes networking will help.
The popularity of containers in software development is continuously growing, and the reasons behind this trend are absolutely clear. These packages of software contain all the required elements to run in any environment. Thanks to their ability to virtualize the operating system, they can quickly and reliably run anywhere, including but not limited to personal laptops, the public cloud, and data centers. But how can containers communicate with each other, or external services be possible? This is already a question of networking.
As the most popular open-source container orchestration platform, Kubernetes (K8s) takes center stage in this article. We’ll delve into its Network Model and explore its key elements and capacities.
Cluster Networking
Before diving deeper into this topic, let us share some general information about Kubernetes networking. If you are going to work with containers, it will be vital to know some basic principles that Kubernetes networks are based on.
- Pods are the smallest unit in the Kubernetes object model that can be created or deployed. And every pod has its unique IP address within a cluster.
- All pods communicate with each other seamlessly, without the need for additional network configurations. Even when your pods are deployed to different nodes, the Kubernetes networking model ensures their communication, making the process straightforward and reassuring.
- All nodes also can communicate with each other. Even if there are several nodes in one cluster, the possibility of their communication via the network is guaranteed.
- The container runtime conducts container execution and container image management on nodes. It is also responsible for implementing the network model on each node.
Networking should be viewed as a central part of Kubernetes because it facilitates communication between various components within the entire ecosystem. In other words, with it, you can make different entity types within Kubernetes interact with one another. Nevertheless, the infrastructure of Kubernetes is very separated by its nature. Its components are distinct. In this context, one of the key tasks is to build a plan for seamless communication between them.
Here, it is vital to talk about different levels of this communication:
- Container-to-container communication;
- Pod-to-pod communication;
- Pod-to-service communication;
- External-to-service communication.
Container-to-Container Networking
This type of communication is performed via the pod network namespaces. Thanks to them, separate network interfaces and routing tables are possible. They will operate independently and in isolation from the other system elements.
In Kubernetes, each pod is assigned its IP address. This means all containers within the same pod can be accessed using this shared pod IP.
Furthermore, containers within the same pod can communicate using localhost. This design facilitates seamless communication between containers of the same logical unit or application.
Pod-to-Pod Networking
The main difference between this type of networking and the previously discussed one is that real IPs will be used in pod-to-pod communication. In such a situation, it won’t matter whether the second pod is deployed in a different node in the cluster of the same one.
When pod 1 communicates with pod 2, the traffic from the pod network namespace should flow to the Root network namespace. Here’s a simplified explanation of how this process is organized:
- Each pod in Kubernetes has its network namespace and virtual ethernet pair (veth pair). One end of the pair resides in the pod’s network namespace (eth0), and the other resides in the root network namespace (veth0 for Pod 1 in this case).
- The root end of the veth pair is connected to a virtual bridge on the node.
- When Pod 1 wants to communicate with Pod 2, it sends traffic to its eth0 interface.
- Then, traffic flows to the virtual bridge, which is connected to the root end of Pod 2’s veth pair (veth1 in this case).
- The traffic is then forwarded to Pod 2’s network namespace via its veth pair, using the Address Resolution Protocol (ARP).
- Finally, the traffic reaches its destination: Pod 2’s eth0 interface.
This process ensures network isolation between pods while still allowing them to communicate with each other. However, the exact details can vary depending on the network plugin used in the Kubernetes cluster.
When you need to establish communication between pods from different nodes, the process is similar to when pods are located in the same node.
Pod-to-Service Networking
When it is required, the size of pods can easily change, and if a node fails or an app crashes, it will be possible to re-create previously existing pods. Kubernetes addresses this with services, providing a flexible and adaptable solution to these challenges.
Thanks to the service function, you can group your pods using a common access policy. As a result, you can get a consistent IP address (also known as a cluster IP) that other pods or systems can use to communicate with the pods behind the service.
Moreover, with services, the traffic sent to one virtual IP address will be load-balanced, and all changes of pods’ IPs will be tracked.
Even if the IP address of the pod to which the client needs to connect has changed, the client may not even know because the connection will be organized via the static virtual address assigned by the service.
First, traffic will go to the virtual bridge. But the differences begin when the bridge discovers that the node doesn’t have the necessary IP addresses. This traffic will be sent to the external interface in such a situation.
Then, the network will respond with information about the node where the necessary IP address is available. Consequently, the traffic will flow to the interface of the respective node and then will be moved to the required pod via the virtual bridge.
External-to-Service Communication
In many scenarios, you may need to expose your application running on Kubernetes to systems or users outside your cluster. For this purpose, Kubernetes provides several mechanisms for external-to-service communication.
While considering this aspect, it is essential to highlight that in Kubernetes, there are different types of services: Cluster IP, NodePort, LoadBalancer, and ExternalName. Each type serves a specific purpose and use case.
The Cluster IP type is not interesting to us in this context. It provides a single, stable IP address that allows for communication between different pods within the entire cluster. However, by default, a cluster IP is only accessible within the cluster.
Other types of services or resources are typically used for external communication. NodePort exposes a service on each Node’s IP at a static port. LoadBalancer exposes the service externally using a cloud provider’s load balancer. ExternalName maps the service to the contents of the externalName field by returning a CNAME record.
Let’s take a closer look at one of the methods for external communication in Kubernetes, such as the NodePort service.
When you create a service, a particular port for it is reserved on every node of your cluster. Your app will be visible to external users unless there are specific restrictions. Users who need the IP address can communicate with particular ports and get their responses.
This is why, when we need to handle external traffic, we often create a service of the NodePort type. The communication process is similar to the previous cases. We will connect to a specific node, and the service will either connect us to the necessary pod via the reserved port or will load balance our traffic to a pod on another node.
However, NodePort is just one of the options available for external communication in Kubernetes. Let’s explore some other alternatives.
- A LoadBalancer service in Kubernetes automatically provisions a load balancer from your cloud provider, if supported, to route external traffic to the service’s backend pods. The cloud provider typically determines the specific load-balancing strategy.
- The ExternalName service type in Kubernetes maps a service to a DNS name, providing a mechanism to point a service to an external service outside the cluster.
- Another alternative for managing external access to a Kubernetes cluster is using an API object known as Ingress. An Ingress provides routing rules governing how your services’ external access is configured. By providing a single point of entry into the cluster, an Ingress simplifies application management and makes troubleshooting routing issues more accessible.
Final Word
As you can see, networking in Kubernetes is similar to networking in the real world. Though it is simple, it requires a good understanding of its basic concepts and the technologies that can be used.
In this article, we have covered the most general information on this topic that can serve as a great starting point for delving deeper into the intricacies of Kubernetes networking.
Thanks for reading!
👏 Clap if you enjoyed reading and follow us for more 👉