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
spec:providerSpec for instance configuration
Machine status

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 Container Cloud 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 Container Cloud web UI:
- 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 Container Cloud 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 MOSK 24.3 and Container Cloud 2.28.x series, Mirantis highly recommends upgrading an operating system on your cluster machines to Ubuntu 22.04 before the following major 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.

The Cluster release update of the Ubuntu 20.04-based MOSK clusters will become impossible as of Container Cloud 2.29.0, where Ubuntu 22.04 is 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.
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.
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
      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
- 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
- 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