By Alex Tesch, Senior Consultant, Cloud Native Computing Practice, HPE Advisory & Professional Services
For many customers transitioning their cloud-native applications from the public cloud to an on-premise Kubernetes environment, a significant hurdle is the absence of load balancing capabilities for services on on-prem Kubernetes clusters.
When deploying cloud-native workloads in managed Kubernetes on public clouds, it is straightforward to define a service of type "LoadBalancer," and the cloud provider will handle provisioning the required appliance to front the application workload. On premise, however, services are created with type โClusterIPโ or โNodePort,โ since using service type โLoadBalancerโ will leave the service external IP on status โPending.โ
The typical approach for on-premise Kubernetes is to place a load balancer appliance in front of the Kubernetes workers. The load balancer appliance will distribute the load across all the workers in the cluster. Once one of the workers gets the request, the Kubernetes service and ingress (if applicable) will handle the traffic until it reaches the application.
MetalLB: In-cluster load balancer for bare-metal clusters
In a recent project delivered by A&PS in Australia, the team faced the challenge of deploying a K3s cluster in the edge. There was only the minimal amount of infrastructure needed to run K3s, and there was no means to provide a load balancer to front the cluster nodes and handle the traffic.
In that scenario, we need to consider a network load balancer implementation that integrates within the Kubernetes cluster itself and does not rely on any external infrastructure. MetalLB is an OpenSource solution that makes it possible to embed the loadbalancer functionality into bare-metal clusters, ending the previous advantage of running Kubernetes on a cloud provider.
The MetalLB deployment provides a controller that handles the IP assignment for the services based on an IP range that the Kubernetes administrator can define from the subnet used by the end users to reach the applications. The deployment also triggers a โspeakerโ daemonset that will run in every single node in the cluster and will speak the protocol of choice to make the application service reachable.
MetalLB is a terrific in-cluster implementation of a load balancer if you need to deploy cloud-native workloads in the edge. Another increasingly common use case is organizations attempting to reduce costs associated with public cloud infrastructure. The load balancer service contributes significantly to monthly expenses. Companies now have the option to repatriate workloads into a bare-metal cluster on-premises without being hindered from breaking free from cloud providers by the "LoadBalancer" service type.
Maximize cloud-native applications strategy with HPE
HPE can help you get the most out of your cloud-native applications strategy. We recognize that once cloud-native workloads have achieved production maturity in the cloud, it is important to manage costs effectively and have the flexibility to repatriate if necessary. And while running cloud-native workloads in the edge is becoming popular, some complex applications require additional planning to make sure that the underlying infrastructure can support the applicationsโ needs for successful operation.
HPE Advisory and Professional Container Adoption Services can help your team design a container platform infrastructure that will allow you to run your applications in production while addressing complex network requirements even at the edge.
To learn more, see our HPE Container Adoption Solution Brief.
Meet HPE Blogger Alex Tesch, Senior Consultant, Cloud Native Computing Practice, HPE Advisory & Professional Services
Services Experts
Hewlett Packard Enterprise
twitter.com/HPE_Services
linkedin.com/showcase/hpe-services/
hpe.com/services
ServicesExperts
HPE Services Team experts share their insights on the topics and technologies that matter most for your business.
