Skip to content
Architecture documentation that describes the components being built under MetalKube.
Branch: master
Clone or download
Latest commit 2ae2e35 Apr 24, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
design Rename Metal3 to Metal³ Apr 23, 2019
images Rename MetalKube to Metal3. Apr 23, 2019 Rename MetalKube to Metal3. Apr 23, 2019
DCO Introduce doc. Mar 14, 2019
LICENSE Initial commit Jan 4, 2019 Add twitter link. Apr 24, 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.

apiVersion: ""
kind: Machine
    generateName: baremetal-master-
        set: master
            apiVersion: "baremetalproviderconfig/v1alpha1"
            kind: "BareMetalProviderConfig"
                node-profile: master

apiVersion: ""
kind: Machine
    generateName: baremetal-node-
          set: node
            apiVersion: "baremetalproviderconfig/v1alpha1"
            kind: "BareMetalProviderConfig"
                node-profile: node
  1. 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

You can’t perform that action at this time.