In this article, we will examine the idea of Kubernetes networking with the help of 10 detailed diagrams and additional context for both novice and experienced readers.
Introduction
Networking is a key topic in the Kubernetes universe. In addition to the fact that Kubernetes applications require access to resources outside the cluster to function, Kubernetes networking also allows you freedom. It promotes the usage of loosely linked service architectures.
We’ll expose you to the fundamentals of Kubernetes networking in this article. We’ll discuss how loosely coupled services may interact to build sophisticated, large-scale systems, how these services can talk to other services, and how different services can talk to our services.
Terminology Used in Networking
We need to define a few networking terminologies before we can begin to talk about Kubernetes. There are a few basic methods that one system communicates with another system in almost all networked systems.
In Figure 1, an application is communicating with Computer “A” on the left and Computer “B” on the right. Several things need to take place for that conversation to happen.
First, Computer “A” must determine the location of the program using the following two pieces of knowledge:
Hostname.
The Computer “B” has been given this unique name. We are using app.myapp.com in this instance.
Port quantity.
This particular address on Computer “B” indicates which program to communicate with on that machine. In this example, the port number is “12953.”
To locate the desired application, Computer “A” takes the hostname and performs a lookup to determine the computer’s IP address. The IP address is the address the underlying network protocols use to locate Computer “B.” It does this by contacting a service called DNS, or Domain Name System. The DNS service performs a lookup to map the hostname to the computer’s IP address. This is analogous to how a phone book is used to find a person’s name and phone number.
Once Computer “A” knows the IP address of Computer “B,” it can send a message to “B” by sending it to the IP address.
This IP address is connected with a particular network interface on computer “B.” The message is sent to a specific port on Computer “B,” allowing it to be delivered to the desired application. A network interface/port number pair is assigned to each application on the computer, ensuring that all communications arriving on a specific network interface (identified by the IP address) and a particular port number are forwarded to the intended application.
Many port numbers are standard among popular applications to make it simpler to discover the relevant program. For instance, port 80 is used by the “HTTP service,” which handles requests for online pages. The “FTP service” for file transfers uses port 21. For the “SMTP service,” port 25 is the standard port used to send emails.
There may be several network interfaces on a machine (for instance, a cell phone typically has one for WiFi networking and one for cellular networking). Additionally, they could include one or more virtual network interfaces. As a result, a single machine might be linked to multiple IP addresses.
Figure.1 Terminology Used in Networking
This is the foundation for all application-to-application and user-to-application networking on the internet today.
The Fundamental Kubernetes Cluster
When it comes to Kubernetes clusters, things get a little more intricate. Let’s take a look at the fundamental components of a Kubernetes cluster.
Containers like those created with Docker run our applications and application services. These containers are contained within a Kubernetes object known as a pod. A pod is a Kubernetes system’s smallest addressable component. A single pod contains a single container (although it can include multiple containers cooperating) and accomplishes the work of a single service instance.
In a Kubernetes-based system, many pod instances will typically run concurrently for the same application. When these pods are combined, they form a Kubernetes service. A Kubernetes service is a collection of deployed pods performing the same function. A service will distribute the workload it must perform across all of its pods. An application will typically have several instances of such a particular service running to distribute the workload and provide a higher level of availability.
Each pod in each service must be run on a computer instance. These computer instances are referred to as nodes in Kubernetes. A Kubernetes node can be a standalone server or a virtualized server instance. To increase availability, the nodes of a single service are typically distributed across multiple nodes. As a result, if a node fails and the pods on that node terminate, the service can continue to operate by distributing the workload to other pods on other nodes.
Figure 2. The Fundamental Kubernetes Cluster
A Kubernetes cluster is formed by all of the nodes running all of the pods in a Kubernetes system working together. Figure 2 depicts the components of a single cluster.
Inter-Pod Communication
We already mentioned network interfaces, but one feature of network interfaces is that they enable a single computer to divide processes into multiple network namespaces, each of which is assigned to a different ethernet interface. Namespaces are typically isolated and cannot communicate with one another without passing through the ethernet interface. Each pod in a Kubernetes cluster is assigned a unique namespace, so you must communicate with the code running in the pod via the assigned ethernet interface.
The node establishes a network tunnel between each pod and the root namespace. Pods can communicate because they all have a tunnel to the root namespace. The root namespace is also a namespace for the node.
Figure 3 shows an example of this.
The root namespace assigns a unique IP address to each pod (a unique range of IP addresses called a CIDR block). Messages sent from one pod are routed to the correct pod by the root namespace using the message’s destination IP address. This is exactly how messages are sent from one computer to another in regular networking. Messages are sent from one pod to another in this case.
When a message is sent to an IP address representing a pod on another node in a different node case, the root namespace sends the message over the typical network connecting the nodes to the node with the destination pod. The message is sent to the destination node’s root namespace, which routes it to the appropriate pod. The same model applies to communication between two pods on the same node and between two pods on different nodes.
Figure 4. Pod to pod communications across nodes
“How does the root namespace know which node to send a message to?” is an intriguing question. How does any given node know where to send a message for it to reach the correct pod? “ Each node may have hundreds of pods, each with one or more unique IP addresses (CIDR blocks), and a Kubernetes cluster may contain hundreds of nodes.”
Kubernetes ensures that each pod in the cluster has a distinct set of IP addresses, allowing each pod to be identified. The IP addresses and how to get to them are then broadcast to each node in the system using a standard network protocol known as ARP. This protocol generates a map, or route, from any given node to any other node’s IP address. Because the exact makeup of pods in the system can change frequently, this protocol dynamically creates this map, which is automatically updated continuously.
The same question arises in traditional networking: “How do you know where to send a message destined for a specific IP address?” The same ARP protocol, along with other standard routing protocols and default routes, determines how any given computer on the internet can communicate with any other computer on the internet automatically and dynamically. In addition, the ARP protocol is used in standard host-based networking. It’s dynamic, fast, scalable to a massive number of hosts, and highly stable. It has been the backbone of the internet since the 1960s.
Communication via Services
Although each pod has an IP address that allows it to be directly addressed, this model has one major flaw. Pods appear and disappear. If a pod encounters a problem, it is terminated, and a new pod is launched. New pods are created when traffic to a service increases and more instances are required to handle the traffic. Pods are essentially temporary, and so are their IP addresses. How can you send a message to a pod when the IP addresses of the pods change?
The service is the solution to that problem. A Kubernetes service is a front end for a collection of pods that perform the same functions. All pods in a system that perform the same functions are considered part of the same service. Pods are added and removed from the corresponding service as they are launched and terminated, ensuring that the service always has a list of valid pods and IP addresses.
If you need the capabilities of a pod, you now send a message to the service rather than directly to the pod. The request is then routed to one of the pods that the service knows is active. The service can load balance requests across a series of pods performing the same capability, even if those pods are located on different nodes.
The service keeps track of which pods are currently active and routes requests to the appropriate active pod. The service is associated with a fixed, assigned IP address. This IP address is typically never changed, so anyone wishing to engage a pod to perform some action can contact the service at a well-known IP address without worrying about which pod is implementing the request. Figure 5 depicts a service called “ABC” and the pods to which it is linked. In the diagram, one pod is dying, and a new pod is being created.
Figure 5 shows how a service generates a virtual address in front of changing pods.
Pod to the Service
When services are involved, the network message routing for one pod talking to another differs slightly. Figure 6 shows Pod A sending a message to Service ABC. This service in the node’s root namespace determines which pod to send the request to. It then updates the message’s IP address to include the correct IP address of the selected pod and forwards the request to that pod (Pod D in this example). The message routing from the service to the pod is the same as shown in Figure 4. If a pod is terminated and a new one is created, the new pod will receive requests sent to the service instead of the old one. The pod mapping service is entirely dynamic
Figure 6: Service-based pod-to-pod communication.
External Internet to Service
Services enable the external internet to easily access the capabilities of the pods within the cluster without having any knowledge of how the pods are laid out in the cluster. A load balancer is attached to the front end of the system facing the internet when a service is created that is designed to accept traffic from the external internet. It directs traffic to the nodes containing the service. The service then selects an appropriate node to which to send the message. As a result, an external internet request can be routed to a specific pod without the requestor knowing the address of the pod.
Figure 7. Service load balancer for external internet access
Figure 7 depicts a message being routed from the external internet (bottom of image) to the service load balancer, then to the service on a node, and finally to the destination pod.
Services for DNS and Kubernetes
The service has a publicly visible IP address for receiving traffic, we can enter it into DNS and refer to it by its hostname rather than its IP address. Figure 8 depicts the hostname “app.myapp.com,” which maps the request to the IP address of the service load balancer in charge of this service.
Figure 8: DNS allows for application discovery.
Communication between clusters
Communication between pods in two different clusters is handled similarly to communication with the outside internet. The pod sending the request queries DNS for the hostname and obtains the IP address of the service load balancer. The load balancer routes the request to one of the destination cluster’s nodes. This node routes the request to the correct pod within the destination cluster.
Large-scale Service-Oriented Applications
Using Kubernetes to build a large service-based application is an exercise in creating multiple Kubernetes services, each of which operates numerous pods. The pods are distributed across multiple nodes to ensure proper load balancing and service-level availability.
Figure 9 depicts a typical service-oriented application (top) and how Kubernetes services and pods map onto it.
Figure 9. Kubernetes services and nodes are mapped to a service-based application.
These nodes are spread across multiple nodes within the cluster, with pods for each service distributed across numerous nodes for availability. Figure 10 depicts the application as seen by pods running on nodes.
Figure 10: Node-based service-based application
This application distribution makes it easy to see why pod-to-pod communication across node boundaries via services is so important. In a Kubernetes cluster environment, Kubernetes provides the networking infrastructure for complex service-oriented architectures to exist and thrive.
Last Thoughts
This was a basic explanation of how networking works in a Kubernetes cluster. Kubernetes is very flexible regarding how it allows communication between pods within the cluster and with the internet. While the details can become technical, the high-level overview is straightforward. Kubernetes networking offers a sophisticated and adaptable model for networking in a distributed containerized environment.
Top comments (0)