We would love to hear from you! Here are some places you can find us.
Our mailing list is email@example.com. It’s for discussions around MetalLB usage, community support, and developer discussion (although for the latter we mostly use GitHub directly).
For a more interactive experience, we have the #metallb slack channel on k8s.slack.com. If you’re not already logged into the Kubernetes slack organization, you’ll need to request an invite before you can join.
Development of MetalLB is discussed in the #metallb-dev slack channel .
Use the GitHub issue tracker to file bugs and features request. If you need support, please send your questions to the metallb-users mailing list rather than filing a GitHub issue.
We welcome contributions to MetalLB! Here’s some information to get you started.
This project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.
Before you make significant code changes, please consider opening a pull
request with a proposed design in the
design/ directory. That should
reduce the amount of time required for code review. If you don’t have a full
design proposal ready, feel free to open an issue to discuss what you would
like to do.
All submissions require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.
By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. See the DCO file for details.
MetalLB’s code is divided between a number of binaries, and some
supporting libraries. The libraries live in the
and each binary has its own top-level directory. Here’s what we
currently have, relative to the top-level directory:
controlleris the cluster-wide MetalLB controller, in charge of IP assignment.
speakeris the per-node daemon that advertises services with assigned IPs using various advertising strategies.
internal/k8scontains the bowels of the logic to talk to the Kubernetes apiserver to get and modify service information. It allows most of the rest of the MetalLB code to be ignorant of the Kubernetes client library, other than the objects (Service, ConfigMap…) that they manipulate.
internal/configparses and validates the MetalLB configmap.
internal/allocatoris the IP address manager. Given pools from the MetalLB configmap, it can allocate addresses on demand.
internal/bgp/nativeis a very stripped down implementation of BGP. It speaks just enough of the protocol to keep peering sessions up, and to push routes to the peer.
internal/bgp/frrcontains the code for translating the MetalLB configuration to the FRR configuration that is applied to the FRR container, when running MetalLB in FRR mode.
internal/layer2is an implementation of an ARP and NDP responder.
internal/loggingis a logging shim that redirects both Kubernetes’s
klogand Go’s standard library
logoutput to go-kit’s structured logger, which is what MetalLB itself uses for logging.
internal/versionjust burns version numbers and git commit information into compiled binaries, so that MetalLB can print its build information.
In addition to code, there’s deployment configuration and documentation:
manifestscontains a variety of Kubernetes manifests. The most important one is
manifests/metallb.yaml, which specifies how to deploy MetalLB onto a cluster.
websitecontains the website for MetalLB. The
website/contentsubdirectory is where all the pages live, in Markdown format.
To develop MetalLB, you’ll need a couple of pieces of software:
NOTE: The development environment was tested with kind
v0.9.0. Older versions may not work since there have been breaking changes between minor versions.
Start by fetching the MetalLB repository, with
From there, you can use Invoke to build Docker images, push them to
registries, and so forth.
inv -l lists the available tasks.
To build and deploy MetalLB to a local development environment using a kind
When you’re developing, running components at the command line and having them attach to a cluster might be more convenient than redeploying them to a cluster over and over.
For the controller, the
-namespace command-line flags
are needed. Speakers need those and
metallb$ go run ./controller/main.go ./controller/service.go -namespace metallb-system -kubeconfig $KUBECONFIG metallb$ go run ./speaker/main.go ./speaker/*controller.go -namespace metallb-system -kubeconfig $KUBECONFIG -node-name node0
For development, fork
the github repository, and add
your fork as a remote in
git remote add fork firstname.lastname@example.org:<your-github-user>/metallb.git.
The following are our commit message guidelines:
When adding a new feature, or modifying a current one, consider adding a new test
to the test suite located in
The website at https://metallb.universe.tf is pinned to the latest released version, so that users who don’t care about ongoing development see documentation that is consistent with the released code.
However, there is a version of the website synced to the latest main
every branch has a published website at
name>--metallb.netlify.com. So if you want to view the documentation
for the 0.2 version, regardless of what the currently released version
is, you can
When editing the website, you can preview your changes locally by
installing Hugo and running
hugo server from
For information about the current maintainers of MetalLB, see the maintainers page.