Kommander DocumentationIn a Kubernetes cluster, depending on the flow of traffic direction, there are two kinds of load balancing:
- Load balancing for the traffic within a Kubernetes cluster
- Load balancing for the traffic coming from outside the cluster
Load balancing for internal traffic
Load balancing within a Kubernetes cluster is accessed through a ClusterIP service type.
ClusterIP presents a single IP address to the client and load balances the traffic going to this IP to the backend servers.
The actual load balancing happens using iptables or IPVS configuration. The kube-proxy Kubernetes component programs these.
The iptables mode of operation uses DNAT rules to distribute direct traffic to real servers, whereas IPVS leverages in-kernel transport-layer load-balancing.
Read a comparison between these two methods.
By default, kube-proxy runs in iptables mode.
The kube-proxy configuration can be altered by updating the kube-proxy configmap in the kube-system namespace.
Load balancing for external traffic
External traffic destined for the Kubernetes service requires a service of type LoadBalancer, through which external clients connect to your internal service.
Under the hood, it uses a load balancer provided by the underlying infrastructure to direct the traffic.
In the Cloud
In cloud deployments, the load balancer is provided by the cloud provider. For example, in AWS, the service controller communicates with the AWS API to provision an ELB service which targets the cluster nodes.
On-premises
For an on-premises deployment, Kommander utilizes MetalLB. MetalLB can now be installed when creating your Kubernetes cluster, refer to the Konvoy installation instructions for new clusters.