In a Kubernetes cluster, depending on the flow of traffic direction, there are two kinds of load balancing:
Internal load balancing for the traffic within a Kubernetes cluster
External 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 DKP environments, the external load balancer must be configured without TLS termination.
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 Pre-provisioned deployment, DKP ships with MetalLB, which provides load-balancing services. The environments that use MetalLB are pre-provisioned and vSphere infrastructures.
For more information on how to configure MetalLB for these environments, refer to the following pages:
Custom Load Balancer for External Traffic
If you want to use a non-DKP load balancer for external traffic, see External Load Balancer.