Skip to content
antalos

MetalLB · Architecture

The chart supplies a controller for allocation and node-level speakers for advertisement. config/pools.yaml defines the address pool and L2 advertisement. In L2 mode an elected node advertises a service address and Kubernetes routes traffic to eligible endpoints.

Component boundaries

MetalLB · component flow
  1. Allocate
    • LoadBalancer Service
    • Configured IPAddressPool
  2. Advertise
    • Controller allocates IP
    • L2 speaker elects advertiser
  3. Route
    • LAN → service address
    • Kubernetes → ready endpoints
Arrows show the main flow between responsibility groups. Parallel boxes are related components, not interchangeable replicas; the text below defines their individual failure and recovery behavior.

State and recovery contract

Address pools and Service declarations live in Git. Reserve the same range outside DHCP and other infrastructure allocation systems. Network configuration outside Kubernetes must be retained separately.

Availability and failure behavior

Availability classification: Partially HA: distributed address advertisement; controller allocation and the physical network remain separate.

This is an interpretation of the checked-in configuration, assuming the declared replicas are healthy, separated as intended, and their required dependencies are reachable. It is not a live-health result or a completed failure drill.

What supplies redundancy

Component Declared layout Mechanism
Speakers Node-level instances An eligible speaker can take over L2 advertisement of an address.
Controller No explicit replica increase Address allocation/config changes can wait for controller recovery.
Data forwarding Kubernetes Services and endpoints A new advertiser still needs reachable healthy service endpoints.

How a failure is handled

In the configured L2 mode, the eligible speaker set selects an advertiser. After its loss, another can advertise the same service IP and clients/neighbors must update their network state. MetalLB does not copy an application session or route around a dead physical subnet.

Failure scenarios

Failure Expected behavior and remaining dependency
One main worker The address may move if its advertiser was on that worker. Ready endpoints on remaining nodes are still needed; Local versus Cluster traffic policy also affects eligible forwarding.
RTX worker only May remove a speaker; no data replica lives in the pool object. Loss of the whole host can additionally interrupt API-driven configuration.
A second failure before recovery Outside the stated single-failure envelope; assess remaining data copies, quorum, endpoints, and capacity before further maintenance.

An RTX worker VM failure is not the same as an RTX Proxmox host failure. The latter also removes its control-plane VM and the configured API address. Read the physical failure-domain explanation before making a whole-host HA claim.

Upgrades and voluntary maintenance

Existing allocations and advertisement have a different dependency path from assigning new IPs. A controller restart should not be described as proof that all existing traffic stops or all new allocations continue.

What prevents a stronger HA claim

L2 failover can have convergence delay. The single external router, address conflict, VLAN, or switch can defeat all speakers. The chart’s controller count is not explicitly overridden.

What would improve the availability contract

Document the external network failure domains, make control-component redundancy explicit if required, and measure reachability from actual LAN/WAN clients after advertiser loss.

These are operational/design requirements, not changes made to the deployment by this documentation. The shared availability reference explains election, replication, durability, recovery time, and shared dependencies; the manifest links below identify this service’s source.

Configuration ownership

apps/metallb/ owns this service’s Kubernetes resources. Hostnames, addresses, versions, node names, and volume sizes belong in apps/variables.yaml. Runtime settings stored in a product database need that product’s backup and administration procedure.

Continue

Read the deployment guide for dependency order, initial credentials, and integration work. The official documentation explains the upstream product; the topology above describes this repository.