LoadBalancing

Load balancing can mitigate many failure issues, but also allows your application to scale well. Good load balancing ensures that all pods are running efficiently. Without load balancing, some pods will be overworked, while others sit idle.

Deployment and ReplicaSet

• You can use a deployment to scale out the ReplicaSet.

• A ReplicaSet ensures that a set number of pods exist in the cluster.

• Replicas can also be used with Horizontal Pod Autoscaling to dynamically scale the number of pods based on the cluster resources.

Although Replicas do not in themselves load-balance, they allow for ease in scaling pods. They are a prerequisite for load balancing. ReplicaSets can create other ReplicaSets, but are easier to manage when they are configured through a deployment. A ReplicationController is another alternative to managing replicas, but the preferred method is using deployments.

When pods are deployed, the API server chooses the node to deploy based on the node resources. Combined with replicas, this approach tries to evenly distribute the replicas between the nodes. The deployment also ensures that when a node is unavailable, another replica can be run on a different node.

Replicas can also be used with Horizontal Pod Autoscaling. This approach allows pods to dynamically scale with the cluster resources.

DaemonSets

• DaemonSets are built for daemons that do not require scale, but must exist on each node.

• The Prometheus node exporter is an example of a DaemonSet—others are Logstash or Fluentd.

• The DaemonSet ensures that a pod exists on every node in the cluster.

Similar to ReplicaSets, DaemonSets are built to scale, but provide a slightly different purpose. If the scale is for high availability rather than compute resources, or if the pod is required on every node, then a DaemonSet is the right tool for the job. A DaemonSet ensures that there is one pod on every node of the cluster. Applications like the Prometheus node exporter, Logstash or Fluentd must be on every node.

This approach does not ensure that a minimum number of pods exist in the cluster. Its only job is to ensure that the configured pod exists on each node in the cluster.

Ingress

• Ingress allows advanced routing and load balancing.

• Ingress controllers offer basic to advanced load-balancing techniques.

• Nginx provides load distribution and load balancing in its ingress controller.

• The F5 Big-IP controller maps pods to their external Big-IP load balancer.

Ingress allows advanced routing and load-balancing functionality. Ingress works on an ingress controller, and the ingress controller implements load balancing.

Nginx is a common ingress controller and offers load distribution and load balancing. Another popular ingress controller is the F5 Big-IP controller. Although the ingress controller does not do the load balancing itself, it sends the pod information to the Big-IP load balancer, which sits outside the Kubernetes cluster.

High Availability

• Kubernetes can be set up to run multiple control plane nodes per cluster. These servers are also known as API servers.

• Kubernetes can use an etcd cluster.

High availability is another type of load balancing. Kubernetes is built on the idea of high availability with deployments using ReplicaSets and multinode clusters. When using kubeadm to bring up a Kubernetes cluster, it creates one instance of API server, etcd, scheduler, controller manager, and cluster autoscaler.

The goal of high availability is to allow one of the control planes to fail, but have the others pick up its load and continue. Running this configuration is very complex. As mentioned earlier, an API server fail does not usually take down the production system. The nodes and pods will continue running without the API Server.

Cloud Load Balancers

• If Kubernetes is hosted in the public cloud, many of these providers integrate with a Service type of LoadBalancer.

• Provides a hosted external load balancer, instead of relying on the ingress controller.

If Kubernetes is hosted on a public cloud, there is likely a load balancer that is built for you to use. Instead of using the ingress controller to load-balance the traffic, you can use the hosted external load balancer. These load balancers integrate with the services. Setting the Service type to LoadBalancer and configuring the settings per the cloud provider’s instructions will allow Kubernetes to update the load balancer with information about reaching the pods.