Bare Metal Gets a Concierge, a Switch, and a Circuit Breaker

Bare metal just got a Kubernetes-native concierge. metal3-io’s baremetal-operator v0.14.0 is out, and it is quietly redesigning how you reserve servers, inspect hardware, and wire up your rack switches — without you ever leaving kubectl.

Let’s say you run a fleet of physical servers. Not cloud VMs, not shiny managed nodes — actual metal in an actual rack, with BMCs that speak Redfish and cables someone (possibly you) has to plug in.

Managing that with YAML feels like herding cats with a spreadsheet.

That’s the problem metal3 (specifically its brain, the baremetal-operator, or BMO) solves: it turns physical servers into Kubernetes objects. A server becomes a BareMetalHost. You provision it, inspect it, and reprovision it the same way you’d scale a Deployment — declaratively, from the comfort of your cluster.

Who uses this? Teams running Kubernetes on bare metal at scale: telcos, private-cloud builders, high-performance computing folks, and anyone using Cluster API — the Kubernetes project for declaratively creating clusters themselves — with its Metal3 provider (CAPM3) instead of a cloud provider. If your “cloud” is a room with good air conditioning, this is your stack.

Three bits of vocabulary before we start: a BMC is the baseboard management controller — the tiny always-on computer on every server motherboard that lets you manage the machine even when its OS is dead. Redfish is the industry-standard protocol those BMCs speak. And a CRD (Custom Resource Definition) is Kubernetes’ way of letting you invent new object types — like a BareMetalHost (BMH for short) that represents one physical server. Keep those three in your pocket and the rest reads itself.

Why care about v0.14.0 specifically? Because it’s the “Metal3 grows up” release. It ships a brand-new way to claim hosts, a switch CRD that reaches beyond servers into the network fabric, an inspection mode that skips the slow parts, and a circuit breaker for provisioning loops that used to spin forever. Released September 8, 2026 — full changelog here.

What’s New in v0.14.0

HostClaim: reserve a server like you’d reserve a table

The headline feature. Until now, taking ownership of a BareMetalHost meant editing the host object itself — pointing its consumerRef field (the “this machine belongs to me” pointer) at yourself and hoping no other tool had the same idea. The new HostClaim controller (PR #3406) introduces a dedicated object whose entire job is saying “I want that machine” — and the controller does the binding for you, with a validation webhook (PR #3196) — a gate Kubernetes consults before saving an object — keeping claims honest, plus cross-resource validation between hosts, claims, and the new HostNetworkAttachment types (PR #3338).

Think of it as OpenTable, but for servers: you request a table for one whatever-OS-you-run, and the maître d’ binds you to a host that fits.

Why it matters: automation tools no longer need to fight over mutating host objects directly — the claim object is the single negotiating table. The status side reports exactly which bareMetalHost your claim landed on:

apiVersion: metal3.io/v1alpha1
kind: HostClaim
metadata:
  name: prod-db-node-claim
spec:
  consumerRef:
    name: prod-db-machine
    namespace: capi-system
status:
  bareMetalHost:
    name: rack2-server-14
    namespace: metal3
  conditions: []

Shipped in PR #3406, with validation in PR #3196 and the BMH/HNA types (HNA = HostNetworkAttachment, for attaching host network interfaces) in PR #3338. Fair warning for early adopters: the PR itself says update and delete handling are stubs and pause-for-pivot (pausing reconciliation while a host moves between management clusters) isn’t wired yet — so today this is a promising foundation to watch, not a finished workflow.

BareMetalSwitch: Kubernetes now configures your Top-of-Rack switches

Yes, you read that right. Quick cast list: Ironic is the OpenStack bare-metal provisioning service (OpenStack being the big open-source cloud toolkit) that actually wipes disks and writes images — BMO drives it. The new BareMetalSwitch CRD (PR #3046) describes Top-of-Rack (ToR) — the switch at the top of each server rack — managed by Ironic’s networking service. You declare the switch — address, credentials secret, device type — and the controller generates the switch config Ironic then uses to manage ports (this is early-days: today it generates configs rather than pushing them out itself). Short name bms, so your wrists get a break:

apiVersion: metal3.io/v1alpha1
kind: BareMetalSwitch
metadata:
  name: tor-rack2
spec:
  address: 10.20.30.2
  credentials:
    name: tor-rack2-creds
  deviceType: netmiko_cisco_ios
  driver: generic-switch
  macAddress: 00:1b:17:00:00:2a
  port: 22

Why it matters: bare-metal provisioning without network automation is half a solution — PXE (network booting an OS installer) and isolated provisioning VLANs live and die by switch config. This is Metal3 reaching past the server and into the fabric, declaratively. (Early days: the controller only registers when IRONIC_NETWORKING_ENABLED=true, and the only driver today is generic-switch.)

Fast Redfish inspection: skip the ramdisk boot

Inspecting hardware used to mean booting a small inspection OS (a ramdisk) on every host and waiting. The new inspectionMode: fast (PR #3482) asks the BMC directly over Redfish — no boot, no agent, no waiting for an OS to cycle up just to learn how much RAM is installed:

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: rack2-server-14
spec:
  bmc:
    address: redfish+https://10.20.30.14/redfish/v1/Systems/1
  inspectionMode: fast

The trade-off, straight from the docs: fast mode may return fewer details than agent-based inspection. Think of it as glancing at the label vs. unpacking the whole box. For fleet onboarding where you mostly need inventory basics, it’s a massive speedup.

Pluggable provisioners and a provisioning circuit breaker

Two operator-quality-of-life features that pair nicely:

• go-plugin provisioners: BMO’s provisioner layer migrated to the go-plugin system (PR #3166), enabling out-of-tree (separately compiled, loaded at runtime) custom provisioners. Your company’s weird bespoke provisioning flow no longer needs a fork of BMO to exist.
• Provisioning retry limit: a new provisioningFailCount status field tracks consecutive provisioning failures, and a --max-provisioning-retries flag (default 5) stops the infinite deprovision-retry-deprovision doom loop when a disk just won’t cooperate (PR #3468). The counter resets on success, when you change the image, or when you remove it; set the flag to 0 if you miss the old unlimited carousel. You can watch it per host:

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: rack2-server-14
status:
  errorCount: 3
  errorMessage: "Provisioning failed: disk sda not found"
  provisioningFailCount: 5

Also worth a nod

• Escape externally-provisioned: hosts managed outside BMO (the “externally provisioned” state) can now exit that state (PR #3181) — previously more of a one-way door.
• TLS curve preferences: you can now set TLS curve preferences (PR #3423), handy for BMCs with strict crypto requirements.
• URL validation webhooks: admission-time validation for URLs (PR #3333) — a webhook is a gate Kubernetes consults before saving an object — catches typos before they become provisioning failures.
• Structured logging: the CAPM3-style structured logging pattern lands in BMO (PR #2943) — your log aggregation will thank you.
• vbmctl grows up: container networking (PR #3241) and veth pair management (PR #3151) make the local dev VM tool far more useful; it’s now built as a release artifact (PR #3493).

Breaking Changes (Read This Before You Upgrade)

Two items flagged in the release notes:

• BMH Taints deprecated (#3465): the Taints field (repel-workload markers borrowed from Kubernetes nodes, balanced by tolerations) on BareMetalHost is deprecated (PR #3465). If your tooling reads or writes taints on hosts, plan the migration now.
• TryInit dropped (#3327): the separate TryInit call — a provisioner hook for retrying failed initializations — was removed from the provisioner interface (PR #3327). In-tree provisioners were updated; custom provisioner authors feel this one.

The Rest of the Story

The changelog also carries 23 bug fixes — including fixes for credentials not persisting while waiting for PreprovisioningImage (the cached boot image BMO prepares for hosts) (PR #3443), OCI pull secret format sent to Ironic (PR #3441), and consistent NeedsMAC semantics across BMC drivers (PR #3382) — plus the usual dependency bumps (Go 1.26.6, k8s v0.36.3, CAPI 1.14.1) and a large e2e test overhaul. No security advisories in this release.

Closing

v0.14.0 is the release where Metal3 stops just managing servers and starts managing the whole metal experience — claims, switches, inspection, and retries included.

Learn More

• metal3-io Official Website
• GitHub Repository
• Full Changelog for v0.14.0