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 two supported ways to install MetalLB: using Kubernetes manifests, or using the Helm package manager.
To install MetalLB, simply apply the manifest:
kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.1/manifests/metallb.yaml
This will deploy MetalLB to your cluster, under the
namespace. The components in the manifest are:
metallb-system/controllerdeployment. This is the cluster-wide controller that handles IP address assignments.
metallb-system/speakerdaemonset. This is the component that speaks the protocol(s) of your choice to make the services reachable.
The installation manifest does not include a configuration file. MetalLB’s components will still start, but will remain idle until you define and deploy a configmap.
Due to code review turnaround time, it usually takes a few days after each MetalLB release before the Helm chart is updated in the stable repository.
If you’re coming here shortly after a new release, you may end up installing an older version of MetalLB if you use Helm. This mismatch usually gets fixed within 2-3 days.
MetalLB maintains a Helm package in the
repository. If you use the Helm package manager in your cluster, you
can install MetalLB that way.
helm install --name metallb stable/metallb
Although Helm allows you to easily deploy multiple releases at the same time, you should not do this with MetalLB! Multiple copies of MetalLB will conflict with each other and lead to cluster instability.
By default, the helm chart looks for MetalLB configuration in the
metallb-config ConfigMap, in the namespace you deployed to. It’s up
to define and deploy
Alternatively, you can manage the configuration with Helm itself, by
putting the configuration under the
config.inline key in your