Full example

As an example of how to use all of MetalLB’s options, consider an ecommerce site that runs a production environment and multiple developer sandboxes side by side. The production environment needs public IP addresses, but the sandboxes can use private IP space, routed to the developer offices through a VPN.

Additionally, because the production IPs end up hardcoded in various places (DNS, security scans for regulatory compliance…), we want specific services to have specific addresses in production. On the other hand, sandboxes come and go as developers bring up and tear down environments, so we don’t want to manage assignments by hand.

We can translate these requirements into MetalLB. First, we define two address pools, and set BGP attributes to control the visibility of each set of addresses:

# Rest of config omitted for brevity
communities:
  # Our datacenter routers understand a "VPN only" BGP community.
  # Announcements tagged with this community will only be propagated
  # through the corporate VPN tunnel back to developer offices.
  vpn-only: 1234:1
address-pools:
- # Production services will go here. Public IPs are expensive, so we leased
  # just 4 of them.
  name: production
  protocol: bgp
  cidr:
  - 42.176.25.64/30

- # On the other hand, the sandbox environment uses private IP space,
  # which is free and plentiful. We give this address pool a ton of IPs,
  # so that developers can spin up as many sandboxes as they need.
  name: sandbox
  protocol: bgp
  cidr:
  - 192.168.144.0/20
  bgp-advertisements:
  - communities:
    - vpn-only

In our Helm charts for sandboxes, we tag all services with the annotation metallb.universe.tf/address-pool: sandbox. Now, whenever developers spin up a sandbox, it’ll come up on some IP address within 192.168.144.0/20.

For production, we set spec.loadBalancerIP to the exact IP address that we want for each service. MetalLB will check that it makes sense given its configuration, but otherwise will do exactly as it’s told.