MetalLB 0.16 was released in May 2026 as a stable release, while v0.15 is officially end of life. This episode covers the CRD v1beta2 refinements, IP pool management and observability, BGP and Layer 2 fixes, and the importance of upgrading to v0.16.x.

Technology that doesn't evolve gets left behind — and MetalLB is clearly evolving. MetalLB 0.16 was released in May 2026, marking the latest stable release after v0.15, which officially entered end of life the same month. Episode 20 covers what changed in the 0.16 series, why upgrading matters, and how to do it safely.
If you're just starting with MetalLB now, you'll be using v0.16.1 directly — the latest stable version. If you're still on v0.15 or older, this episode is both the reason and the guide to upgrade as soon as possible.
The 0.16 series continues maturing the CRD v1beta2 introduced back in v0.14. This version brings improvements in consistency and clarity to CRD fields, especially for IPAddressPool, which now uses metallb.io/v1beta2 as its primary version. The main changes are about maturity rather than revolutionary new features — which is expected for a release focused on stability.
Check the active CRD version in your cluster:
kubectl get crd ipaddresspools.metallb.io -o jsonpath='{.spec.versions[*].name}'
kubectl get crd | grep metallb.iokubectl get crd ipaddresspools.metallb.io -o jsonpath='{.spec.versions[*].name}' shows the versions served by the CRD — you should see v1beta1 and v1beta2. The version column in the kubectl get crd | grep metallb.io output confirms which version is the storage one.
Pool management in v0.16 focuses on allocation stability. The autoAssign and avoidBuggyIPs behaviors are retained and tested more thoroughly, making IP allocation across many pools more predictable. For users, there's nothing to relearn about how it works — and that's the good news.
The 0.16 series improves observability: Prometheus metrics are named more consistently, and status on resources such as IPAddressPool and BGPPeer is more informative. This makes the monitoring we built in episode 11 easier.
kubectl get ipaddresspool
kubectl get bgppeerkubectl get ipaddresspool and kubectl get bgppeer show resource status more clearly. Using metrics for alerts still follows the same pattern as episodes 11 and 17.
In BGP mode, v0.16 brings fixes to session stability and edge-case handling — for example, better behavior when a peer changes configuration or when a node loses connectivity. For those using FRR as the BGP backend (the default since v0.13), these fixes reduce unwanted session flapping.
In Layer 2 mode, fixes focus on more responsive announcements during failover and less disruption to in-flight traffic. The Layer 2 failover experience in v0.16 is generally smoother than in earlier versions.
A key decision of this release: v0.15 is officially end of life as of May 2026. That means:
If you're still running v0.15 or older, upgrading is no longer a choice — it's a security requirement.
Before upgrading, confirm the version currently running in your cluster:
kubectl get deployment metallb-controller -n metallb-system -o jsonpath='{.spec.template.spec.containers[0].image}'
kubectl get daemonset metallb-speaker -n metallb-system -o jsonpath='{.spec.template.spec.containers[0].image}'The output of kubectl get deployment metallb-controller -n metallb-system -o jsonpath='{.spec.template.spec.containers[0].image}' shows the current controller image tag — for example v0.15.0. If it isn't v0.16.1, it's time to upgrade.
The safest, most controlled way is through Helm:
helm repo update
helm upgrade metallb metallb/metallb --namespace metallb-system --version 0.16.1
kubectl get pods -n metallb-systemhelm upgrade metallb metallb/metallb --version 0.16.1 applies all resource changes at once. When it's done, kubectl get pods -n metallb-system confirms that all components are healthy again.
Don't stop at healthy pods. Also verify that the configuration still works:
kubectl get ipaddresspool
kubectl get l2advertisement
kubectl get bgppeer
kubectl get svc -Akubectl get ipaddresspool, kubectl get l2advertisement, and kubectl get bgppeer confirm that all configuration is still readable. kubectl get svc -A confirms that existing LoadBalancer IPs aren't lost after the upgrade.
Warning
If the upgrade fails partway through, don't panic — stick to the official release and use the release notes to resolve field conflicts. The allocated IP data isn't lost, because allocation is stored in the Service status, not in the configuration.
Episode 20 completes the latest stable features: MetalLB 0.16 released in May 2026, the CRD v1beta2 refinements, better pool management and observability, BGP and Layer 2 fixes, and the urgency of upgrading since v0.15 is end of life.
Key takeaways:
In the next episode, episode 21, we'll discuss production-ready architecture — IP pool planning, choosing between L2 and BGP modes, router integration, high availability, upgrade strategy, GitOps pipelines, observability with Prometheus and dashboards, sizing, and an incident runbook.