Skip to content
Architecture documentation that describes the components being built under Metal³.
Branch: master
Clone or download
dhellmann Merge pull request #36 from russellb/api-docs
Add pointer to current cluster-api integration API docs.
Latest commit 20fe9c8 May 14, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
design Rename Metal3 to Metal³ Apr 23, 2019
images URL update to stickers May 2, 2019 Rename MetalKube to Metal3. Apr 23, 2019
DCO Introduce doc. Mar 14, 2019
LICENSE Initial commit Jan 4, 2019 Add pointer to current cluster-api integration API docs. May 14, 2019

Metal³ Documentation

Metal³ Logo

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.

Social Media

Project Discussion

Metal³ Component Overview

Machine API Integration

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:

High Level Architecture

Machine API Actuator

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.

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 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.

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.


  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.

Design Documents

Overall Architecture

Implementation Details

Around the Web

Conference Talks

In The News

Blog Posts

You can’t perform that action at this time.