Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!

Starting with MOSK 25.2, the MOSK documentation set covers all product layers, including MOSK management (formerly Container Cloud). This means everything you need is in one place. Some legacy names may remain in the code and documentation and will be updated in future releases. The separate Container Cloud documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Machine resource

This section outlines the Machine resource used in MOSK to describe the machine-level parameters.

For demonstration purposes, the Machine custom resource (CR) is split into the following major sections:

metadata

The Machine CR contains the following fields:

  • apiVersion

    API version of the object that is cluster.k8s.io/v1alpha1.

  • kind

    Object type that is Machine.

The metadata object field of the Machine resource contains the following fields:

  • name

    Name of the Machine object.

  • namespace

    Project in which the Machine object is created.

  • annotations

    Key-value pair to attach arbitrary metadata to the object:

    • metal3.io/BareMetalHost

      Annotation attached to the Machine object to reference the corresponding BareMetalHostInventory object in the <BareMetalHostProjectName/BareMetalHostName> format.

      Note

      Before update of the management cluster to 2.29.0 (Cluster release 16.4.0), instead of BareMetalHostInventory, use the BareMetalHost object. For details, see BareMetalHost resource.

      Caution

      While the Cluster release of the management cluster is 16.4.0, BareMetalHostInventory operations are allowed to m:kaas@management-admin only. This limitation is lifted once the management cluster is updated to the Cluster release 16.4.1 or later.

  • labels

    Key-value pairs that are attached to the object:

    • kaas.mirantis.com/provider

      Provider type that matches the provider type in the Cluster object and must be baremetal.

    • kaas.mirantis.com/region

      Region name that matches the region name in the Cluster object.

      Note

      The kaas.mirantis.com/region label is removed from all MOSK objects in 24.1. Therefore, do not add the label starting with this release. On existing clusters updated to this release, or if added manually, MOSK ignores this label.

    • cluster.sigs.k8s.io/cluster-name

      Cluster name that the Machine object is linked to.

    • cluster.sigs.k8s.io/control-plane

      For the control plane role of a machine, this label contains any value, for example, "true". For the worker role, this label is absent.

    Warning

    Labels and annotations that are not documented in this API Reference are generated automatically. Do not modify them using the API.

Configuration example:

apiVersion: cluster.k8s.io/v1alpha1
kind: Machine
metadata:
  name: example-control-plane
  namespace: example-ns
  annotations:
    metal3.io/BareMetalHost: default/master-0
  labels:
    kaas.mirantis.com/provider: baremetal
    cluster.sigs.k8s.io/cluster-name: example-cluster
    cluster.sigs.k8s.io/control-plane: "true" # remove for worker

spec:providerSpec for instance configuration

The spec object field of the Machine object represents the BareMetalMachineProviderSpec subresource with all required details to create a bare metal instance. It contains the following fields:

  • apiVersion

    API version of the object that is baremetal.k8s.io/v1alpha1.

  • kind

    Object type that is BareMetalMachineProviderSpec.

  • bareMetalHostProfile

    Configuration profile of a bare metal host:

    • name

      Name of a bare metal host profile

    • namespace

      Project in which the bare metal host profile is created.

  • l2TemplateIfMappingOverride

    If specified, overrides the interface mapping value for the corresponding L2Template object.

  • l2TemplateSelector

    Optional. Contains the name (first priority) or label of the L2 template that will be applied during machine creation. The l2TemplateSelector field is copied from providerSpec of the Machine object to the IpamHost object only once, during machine creation. To modify l2TemplateSelector after creation of the Machine object, edit the IpamHost object.

  • hostSelector

    Specifies the matching criteria for labels on the bare metal hosts. Limits the set of the BareMetalHostInventory objects considered for claiming for the Machine object. The following selector labels can be added when creating a machine using the MOSK management console:

    • hostlabel.bm.kaas.mirantis.com/controlplane

    • hostlabel.bm.kaas.mirantis.com/worker

    • hostlabel.bm.kaas.mirantis.com/storage

    Any custom label that is assigned to one or more bare metal hosts using API can be used as a host selector. If the BareMetalHostInventory objects with the specified label are missing, the Machine object will not be deployed until at least one bare metal host with the specified label is available.

    Note

    Before update of the management cluster to 2.29.0 (Cluster release 16.4.0), instead of BareMetalHostInventory, use the BareMetalHost object. For details, see BareMetalHost resource.

    Caution

    While the Cluster release of the management cluster is 16.4.0, BareMetalHostInventory operations are allowed to m:kaas@management-admin only. This limitation is lifted once the management cluster is updated to the Cluster release 16.4.1 or later.

  • nodeLabels

    This field contains the list of node labels to be attached to a node for the user to run certain components on separate cluster nodes. The list of allowed node labels is located in the Cluster object status providerStatus.releaseRef.current.allowedNodeLabels field.

    If the value field is not defined in allowedNodeLabels, a label can have any value. For example:

    allowedNodeLabels:
- displayName: Stacklight
  key: stacklight

    Before or after a machine deployment, add the required label from the allowed node labels list with the corresponding value to spec.providerSpec.value.nodeLabels in machine.yaml. For example:

    nodeLabels:
- key: stacklight
  value: enabled

    Adding of a node label that is not available in the list of allowed node labels is restricted.

  • distribution Mandatory

    Specifies an operating system (OS) distribution ID that is present in the current ClusterRelease object under the AllowedDistributions list. When specified, the BareMetalHostInventory object linked to this Machine object will be provisioned using the selected OS distribution instead of the default one.

    By default, ubuntu/jammy is installed on greenfield MOSK clusters since MOSK 24.3. The default distribution is marked with the boolean flag default inside one of the elements under the AllowedDistributions list.

    The ubuntu/focal distribution was deprecated in MOSK 24.3 and only supported for existing MOSK clusters. MOSK 24.3.x release series is the last one to support Ubuntu 20.04 as the host operating system for MOSK clusters.

    Caution

    The outdated ubuntu/bionic distribution, which is removed in MOSK 23.3, is only supported for existing clusters based on Ubuntu 18.04.

    Warning

    During the course of the Container Cloud 2.28.x series, Mirantis highly recommends upgrading an operating system on any nodes of all your MOSK cluster machines to Ubuntu 22.04 before the next major Cluster release becomes available.

    It is not mandatory to upgrade all machines at once. You can upgrade them one by one or in small batches, for example, if the maintenance window is limited in time.

    Otherwise, the Cluster release update of the Ubuntu 20.04-based MOSK clusters will become impossible as of Container Cloud 2.29.0 with Ubuntu 22.04 as the only supported version.

    Management cluster update to Container Cloud 2.29.1 will be blocked if at least one node of any related MOSK cluster is running Ubuntu 20.04.

    In MOSK management 2.30.0 and MOSK 25.2, the management cluster is automatically upgraded from Ubuntu 22.04 to 24.04. Upgrade of MOSK clusters to Ubuntu 24.04 will become available in one of the following releases.

  • maintenance

    Maintenance mode of a machine. If enabled, the node of the selected machine is drained, cordoned, and prepared for maintenance operations.

  • upgradeIndex (optional)

    Positive numeral value that determines the order of machines upgrade. The first machine to upgrade is always one of the control plane machines with the lowest upgradeIndex. Other control plane machines are upgraded one by one according to their upgrade indexes.

    If the Cluster spec dedicatedControlPlane field is false, worker machines are upgraded only after the upgrade of all control plane machines finishes. Otherwise, they are upgraded after the first control plane machine, concurrently with other control plane machines.

    If two or more machines have the same value of upgradeIndex, these machines are equally prioritized during upgrade.

  • day1Provisioning (optional)

    Available since MOSK management 2.30.0 and MOSK 25.2. Controls the workflow during initial machine provisioning. This field allows operators to manually control the start of baremetal host provisioning, enabling hardware verification before deployment. Possible values:

    • manual

      Default. Requires explicit approval before proceeding with provisioning. The machine enters the AwaitsProvisioning state and waits for an operator to change this field to auto to start provisioning.

    • auto

      Enables provisioning workflow that occurs either automatically from the start or manually after inspection and approval by an operator.

    For details on the controlled provisioning workflow, see Controlled bare metal provisioning workflows.

  • day1Deployment (optional)

    Available since MOSK management 2.30.0 and MOSK 25.2. Controls the workflow of initial machine deployment after provisioning completes. This field allows operators to verify disk layout and other system configuration before proceeding with component deployment. Possible values:

    • manual

      Default. Requires an explicit approval before proceeding with deployment. The machine enters the AwaitsDeployment state after provisioning completes and waits for an operator to change this field to auto to start deployment.

    • auto

      Enables deployment workflow that occurs either automatically from the start or manually after inspection and approval by an operator.

    For details on the controlled deployment workflow, see Controlled bare metal provisioning workflows.

  • deletionPolicy

    Generally available since Container Cloud 2.25.0 (Cluster releases 17.0.0 and 16.0.0). Policy used to identify steps required during a Machine object deletion. Supported policies are as follows:

    • graceful

      Prepares a machine for deletion by cordoning, draining, and removing from Docker Swarm of the related node. Then deletes Kubernetes objects and associated resources. Can be aborted only before a node is removed from Docker Swarm.

    • unsafe

      Default. Deletes Kubernetes objects and associated resources without any preparations.

    • forced

      Deletes Kubernetes objects and associated resources without any preparations. Removes the Machine object even if the cloud provider or LCM Controller gets stuck at some step. May require a manual cleanup of machine resources in case of the controller failure.

    For details on the workflow of machine deletion policies, see Overview of machine deletion policies.

Configuration example:

spec:
  ...
  providerSpec:
    value:
      apiVersion: baremetal.k8s.io/v1alpha1
      kind: BareMetalMachineProviderSpec
      bareMetalHostProfile:
        name: default
        namespace: default
      l2TemplateIfMappingOverride:
        - eno1
        - enp0s0
      l2TemplateSelector:
        label: l2-template1-label-1
      hostSelector:
        matchLabels:
          kaas.mirantis.com/baremetalhost-id: hw-master-0
      kind: BareMetalMachineProviderSpec
      nodeLabels:
      - key: stacklight
        value: enabled
      distribution: ubuntu/jammy
      day1Provisioning: manual # since MOSK management 2.30 and MOSK 25.2
      day1Deployment: manual # since MOSK management 2.30 and MOSK 25.2
      delete: false
      deletionPolicy: graceful

Machine status

The status object field of the Machine object represents the BareMetalMachineProviderStatus subresource that describes the current bare metal instance state and contains the following fields:

  • apiVersion

    API version of the object that is cluster.k8s.io/v1alpha1.

  • kind

    Object type that is BareMetalMachineProviderStatus.

  • hardware

    Provides a machine hardware information:

    • cpu

      Number of CPUs.

    • ram

      RAM capacity in GB.

    • storage

      List of hard drives mounted on the machine. Contains the disk name and size in GB.

  • status

    Represents the current status of a machine:

    • Provision

      A machine is yet to obtain a status

    • AwaitsProvisioning

      Available since MOSK management 2.30.0 and MOSK 25.2. A machine has completed bare metal host inspection and is waiting for an approval from an operator to start provisioning. Applies when day1Provisioning is set to manual or unset.

    • Uninitialized

      A machine is yet to obtain the node IP address and host name

    • Pending

      A machine is yet to receive the deployment instructions and it is either not booted yet or waits for the LCM controller to be deployed

    • Prepare

      A machine is running the Prepare phase during which Docker images and packages are being predownloaded

    • Deploy

      A machine is processing the LCM Controller instructions

    • AwaitsDeployment

      Available since MOSK management 2.30.0 and MOSK 25.2. A machine has completed provisioning and is waiting for an approval from an operator to start deployment. Applies when day1Deployment is set to manual or unset.

    • Reconfigure

      A machine is being updated with a configuration without affecting workloads running on the machine

    • Ready

      A machine is deployed and the supported Mirantis Kubernetes Engine (MKE) version is set

    • Maintenance

      A machine host is cordoned, drained, and prepared for maintenance operations

  • currentDistribution

    Generally available since Container Cloud 2.24.2 (Cluster releases 15.0.1 and 14.0.1). Distribution ID of the current operating system installed on the machine. For example, ubuntu/jammy.

  • maintenance

    Maintenance mode of a machine. If enabled, the node of the selected machine is drained, cordoned, and prepared for maintenance operations.

  • reboot

    Available since Container Cloud 2.22.0 (Cluster release 11.6.0). Indicator of a host reboot to complete the Ubuntu operating system updates, if any.

    • required

      Specifies whether a host reboot is required. Boolean. If true, a manual host reboot is required.

    • reason

      Specifies the package name(s) to apply during a host reboot.

  • upgradeIndex

    Positive numeral value that determines the order of machines upgrade. If upgradeIndex in the Machine object spec is set, this status value equals the one in the spec. Otherwise, this value displays the automatically generated order of upgrade.

  • delete

    Generally available since Container Cloud 2.25.0 (Cluster releases 17.0.0 and 16.0.0). Start of a machine deletion or a successful abortion. Boolean.

  • prepareDeletionPhase

    Generally available since Container Cloud 2.25.0 (Cluster releases 17.0.0 and 16.0.0). Preparation phase for a graceful machine deletion. Possible values are as follows:

    • started

      The provider controller prepares a machine for deletion by cordoning, draining the machine, and so on.

    • completed

      LCM Controller starts removing the machine resources since the preparation for deletion is complete.

    • aborting

      The provider controller attempts to uncordon the node. If the attempt fails, the status changes to failed.

    • failed

      Error in the deletion workflow.

    For the workflow description of a graceful deletion, see Overview of machine deletion policies.

Configuration example:

status:
  providerStatus:
    apiVersion: baremetal.k8s.io/v1alpha1
    kind: BareMetalMachineProviderStatus
    hardware:
      cpu: 11
      ram: 16
    storage:
      - name: /dev/vda
        size: 61
      - name: /dev/vdb
        size: 32
      - name: /dev/vdc
        size: 32
    reboot:
      required: true
      reason: |
        linux-image-5.13.0-51-generic
        linux-base
    status: Ready
    upgradeIndex: 1