1 Metal³を使用したBMCの自動デプロイメント #

Metal³は、Kubernetesにベアメタルインフラストラクチャ管理機能を提供するCNCFプロジェクトです。

Metal³は、Redfishなどのアウトオブバンドプロトコルを介した管理をサポートするベアメタルサーバのライフサイクルを管理するためのKubernetesネイティブリソースを提供します。

また、Cluster API (CAPI)も十分にサポートされており、広く採用されているベンダニュートラルなAPIを使用して、複数のインフラストラクチャプロバイダにわたってインフラストラクチャリソースを管理できます。

1.1 この方法を使用する理由 #

この方法は、ターゲットハードウェアがアウトオブバンド管理をサポートしていて、完全に自動化されたインフラストラクチャ管理フローが望まれるシナリオで役立ちます。

管理クラスタは宣言型APIを提供するように設定されており、このAPIによってダウンストリームクラスタのベアメタルサーバのインベントリと状態を管理できます。これには、自動検査、クリーニング、プロビジョニング/プロビジョニング解除も含まれます。

1.2 高レベルアーキテクチャ #

1.3 前提条件 #

ダウンストリームクラスタのサーバハードウェアとネットワーキングに関連する固有の制約がいくつかあります。

管理クラスタ
- ターゲットサーバ管理/BMC APIへのネットワーク接続が必要
- ターゲットサーバのコントロールプレーンネットワークへのネットワーク接続が必要
- マルチノード管理クラスタの場合、追加の予約済みIPアドレスが必要
制御対象ホスト
- Redfish、iDRAC、またはiLOのインタフェースを介したアウトオブバンド管理のサポートが必要
- 仮想メディアを使用したデプロイメントのサポートが必要(PXEは現在サポートされていない)
- Metal³プロビジョニングAPIにアクセスするために管理クラスタへのネットワーク接続が必要

ツールがいくつか必要です。ツールは管理クラスタにインストールするか、管理クラスタにアクセス可能なホストにインストールできます。

Kubectl、Helm、およびClusterctl
PodmanやRancher Desktopなどのコンテナランタイム

SL-Micro.x86_64-6.1-Base-GM.raw OSイメージファイルはSUSE Customer CenterまたはSUSEダウンロードページからダウンロードする必要があります。

1.3.1 管理クラスタのセットアップ #

管理クラスタをインストールし、Metal³を使用する基本的な手順は次のとおりです。

RKE2管理クラスタをインストールします。
Rancherのインストール
ストレージプロバイダをインストールします(オプション)。
Metal³の依存関係をインストールします。
Rancher Turtles経由でCAPIの依存関係をインストールします。
ダウンストリームクラスタホスト用のSLEMicro OSイメージを構築します。
BareMetalHost CRを登録し、ベアメタルのインベントリを定義します。
CAPIリソースを定義して、ダウンストリームクラスタを作成します。

このガイドでは、既存のRKE2クラスタとRancher (cert-managerを含む)が、たとえばEdge Image Builder (第11章「Edge Image Builder」)を使用してインストールされていることを前提としています。

ヒント

ここでの手順は、管理クラスタのドキュメント(第40章「管理クラスタの設定」)で説明されているように、完全に自動化することもできます。

1.3.2 Metal³の依存関係のインストール #

cert-managerがまだRancherのインストールの一部としてインストールされていない場合は、cert-managerをインストールして実行する必要があります。

永続ストレージプロバイダをインストールする必要があります。SUSE Storageを推奨しますが、開発/PoC環境ではlocal-path-provisionerを使用することもできます。以下の手順は、StorageClassがデフォルトとしてマークされていることを前提としています。マークされていない場合は、Metal³チャートに追加の設定が必要です。

追加のIPが必要です。このIPはMetalLBによって管理され、Metal³管理サービスに一貫したエンドポイントを提供します。このIPは、コントロールプレーンサブネットに属していて、静的設定用に予約されている必要があります(どのDHCPプールにも属していてはなりません)。

ヒント

管理クラスタがシングルノードである場合、MetalLBを介して管理されるフローティングIPを追加する必要はありません。1.6.1項「シングルノード設定」を参照してください。

まず、MetalLBをインストールします。

helm install \
  metallb oci://registry.suse.com/edge/charts/metallb \
  --namespace metallb-system \
  --create-namespace

続いて、次のように、STATIC_IRONIC_IPとして定義された予約済みIPを使用して、IPAddressPoolと L2Advertisementを定義します。

export STATIC_IRONIC_IP=<STATIC_IRONIC_IP>

cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ironic-ip-pool
  namespace: metallb-system
spec:
  addresses:
  - ${STATIC_IRONIC_IP}/32
  serviceAllocation:
    priority: 100
    serviceSelectors:
    - matchExpressions:
      - {key: app.kubernetes.io/name, operator: In, values: [metal3-ironic]}
EOF

cat <<-EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: ironic-ip-pool-l2-adv
  namespace: metallb-system
spec:
  ipAddressPools:
  - ironic-ip-pool
EOF

これでMetal³をインストールできます。

helm install \
  metal3 oci://registry.suse.com/edge/charts/metal3 \
  --namespace metal3-system \
  --create-namespace \
  --set global.ironicIP="$STATIC_IRONIC_IP"

initコンテナがこのデプロイメントで実行されるまで約2分かかる場合があるため、続行する前にPodがすべて実行されていることを確認します。

kubectl get pods -n metal3-system
NAME                                                    READY   STATUS    RESTARTS   AGE
baremetal-operator-controller-manager-85756794b-fz98d   2/2     Running   0          15m
metal3-metal3-ironic-677bc5c8cc-55shd                   4/4     Running   0          15m
metal3-metal3-mariadb-7c7d6fdbd8-64c7l                  1/1     Running   0          15m

警告

metal3-systemネームスペースのすべてのPodが実行されるまで、以下の手順に進まないでください。

1.3.3 Cluster APIの依存関係のインストール #

Cluster APIの依存関係は、Rancher Turtles Helmチャートで管理されます。

cat > values.yaml <<EOF
rancherTurtles:
  features:
    embedded-capi:
      disabled: true
    rancher-webhook:
      cleanup: true
EOF

helm install \
  rancher-turtles oci://registry.suse.com/edge/charts/rancher-turtles \
  --namespace rancher-turtles-system \
  --create-namespace \
  -f values.yaml

しばらくすると、コントローラPodがcapi-system、capm3-system、rke2-bootstrap-system、およびrke2-control-plane-systemの各ネームスペースで実行されているはずです。

1.3.4 ダウンストリームクラスタイメージの準備 #

Kiwi (第28章「Kiwiを使用したSUSE Linux Microの更新イメージの構築」)とEdge Image Builder (第11章「Edge Image Builder」)を使用して、ダウンストリームクラスタホスト上にプロビジョニングされる、変更されたSLEMicroゴールデンイメージを準備します。

このガイドではダウンストリームクラスタをデプロイするために必要な最小限の設定について説明します。

1.3.4.1 イメージの設定 #

注記

クラスタの作成に必要な最初の手順として、まず第28章「Kiwiを使用したSUSE Linux Microの更新イメージの構築」に従って、新しいイメージを構築してください。

Edge Image Builderを実行すると、そのホストからディレクトリがマウントされるため、ターゲットイメージの定義に使用する設定ファイルを保存するディレクトリ構造を作成する必要があります。

downstream-cluster-config.yamlはイメージ定義ファイルです。詳細については、第3章「Edge Image Builderを使用したスタンドアロンクラスタ」を参照してください。
ダウンロードされたゴールデンイメージはxzで圧縮されているので、unxzで展開し、base-imagesフォルダの下にコピー/移動する必要があります。
networkフォルダはオプションです。詳細については、1.3.5.1.1項「静的ネットワーク設定用の追加スクリプト」を参照してください。
custom/scriptsディレクトリには、初回ブート時に実行するスクリプトが含まれます。現在、デプロイメントのOSルートパーティションのサイズを変更するには、01-fix-growfs.shスクリプトが必要です。

├── downstream-cluster-config.yaml
├── base-images/
│   └ SL-Micro.x86_64-6.1-Base-GM.raw
├── network/
|   └ configure-network.sh
└── custom/
    └ scripts/
        └ 01-fix-growfs.sh

1.3.4.1.1 ダウンストリームクラスタイメージ定義ファイル #

downstream-cluster-config.yamlファイルは、ダウンストリームクラスタイメージの主要な設定ファイルです。次に、Metal³を介したデプロイメントの最小例を示します。

apiVersion: 1.2
image:
  imageType: raw
  arch: x86_64
  baseImage: SL-Micro.x86_64-6.1-Base-GM.raw
  outputImageName: SLE-Micro-eib-output.raw
operatingSystem:
  time:
    timezone: Europe/London
    ntp:
      forceWait: true
      pools:
        - 2.suse.pool.ntp.org
      servers:
        - 10.0.0.1
        - 10.0.0.2
  kernelArgs:
    - ignition.platform.id=openstack
    - net.ifnames=1
  systemd:
    disable:
      - rebootmgr
      - transactional-update.timer
      - transactional-update-cleanup.timer
  users:
    - username: root
      encryptedPassword: $ROOT_PASSWORD
      sshKeys:
      - $USERKEY1
  packages:
    packageList:
      - jq
  sccRegistrationCode: $SCC_REGISTRATION_CODE

ここで、$SCC_REGISTRATION_CODEはSUSE Customer Centerからコピーした登録コードで、パッケージリストには必要なjqが含まれています。

$ROOT_PASSWORDはルートユーザの暗号化パスワードで、テスト/デバッグに役立ちます。このパスワードは、openssl passwd -6 PASSWORDコマンドで生成できます。

運用環境では、$USERKEY1を実際のSSHキーに置き換えて、usersブロックに追加できるSSHキーを使用することをお勧めします。

注記

net.ifnames=1は、Predictable Network Interface Namingを有効にします。

これはMetal³チャートのデフォルト設定と一致しますが、この設定は、設定されたチャートのpredictableNicNamesの値と一致する必要があります。

また、ignition.platform.id=openstackは必須であり、この引数がないと、Metal³の自動化フローでIgnitionによるSUSE Linux Microの設定が失敗することにも注意してください。

timeセクションはオプションですが、証明書とクロックスキューに関する潜在的な問題を避けるために、設定することを強くお勧めします。この例で指定されている値は説明のみを目的としています。ご自身の特定の要件に合わせて調整してください。

1.3.4.1.2 Growfsスクリプト #

現在、プロビジョニング後の初回ブート時にディスクサイズに合わせてファイルシステムを拡張するには、カスタムスクリプト(custom/scripts/01-fix-growfs.sh)が必要です。01-fix-growfs.shスクリプトには次の情報が含まれます。

#!/bin/bash
growfs() {
  mnt="$1"
  dev="$(findmnt --fstab --target ${mnt} --evaluate --real --output SOURCE --noheadings)"
  # /dev/sda3 -> /dev/sda, /dev/nvme0n1p3 -> /dev/nvme0n1
  parent_dev="/dev/$(lsblk --nodeps -rno PKNAME "${dev}")"
  # Last number in the device name: /dev/nvme0n1p42 -> 42
  partnum="$(echo "${dev}" | sed 's/^.*[^0-9]\([0-9]\+\)$/\1/')"
  ret=0
  growpart "$parent_dev" "$partnum" || ret=$?
  [ $ret -eq 0 ] || [ $ret -eq 1 ] || exit 1
  /usr/lib/systemd/systemd-growfs "$mnt"
}
growfs /

注記

同じアプローチを使用して、プロビジョニングプロセス中に実行する独自のカスタムスクリプトを追加します。詳細については、第3章「Edge Image Builderを使用したスタンドアロンクラスタ」を参照してください。

1.3.4.2 イメージの作成 #

これまでのセクションに従ってディレクトリ構造を準備したら、次のコマンドを実行してイメージを構築します。

podman run --rm --privileged -it -v $PWD:/eib \
 registry.suse.com/edge/3.3/edge-image-builder:1.2.1 \
 build --definition-file downstream-cluster-config.yaml

これにより、上記の定義に基づいて、SLE-Micro-eib-output.rawという名前の出力イメージファイルが作成されます。

その後、この出力イメージをWebサーバ経由で利用できるようにする必要があります。その際、Metal3チャートを使用して有効にしたメディアサーバコンテナ(注記)か、ローカルにアクセス可能な他のサーバのいずれかを使用します。以下の例では、このサーバをimagecache.local:8080として参照します。

注記

EIBイメージをダウンストリームクラスタにデプロイする際は、Metal3MachineTemplateオブジェクトにイメージのSHA256ハッシュ値を含める必要があります。これは次のように生成できます:

sha256sum <image_file> > <image_file>.sha256
# On this example:
sha256sum SLE-Micro-eib-output.raw > SLE-Micro-eib-output.raw.sha256

1.3.5 BareMetalHostインベントリの追加 #

自動デプロイメント用にベアメタルサーバを登録するには、リソースを2つ作成する必要があります。BMCアクセス資格情報を保存するシークレットと、BMC接続とその他の詳細を定義するMetal³ BareMetalHostリソースです。

apiVersion: v1
kind: Secret
metadata:
  name: controlplane-0-credentials
type: Opaque
data:
  username: YWRtaW4=
  password: cGFzc3dvcmQ=
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: controlplane-0
  labels:
    cluster-role: control-plane
spec:
  online: true
  bootMACAddress: "00:f3:65:8a:a3:b0"
  bmc:
    address: redfish-virtualmedia://192.168.125.1:8000/redfish/v1/Systems/68bd0fb6-d124-4d17-a904-cdf33efe83ab
    disableCertificateVerification: true
    credentialsName: controlplane-0-credentials

次の点に注意してください。

シークレットのユーザ名/パスワードはbase64でエンコードされている必要があります。また、末尾に改行を含めないでください(たとえば、単なるechoではなく、echo ‑nを使用してください)。
cluster-roleラベルは、この時点で設定することも、後でクラスタの作成時に設定することもできます。以下の例では、control-planeまたはworkerを想定しています。
bootMACAddressは、ホストのコントロールプレーンNICに一致する有効なMACである必要があります。
bmcのアドレスはBMC管理APIへの接続です。次のアドレスがサポートされています。
- redfish-virtualmedia://<IP ADDRESS>/redfish/v1/Systems/<SYSTEM ID>: Redfish仮想メディア(たとえば、SuperMicro)
- idrac-virtualmedia://<IP ADDRESS>/redfish/v1/Systems/System.Embedded.1: Dell iDRAC
BareMetalHost APIの詳細については、アップストリームのAPIドキュメントを参照してください。

1.3.5.1 静的IPの設定 #

上記のBareMetalHostの例では、DHCPでコントロールプレーンネットワークの設定を提供することを想定していますが、静的IPなどの手動設定が必要なシナリオでは、以下に説明するように追加の設定を指定できます。

1.3.5.1.1 静的ネットワーク設定用の追加スクリプト #

Edge Image Builderでゴールデンイメージを作成する際には、networkフォルダ内に次のconfigure-network.shファイルを作成します。

このファイルにより、初回ブート時に設定ドライブのデータを使用して、NM Configuratorツールを使ってホストネットワーキングを設定します。

#!/bin/bash

set -eux

# Attempt to statically configure a NIC in the case where we find a network_data.json
# In a configuration drive

CONFIG_DRIVE=$(blkid --label config-2 || true)
if [ -z "${CONFIG_DRIVE}" ]; then
  echo "No config-2 device found, skipping network configuration"
  exit 0
fi

mount -o ro $CONFIG_DRIVE /mnt

NETWORK_DATA_FILE="/mnt/openstack/latest/network_data.json"

if [ ! -f "${NETWORK_DATA_FILE}" ]; then
  umount /mnt
  echo "No network_data.json found, skipping network configuration"
  exit 0
fi

DESIRED_HOSTNAME=$(cat /mnt/openstack/latest/meta_data.json | tr ',{}' '\n' | grep '\"metal3-name\"' | sed 's/.*\"metal3-name\": \"\(.*\)\"/\1/')
echo "${DESIRED_HOSTNAME}" > /etc/hostname

mkdir -p /tmp/nmc/{desired,generated}
cp ${NETWORK_DATA_FILE} /tmp/nmc/desired/_all.yaml
umount /mnt

./nmc generate --config-dir /tmp/nmc/desired --output-dir /tmp/nmc/generated
./nmc apply --config-dir /tmp/nmc/generated

1.3.5.1.2 ホストネットワーク設定の追加シークレット #

NM Configurator (第12章「Edgeネットワーキング」)でサポートされているnmstate形式のデータを含む追加シークレットをホストごとに定義できます。

その後、このシークレットは、BareMetalHostリソースでpreprovisioningNetworkDataNameの指定フィールドを使用して参照されます。

apiVersion: v1
kind: Secret
metadata:
  name: controlplane-0-networkdata
type: Opaque
stringData:
  networkData: |
    interfaces:
    - name: enp1s0
      type: ethernet
      state: up
      mac-address: "00:f3:65:8a:a3:b0"
      ipv4:
        address:
        - ip:  192.168.125.200
          prefix-length: 24
        enabled: true
        dhcp: false
    dns-resolver:
      config:
        server:
        - 192.168.125.1
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: 192.168.125.1
        next-hop-interface: enp1s0
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: controlplane-0
  labels:
    cluster-role: control-plane
spec:
  preprovisioningNetworkDataName: controlplane-0-networkdata
# Remaining content as in previous example

注記

状況によっては、MACアドレスが省略される場合があります。詳細については、12.5.8項「統合されたノード設定」を参照してください。

1.3.5.2 BareMetalHostの準備 #

上記の説明に従ってBareMetalHostリソースと関連するシークレットを作成すると、次のようにホスト準備ワークフローがトリガされます。

ターゲットホストのBMCに接続された仮想メディアによってramdiskイメージがブートされる
ramdiskがハードウェア詳細を検査し、ホストをプロビジョニング用に準備する(たとえば、ディスクから以前のデータを消去する)
このプロセスが完了すると、BareMetalHostのstatus.hardwareフィールドのハードウェア詳細が更新され、検証可能になる

このプロセスには数分かかる場合がありますが、完了すると、BareMetalHostの状態がavailableになります。

% kubectl get baremetalhost
NAME             STATE       CONSUMER   ONLINE   ERROR   AGE
controlplane-0   available              true             9m44s
worker-0         available              true             9m44s

1.3.6 ダウンストリームクラスタの作成 #

続いて、ダウンストリームクラスタを定義するCluster APIリソースと、BareMetalHostリソースをプロビジョニングしてからブートストラップを実行してRKE2クラスタを形成するマシンリソースを作成します。

1.3.7 コントロールプレーンのデプロイメント #

コントロールプレーンをデプロイするために、以下のリソースを含む次のようなyamlマニフェストを定義します。

クラスタリソースでは、クラスタ名、ネットワーク、およびコントロールプレーン/インフラストラクチャプロバイダのタイプ(この場合はRKE2/Metal3)を定義します。
Metal3Clusterでは、コントロールプレーンのエンドポイント(シングルノードの場合はホストIP、マルチノードの場合はLoadBalancerエンドポイント。この例ではシングルノードを想定)を定義します。
RKE2ControlPlaneでは、RKE2のバージョンと、クラスタのブートストラップ時に必要な追加設定を定義します。
Metal3MachineTemplateではBareMetalHostリソースに適用するOSイメージを定義し、hostSelectorでは使用するBareMetalHostを定義します。
Metal3DataTemplateでは、BareMetalHostに渡す追加のメタデータを定義します(networkDataは現在のところEdgeソリューションではサポートされていないことに注意してください)。

注記

簡潔にするため、この例では、BareMetalHostのIPアドレスが192.168.125.200で設定されている単一ノードのコントロールプレーンを想定しています。より高度なマルチノードの例については、第42章「完全に自動化されたダイレクトネットワークプロビジョニング」を参照してください。

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: sample-cluster
  namespace: default
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 192.168.0.0/18
    services:
      cidrBlocks:
        - 10.96.0.0/12
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: RKE2ControlPlane
    name: sample-cluster
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3Cluster
    name: sample-cluster
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3Cluster
metadata:
  name: sample-cluster
  namespace: default
spec:
  controlPlaneEndpoint:
    host: 192.168.125.200
    port: 6443
  noCloudProvider: true
---
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: sample-cluster
  namespace: default
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3MachineTemplate
    name: sample-cluster-controlplane
  replicas: 1
  version: v1.32.4+rke2r1
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  agentConfig:
    format: ignition
    kubelet:
      extraArgs:
        - provider-id=metal3://BAREMETALHOST_UUID
    additionalUserData:
      config: |
        variant: fcos
        version: 1.4.0
        systemd:
          units:
            - name: rke2-preinstall.service
              enabled: true
              contents: |
                [Unit]
                Description=rke2-preinstall
                Wants=network-online.target
                Before=rke2-install.service
                ConditionPathExists=!/run/cluster-api/bootstrap-success.complete
                [Service]
                Type=oneshot
                User=root
                ExecStartPre=/bin/sh -c "mount -L config-2 /mnt"
                ExecStart=/bin/sh -c "sed -i \"s/BAREMETALHOST_UUID/$(jq -r .uuid /mnt/openstack/latest/meta_data.json)/\" /etc/rancher/rke2/config.yaml"
                ExecStart=/bin/sh -c "echo \"node-name: $(jq -r .name /mnt/openstack/latest/meta_data.json)\" >> /etc/rancher/rke2/config.yaml"
                ExecStartPost=/bin/sh -c "umount /mnt"
                [Install]
                WantedBy=multi-user.target
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: sample-cluster-controlplane
  namespace: default
spec:
  template:
    spec:
      dataTemplate:
        name: sample-cluster-controlplane-template
      hostSelector:
        matchLabels:
          cluster-role: control-plane
      image:
        checksum: http://imagecache.local:8080/SLE-Micro-eib-output.raw.sha256
        checksumType: sha256
        format: raw
        url: http://imagecache.local:8080/SLE-Micro-eib-output.raw
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3DataTemplate
metadata:
  name: sample-cluster-controlplane-template
  namespace: default
spec:
  clusterName: sample-cluster
  metaData:
    objectNames:
      - key: name
        object: machine
      - key: local-hostname
        object: machine
      - key: local_hostname
        object: machine

自身の環境に合わせて調整したら、kubectlを使用して例を適用し、その後 clusterctlを使用してクラスタのステータスを監視できます。

% kubectl apply -f rke2-control-plane.yaml

# Wait for the cluster to be provisioned
% clusterctl describe cluster sample-cluster
NAME                                                    READY  SEVERITY  REASON  SINCE  MESSAGE
Cluster/sample-cluster                                  True                     22m
├─ClusterInfrastructure - Metal3Cluster/sample-cluster  True                     27m
├─ControlPlane - RKE2ControlPlane/sample-cluster        True                     22m
│ └─Machine/sample-cluster-chflc                        True                     23m

1.3.8 ワーカー/コンピュートのデプロイメント #

コントロールプレーンのデプロイメントと同様に、次のリソースを含むYAMLマニフェストを定義します。

MachineDeploymentでは、レプリカ(ホスト)の数とブートストラップ/インフラストラクチャプロバイダ(この場合はRKE2/Metal3)を定義します。
RKE2ConfigTemplateでは、エージェントホストのブートストラップ用のRKE2のバージョンと初回ブート設定を記述します。
Metal3MachineTemplateではBareMetalHostリソースに適用するOSイメージを定義し、hostSelectorでは使用するBareMetalHostを定義します。
Metal3DataTemplateでは、BareMetalHostに渡す追加のメタデータを定義します(networkDataは現在サポートされていないことに注意してください)。

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  labels:
    cluster.x-k8s.io/cluster-name: sample-cluster
  name: sample-cluster
  namespace: default
spec:
  clusterName: sample-cluster
  replicas: 1
  selector:
    matchLabels:
      cluster.x-k8s.io/cluster-name: sample-cluster
  template:
    metadata:
      labels:
        cluster.x-k8s.io/cluster-name: sample-cluster
    spec:
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1alpha1
          kind: RKE2ConfigTemplate
          name: sample-cluster-workers
      clusterName: sample-cluster
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: Metal3MachineTemplate
        name: sample-cluster-workers
      nodeDrainTimeout: 0s
      version: v1.32.4+rke2r1
---
apiVersion: bootstrap.cluster.x-k8s.io/v1alpha1
kind: RKE2ConfigTemplate
metadata:
  name: sample-cluster-workers
  namespace: default
spec:
  template:
    spec:
      agentConfig:
        format: ignition
        version: v1.32.4+rke2r1
        kubelet:
          extraArgs:
            - provider-id=metal3://BAREMETALHOST_UUID
        additionalUserData:
          config: |
            variant: fcos
            version: 1.4.0
            systemd:
              units:
                - name: rke2-preinstall.service
                  enabled: true
                  contents: |
                    [Unit]
                    Description=rke2-preinstall
                    Wants=network-online.target
                    Before=rke2-install.service
                    ConditionPathExists=!/run/cluster-api/bootstrap-success.complete
                    [Service]
                    Type=oneshot
                    User=root
                    ExecStartPre=/bin/sh -c "mount -L config-2 /mnt"
                    ExecStart=/bin/sh -c "sed -i \"s/BAREMETALHOST_UUID/$(jq -r .uuid /mnt/openstack/latest/meta_data.json)/\" /etc/rancher/rke2/config.yaml"
                    ExecStart=/bin/sh -c "echo \"node-name: $(jq -r .name /mnt/openstack/latest/meta_data.json)\" >> /etc/rancher/rke2/config.yaml"
                    ExecStartPost=/bin/sh -c "umount /mnt"
                    [Install]
                    WantedBy=multi-user.target
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: sample-cluster-workers
  namespace: default
spec:
  template:
    spec:
      dataTemplate:
        name: sample-cluster-workers-template
      hostSelector:
        matchLabels:
          cluster-role: worker
      image:
        checksum: http://imagecache.local:8080/SLE-Micro-eib-output.raw.sha256
        checksumType: sha256
        format: raw
        url: http://imagecache.local:8080/SLE-Micro-eib-output.raw
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3DataTemplate
metadata:
  name: sample-cluster-workers-template
  namespace: default
spec:
  clusterName: sample-cluster
  metaData:
    objectNames:
      - key: name
        object: machine
      - key: local-hostname
        object: machine
      - key: local_hostname
        object: machine

上記の例をコピーし、自身の環境に合わせて調整したら、kubectlを使用して適用し、clusterctlでクラスタのステータスを監視できます。

% kubectl apply -f rke2-agent.yaml

# Wait for the worker nodes to be provisioned
% clusterctl describe cluster sample-cluster
NAME                                                    READY  SEVERITY  REASON  SINCE  MESSAGE
Cluster/sample-cluster                                  True                     25m
├─ClusterInfrastructure - Metal3Cluster/sample-cluster  True                     30m
├─ControlPlane - RKE2ControlPlane/sample-cluster        True                     25m
│ └─Machine/sample-cluster-chflc                        True                     27m
└─Workers
  └─MachineDeployment/sample-cluster                    True                     22m
    └─Machine/sample-cluster-56df5b4499-zfljj           True                     23m

1.3.9 クラスタのプロビジョニング解除 #

ダウンストリームクラスタをプロビジョニング解除するには、上記の作成手順で適用したリソースを削除します。

% kubectl delete -f rke2-agent.yaml
% kubectl delete -f rke2-control-plane.yaml

これにより、BareMetalHostリソースのプロビジョニング解除がトリガされます。これには数分かかることがあり、その後リソースは再び利用可能な状態になります。

% kubectl get bmh
NAME             STATE            CONSUMER                            ONLINE   ERROR   AGE
controlplane-0   deprovisioning   sample-cluster-controlplane-vlrt6   false            10m
worker-0         deprovisioning   sample-cluster-workers-785x5        false            10m

...

% kubectl get bmh
NAME             STATE       CONSUMER   ONLINE   ERROR   AGE
controlplane-0   available              false            15m
worker-0         available              false            15m

1.4 既知の問題 #

現在、アップストリームのIPアドレス管理コントローラはサポートされていません。このコントローラには、SLEMicroで選択されているネットワーク設定ツールと初回ブートツールチェーンとの互換性がまだないためです。
関連して、 IPAMリソースと、Metal3DataTemplateのnetworkDataフィールドは現在のところサポートされていません。
redfish-virtualmediaを介したデプロイメントのみが現在サポートされています。

1.5 予定されている変更 #

networkDataフィールドを使用した、IPAMリソースと設定のサポートの有効化

1.6 追加のリソース #

SUSE Edge for Telcoドキュメント(第37章「SUSE Edge for Telco」)には、通信事業者のユースケースにおける Metal³のより高度な使用例が記載されています。

1.6.1 シングルノード設定 #

管理クラスタがシングルノードであるテスト/PoC環境では、MetalLBを介して管理されるフローティングIPを追加する必要はありません。

このモードでは、管理クラスタAPIのエンドポイントが管理クラスタのIPになるため、DHCPを使用している場合はそのIPを予約するか、管理クラスタのIPが変更されないように静的に設定する必要があります(以下では<MANAGEMENT_CLUSTER_IP>と表記しています)。

このシナリオを有効にするために必要なMetal³チャートの値は次のとおりです。

global:
  ironicIP: <MANAGEMENT_CLUSTER_IP>
metal3-ironic:
  service:
    type: NodePort

1.6.2 仮想メディアISOをアタッチするためのTLSの無効化 #

一部のサーバベンダは、仮想メディアISOイメージをBMCにアタッチする際にSSL接続を検証しますが、Metal³のデプロイメント用に生成された証明書は自己署名されているため、問題が発生する可能性があります。この問題を回避するには、次のようなMetal³チャートの値を使用して、仮想メディアディスクをアタッチする場合にのみTLSを無効にすることができます。

global:
  enable_vmedia_tls: false

別の解決策は、CA証明書を使用してBMCを設定することです。この場合、kubectlを使用してクラスタから証明書を読み込むことができます。

kubectl get secret -n metal3-system ironic-vmedia-cert -o yaml

これにより、証明書をサーバのBMCコンソールで設定できますが、そのプロセスはベンダ固有です(すべてのベンダで可能というわけではなく、可能でない場合はenable_vmedia_tlsフラグが必要なことがあります)。

1.6.3 ストレージ設定 #

管理クラスタがシングルノードであるテスト/PoC環境では、永続ストレージは不要ですが、運用ユースケースでは管理クラスタにSUSE Storage (Longhorn)をインストールすることをお勧めします。これによりPodの再起動/再スケジュール時にMetal³に関連するイメージを保持できます。

この永続ストレージを有効にするために必要なMetal³チャート値は次のとおりです。

metal3-ironic:
  persistence:
    ironic:
      size: "5Gi"

SUSE Edge for Telco管理クラスタのドキュメント(第40章「管理クラスタの設定」)には、永続ストレージを使用した管理クラスタの設定方法に関する詳細が記載されています。

1 Metal3を使用したBMCの自動デプロイメント #

1.1 この方法を使用する理由 #

1.2 高レベルアーキテクチャ #

1.3 前提条件 #

1.3.1 管理クラスタのセットアップ #

1.3.2 Metal3の依存関係のインストール #

1.3.3 Cluster APIの依存関係のインストール #

1.3.4 ダウンストリームクラスタイメージの準備 #

1.3.4.1 イメージの設定 #

1.3.4.1.1 ダウンストリームクラスタイメージ定義ファイル #

1.3.4.1.2 Growfsスクリプト #

1.3.4.2 イメージの作成 #

1.3.5 BareMetalHostインベントリの追加 #

1.3.5.1 静的IPの設定 #

1.3.5.1.1 静的ネットワーク設定用の追加スクリプト #

1.3.5.1.2 ホストネットワーク設定の追加シークレット #

1.3.5.2 BareMetalHostの準備 #

1.3.6 ダウンストリームクラスタの作成 #

1.3.7 コントロールプレーンのデプロイメント #

1.3.8 ワーカー/コンピュートのデプロイメント #

1.3.9 クラスタのプロビジョニング解除 #

1.4 既知の問題 #

1.5 予定されている変更 #

1.6 追加のリソース #

1.6.1 シングルノード設定 #

1.6.2 仮想メディアISOをアタッチするためのTLSの無効化 #

1.6.3 ストレージ設定 #

1 Metal³を使用したBMCの自動デプロイメント #

1.3.2 Metal³の依存関係のインストール #