Add a bare metal host using CLI¶

This section describes how to add bare metal hosts using the Container Cloud CLI during a managed cluster creation.

To add a bare metal host using API:

Verify that you configured each bare metal host as described in Configure BIOS on a bare metal host.
Optional. Create a custom bare metal host profile depending on your needs as described in Create a custom bare metal host profile.
Log in to the host where your management cluster kubeconfig is located and where kubectl is installed.
Select from the following options:
Since Cluster releases 12.5.0 and 11.5.0
Create a YAML file that describes the unique credentials of the new bare metal host as a BareMetalHostCredential object.

Example of BareMetalHostCredential:
apiVersion: kaas.mirantis.com/v1alpha1 kind: BareMetalHostCredential metadata: labels: kaas.mirantis.com/provider: baremetal kaas.mirantis.com/region: region-one name: <bareMetalHostCredentialUniqueName> namespace: <managedClusterProjectName> spec: username: <ipmiUserName> password: value: <ipmiPassword>
- In the metadata section, add a unique credentials name and the name of the non-default project (namespace) dedicated for the managed cluster being created.
- In the spec section, add the IPMI user name and password in plain text to access the Baseboard Management Controller (BMC). The password will not be stored in the BareMetalHostCredential object but will be erased and saved in an underlying Secret object.
  
  Caution
  
  Each bare metal host must have a unique BareMetalHostCredential.
Note

The kaas.mirantis.com/region label is removed from all Container Cloud objects in 2.26.0 (Cluster releases 17.1.0 and 16.1.0). Therefore, do not add the label starting these releases. On existing clusters updated to these releases, or if manually added, this label will be ignored by Container Cloud.
Before Cluster releases 12.5.0 and 11.5.0
Create a secret YAML file that describes the unique credentials of the new bare metal host.

Example of the bare metal host secret:
apiVersion: v1 data: password: <credentialsPassword> username: <credentialsUserName> kind: Secret metadata: labels: kaas.mirantis.com/credentials: "true" kaas.mirantis.com/provider: baremetal kaas.mirantis.com/region: region-one name: <credentialsName> namespace: <managedClusterProjectName> type: Opaque
- In the data section, add the IPMI user name and password in the base64 encoding to access the BMC. To obtain the base64-encoded credentials, you can use the following command in your Linux console:
  echo -n <username|password> | base64
  Caution
  
  Each bare metal host must have a unique Secret.
- In the metadata section, add the unique name of credentials and the name of the non-default project (namespace) dedicated for the managed cluster being created. To create a project, refer to Create a project for managed clusters.
Apply the created YAML file with credentials to your deployment:

Warning

The kubectl apply command automatically saves the applied data as plain text into the kubectl.kubernetes.io/last-applied-configuration annotation of the corresponding object. This may result in revealing sensitive data in this annotation when creating or modifying the object.

Therefore, do not use kubectl apply on this object. Use kubectl create, kubectl patch, or kubectl edit instead.

If you used kubectl apply on this object, you can remove the kubectl.kubernetes.io/last-applied-configuration annotation from the object using kubectl edit.
```
kubectl create -n <managedClusterProjectName> -f ${<BareMetalHostCredsFileName>}.yaml
```

Create a YAML file that contains a description of the new bare metal host.

Example of the bare metal host configuration file with the worker role:

Since Cluster releases 12.5.0 and 11.5.0

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  annotations:
    kaas.mirantis.com/baremetalhost-credentials-name: <bareMetalHostCredentialUniqueName>
  labels:
    kaas.mirantis.com/baremetalhost-id: <uniqueBareMetalHostHardwareNodeId>
    hostlabel.bm.kaas.mirantis.com/worker: "true"
    kaas.mirantis.com/provider: baremetal
    kaas.mirantis.com/region: region-one
  name: <BareMetalHostUniqueName>
  namespace: <managedClusterProjectName>
spec:
  bmc:
    address: <ipAddressForIpmiAccess>
    credentialsName: ''
  bootMACAddress: <BareMetalHostBootMacAddress>
  online: true

Note

If you have a limited amount of free and unused IP addresses for server provisioning, you can add the baremetalhost.metal3.io/detached annotation that pauses automatic host management to manually allocate an IP address for the host. For details, see Manually allocate IP addresses for bare metal hosts.

Before Cluster releases 12.5.0 and 11.5.0

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  labels:
    kaas.mirantis.com/baremetalhost-id: <uniqueBareMetalHostHardwareNodeId>
    hostlabel.bm.kaas.mirantis.com/worker: "true"
    kaas.mirantis.com/provider: baremetal
    kaas.mirantis.com/region: region-one
  name: <BareMetalHostUniqueName>
  namespace: <managedClusterProjectName>
spec:
  bmc:
    address: <ipAddressForBmcAccess>
    credentialsName: <credentialsSecretName>
  bootMACAddress: <BareMetalHostBootMacAddress>
  online: true

For a detailed fields description, see BareMetalHost.

Apply this configuration YAML file to your deployment:
```
kubectl create -n <managedClusterProjectName> -f ${<BareMetalHostConfigFileName>}.yaml
```
During provisioning, baremetal-operator inspects the bare metal host and moves it to the Preparing state. The host becomes ready to be linked to a bare metal machine.

Verify the new BareMetalHost object status:

kubectl create -n <managedClusterProjectName> get bmh -o wide <BareMetalHostUniqueName>

Example of system response:

NAMESPACE    NAME   STATUS   STATE      CONSUMER  BMC                        BOOTMODE  ONLINE  ERROR  REGION
my-project   bmh1   OK       preparing            ip_address_for-bmc-access  legacy    true           region-one

During provisioning, the status changes as follows:

registering
inspecting
preparing

After BareMetalHost switches to the preparing stage, the inspecting phase finishes and you can verify hardware information available in the object status. For example:

Verify the status of hardware NICs:

kubectl -n <managedClusterProjectName> get bmh -o yaml <BareMetalHostUniqueName> -o json |  jq -r '[.status.hardware.nics]'

Example of system response:

[
  [
    {
      "ip": "172.18.171.32",
      "mac": "ac:1f:6b:02:81:1a",
      "model": "0x8086 0x1521",
      "name": "eno1",
      "pxe": true
    },
    {
      "ip": "fe80::225:90ff:fe33:d5ac%ens1f0",
      "mac": "00:25:90:33:d5:ac",
      "model": "0x8086 0x10fb",
      "name": "ens1f0"
    },
 ...

Verify the status of RAM:

kubectl -n <managedClusterProjectName> get bmh -o yaml <BareMetalHostUniqueName> -o json |  jq -r '[.status.hardware.ramMebibytes]'

Example of system response:

[
  98304
]