navigation

MetalLB

MetalLB is a load-balancer implementation for bare metal Kubernetes clusters, using standard routing protocols.

MetalLB is a young project. You should treat it as a beta system. The project maturity page explains what that implies.

Why?

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.

Requirements

MetalLB requires the following to function:

  • A Kubernetes cluster, running Kubernetes 1.13.0 or later, that does not already have network load-balancing functionality.
  • A cluster network configuration that can coexist with MetalLB.
  • Some IPv4 addresses for MetalLB to hand out.
  • When using the BGP operating mode, you will need one or more routers capable of speaking BGP.
  • When using the L2 operating mode, traffic on port 7946 (TCP & UDP, other port can be configured) must be allowed between nodes, as required by memberlist.

Backward Compatibility

Previous versions of MetalLB are configurable via a configmap. However, starting from the version v0.13.0, it will be possible to configure it only via CRs. A tool to convert old configmaps to CRs is provided as a container image under quay.io/metallb/configmaptocrs.

In order to use the tool the container must be ran mapping the path with the source file config.yaml to /var/input, and it will generate a resources.yaml file containing the resources mapped to the yaml.

docker run -d -v $(pwd):/var/input quay.io/metallb/configmaptocrs -source config.yaml

Usage

The concepts section will give you a primer on what MetalLB does in your cluster. When you’re ready to deploy to a Kubernetes cluster, head to the installation and usage guides.

FRR Mode

MetalLB implements an experimental FRR Mode that uses an FRR container as the backend for handling BGP sessions. It provides features that are not available with the native BGP implementation, such as pairing BGP sessions with BFD sessions, and advertising IPV6 addresses.

The FRR mode is considered to be experimental, please see the installation section for instructions on how to enable it.

Contributing

We welcome contributions in all forms. Please check out the contributing guide for more information.

One lightweight way you can contribute is to tell us that you’re using MetalLB, which will give us warm fuzzy feelings :).

We are a Cloud Native Computing Foundation sandbox project. cncf

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