Metal3.io Architecture: From Multicluster Down to Physical Hardware

▶ Watch (0:42)

Metal3.io splits cleanly at a dashed line in its reference architecture. Above the line sits multicluster management through Cluster API and the Cluster API Metal3 provider. Below it sits bare metal lifecycle management: OS installation, firmware updates, and power cycling via the baseboard management controller. Both halves are optional. A team that only wants to provision physical machines skips the top entirely and deploys just the BareMetalHost custom resource plus one supporting component.

Ironic as a Standalone Provisioner, Not an OpenStack Dependency

▶ Watch (5:49)

Metal3.io ships Ironic as a pre-built image that runs as a pod, with all auxiliary components bundled inside. No OpenStack installation required. For large deployments with thousands of machines, or machines spread across geographically separated sites, the Ironic Standalone Operator handles configuration. Ironic has hundreds of configuration options, and the operator reduces that burden. Metal3.io supports Redfish, ISO, iDRAC, and IPMI protocols for BMC communication. Any machine without a BMC cannot be managed.

IP Address Management Without DHCP

▶ Watch (2:55)

Some data centers have strict routing rules or no DHCP server. Metal3.io includes a Kubernetes-native IP address manager that replicates DHCP leasing logic using pools and claims. A claim is filed against a pool, fulfilled, and the resulting address is attached to a node. In practice, deployments can reach 14 or more network interfaces per machine drawing from 20 different pools. Machine templates can pull values from the IP address manager directly to build per-node configuration files automatically.

Sylva: A Telco Edge Framework Built on Metal3.io and Flux

▶ Watch (10:19)

Sylva is a Linux Foundation Europe telco initiative. Its members include carriers, network function vendors, hardware vendors, and infrastructure software providers. The typical deployment has a central site running Cluster API and Metal3.io, managing many edge sites for workloads such as 5G. Everything is deployed declaratively via a large Sylva-units Helm chart and Flux. That chart configures Cluster API, the Metal3 provider, and Kubernetes distribution providers including K3s, Kubeadm, OKD, and Canonical Kubernetes.

Sylva’s Specific Metal3.io Choices: Virtual Media and Air-Gap Support

▶ Watch (13:53)

Sylva uses Redfish with virtual media rather than PXE boot. Virtual media removes the requirement for a layer-2 network link between the management cluster and edge clusters. Plain IP connectivity is enough, and Ironic no longer needs access to the host network. Sylva also ships a custom IPA provider that embeds the OS image directly, which simplifies air-gap deployments common in telco environments. DHCP, keepalived, and iPXE components are all dropped from the Ironic deployment as a result.

Firmware Settings, Firmware Updates, and the Upgrade Cycle

▶ Watch (22:05)

Metal3.io exposes firmware configuration through two separate CRs linked to a BareMetalHost: HostFirmwareSettings and HostFirmwareComponents. A firmware schema CR validates which settings and value ranges are permitted before any change applies. Firmware updates run during the “preparing” state, triggered at initial registration or after a deprovision cycle. Rolling upgrades reuse Cluster API’s max-surge option. Control planes update one by one, workers scale at any rate. A node-reuse feature lets the host selector always pick the same physical machine.

Q&A

What switch types will the planned switch management feature support? Metal3.io will adopt OpenStack’s generic-switch project, so any switch that generic-switch supports will be manageable via new CRs exposing options such as VLAN IDs. ▶ 26:07

Does Metal3.io support Cluster API in-place updates introduced in v0.12? The team supports in-place updates today but plans a dedicated hook that adds full disk reimage as part of the in-place flow, going beyond the current SSH-based approach. ▶ 27:35

Can Metal3.io provision OpenShift or other non-kubeadm distributions? Yes. Sylva already uses a K3s bootstrap provider, and ignition-based providers exist for OpenShift-style deployments. A custom bootstrap provider is all that is needed for any other distribution. ▶ 28:54

Notable Quotes

Each machine has 14 different network interfaces or even more and they take uh IP addresses for I don’t know 20 different pools. So this can go uh grow quite large. Ádám Rozmán · ▶ 03:45

we don’t need uh the ipixie uh stuff because we are not using the this uh pixie boot uh elements we providing an IPA provider that embeds the uh the OS image uh simply to uh ease the air gap deployments that are pretty common in the space. Nicolas Belouin · ▶ 16:39

you can ask yourself all these questions and those will help you uh decides how to uh integrate and how to structure the whole meta cube. Ádám Rozmán · ▶ 10:07

Key Takeaways

  • Metal3.io’s BareMetalHost CR requires only a boot MAC address, BMC address, credentials, and a disk image.
  • Sylva drops DHCP and PXE entirely, using Redfish virtual media for simpler air-gap edge deployments.
  • Firmware settings, firmware updates, and rolling upgrades are all managed declaratively through dedicated CRs.

About the Speaker(s)

Ádám Rozmán is a Senior Developer at Ericsson Software Technology with over 8 years of experience across embedded, DevOps, and cloud roles. He has been a member of the Metal3 developer community since July 2021 and contributes as an upstream developer on open source projects.

Nicolas Belouin is a Senior Edge Engineer at SUSE, where he works on the Edge product with a focus on telco-oriented technologies.