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などのコンテナランタイム

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

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

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

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

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

ヒント

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

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

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

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

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

ヒント

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

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

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

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

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/metal3-chart \
  --namespace metal3-system \
  --create-namespace \
  --set global.ironicIP="${STATIC_IRONIC_IP}"

initContainerがこのデプロイメントで実行されるまでに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の依存関係のインストール #

まず、Rancherに組み込みのCAPIコントローラを無効にする必要があります。

cat <<-EOF | kubectl apply -f -
apiVersion: management.cattle.io/v3
kind: Feature
metadata:
  name: embedded-cluster-api
spec:
  value: false
EOF

kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io mutating-webhook-configuration
kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io validating-webhook-configuration
kubectl wait --for=delete namespace/cattle-provisioning-capi-system --timeout=300s

次に、SUSEイメージを使用するために、設定ファイルが必要です。

mkdir ~/.cluster-api
cat >  ~/.cluster-api/clusterctl.yaml <<EOF
images:
  all:
    repository: registry.suse.com/edge
EOF

clusterctl 1.6.xをインストールし、その後、次のようにコア、インフラストラクチャ、ブートストラップ、およびコントロールプレーンのプロバイダをインストールします。

clusterctl init --core "cluster-api:v1.6.2" --infrastructure "metal3:v1.6.0" --bootstrap "rke2:v0.2.6" --control-plane "rke2:v0.2.6"

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

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

Edge Image Builder (第9章「Edge Image Builder」)を使用して、ダウンストリームクラスタホスト上にプロビジョニングされる、変更されたSLEMicroベースイメージを準備します。

ほとんどの設定はEdge Image Builderを使用して行うことができますが、このガイドではダウンストリームクラスタをセットアップするために必要な最小限の設定について説明します。

1.3.4.1 イメージの設定 #

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

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

├── downstream-cluster-config.yaml
├── base-images/
│   └ SLE-Micro.x86_64-5.5.0-Default-GM.raw
├── network/
|   └ configure-network.sh
└── custom/
    └ scripts/
        └ growfs.sh

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

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

apiVersion: 1.0
image:
  imageType: RAW
  arch: x86_64
  baseImage: SLE-Micro.x86_64-5.5.0-Default-GM.raw
  outputImageName: SLE-Micro-eib-output.raw
operatingSystem:
  kernelArgs:
    - ignition.platform.id=openstack
    - net.ifnames=1
  systemd:
    disable:
      - rebootmgr
  users:
    - username: root
      encryptedPassword: ${ROOT_PASSWORD}
      sshKeys:
      - ${USERKEY1}

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

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

注記

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

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

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

1.3.4.1.2 Growfsスクリプト #

現在は、カスタムスクリプト(custom/scripts/growfs.sh)があります。これは、プロビジョニング後の初回ブート時にディスクサイズに合わせてファイルシステムを拡張するために必要です。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を使用したスタンドアロンクラスタ」を参照してください。

この回避策に関連するバグは、https://bugzilla.suse.com/show_bug.cgi?id=1217430です。

1.3.4.2 イメージの作成 #

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

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

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

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

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/')

mkdir -p /tmp/nmc/{desired,generated}
cp ${NETWORK_DATA_FILE} /tmp/nmc/desired/${DESIRED_HOSTNAME}.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 (第10章「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-addressは、nmstate APIではオプションですが、NM Configuratorを介した設定では必須であり、必ず指定する必要があります。

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が設定されたシングルノードのコントロールプレーンを想定しています。より高度なマルチノードの例については、ATIPのドキュメント(第31章「完全に自動化されたダイレクトネットワークプロビジョニング」)を参照してください。

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/v1alpha1
    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/v1alpha1
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
  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
    version: v1.28.9+rke2r1
---
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 - status can be checked via clusterctl
% 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は現在のところEdgeソリューションではサポートされていないことに注意してください)。

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.28.9+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.28.9+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 some time for the compute/agent hosts 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を介したデプロイメントのみが現在サポートされています。
デプロイされたクラスタは現在、Rancherにインポートされません。
Rancherの組み込みCAPIコントローラが無効化されるため、上記の方法でMetal³用に設定した管理クラスタを、Elemental (第11章「Elemental」)などの他のクラスタプロビジョニング方法でも使用することはできません。

1.5 予定されている変更 #

Rancherへのデプロイされたクラスタのインポート。これは今後、Rancher Turtlesを介してインポートできるようになる予定です。
Rancher Turtlesとの連携。これにより、Rancherの組み込みCAPIを無効にする必要がなくなるため、管理クラスタを介して他のクラスタ方法も使用できるようになります。
networkDataフィールドを使用した、IPAMリソースと設定のサポートの有効化。

1.6 追加のリソース #

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

1.6.1 シングルノード設定 #

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

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

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

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

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

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

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