The Metal³ project (pronounced: Metal Kubed) exists to provide components that allow you to do bare metal host management for Kubernetes. Metal³ works as a Kubernetes application, meaning it runs on Kubernetes and is managed through Kubernetes interfaces.

• twitter.com/metal3_io

• Metal³ Development Mailing List
• #cluster-api-baremetal on Kubernetes Slack

Another set of components is being designed and built to provide integration with the Kubernetes Machine API.

This first diagram represents the high level architecture:

The first component is the Bare Metal Actuator, which is an implementation of the Machine Actuator interface defined by the cluster-api project. This actuator reacts to changes to Machine objects and acts as a client of the BareMetalHost custom resources managed by the Bare Metal Operator.

The architecture also includes a new Bare Metal Operator, which includes the following:

• A Controller for a new Custom Resource, BareMetalHost. This custom resource represents an inventory of known (configured or automatically discovered) bare metal hosts. When a Machine is created the Bare Metal Actuator will claim one of these hosts to be provisioned as a new Kubernetes node.
• In response to BareMetalHost updates, will perform bare metal host provisioning actions as necessary to reach the desired state. It will do so by managing and driving a set of underlying bare metal provisioning components.

The creation of the BareMetalHost inventory can be done in two ways:

1. Manually via creating BareMetalHost objects.
2. Optionally, automatically created via a bare metal host discovery process. Ironic is capable of doing this, which will also be integrated into Metal³ as an option.

For more information about Operators, see the operator-sdk.

The implementation will focus on using Ironic as its first implementation of the Bare Metal Management Pods, but aims to keep this as an implementation detail under the hood such that alternatives could be added in the future if the need arises.

For more information about the choice to use Ironic, see the use-ironic design document.

1. Enroll nodes by creating BareMetalHost resources. This would either be manually or done by a component doing node discovery and introspection.

   See the documentation in the baremetal-operator repository for details.

2. Use the machine API to allocate a machine.

   See the documentation in the cluster-api-provider-baremetal repository for details.

3. Machine is associated with an available BareMetalHost, which triggers provisioning of that host to join the cluster. This association is done by the Actuator when it sets the MachineRef field on the BareMetalHost.

• nodes-machines-and-hosts
• use-ironic

• bmc-address
• hardware-status
• how-ironic-works
• image-ownership
• managing-provisioning-dependencies
• worker-config-drive

• physical-network-api-prototype

• Extend Your Data Center to the Hybrid Edge - Red Hat Summit, May 2019
• OpenStack Ironic and Bare Metal Infrastructure: All Abstractions Start Somewhere - Chris Hoge, OpenStack Foundation; Julia Kreger, Red Hat
• Kubernetes-native Infrastructure: Managed Baremetal with Kubernetes Operators and OpenStack Ironic - Steve Hardy, Red Hat

• The New Stack: Metal3 Uses OpenStack’s Ironic for Declarative Bare Metal Kubernetes
• The Register: Raise some horns: Red Hat's MetalKube aims to make Kubernetes on bare machines simple

• Metal³ – Metal Kubed, Bare Metal Provisioning for Kubernetes