7.4 KiB
metallb 2022 Annual Review
This is a Kubernetes ToC Annual Review for the metallb project for 2022.
Table of Contents
- Background
- DevStats
- Maintainers
- Adoption
- Latest Achievements
- Project Goals
- CNCF Membership
- Incubation
Background
MetalLB is a load-balancer implementation for bare metal Kubernetes clusters, using standard routing protocols.
Kubernetes does not offer an implementation of network load balancers (Services of type LoadBalancer) for bare-metal clusters. The implementations of network load balancers that Kubernetes does ship with are all glue code that calls out to various IaaS platforms (GCP, AWS, Azure…). If you’re not running on a supported IaaS platform (GCP, AWS, Azure…), LoadBalancers will remain in the “pending” state indefinitely when created.
Bare-metal cluster operators are left with two lesser tools to bring user traffic into their clusters, “NodePort” and “externalIPs” services. Both of these options have significant downsides for production use, which makes bare-metal clusters second-class citizens in the Kubernetes ecosystem.
MetalLB aims to redress this imbalance by offering a network load balancer implementation that integrates with standard network equipment, so that external services on bare-metal clusters also “just work” as much as possible.
MetalLB works with both relatively simple networking topology using the L2 mode that does not require any additional network component, or using the BGP protocol when BGP enabled routers are available.
More information about the MetalLB architecture can be found here
Development metrics
The MetalLB devstats page and dashboards can be found here.
Here are some links worth mentioning:
Maintainers
There are three maintainers actively working on the project (alphabetically):
| Maintainer | GitHub ID | Affiliation |
|---|---|---|
| Federico Paolinelli | fedepaol | Red Hat |
| Graeme Lawes | gclawes | Nasdaq |
| Ori Braunshtein | oribon | Red Hat |
Adoption
MetalLB is probably the most popular solution for exposing services of type LoadBalancer in bare metal deployments. It is widely used by users running kubernetes in homelabs (an issue opened against MetalLB revealed a wide community of users in the k8s@home discord channel). MetalLB is part of multiple tutorials and videos written by the community and suggested by multiple projects such as kubespray, kind and microk8s (to mention some).
Despite not having a clear estimate of the number users / companies consuming MetalLB, the images related to the controller / speaker components show an average of 40k "actions" per day for the controller image (which is deployed in single instance) and 150k "actions" per day for the speaker image.
We have a who is using MetalLB issue to provide some form of tracking, but that is not really indicative.
On the enterprise side, MetalLB is distributed as part of Red Hat's Openshift since version 4.9, Microsoft's Azure HCI, Platform9, Google's Anthos on premise clusters, Amazon's EKS anywhere and suggested in Canonical's kubernetes distribution.
In the next year we hope to have a clearer identity / sizing of the userbase via surveys and other statistics.
Latest Achievements
The biggest achievement of the past year was adding a very comprehensive CI based on github actions and kind. Going from no end to end tests to covering all the existing and new features lowers the bar for new contributions and avoids the risk of regressions, not to mention a quicker development cycle.
Feature wise, the following improvements were done:
- Replaced the native BGP implementation with FRR, which made the implementation of new features faster
- Moved from a configmap based configuration to a custom resource based configuration
- Added support for IPV6 and dual stack clusters
- Added support for BFD for quicker failover
- Added support for interface selection in case of L2 mode
- Added more flexible options for announcement, such as node selector and BGP peer selector
- Added a MetalLB Operator to deploy MetalLB via OLM
- Images are co-signed using cosign
- A proper kustomize friendly layout to deploy the various configuration flavours
On top of that, we kept the project aligned with the evolution of the platform, moving from pod security policy to pod security admission, removing deprecated apis and adding support for loadbalancer class.
Project Goals
MetalLB must continue to evolve with two goals in mind. On one hand it must keep being the (nearly) zero configuration load balancer that enables loadbalancers on Kubernetes clusters running on RaspberryPIs, on the other it must offer optional configuration knobs to accommodate the requirements of enterprise customers that are using MetalLB on more complex scenarios and topologies.
On top of that, the project must keep being contributor friendly and open to discuss new feature requests and responsive to contributors willing to help.
CNCF Membership
We don't have particular needs that must be addressed. The interaction with the CNCF has always been productive and we are already leveraging a few of the benefits provided by the CNCF.
Incubation
This was the first year after the sandboxing process finished. Despite MetalLB probably already meets the majority of the criteria for Incubation, we will probably invest more time in filling the gaps and starting the process next year.