Utility Dry: Full solution for load balancing in Kubernetes

Many enterprises choose Kubernetes as their container orchestration system when deploying containers. This is a broad affirmation of the reliability, flexibility and characteristics of the kubernetes. In this article, we will take a deep look at how Kubernetes handles a very common and necessary task-load balancing. Load balancing is a relatively simple task in many non-container environments (that is, balancing between servers), but when it comes to containers, some other, special processing is required.

Manage containers

To understand kubernetes load balancing, you first need to understand how kubernetes is forming a container.

Containers are typically used to perform a particular service or set of services, so they need to be viewed according to the services they provide, rather than as a single instance of the service (that is, a single container). In fact, that's what Kubernetes did.

Put them in the pods.

In Kubernetes, Pod is a basic functional unit. A pod is a set of containers and the volumes they share (volumes). Containers are usually closely linked in terms of functionality and service.

A pods that has the same set of features is abstracted into a collection, called a service. These services accept application client access based on Kubernetes, which in turn can manage access to the containers that make up them, isolating the client from the container itself.

Management pods

Now let's take a look at some specific details.

Pods are typically created and destroyed by Kubernetes, rather than designed to be persisted entities. Each pod has its own IP address (based on the local address), UID, and port number, and the newly created pods, whether they are copies of the current pod or the previous pod, will be assigned a new UID and IP address.

Inside each pod is the ability to communicate between containers, but it cannot communicate directly with containers in different pods.

Let Kubernetes handle the transaction

Kubernetes uses its own built-in tools to manage communication with a single pod. This shows that in general, relying on kubernetes internal monitoring pods is sufficient, do not have to worry about pods creation, deletion or replication. However, it is sometimes necessary to kubernetes managed applications where at least some of the internal elements are visible to the underlying network. When this happens, the scenario must take into account what to do with the lack of a permanent IP address.

Pods and nodes (Nodes)

In many ways, kubernetes can be seen as a pod management system, just like a container management system. Most of the infrastructure is processing containers at the pod level, not at the container level.

From kubernetes Internal management, the organization level above the pod is the same as the node, which is a virtual machine that contains management and communication resources and is the environment for deploying pods. The node itself can also be created, destroyed, and replaced/redeployed internally. Their creation, destruction, redeployment, use, and expansion, both at the node level and at the pod level, are handled by internal processes called controllers.

Serves as the dispatcher's "service"

Service is the way Kubernetes handles containers and pods at the management level. But as we mentioned above, it also abstracts functional-related or identical pods into services, and Kubernetes is at the service level when other elements in the external client and application interact with the pod.

The service has a relatively stable IP address (used internally by Kubernetes). When a program needs to use a feature in the service, it makes a request to the service, not to a single pod. The service then assigns a pod to handle the request as a dispatcher.

Scheduling and load distribution

As you can see here, you might think that load balancing is going to happen at the scheduling level? That's true. The Kubernetes service is a bit like a huge pool of devices, and the same machine is fed into the specified area as needed. As part of the scheduling process, it needs to take full account of the management availability and avoid encountering resource bottlenecks.

Let Kube-proxy perform load balancing

The most basic type of load-balancing in kubernetes is actually load-distribution, which is easy to implement at the scheduling level. Kubernetes uses two methods of load distribution, both of which are performed by Kube-proxy, which manages the virtual IPs used by the service.

The default mode for Kube-proxy is iptables, which supports fairly complex rules-based IP management. In iptables mode, the local method of load allocation is randomly selected--an incoming request to randomly select a pod in a service. The Kube-proxy mode of the previous version (and the original default mode) is userspace, which uses a cyclic load distribution, assigns the next available pod to the IP list, and then replaces (or displaces) the list.

True load balancing: ingress

We mentioned two methods of load balancing before, however, these are not true load balancing. To achieve true load balancing, the current most popular, flexible, and many-domain approach is ingress, which operates through a controller in a dedicated kubernetes pod. The controller includes a ingress resource-a set of rules for managing traffic and a daemon that applies these rules.

The controller has its own built-in load balancing feature, with some fairly complex functions. You can also allow ingress resources to include more complex load balancing rules to meet load balancing capabilities and requirements for specific systems or vendors.

Using a load balancer as a substitute

In addition to ingress, you can use the Load Balancer type of service to replace it. The service uses an external load balancer based on the cloud service. Load balancers can only be used with specific cloud service providers such as AWS, Azure, OpenStack, Cloudstack, and Google Compute engine, and the functionality of the equalizer depends on the provider. Other load balancing methods can be obtained from service providers and third parties.

Overall, it is recommended ingress

The current ingress is the preferred load balancing method. Because it is executed as a pod-based controller within Kubernetes, access to the Kubernetes functionality is relatively unrestricted (unlike external load balancers, some of them may not be accessible at the pod level). The configurable rules included in the Ingress resource support very detailed and highly granular load balancing that can be tailored to the application's functional requirements for extreme operating conditions.

Utility Dry: Full solution for load balancing in Kubernetes