Before starting with installation, make sure you meet all the requirements. In particular, you should pay attention to network addon compatibility.

If you’re trying to run MetalLB on a cloud platform, you should also look at the cloud compatibility page and make sure your cloud platform can work with MetalLB (most cannot).

There are three supported ways to install MetalLB: using plain Kubernetes manifests, using Kustomize, or using Helm.


If you’re using kube-proxy in IPVS mode, since Kubernetes v1.14.2 you have to enable strict ARP mode.

Note, you don’t need this if you’re using kube-router as service-proxy because it is enabling strict ARP by default.

You can achieve this by editing kube-proxy config in current cluster:

kubectl edit configmap -n kube-system kube-proxy

and set:

kind: KubeProxyConfiguration
mode: "ipvs"
  strictARP: true

You can also add this configuration snippet to your kubeadm-config, just append it with --- after the main configuration.

If you are trying to automate this change, these shell snippets may help you:

# see what changes would be made, returns nonzero returncode if different
kubectl get configmap kube-proxy -n kube-system -o yaml | \
sed -e "s/strictARP: false/strictARP: true/" | \
kubectl diff -f - -n kube-system

# actually apply the changes, returns nonzero returncode on errors only
kubectl get configmap kube-proxy -n kube-system -o yaml | \
sed -e "s/strictARP: false/strictARP: true/" | \
kubectl apply -f - -n kube-system

Installation by manifest

To install MetalLB, apply the manifest:

kubectl apply -f

If you want to deploy MetalLB using the experimental FRR mode, apply the manifests:

kubectl apply -f

Please do note that these manifests deploy MetalLB from the main development branch. We highly encourage cloud operators to deploy a stable released version of MetalLB on production environments!

This will deploy MetalLB to your cluster, under the metallb-system namespace. The components in the manifest are:

  • The metallb-system/controller deployment. This is the cluster-wide controller that handles IP address assignments.
  • The metallb-system/speaker daemonset. This is the component that speaks the protocol(s) of your choice to make the services reachable.
  • Service accounts for the controller and speaker, along with the RBAC permissions that the components need to function.

The installation manifest does not include a configuration file. MetalLB’s components will still start, but will remain idle until you start deploying resources.

Installation with kustomize

You can install MetalLB with Kustomize by pointing at the remote kustomization file.

In the following example, we are deploying MetalLB with the native bgp implementation :

# kustomization.yml
namespace: metallb-system


In order to deploy the experimental FRR mode:

# kustomization.yml
namespace: metallb-system


Installation with Helm

You can install MetallLB with Helm by using the Helm chart repository:

helm repo add metallb
helm install metallb metallb/metallb

A values file may be specified on installation. This is recommended for providing configs in Helm values:

helm install metallb metallb/metallb -f values.yaml

The speaker pod requires elevated permission in order to perform its network functionalities.

If you are using MetalLB with a kubernetes version that enforces pod security admission (which is beta in k8s 1.23), the namespace MetalLB is deployed to must be labelled with:

  labels: privileged privileged privileged

If you want to deploy MetalLB using the experimental FRR mode, the following value must be set:

    enabled: true

Using the MetalLB Operator

The MetalLB Operator is available on OperatorHub at It eases the deployment and life-cycle of MetalLB in a cluster and allows configuring MetalLB via CRDs.

If you want to deploy MetalLB using the experimental FRR mode, you must edit the ClusterServiceVersion resource named metallb-operator:

kubectl edit csv metallb-operator

and change the BGP_TYPE environment variable of the manager container to frr:

  value: frr

FRR daemons logging level

The FRR daemons logging level are configured using the speaker --log-level argument following the below mapping:

Speaker log level FRR log level
all, debug debugging
info informational
warn warnings
error error
none emergencies

To override this behavior, you can set the FRR_LOGGING_LEVEL speaker’s environment to any FRR supported value.


When upgrading MetalLB, always check the release notes to see the changes and required actions, if any. Pay special attention to the release notes when upgrading to newer major/minor releases.

Unless specified otherwise in the release notes, upgrade MetalLB either using plain manifests or using Kustomize as described above.

Please take the known limitations for layer2 and bgp into account when performing an upgrade.

Setting the LoadBalancer Class

MetalLB supports LoadBalancerClass, which allows multiple load balancer implementations to co-exist. In order to set the loadbalancer class MetalLB should be listening for, the --lb-class=<CLASS_NAME> parameter must be provided to both the speaker and the controller.

The helm charts support it via the loadBalancerClass parameter.

Copyright © The MetalLB Contributors.
Copyright © 2021 The Linux Foundation ®. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page