In 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
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.
For an on-premises deployment, DKP ships with MetalLB, which provides load-balancing services. The environments that use MetalLB are pre-provisioned and vSpere infrastructures.
For more information on how to configure MetalB for these environments, refer to the following pages: