Need to route traffic on bare-metal Kubernetes clusters? MetalLB is a solution you should consider. As a load balancer that is purpose-built for bare-metal Kubernetes, MetalLB lets you deploy a Kubernetes Service of type LoadBalancer. Then, MetalLB automatically routes traffic for you, using a pool of IP addresses that you define.
Although MetalLB is not the only traffic management solution for bare-metal Kubernetes (you could use an alternative bare-metal load balancer like Porter, or a technique like NodePort), MetalLB offers some standout features. Keep reading for details on why MetalLB is a good choice, how it works, as well as how to get started using it.
Kubernetes MetalLB over NodePort or Ingress
MetalLB isn’t the only way to route traffic in bare-metal Kubernetes clusters. Other methods include:
- NodePort, which lets you route traffic from external endpoints to specific node and port configurations inside your cluster. NodePort is easy to set up, but it is subject to many limitations, not least of which is that you can only run one Service on each NodePort. You also have to update your configuration manually if your nodes’ IP assignments change.
- An Ingress Service, which exposes a Service to an external URL or other endpoint. This approach is relatively sophisticated, and it gives you a lot of control over how traffic is routed, but it requires you to set up your own ingress controller on all of your nodes.
In the past, these were the main ways to manage traffic for bare-metal clusters. But they were not ideal for the reasons described above.
In comparison, MetalLB offers a load balancing solution for bare metal that is:
- Easy to set up: You just have to create a load balancer Service and assign an IP address pool to MetalLB.
- Easy to scale: MetalLB automates most aspects of traffic management, and unlike NodePort and ExternalIP, it requires minimal changes to your configurations. It can thus scale to support mappings for dozens or even hundreds of applications, if you need.
- Consistent with cloud-based load balancing: Because MetalLB uses LoadBalancer Service configurations rather than specialized routing methods like NodePort, you can configure MetalLB in a very similar fashion to configuring load balancing in any public cloud-based Kubernetes environment. If you’re already familiar with Kubernetes load balancing in AWS, Azure or GCP, then, you’ll probably find MetalLB easy to work with.
For these reasons, MetalLB is the obvious solution for most bare-metal routing and load balancing needs today. Older methods, like NodePort and ExternalIP, are still fully supported in Kubernetes, at least for now. But MetalLB is the simpler and more sophisticated option for most use cases.
The simplicity of MetalLB starts with the installation process. To install MetalLB in most clusters, first enable strict ARP mode by running:
kubectl edit configmap -n kube-system kube-proxy
And make sure the strictARP value is set to true:
apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration mode: "ipvs" ipvs: strictARP: true
Then, install MetalLB with kubectl:
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/namespace.yaml kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/metallb.yaml
You can alternatively install MetalLB with Helm, if you prefer:
helm repo add metallb https://metallb.github.io/metallb helm install metallb metallb/metallb
The easiest way to use MetalLB is to configure networking at layer 2. Under this approach, you simply assign a range of IP addresses to MetalLB. It then automatically assigns them nodes and manages traffic between them and your endpoints.
To define the address pool, open the MetalLB ConfigMap with:
kubectl edit configmap config -n metallb-system
Then define the address-pools and addresses values as desired. For example, to use the range 192.168.255.1–192.168.255.255, set the configuration to:
apiVersion: v1 kind: ConfigMap metadata: namespace: metallb-system name: config data: config: address-pools: - name: default protocol: layer2 addresses: - 192.168.255.1-192.168.255.255
After making changes, apply them with:
kubectl rollout restart deployment controller -n metallb-system
Once MetalLB is provisioned with IP addresses, simply define a LoadBalancer Service to route traffic to an application, just as you would in a public cloud environment. For example:
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 clusterIP: 10.0.171.239 type: LoadBalancer status: loadBalancer: ingress: - ip: 192.0.2.127
Advanced MetalLB usage
The steps above reflect the simplest way to get started with MetalLB. But there are many more things you can do with the load balancer, especially if you opt for BGP mode instead of using layer 2 configurations. Under BGP mode, you set up peering sessions between each node and your routers, providing more fine-grained control over traffic routing than you would have at layer 2.
The MetalLB documentation offers full details on configuring MetalLB for BGP mode, along with other advanced setup options. Note, too, that MetalLB is one of the load balancers natively available through Palette. Read more about using MetalLB and Palette together in our documentation, or sign up for a free account to see MetalLB and Palette in action.
K8s, Palette, our upcoming webinar, events, and much more!
We are using the information you provide to us to send you our monthly newsletter. You may unsubscribe at any time.