Version 0.7.1

Version 0.7.0

MetalLB no longer does leader election. After upgrading to 0.7, you
can delete a number of k8s resources associated with that. This is
just a cleanup, nothing bad happens if you leave the resources
orphaned in your cluster. Depending on your installation method,
some of these may have already been cleaned up for you.

Layer2 mode now selects leader nodes on a per-service level, instead of using
a single leader node for all services in the cluster. If you have many
services, this change spreads the load of handling incoming traffic across
more than one machine. (#195)

MetalLB’s maturity has upgraded from alpha to beta! Mostly this
just reflects the increased confidence in the code from the larger
userbase, and adds some guarantees around graceful upgrades from one
version to the next.

Version 0.6.0

As documented in the 0.5.0 release notes, several deprecated fields
have been removed from the configuration. If you didn’t update your
configurations for 0.5, you may need to make the following changes:

Rename the cidr field of address pools to addresses

Rename protocol: arp and protocol: ndp to protocol: layer2

Replace arp-network statements with a range-based IP allocation

New features:

You can now colocate multiple services on a single IP address, using
annotations on the Service objects. See
the
IP sharing documentation for
instructions and caveats. (#121)

Layer 2 mode now listens on all interfaces for ARP and NDP requests,
not just the interface used for communication by Kubernetes
components. (#165)

MetalLB now uses structured logging instead of Google’s glog
package. Logging events are written to standard output as a series
of JSON objects suitable for collection by centralized logging
systems. (#189)

Version 0.5.0

The cidr field of address pools in the configuration file has been
renamed to addresses. MetalLB 0.5 understands both cidr and
addresses, but in 0.6 it will only understand addresses, so
please update now.

The arp and ndp protocols have been replaced by a unified
layer2 protocol. MetalLB 0.5 understands both the old and new
names, but 0.6 will only understand layer2, so please update now.

Remove any arp-network entries from your configuration. If your
address pool overlaps with the ethernet network or broadcast
addresses for your LAN, use IP range notation (see new features) to
exclude them from your address pool.

The router IDs used on BGP sessions may change in this version, in
clusters where nodes have multiple IP addresses. If your BGP
infrastructure monitors or enforces specific router IDs for peers,
you may need to update those systems to match new router IDs.

The Prometheus metrics for ARP and NDP traffic have been
merged. Instead of arp_* and ndp_* metrics, there is now single
set of layer2_* metrics, in which the ip label can be IPv4 or
IPv6.

New features:

ARP and NDP modes have been replaced by a single “layer 2” mode,
indicated by protocol: layer2 in the configuration file. Layer 2
mode uses ARP and NDP under the hood, but having a single protocol
name makes it easier to build protocol-agnostic configuration
templates.

You can give addresses to MetalLB using a simple IP range notation,
in addition to CIDR prefixes. For example,
192.168.0.0-192.168.0.255 is equivalent to 192.168.0.0/24. This
makes it much easier to allocate IP ranges that don’t fall cleanly
on CIDR prefix boundaries.

BGP mode supports nodes with multiple interfaces and IP addresses
(#182). Previously,
MetalLB could only establish working BGP sessions on the node’s
“primary” interface, i.e. the one that owned the IP that Kubernetes
uses to identify the node. Now, peerings may be established via any
interface on the nodes, and traffic will flow in the expected
manner.

Version 0.4.1

Version 0.4.0

MetalLB’s use of Kubernetes labels has changed slightly to conform
to Kubernetes best practices. If you were using a label match on
app: controller or app: speaker Kubernetes labels to find
MetalLB objects, you should now match on a combination of app:
metallb, component: controller or component: speaker, depending
on what objects you want to select.

RBAC rules have changed, and now allow the MetalLB speaker to list
and watch Node objects. If you are not installing MetalLB via the
provided manifest, you will need to make this change by hand.

If you want to switch to using Helm to manage your MetalLB
installation, you must first uninstall the manifest-based version,
with kubectl delete -f metallb.yaml.

New features:

Initial IPv6 support! The ndp protocol allows v6 Kubernetes
clusters to advertise their services using
the
Neighbor Discovery Protocol,
IPv6’s analog to ARP. If you have an IPv6 Kubernetes cluster, please
try it out
and file bugs!

BGP peers now have
a
node selector. You
can use this to integrate MetalLB into more complex cluster network
topologies.

MetalLB now has
a
Helm chart. If
you use Helm on your cluster, this should make it
easier to track and manage your MetalLB installation. The chart will
be submitted for inclusion in the main Helm stable repository
shortly after the release is finalized. Use of Helm is optional,
installing the manifest directly is still fully supported.

Version 0.3.0

The bgp-speaker DaemonSet has been renamed to just
speaker. Before applying the manifest for 0.3.0, delete the old
daemonset with kubectl delete -n metallb-system
ds/bgp-speaker. This will take down your load-balancers until you
deploy the new DaemonSet.

Each address-pool must now have a protocol field, to select
between ARP and BGP mode. For your existing configurations, add
protocol: bgp to each address pool definition.

The advertisements field of address-pool has been renamed to
bgp-advertisements, and is now optional. If you don’t need any
special advertisement settings, you can remove the section
entirely, and MetalLB will use a reasonable default.

The communities section has been renamed to bgp-communities.

New features:

MetalLB now supports ARP advertisement, enabled by setting
protocol: arp on an address pool. ARP mode does not require any
special network equipment, and minimal configuration. You can follow
the ARP mode tutorial to get
started. There is also a page about ARP
mode’s behavior and tradeoffs,
and documentation
on configuring ARP mode.

The container images are
now
multi-architecture images. MetalLB
now supports running on all supported Kubernetes architectures:
amd64, arm, arm64, ppc64le, and s390x.

Version 0.2.1

Version 0.2.0

Major themes for this version are: improved BGP interoperability,
vastly increased test coverage, and improved documentation structure
and accessibility.

Notable features:

This website! It replaces a loose set of markdown files, and
hopefully makes MetalLB more accessible.

The BGP speaker now speaks Multiprotocol BGP
(RFC 4760). While we still
only support IPv4 service addresses, speaking Multiprotocol BGP is a
requirement to successfully interoperate with several popular BGP
stacks. In particular, this makes MetalLB compatible
with Quagga and Ubiquiti’s
EdgeRouter and Unifi product lines.

The development workflow with Minikube now works with Docker for
Mac, allowing mac users to hack on MetalLB. See
the hacking documentation
for the required additional setup.

Notable fixes:

Handle multiple BGP peers properly. Previously, bgp-speaker
mistakenly made all its connections to the last defined peer,
ignoring the others.

Fix a startup race condition where MetalLB might never allocate an
IP for some services.

Test coverage is above 90% for almost all packages, up from ~0%
previously.