42 完全に自動化されたダイレクトネットワークプロビジョニング #
42.1 はじめに #
ダイレクトネットワークプロビジョニングは、ダウンストリームクラスタのプロビジョニングを自動化できる機能です。この機能は、プロビジョニングするダウンストリームクラスタが多数あり、そのプロセスを自動化したい場合に便利です。
管理クラスタ(第40章 「管理クラスタの設定」)は、次のコンポーネントのデプロイメントを自動化します。
- SUSE Linux Micro RT(OS)。ユースケースに応じて、ネットワーキング、ストレージ、ユーザ、カーネル引数などの設定をカスタマイズできます。
- RKE2(Kubernetesクラスタ)。デフォルトの- CNIプラグインは- Ciliumです。ユースケースに応じて、特定の- CNIプラグイン(- Cilium+Multusなど)を使用できます。
- SUSE Storage
- SUSE Security
- MetalLB。高可用性マルチノードクラスタのロードバランサとして使用できます。
SUSE Linux Microの詳細については、第9章 「SUSE Linux Micro」を参照してください。RKE2の詳細については、第16章 「RKE2」を参照してください。SUSE
Storageの詳細については、第17章 「SUSE
Storage」を参照してください。SUSE
Securityの詳細については、第18章 「SUSE
Security」を参照してください。
以降のセクションでは、さまざまなダイレクトネットワークプロビジョニングワークフローと、プロビジョニングプロセスに追加できる機能について説明します。
次のセクションでは、SUSE Edge for Telcoを使用してダイレクトネットワークプロビジョニングワークフローの異なるシナリオを準備する方法について説明します。 デプロイメントの異なる設定オプション(エアギャップ環境、DHCPおよびDHCPなしのネットワーク、プライベートコンテナレジストリなどを含む)の例については、SUSE Edge for Telcoリポジトリを参照してください。
42.2 接続シナリオのダウンストリームクラスタイメージの準備 #
Edge Image Builder (第11章 「Edge Image Builder」)を使用して、ダウンストリームクラスタホスト上にプロビジョニングされる、変更されたSLEMicroゴールデンイメージを準備します。
ほとんどの設定はEdge Image Builderを使用して行うことができますが、このガイドではダウンストリームクラスタをセットアップするために必要な最小限の設定について説明します。
42.2.1 接続シナリオの前提条件 #
- Edge Image Builderを実行するには、PodmanやRancher Desktopなどのコンテナランタイムが必要です。 
- ゴールデンイメージは、プロファイル - Base-SelfInstall(リアルタイムカーネルには- Base-RT-SelfInstall)を使用し、次のガイド第28章 「Kiwiを使用したSUSE Linux Microの更新イメージの構築」に従って構築されます。このプロセスは両方のアーキテクチャ(x86-64とaarch64)で同じです。
- aarch64ダウンストリームクラスタをデプロイするには、管理クラスタのデプロイメント前に、管理クラスタのドキュメント(???)で説明されている - metal3.yamlファイルの- deployArchitecture: arm64パラメータを設定する必要があります。これは、ダウンストリームクラスタに適切なアーキテクチャが使用されるようにするために必要です。
構築するイメージと同じアーキテクチャの構築ホストを使用する必要があります。つまり、aarch64のイメージを構築するにはaarch64の構築ホストを使用する必要があり、x86-64の場合も同様です(クロス構築は現在のところサポートされていません)。
42.2.2 接続シナリオのイメージの設定 #
Edge Image Builderを実行すると、そのホストからディレクトリがマウントされるため、ターゲットイメージの定義に使用する設定ファイルを保存するディレクトリ構造を作成する必要があります。
- downstream-cluster-config.yamlはイメージ定義ファイルです。詳細については、第3章 「Edge Image Builderを使用したスタンドアロンクラスタ」を参照してください。
- ゴールデンイメージフォルダには、ガイド第28章 「Kiwiを使用したSUSE Linux Microの更新イメージの構築」に従って生成された出力RAWイメージが含まれます。プロファイル - Base-SelfInstall(または、リアルタイムカーネルの場合は- Base-RT-SelfInstall)は、- base-imagesフォルダにコピー/移動する必要があります。
- networkフォルダはオプションです。詳細については、42.2.2.6項 「高度なネットワーク設定のための追加スクリプト」を参照してください。
- custom/scriptsディレクトリには初回ブート時に実行するスクリプトが含まれます。- 01-fix-growfs.shスクリプトは、デプロイメント時にOSルートパーティションをサイズ変更するために必要です。
- 02-performance.shスクリプトはオプションであり、パフォーマンス調整用にシステムを設定するために使用できます。
- 03-sriov.shスクリプトはオプションであり、SR-IOV用にシステムを設定するために使用できます。
 
- custom/filesディレクトリには、イメージ作成プロセス中にイメージにコピーされる- performance-settings.shおよび- sriov-auto-filler.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
    |   └ 02-performance.sh
    |   └ 03-sriov.sh
    └ files/
        └ performance-settings.sh
        └ sriov-auto-filler.sh42.2.2.1 ダウンストリームクラスタイメージ定義ファイル #
downstream-cluster-config.yamlファイルは、ダウンストリームクラスタイメージの主要な設定ファイルです。次に、Metal3を介したデプロイメントの最小例を示します。
apiVersion: 1.2
image:
  imageType: raw
  arch: x86_64
  baseImage: SL-Micro.x86_64-6.1-Base-GM.raw
  outputImageName: eibimage-output-telco.raw
operatingSystem:
  kernelArgs:
    - ignition.platform.id=openstack
    - net.ifnames=1
  systemd:
    disable:
      - rebootmgr
      - transactional-update.timer
      - transactional-update-cleanup.timer
      - fstrim
      - time-sync.target
  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キーを使用することをお勧めします。
arch:
x86_64は、イメージのアーキテクチャです。arm64アーキテクチャの場合は、arch:
aarch64を使用します。
net.ifnames=1は、Predictable
Network Interface Namingを有効にします。
これはmetal3チャートのデフォルト設定と一致しますが、この設定は、設定されたチャートのpredictableNicNamesの値と一致する必要があります。
また、ignition.platform.id=openstackは必須であり、この引数がないと、Metal3の自動化フローでIgnitionによるSLEMicroの設定が失敗することにも注意してください。
42.2.2.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 /42.2.2.3 パフォーマンススクリプト #
次のオプションのスクリプト(custom/scripts/02-performance.sh)は、パフォーマンス調整用にシステムを設定するために使用できます。
#!/bin/bash
# create the folder to extract the artifacts there
mkdir -p /opt/performance-settings
# copy the artifacts
cp performance-settings.sh /opt/performance-settings/custom/files/performance-settings.shのコンテンツは、パフォーマンス調整用にシステムを設定するために使用可能なスクリプトであり、次のリンクからダウンロードできます。
42.2.2.4 SR-IOVスクリプト #
次のオプションスクリプト(custom/scripts/03-sriov.sh)はSR-IOV用にシステムを設定するために使用できます。
#!/bin/bash
# create the folder to extract the artifacts there
mkdir -p /opt/sriov
# copy the artifacts
cp sriov-auto-filler.sh /opt/sriov/sriov-auto-filler.shcustom/files/sriov-auto-filler.shのコンテンツは、
SR-IOV用にシステムを設定するために使用可能なスクリプトであり、次のリンクからダウンロードできます。
同じアプローチを使用して、プロビジョニングプロセス中に実行する独自のカスタムスクリプトを追加します。詳細については、第3章 「Edge Image Builderを使用したスタンドアロンクラスタ」を参照してください。
42.2.2.5 通信ワークロードの追加設定 #
dpdk、sr-iov、FECなどの通信機能を有効にするには、次の例に示すように追加のパッケージが必要な場合があります。
apiVersion: 1.2
image:
  imageType: raw
  arch: x86_64
  baseImage: SL-Micro.x86_64-6.1-Base-GM.raw
  outputImageName: eibimage-output-telco.raw
operatingSystem:
  kernelArgs:
    - ignition.platform.id=openstack
    - net.ifnames=1
  systemd:
    disable:
      - rebootmgr
      - transactional-update.timer
      - transactional-update-cleanup.timer
      - fstrim
      - time-sync.target
  users:
    - username: root
      encryptedPassword: $ROOT_PASSWORD
      sshKeys:
      - $user1Key1
  packages:
    packageList:
      - jq
      - dpdk
      - dpdk-tools
      - libdpdk-23
      - pf-bb-config
    sccRegistrationCode: $SCC_REGISTRATION_CODEここで、$SCC_REGISTRATION_CODEはSUSE Customer
Centerからコピーした登録コードです。また、パッケージリストには通信事業者プロファイル用の最小限のパッケージが含まれています。
arch:
x86_64は、イメージのアーキテクチャです。arm64アーキテクチャの場合は、arch:
aarch64を使用します。
42.2.2.6 高度なネットワーク設定のための追加スクリプト #
42.6項 「高度なネットワーク設定」で説明されている静的IPや、より高度なネットワーキングシナリオを設定する必要がある場合、次の追加設定が必要です。
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/generated42.2.3 イメージの作成 #
これまでのセクションに従ってディレクトリ構造を準備したら、次のコマンドを実行してイメージを構築します。
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これにより、上記の定義に基づいた、eibimage-output-telco.rawという名前の出力ISOイメージファイルが作成されます。
その後、この出力イメージをWebサーバ経由で利用できるようにする必要があります。その際、管理クラスタのドキュメントを使用して有効にしたメディアサーバコンテナ(注記)か、ローカルにアクセス可能な他のサーバのいずれかを使用します。以下の例では、このサーバをimagecache.local:8080として参照します。
42.3 エアギャップシナリオ用のダウンストリームクラスタイメージの準備 #
Edge Image Builder (第11章 「Edge Image Builder」)を使用して、ダウンストリームクラスタホスト上にプロビジョニングされる、変更されたSLEMicroゴールデンイメージを準備します。
設定の多くはEdge Image Builderを使用して行うことができますが、このガイドではエアギャップシナリオ用のダウンストリームクラスタの設定に必要な最小限の設定について説明します。
42.3.1 エアギャップシナリオの前提条件 #
- Edge Image Builderを実行するには、PodmanやRancher Desktopなどのコンテナランタイムが必要です。 
- ゴールデンイメージは、プロファイル - Base-SelfInstall(リアルタイムカーネルには- Base-RT-SelfInstall)を使用し、次のガイド第28章 「Kiwiを使用したSUSE Linux Microの更新イメージの構築」に従って構築されます。このプロセスは両方のアーキテクチャ(x86-64とaarch64)で同じです。
- aarch64ダウンストリームクラスタをデプロイするには、管理クラスタのデプロイメント前に、管理クラスタのドキュメント(???)で説明されている - metal3.yamlファイルの- deployArchitecture: arm64パラメータを設定する必要があります。これは、ダウンストリームクラスタに適切なアーキテクチャが使用されるようにするために必要です。
- コンテナイメージが必要なSR-IOVなどのワークロードを使用する場合、ローカルのプライベートレジストリをデプロイして設定済みである必要があります(TLSまたは認証、あるいはその両方を使用/不使用)。このレジストリを使用して、イメージとHelmチャートOCIイメージを保存します。 
構築するイメージと同じアーキテクチャの構築ホストを使用する必要があります。つまり、aarch64のイメージを構築するにはaarch64の構築ホストを使用する必要があり、x86-64の場合も同様です(クロス構築は現在のところサポートされていません)。
42.3.2 エアギャップシナリオのイメージの設定 #
Edge Image Builderを実行すると、そのホストからディレクトリがマウントされるため、ターゲットイメージの定義に使用する設定ファイルを保存するディレクトリ構造を作成する必要があります。
- downstream-cluster-airgap-config.yamlはイメージ定義ファイルです。詳細については、第3章 「Edge Image Builderを使用したスタンドアロンクラスタ」を参照してください。
- ゴールデンイメージフォルダには、ガイド第28章 「Kiwiを使用したSUSE Linux Microの更新イメージの構築」に従って生成された出力RAWイメージが含まれます。プロファイル - Base-SelfInstall(または、リアルタイムカーネルの場合は- Base-RT-SelfInstall)は、- base-imagesフォルダにコピー/移動する必要があります。
- networkフォルダはオプションです。詳細については、42.2.2.6項 「高度なネットワーク設定のための追加スクリプト」を参照してください。
- custom/scriptsディレクトリには初回ブート時に実行するスクリプトが含まれます。- 01-fix-growfs.shスクリプトは、デプロイメント時にOSルートパーティションをサイズ変更するために必要です。
- 02-airgap.shスクリプトは、エアギャップ環境でのイメージ作成プロセス中にイメージを適切な場所にコピーするために必要です。
- 03-performance.shスクリプトはオプションであり、パフォーマンス調整用にシステムを設定するために使用できます。
- 04-sriov.shスクリプトはオプションであり、SR-IOV用にシステムを設定するために使用できます。
 
- custom/filesディレクトリには、イメージ作成プロセス中にイメージにコピーされる- rke2および- cniイメージが含まれています。また、オプションの- performance-settings.shおよび- sriov-auto-filler.shファイルを含めることもできます。
├── downstream-cluster-airgap-config.yaml
├── base-images/
│   └ SL-Micro.x86_64-6.1-Base-GM.raw
├── network/
|   └ configure-network.sh
└── custom/
    └ files/
    |   └ install.sh
    |   └ rke2-images-cilium.linux-amd64.tar.zst
    |   └ rke2-images-core.linux-amd64.tar.zst
    |   └ rke2-images-multus.linux-amd64.tar.zst
    |   └ rke2-images.linux-amd64.tar.zst
    |   └ rke2.linux-amd64.tar.zst
    |   └ sha256sum-amd64.txt
    |   └ performance-settings.sh
    |   └ sriov-auto-filler.sh
    └ scripts/
        └ 01-fix-growfs.sh
        └ 02-airgap.sh
        └ 03-performance.sh
        └ 04-sriov.sh42.3.2.1 ダウンストリームクラスタイメージ定義ファイル #
downstream-cluster-airgap-config.yamlファイルは、ダウンストリームクラスタ用のメイン設定ファイルです。その内容については、前のセクション(42.2.2.5項 「通信ワークロードの追加設定」)で説明されています。
42.3.2.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 /42.3.2.3 エアギャップスクリプト #
イメージ作成プロセス中にイメージを正しい場所にコピーするために、次のスクリプト(custom/scripts/02-airgap.sh)が必要です。
#!/bin/bash
# create the folder to extract the artifacts there
mkdir -p /opt/rke2-artifacts
mkdir -p /var/lib/rancher/rke2/agent/images
# copy the artifacts
cp install.sh /opt/
cp rke2-images*.tar.zst rke2.linux-amd64.tar.gz sha256sum-amd64.txt /opt/rke2-artifacts/42.3.2.4 パフォーマンススクリプト #
次のオプションのスクリプト(custom/scripts/03-performance.sh)は、パフォーマンス調整用にシステムを設定するために使用できます。
#!/bin/bash
# create the folder to extract the artifacts there
mkdir -p /opt/performance-settings
# copy the artifacts
cp performance-settings.sh /opt/performance-settings/custom/files/performance-settings.shのコンテンツは、パフォーマンス調整用にシステムを設定するために使用可能なスクリプトであり、次のリンクからダウンロードできます。
42.3.2.5 SR-IOVスクリプト #
次のオプションのスクリプト(custom/scripts/04-sriov.sh)は、SR-IOV用にシステムを設定するために使用できます。
#!/bin/bash
# create the folder to extract the artifacts there
mkdir -p /opt/sriov
# copy the artifacts
cp sriov-auto-filler.sh /opt/sriov/sriov-auto-filler.shcustom/files/sriov-auto-filler.shのコンテンツは、
SR-IOV用にシステムを設定するために使用可能なスクリプトであり、次のリンクからダウンロードできます。
42.3.2.6 エアギャップシナリオのカスタムファイル #
custom/filesディレクトリには、イメージ作成プロセス中にそのイメージにコピーするrke2イメージとcniイメージが含まれています。イメージを簡単に生成するには、次のスクリプトと、こちらにあるイメージのリストを使用してローカルでイメージを準備し、custom/filesに含める必要があるアーティファクトを生成します。また、最新のrke2-installスクリプトをこちらからダウンロードすることもできます。
$ ./edge-save-rke2-images.sh -o custom/files -l ~/edge-release-rke2-images.txtイメージをダウンロードした後、ディレクトリ構造は次のようになるはずです。
└── custom/
    └ files/
        └ install.sh
        └ rke2-images-cilium.linux-amd64.tar.zst
        └ rke2-images-core.linux-amd64.tar.zst
        └ rke2-images-multus.linux-amd64.tar.zst
        └ rke2-images.linux-amd64.tar.zst
        └ rke2.linux-amd64.tar.zst
        └ sha256sum-amd64.txt42.3.2.7 エアギャップシナリオおよびSR-IOV (オプション)に必要なイメージのプライベートレジストリへのプリロード #
エアギャップシナリオまたはその他のワークロードイメージでSR-IOVを使用する場合、次の各手順に従って、ローカルのプライベートレジストリにイメージをプリロードする必要があります。
- HelmチャートOCIイメージをダウンロードして抽出し、プライベートレジストリにプッシュする 
- 必要な残りのイメージをダウンロードして抽出し、プライベートレジストリにプッシュする 
次のスクリプトを使用して、イメージをダウンロードして抽出し、プライベートレジストリにプッシュできます。これからSR-IOVイメージをプリロードする例を示しますが、その他のカスタムイメージも同じ方法でプリロードすることができます。
- SR-IOVのHelmチャートOCIイメージのプリロード: - 必要なHelmチャートOCIイメージが含まれるリストを作成する必要があります。 - $ cat > edge-release-helm-oci-artifacts.txt <<EOF edge/sriov-network-operator-chart:303.0.2+up1.5.0 edge/sriov-crd-chart:303.0.2+up1.5.0 EOF
- 次のスクリプトと上記で作成したリストを使用してローカルtarballファイルを生成します。 - $ ./edge-save-oci-artefacts.sh -al ./edge-release-helm-oci-artifacts.txt -s registry.suse.com Pulled: registry.suse.com/edge/charts/sriov-network-operator:303.0.2+up1.5.0 Pulled: registry.suse.com/edge/charts/sriov-crd:303.0.2+up1.5.0 a edge-release-oci-tgz-20240705 a edge-release-oci-tgz-20240705/sriov-network-operator-chart-303.0.2+up1.5.0.tgz a edge-release-oci-tgz-20240705/sriov-crd-chart-303.0.2+up1.5.0.tgz
- 次のスクリプトを使用してtarballファイルをプライベートレジストリ(例: - myregistry:5000)にアップロードし、前の手順でダウンロードしたHelmチャートOCIイメージをレジストリにプリロードします。- $ tar zxvf edge-release-oci-tgz-20240705.tgz $ ./edge-load-oci-artefacts.sh -ad edge-release-oci-tgz-20240705 -r myregistry:5000
 
- SR-IOVに必要な残りのイメージをプリロードします。 - ここでは、通信ワークロードのために「sr-iov」コンテナイメージを含める必要があります(例: 参考として、これは helmチャート値から取得できます)。 - $ cat > edge-release-images.txt <<EOF rancher/hardened-sriov-network-operator:v1.3.0-build20240816 rancher/hardened-sriov-network-config-daemon:v1.3.0-build20240816 rancher/hardened-sriov-cni:v2.8.1-build20240820 rancher/hardened-ib-sriov-cni:v1.1.1-build20240816 rancher/hardened-sriov-network-device-plugin:v3.7.0-build20240816 rancher/hardened-sriov-network-resources-injector:v1.6.0-build20240816 rancher/hardened-sriov-network-webhook:v1.3.0-build20240816 EOF
- 次のスクリプトと上記で作成したリストを使用して、必要なイメージを含む、tarballファイルをローカルで生成する必要があります。 - $ ./edge-save-images.sh -l ./edge-release-images.txt -s registry.suse.com Image pull success: registry.suse.com/rancher/hardened-sriov-network-operator:v1.3.0-build20240816 Image pull success: registry.suse.com/rancher/hardened-sriov-network-config-daemon:v1.3.0-build20240816 Image pull success: registry.suse.com/rancher/hardened-sriov-cni:v2.8.1-build20240820 Image pull success: registry.suse.com/rancher/hardened-ib-sriov-cni:v1.1.1-build20240816 Image pull success: registry.suse.com/rancher/hardened-sriov-network-device-plugin:v3.7.0-build20240816 Image pull success: registry.suse.com/rancher/hardened-sriov-network-resources-injector:v1.6.0-build20240816 Image pull success: registry.suse.com/rancher/hardened-sriov-network-webhook:v1.3.0-build20240816 Creating edge-images.tar.gz with 7 images
- 次のスクリプトを使用してtarballファイルをプライベートレジストリ(例: - myregistry:5000)にアップロードし、前の手順でダウンロードしたイメージをプライベートレジストリにプリロードします。- $ tar zxvf edge-release-images-tgz-20240705.tgz $ ./edge-load-images.sh -ad edge-release-images-tgz-20240705 -r myregistry:5000
 
42.3.3 エアギャップシナリオのイメージの作成 #
これまでのセクションに従ってディレクトリ構造を準備したら、次のコマンドを実行してイメージを構築します。
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-airgap-config.yamlこれにより、上記の定義に基づいた、eibimage-output-telco.rawという名前の出力ISOイメージファイルが作成されます。
その後、この出力イメージをWebサーバ経由で利用できるようにする必要があります。その際、管理クラスタドキュメントを使用して有効にしたメディアサーバコンテナ(注記)か、ローカルにアクセス可能な他のサーバのいずれかを使用します。以下の例では、このサーバをimagecache.local:8080として参照します。
42.4 ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(シングルノード) #
このセクションでは、ダイレクトネットワークプロビジョニングを使用してシングルノードのダウンストリームクラスタのプロビジョニングを自動化するために用いるワークフローについて説明します。これは、ダウンストリームクラスタのプロビジョニングを自動化する最もシンプルな方法です。
要件
- 前のセクション(42.2項 「接続シナリオのダウンストリームクラスタイメージの準備」)で説明されているように、 - EIBを使用して、ダウンストリームクラスタを設定するための最小限の設定で生成されたイメージが、こちらのセクション(注記)で設定した正確なパス上にある管理クラスタに配置されている。
- 管理サーバが作成されていて、次の各セクションで使用できるようになっている。詳細については、管理クラスタに関するセクション第40章 「管理クラスタの設定」を参照してください。 
ワークフロー
次の図は、ダイレクトネットワークプロビジョニングを使用してシングルノードのダウンストリームクラスタのプロビジョニングを自動化するために用いるワークフローを示しています。
ダイレクトネットワークプロビジョニングを使用してシングルノードのダウンストリームクラスタのプロビジョニングを自動化する手順は2種類です。
- ベアメタルホストを登録して、プロビジョニングプロセスで使用できるようにする。 
- ベアメタルホストをプロビジョニングして、オペレーティングシステムとKubernetesクラスタをインストールして設定する。 
ベアメタルホストの登録
最初の手順では、新しいベアメタルホストを管理クラスタに登録してプロビジョニングできるようにします。そのためには、ファイルbmh-example.yamlを管理クラスタ内に作成して、使用するBMC資格情報と登録するBaremetalHostオブジェクトを指定する必要があります。
apiVersion: v1
kind: Secret
metadata:
  name: example-demo-credentials
type: Opaque
data:
  username: ${BMC_USERNAME}
  password: ${BMC_PASSWORD}
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: example-demo
  labels:
    cluster-role: control-plane
spec:
  online: true
  bootMACAddress: ${BMC_MAC}
  rootDeviceHints:
    deviceName: /dev/nvme0n1
  bmc:
    address: ${BMC_ADDRESS}
    disableCertificateVerification: true
    credentialsName: example-demo-credentials各項目の内容は次のとおりです。
- ${BMC_USERNAME}— 新しいベアメタルホストの- BMCのユーザ名。
- ${BMC_PASSWORD}— 新しいベアメタルホストの- BMCのパスワード。
- ${BMC_MAC}— 使用する新しいベアメタルホストの- MACアドレス。
- ${BMC_ADDRESS}— ベアメタルホストの- BMCの- URL(例:- redfish-virtualmedia://192.168.200.75/redfish/v1/Systems/1/)。ハードウェアプロバイダに応じて使用できる各種のオプションの詳細については、こちらのリンクを確認してください。
ホストのネットワーク設定が、イメージのビルド時またはBareMetalHost定義を通じて指定されていない場合、自動設定メカニズム(DHCP、DHCPv6、SLAAC)が使用されます。詳細または複雑な設定については、42.6項 「高度なネットワーク設定」を参照してください。
ファイルを作成したら、管理クラスタで次のコマンドを実行し、管理クラスタで新しいベアメタルホストの登録を開始する必要があります。
$ kubectl apply -f bmh-example.yaml新しいベアメタルホストオブジェクトが登録され、その状態が「Registering (登録中)」から「Inspecting (検査中)」に変わり、「Available (使用可能)」になります。この変更は次のコマンドを使用して確認できます。
$ kubectl get bmhBaremetalHostオブジェクトは、BMCの資格情報が検証されるまでは「Registering
(登録中)」の状態です。資格情報の検証が完了すると、BaremetalHostオブジェクトの状態が「Inspecting
(検査中)」に変わります。この手順はハードウェアによっては多少時間がかかる可能性があります(最大で20分)。「Inspecting
(検査中)」のフェーズ中に、ハードウェア情報が取得されてKubernetesオブジェクトが更新されます。kubectl get bmh
-o yamlコマンドを使用して情報を確認してください。
プロビジョニング手順
ベアメタルホストが登録されて使用可能になったら、次の手順で、ベアメタルホストをプロビジョニングしてオペレーティングシステムとKubernetesクラスタをインストールして設定します。そのためには、次の情報を使用して管理クラスタでファイルcapi-provisioning-example.yamlを作成する必要があります(capi-provisioning-example.yamlは、以下のブロックを結合して生成できます)。
実際の値に置き換える必要があるのは、$\{…\}の中の値だけです。
次のブロックはクラスタ定義です。ここで、podsブロックとservicesブロックを使用してネットワーキングを設定できます。また、ここにはコントロールプレーンオブジェクトと、使用するインフラストラクチャ(Metal3プロバイダを使用)オブジェクトへの参照も含まれています。
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: single-node-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: single-node-cluster
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3Cluster
    name: single-node-clusterデュアルスタックのPodとServiceを含むデプロイメントの場合、代わりに次の定義を使用できます。
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: single-node-cluster
  namespace: default
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 192.168.0.0/18
        - fd00:bad:cafe::/48
    services:
      cidrBlocks:
        - 10.96.0.0/12
        - fd00:bad:bad:cafe::/112
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: RKE2ControlPlane
    name: single-node-cluster
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3Cluster
    name: single-node-clusterIPv6 およびデュアルスタックのデプロイメントは技術プレビュー状態であり、公式にはサポートされていません。
Metal3Clusterオブジェクトには、設定するコントロールプレーンのエンドポイント(${DOWNSTREAM_CONTROL_PLANE_IP}を置き換える)と、noCloudProvider(ベアメタルノードを使用しているため)を指定します。
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3Cluster
metadata:
  name: single-node-cluster
  namespace: default
spec:
  controlPlaneEndpoint:
    host: ${DOWNSTREAM_CONTROL_PLANE_IP}
    port: 6443
  noCloudProvider: trueRKE2ControlPlaneオブジェクトには、使用するコントロールプレーン設定を指定し、Metal3MachineTemplateオブジェクトには、使用するコントロールプレーンのイメージを指定します。また、ここには使用するレプリカの数(ここでは1)と、使用するCNIプラグイン(ここではCilium)に関する情報が含まれています。agentConfigブロックには、使用する
Ignition形式と、使用するadditionalUserDataが含まれます。これを使用してRKE2ノードにrke2-preinstall.serviceという名前のsystemdサービスを設定し、プロビジョニングプロセス中にIronicの情報を使用してBAREMETALHOST_UUIDとnode-nameを自動的に置き換えます。ciliumでmultusを有効にするには、使用する設定を含むファイルを
rke2サーバマニフェストディレクトリにrke2-cilium-config.yamlという名前で作成します。最後の情報ブロックには、使用するKubernetesバージョンが含まれています。
${RKE2_VERSION}は使用するRKE2のバージョンであり、この値は置き換えます(例:
v1.32.4+rke2r1)。
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: single-node-cluster
  namespace: default
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3MachineTemplate
    name: single-node-cluster-controlplane
  replicas: 1
  version: ${RKE2_VERSION}
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  serverConfig:
    cni: cilium
  agentConfig:
    format: ignition
    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
        storage:
          files:
            # https://docs.rke2.io/networking/multus_sriov#using-multus-with-cilium
            - path: /var/lib/rancher/rke2/server/manifests/rke2-cilium-config.yaml
              overwrite: true
              contents:
                inline: |
                  apiVersion: helm.cattle.io/v1
                  kind: HelmChartConfig
                  metadata:
                    name: rke2-cilium
                    namespace: kube-system
                  spec:
                    valuesContent: |-
                      cni:
                        exclusive: false
              mode: 0644
              user:
                name: root
              group:
                name: root
    kubelet:
      extraArgs:
        - provider-id=metal3://BAREMETALHOST_UUID
    nodeName: "localhost.localdomain"Metal3MachineTemplateオブジェクトには次の情報を指定します。
- テンプレートへの参照として使用する - dataTemplate。
- 登録プロセス中に作成されたラベルとの一致に使用する - hostSelector。
- 前のセクション(42.2項 「接続シナリオのダウンストリームクラスタイメージの準備」)で - EIBを使用して生成されたイメージへの参照として使用する- image、およびそのイメージを検証するために使用する- checksumと- checksumType。
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: single-node-cluster-controlplane
  namespace: default
spec:
  template:
    spec:
      dataTemplate:
        name: single-node-cluster-controlplane-template
      hostSelector:
        matchLabels:
          cluster-role: control-plane
      image:
        checksum: http://imagecache.local:8080/eibimage-output-telco.raw.sha256
        checksumType: sha256
        format: raw
        url: http://imagecache.local:8080/eibimage-output-telco.rawMetal3DataTemplateオブジェクトには、ダウンストリームクラスタのmetaDataを指定します。
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3DataTemplate
metadata:
  name: single-node-cluster-controlplane-template
  namespace: default
spec:
  clusterName: single-node-cluster
  metaData:
    objectNames:
      - key: name
        object: machine
      - key: local-hostname
        object: machine
      - key: local_hostname
        object: machine前のブロックを結合してファイルを作成したら、管理クラスタで次のコマンドを実行して、新しいベアメタルホストのプロビジョニングを開始する必要があります。
$ kubectl apply -f capi-provisioning-example.yaml42.5 ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(マルチノード) #
このセクションでは、ダイレクトネットワークプロビジョニングとMetalLBをロードバランサ戦略として使用して、マルチノードのダウンストリームクラスタのプロビジョニングを自動化するために使用するワークフローについて説明します。これはダウンストリームクラスタのプロビジョニングを自動化する最もシンプルな方法です。次の図は、ダイレクトネットワークプロビジョニングとMetalLBを使用してマルチノードのダウンストリームクラスタのプロビジョニングを自動化するためのワークフローを示しています。
要件
- 前のセクション(42.2項 「接続シナリオのダウンストリームクラスタイメージの準備」)で説明されているように、 - EIBを使用して、ダウンストリームクラスタを設定するための最小限の設定で生成されたイメージが、こちらのセクション(注記)で設定した正確なパス上にある管理クラスタに配置されている。
- 管理サーバが作成されていて、次の各セクションで使用できるようになっている。詳細については、管理クラスタに関するセクション第40章 「管理クラスタの設定」を参照してください。 
ワークフロー
次の図は、ダイレクトネットワークプロビジョニングを使用してマルチノードのダウンストリームクラスタのプロビジョニングを自動化するために使用するワークフローを示しています。
- 3つのベアメタルホストを登録し、プロビジョニングプロセスで使用できるようにする。 
- 3つのベアメタルホストをプロビジョニングし、オペレーティングシステムと、 - MetalLBを使用するKubernetesクラスタをインストールして設定する。
ベアメタルホストの登録
最初の手順では、管理クラスタに3つのベアメタルホストを登録してプロビジョニングできるようにします。そのためには、管理クラスタにファイルbmh-example-node1.yaml、bmh-example-node2.yaml、およびbmh-example-node3.yamlを作成して、使用するBMC資格情報と、管理クラスタに登録するBaremetalHostオブジェクトを指定する必要があります。
- 実際の値に置き換える必要があるのは、 - $\{…\}の中の値だけです。
- 1つのホストのプロセスについてのみ説明します。他の2つのノードにも同じ手順が適用されます。 
apiVersion: v1
kind: Secret
metadata:
  name: node1-example-credentials
type: Opaque
data:
  username: ${BMC_NODE1_USERNAME}
  password: ${BMC_NODE1_PASSWORD}
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: node1-example
  labels:
    cluster-role: control-plane
spec:
  online: true
  bootMACAddress: ${BMC_NODE1_MAC}
  bmc:
    address: ${BMC_NODE1_ADDRESS}
    disableCertificateVerification: true
    credentialsName: node1-example-credentials各項目の内容は次のとおりです。
- ${BMC_NODE1_USERNAME}— 最初のベアメタルホストのBMCのユーザ名。
- ${BMC_NODE1_PASSWORD}— 最初のベアメタルホストのBMCのパスワード。
- ${BMC_NODE1_MAC}— 使用する最初のベアメタルホストのMACアドレス。
- ${BMC_NODE1_ADDRESS}— 最初のベアメタルホストのBMCのURL (例:- redfish-virtualmedia://192.168.200.75/redfish/v1/Systems/1/)。ハードウェアプロバイダに応じて使用できる各種のオプションの詳細については、こちらのリンクを確認してください。
- ホストのネットワーク設定が、イメージのビルド時または - BareMetalHost定義を通じて指定されていない場合、自動設定メカニズム(DHCP、DHCPv6、SLAAC)が使用されます。詳細または複雑な設定については、42.6項 「高度なネットワーク設定」を参照してください。
- マルチノードのデュアルスタックまたはIPv6専用クラスタは、まだサポートされていません。 
ファイルを作成したら、管理クラスタで次のコマンドを実行して、管理クラスタへのベアメタルホストの登録を開始する必要があります。
$ kubectl apply -f bmh-example-node1.yaml
$ kubectl apply -f bmh-example-node2.yaml
$ kubectl apply -f bmh-example-node3.yaml新しいベアメタルホストオブジェクトが登録され、その状態が「Registering (登録中)」から「Inspecting (検査中)」に変わり、「Available (使用可能)」になります。この変更は次のコマンドを使用して確認できます。
$ kubectl get bmh -o wideBaremetalHostオブジェクトは、BMCの資格情報が検証されるまでは「Registering
(登録中)」の状態です。資格情報の検証が完了すると、BaremetalHostオブジェクトの状態が「Inspecting
(検査中)」に変わります。この手順はハードウェアによっては多少時間がかかる可能性があります(最大で20分)。「Inspecting
(検査中)」のフェーズ中に、ハードウェア情報が取得されてKubernetesオブジェクトが更新されます。kubectl get bmh
-o yamlコマンドを使用して情報を確認してください。
プロビジョニング手順
3つのベアメタルホストが登録されて使用可能になったら、次の手順は、ベアメタルホストをプロビジョニングしてオペレーティングシステムとKubernetesクラスタをインストールして設定し、ロードバランサを作成して3つのベアメタルホストを管理することです。そのためには、次の情報を使用して管理クラスタにファイルcapi-provisioning-example.yamlを作成する必要があります(capi-provisioning-example.yamlは、次のブロックを結合して生成できます)。
- 実際の値に置き換える必要があるのは、 - $\{…\}の中の値だけです。
- VIPアドレスは、どのノードにも割り当てられていない予約済みのIPアドレスであり、ロードバランサを設定するために使用されます。
以下はクラスタ定義です。ここで、podsブロックとservicesブロックを使用してクラスタのネットワークを設定できます。また、ここにはコントロールプレーンと、使用するインフラストラクチャ(Metal3プロバイダを使用)のオブジェクトへの参照も含まれています。
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: multinode-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: multinode-cluster
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3Cluster
    name: multinode-clusterMetal3Clusterオブジェクトには、予約済みのVIPアドレス(${DOWNSTREAM_VIP_ADDRESS}を置き換え)を使用して設定するコントロールプレーンのエンドポイントと、noCloudProvider
(3つのベアメタルノードを使用しているため)を指定しています。
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3Cluster
metadata:
  name: multinode-cluster
  namespace: default
spec:
  controlPlaneEndpoint:
    host: ${EDGE_VIP_ADDRESS}
    port: 6443
  noCloudProvider: trueRKE2ControlPlaneオブジェクトには、使用するコントロールプレーンの設定を指定し、Metal3MachineTemplateオブジェクトには、使用するコントロールプレーンのイメージを指定します。
- 使用するレプリカの数(ここでは3)。 
- ロードバランサで使用するアドバタイズモード( - addressではL2実装を使用)、および使用するアドレス(- ${EDGE_VIP_ADDRESS}を- VIPアドレスに置き換え)。
- 使用する - CNIプラグイン(ここでは- Cilium)と、- VIPアドレスの設定に使用する- tlsSanが含まれる- serverConfig。
- agentConfigブロックには、使用する - Ignitionの形式と、- RKE2ノードに次のような情報を設定するために使用する- additionalUserDataが含まれています。- プロビジョニングプロセス中にIronicの情報を使用して - BAREMETALHOST_UUIDと- node-nameを自動的に置き換える、- rke2-preinstall.serviceという名前のsystemdサービス。
- MetalLBと- endpoint-copier-operatorのインストールに使用するHelmチャートが含まれている- storageブロック。
- 使用する - IPaddressPoolと- L2Advertisementが含まれている- metalLBカスタムリソースファイル(- ${EDGE_VIP_ADDRESS}を- VIPアドレスに置き換え)。
- MetalLBが- VIPアドレスを管理するために使用する- kubernetes-vipサービスの設定に使用する- endpoint-svc.yamlファイル。
 
- 最後の情報ブロックには、使用するKubernetesバージョンが含まれています。 - ${RKE2_VERSION}は使用する- RKE2のバージョンで、この値は置き換えます(例:- v1.32.4+rke2r1)。
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: multinode-cluster
  namespace: default
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3MachineTemplate
    name: multinode-cluster-controlplane
  replicas: 3
  version: ${RKE2_VERSION}
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  registrationMethod: "control-plane-endpoint"
  registrationAddress: ${EDGE_VIP_ADDRESS}
  serverConfig:
    cni: cilium
    tlsSan:
      - ${EDGE_VIP_ADDRESS}
      - https://${EDGE_VIP_ADDRESS}.sslip.io
  agentConfig:
    format: ignition
    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
        storage:
          files:
            # https://docs.rke2.io/networking/multus_sriov#using-multus-with-cilium
            - path: /var/lib/rancher/rke2/server/manifests/rke2-cilium-config.yaml
              overwrite: true
              contents:
                inline: |
                  apiVersion: helm.cattle.io/v1
                  kind: HelmChartConfig
                  metadata:
                    name: rke2-cilium
                    namespace: kube-system
                  spec:
                    valuesContent: |-
                      cni:
                        exclusive: false
              mode: 0644
              user:
                name: root
              group:
                name: root
            - path: /var/lib/rancher/rke2/server/manifests/endpoint-copier-operator.yaml
              overwrite: true
              contents:
                inline: |
                  apiVersion: helm.cattle.io/v1
                  kind: HelmChart
                  metadata:
                    name: endpoint-copier-operator
                    namespace: kube-system
                  spec:
                    chart: oci://registry.suse.com/edge/charts/endpoint-copier-operator
                    targetNamespace: endpoint-copier-operator
                    version: 303.0.0+up0.2.1
                    createNamespace: true
            - path: /var/lib/rancher/rke2/server/manifests/metallb.yaml
              overwrite: true
              contents:
                inline: |
                  apiVersion: helm.cattle.io/v1
                  kind: HelmChart
                  metadata:
                    name: metallb
                    namespace: kube-system
                  spec:
                    chart: oci://registry.suse.com/edge/charts/metallb
                    targetNamespace: metallb-system
                    version: 303.0.0+up0.14.9
                    createNamespace: true
            - path: /var/lib/rancher/rke2/server/manifests/metallb-cr.yaml
              overwrite: true
              contents:
                inline: |
                  apiVersion: metallb.io/v1beta1
                  kind: IPAddressPool
                  metadata:
                    name: kubernetes-vip-ip-pool
                    namespace: metallb-system
                  spec:
                    addresses:
                      - ${EDGE_VIP_ADDRESS}/32
                    serviceAllocation:
                      priority: 100
                      namespaces:
                        - default
                      serviceSelectors:
                        - matchExpressions:
                          - {key: "serviceType", operator: In, values: [kubernetes-vip]}
                  ---
                  apiVersion: metallb.io/v1beta1
                  kind: L2Advertisement
                  metadata:
                    name: ip-pool-l2-adv
                    namespace: metallb-system
                  spec:
                    ipAddressPools:
                      - kubernetes-vip-ip-pool
            - path: /var/lib/rancher/rke2/server/manifests/endpoint-svc.yaml
              overwrite: true
              contents:
                inline: |
                  apiVersion: v1
                  kind: Service
                  metadata:
                    name: kubernetes-vip
                    namespace: default
                    labels:
                      serviceType: kubernetes-vip
                  spec:
                    ports:
                    - name: rke2-api
                      port: 9345
                      protocol: TCP
                      targetPort: 9345
                    - name: k8s-api
                      port: 6443
                      protocol: TCP
                      targetPort: 6443
                    type: LoadBalancer
    kubelet:
      extraArgs:
        - provider-id=metal3://BAREMETALHOST_UUID
    nodeName: "Node-multinode-cluster"Metal3MachineTemplateオブジェクトには次の情報を指定します。
- テンプレートへの参照として使用する - dataTemplate。
- 登録プロセス中に作成されたラベルとの一致に使用する - hostSelector。
- 前のセクション(42.2項 「接続シナリオのダウンストリームクラスタイメージの準備」)で - EIBを使用して生成されたイメージへの参照として使用する- image、およびそのイメージを検証するために使用する- checksumと- checksumType。
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: multinode-cluster-controlplane
  namespace: default
spec:
  template:
    spec:
      dataTemplate:
        name: multinode-cluster-controlplane-template
      hostSelector:
        matchLabels:
          cluster-role: control-plane
      image:
        checksum: http://imagecache.local:8080/eibimage-output-telco.raw.sha256
        checksumType: sha256
        format: raw
        url: http://imagecache.local:8080/eibimage-output-telco.rawMetal3DataTemplateオブジェクトには、ダウンストリームクラスタのmetaDataを指定します。
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3DataTemplate
metadata:
  name: multinode-cluster-controlplane-template
  namespace: default
spec:
  clusterName: multinode-cluster
  metaData:
    objectNames:
      - key: name
        object: machine
      - key: local-hostname
        object: machine
      - key: local_hostname
        object: machine前のブロックを結合してファイルを作成したら、管理クラスタで次のコマンドを実行して、新しい3つのベアメタルホストのプロビジョニングを開始する必要があります。
$ kubectl apply -f capi-provisioning-example.yaml42.6 高度なネットワーク設定 #
ダイレクトネットワークプロビジョニングワークフローを使用すると、静的IP、ボンディング、VLAN、IPv6など、ダウンストリームクラスタの特定のネットワーク設定が可能になります。
次の各セクションでは、高度なネットワーク設定を使用してダウンストリームクラスタをプロビジョニングできるようにするために必要な追加手順について説明します。
要件
- このセクション(42.2.2.6項 「高度なネットワーク設定のための追加スクリプト」)に従って、 - EIBを使用して生成したイメージにネットワークフォルダとスクリプトを含める必要があります。
設定
続行する前に、ホストの登録およびプロビジョニングに必要な手順に関するガイダンスについて、次のいずれかのセクションを参照してください。
- ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(シングルノード) (42.4項 「ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(シングルノード)」) 
- ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(マルチノード) (42.5項 「ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(マルチノード)」) 
高度なネットワーク設定は、登録時にBareMetalHostホスト定義およびnmstate形式のnetworkDataブロックを含む関連するシークレットを通じて適用する必要があります。次のサンプルファイルは、ダウンストリームクラスタホストに静的IPとVLANを要求する、必須のnetworkDataを含むシークレットを定義しています。
apiVersion: v1
kind: Secret
metadata:
  name: controlplane-0-networkdata
type: Opaque
stringData:
  networkData: |
    interfaces:
    - name: ${CONTROLPLANE_INTERFACE}
      type: ethernet
      state: up
      mtu: 1500
      identifier: mac-address
      mac-address: "${CONTROLPLANE_MAC}"
      ipv4:
        address:
        - ip:  "${CONTROLPLANE_IP}"
          prefix-length: "${CONTROLPLANE_PREFIX}"
        enabled: true
        dhcp: false
    - name: floating
      type: vlan
      state: up
      vlan:
        base-iface: ${CONTROLPLANE_INTERFACE}
        id: ${VLAN_ID}
    dns-resolver:
      config:
        server:
        - "${DNS_SERVER}"
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: "${CONTROLPLANE_GATEWAY}"
        next-hop-interface: ${CONTROLPLANE_INTERFACE}ご覧のとおり、この例は、静的IPを使用してインタフェースを有効にするための設定と、ベースインタフェースを使用してVLANを有効にするための設定を示しています。インフラストラクチャに応じて、以下の変数を実際の値に置き換えてください。
- ${CONTROLPLANE1_INTERFACE}— エッジクラスタに使用するコントロールプレーンインタフェース(例:- eth0)。- identifier: mac-addressを含めると、名前がMACアドレスに基づいて自動的に検査されるため、任意のインタフェース名を使用できます。
- ${CONTROLPLANE1_IP}— エッジクラスタのエンドポイントとして使用するIPアドレス(kubeapiサーバのエンドポイントと一致する必要があります)。
- ${CONTROLPLANE1_PREFIX}— エッジクラスタに使用するCIDR (例:- /24または- 255.255.255.0を使用する場合には- 24)。
- ${CONTROLPLANE1_GATEWAY}— エッジクラスタに使用するゲートウェイ(例:- 192.168.100.1)。
- ${CONTROLPLANE1_MAC}— コントロールプレーンインタフェースに使用するMACアドレス(例:- 00:0c:29:3e:3e:3e)。
- ${DNS_SERVER}— エッジクラスタに使用するDNS (例:- 192.168.100.2)。
- ${VLAN_ID}— エッジクラスタに使用するVLAN ID (例:- 100)。
他のnmstate準拠の定義を使用して、ダウンストリームクラスタのネットワークを特定の要件に適合するように設定できます。たとえば、静的デュアルスタック設定を指定できます。
apiVersion: v1
kind: Secret
metadata:
  name: controlplane-0-networkdata
type: Opaque
stringData:
  networkData: |
    interfaces:
    - name: ${CONTROLPLANE_INTERFACE}
      type: ethernet
      state: up
      mac-address: ${CONTROLPLANE_MAC}
      ipv4:
        enabled: true
        dhcp: false
        address:
        - ip: ${CONTROLPLANE_IP_V4}
          prefix-length: ${CONTROLPLANE_PREFIX_V4}
      ipv6:
        enabled: true
        dhcp: false
        autoconf: false
        address:
        - ip: ${CONTROLPLANE_IP_V6}
          prefix-length: ${CONTROLPLANE_PREFIX_V6}
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: ${CONTROLPLANE_GATEWAY_V4}
        next-hop-interface: ${CONTROLPLANE_INTERFACE}
      - destination: ::/0
        next-hop-address: ${CONTROLPLANE_GATEWAY_V6}
        next-hop-interface: ${CONTROLPLANE_INTERFACE}
    dns-resolver:
      config:
        server:
        - ${DNS_SERVER_V4}
        - ${DNS_SERVER_V6}前の例と同様に、インフラストラクチャに応じて、以下の変数を実際の値に置き換えてください。
- ${CONTROLPLANE_IP_V4}- ホストに割り当てるIPv4アドレス
- ${CONTROLPLANE_PREFIX_V4}- ホストIPが属するネットワークのIPv4プレフィックス
- ${CONTROLPLANE_IP_V6}- ホストに割り当てるIPv6アドレス
- ${CONTROLPLANE_PREFIX_V6}- ホストIPが属するネットワークのIPv6プレフィックス
- ${CONTROLPLANE_GATEWAY_V4}- デフォルトルートに一致するトラフィック用のゲートウェイのIPv4アドレス
- ${CONTROLPLANE_GATEWAY_V6}- デフォルトルートに一致するトラフィック用のゲートウェイのIPv6アドレス
- ${CONTROLPLANE_INTERFACE}- IPv4とIPv6の両方で、デフォルトルートに一致する出力トラフィックにアドレスを割り当て、使用するインタフェースの名前。
- ${DNS_SERVER_V4}および/または- ${DNS_SERVER_V6}- 使用するDNSサーバのIPアドレス。単一または複数のエントリとして指定できます。IPv4および/またはIPv6アドレスがサポートされています。
IPv6 およびデュアルスタックのデプロイメントは技術プレビュー状態であり、公式にはサポートされていません。
最後に、ネットワーク設定の詳細に関わらず、ホストを管理クラスタに正常に登録するために、BaremetalHostオブジェクトにpreprovisioningNetworkDataNameを追加してシークレットが参照されるようにします。
apiVersion: v1
kind: Secret
metadata:
  name: example-demo-credentials
type: Opaque
data:
  username: ${BMC_USERNAME}
  password: ${BMC_PASSWORD}
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: example-demo
  labels:
    cluster-role: control-plane
spec:
  online: true
  bootMACAddress: ${BMC_MAC}
  rootDeviceHints:
    deviceName: /dev/nvme0n1
  bmc:
    address: ${BMC_ADDRESS}
    disableCertificateVerification: true
    credentialsName: example-demo-credentials
  preprovisioningNetworkDataName: controlplane-0-networkdata- マルチノードクラスタをデプロイする必要がある場合は、同じプロセスを各ノードに対して実行する必要があります。 
- Metal3DataTemplate、- networkData、および- Metal3 IPAMは現在サポートされていません。静的シークレットを介した設定のみが完全にサポートされています。
42.7 通信機能(DPDK、SR-IOV、CPUの分離、Huge Page、NUMAなど) #
ダイレクトネットワークプロビジョニングのワークフローでは、ダウンストリームクラスタで使用する通信機能を自動化して、そのサーバ上で通信ワークロードを実行できます。
要件
- 前のセクション(42.2項 「接続シナリオのダウンストリームクラスタイメージの準備」)で説明されているように、 - EIBを使用して生成したイメージが、こちらのセクション(注記)で設定した正確なパス上の管理クラスタに配置されている。
- こちらのセクション(42.2.2.5項 「通信ワークロードの追加設定」)に従って、 - EIBを使用して生成したイメージに特定の通信機能を含める必要がある。
- 管理サーバが作成されていて、次の各セクションで使用できるようになっている。詳細については、管理クラスタに関するセクション第40章 「管理クラスタの設定」を参照してください。 
設定
次の2つのセクションをベースとして使用し、ホストを登録してプロビジョニングします。
- ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(シングルノード) (42.4項 「ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(シングルノード)」) 
- ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(マルチノード) (42.5項 「ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(マルチノード)」) 
このセクションで説明する通信機能を次に示します。
- DPDKとVFの作成 
- ワークロードで使用されるSR-IOVとVFの割り当て 
- CPUの分離とパフォーマンスの調整 
- Huge Pageの設定 
- カーネルパラメータの調整 
上記の通信機能を有効にするために必要な変更はすべて、プロビジョニングファイルcapi-provisioning-example.yamlのRKE2ControlPlaneブロック内にあります。ファイルcapi-provisioning-example.yaml内の残りの情報は、プロビジョニングに関するセクション(42.4項 「ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(シングルノード)」)で指定した情報と同じです。
このプロセスを明確にするために、通信機能を有効にするためにそのブロック(RKE2ControlPlane)で必要な変更を次に示します。
- RKE2インストールプロセスの前にコマンドを実行するために使用する- preRKE2Commands。ここでは、- modprobeコマンドを使用して、- vfio-pciと- SR-IOVのカーネルモジュールを有効にします。
- 作成してワークロードに公開するインタフェース、ドライバ、および - VFの数を定義するために使用するIgnitionファイル- /var/lib/rancher/rke2/server/manifests/configmap-sriov-custom-auto.yaml。- 実際の値に置き換える値は、設定マップ - sriov-custom-auto-config内の値のみです。- ${RESOURCE_NAME1}— 最初の- PFインタフェースに使用するリソース名(例:- sriov-resource-du1)。このリソース名はプレフィックス- rancher.ioに追加されてラベルとして使用され、ワークロードで使用されます(例:- rancher.io/sriov-resource-du1)。
- ${SRIOV-NIC-NAME1}— 使用する最初の- PFインタフェースの名前(例:- eth0)。
- ${PF_NAME1}— 使用する最初の物理機能- PFの名前。これを使用して、より複雑なフィルタを生成します(例:- eth0#2-5)。
- ${DRIVER_NAME1}— 最初の- VFインタフェースに使用するドライバ名(例:- vfio-pci)。
- ${NUM_VFS1}— 最初の- PFインタフェース用に作成する- VFの数(例:- 8)。
 
 
- /var/sriov-auto-filler.shは、高レベルの設定マップ- sriov-custom-auto-configと、低レベルのハードウェア情報を含む- sriovnetworknodepolicyとの間で情報を変換するために使用されます。このスクリプトは、ユーザがハードウェア情報を事前に把握する手間をなくすために作成されています。このファイルを変更する必要はありませんが、- sr-iovを有効にして- VFを作成する必要がある場合は、このファイルが存在する必要があります。
- 次の機能を有効にするために使用するカーネル引数: 
| パラメータ | 値 | 説明 | 
| isolcpus | domain、nohz、managed_irq、1-30、33-62 | コア1-30および33-62を分離します。 | 
| skew_tick | 1 | 分離されたCPU間でカーネルがタイマー割り込みをずらすことができるようにします。 | 
| nohz | on | システムがアイドル状態のときにカーネルが1つのCPUでタイマーティックを実行できるようにします。 | 
| nohz_full | 1-30、33-62 | カーネルブートパラメータは、完全なdynticksとCPU分離の設定を行うための現在の主要インタフェースです。 | 
| rcu_nocbs | 1-30、33-62 | システムがアイドル状態のときにカーネルが1つのCPUでRCUコールバックを実行できるようにします。 | 
| irqaffinity | 0、31、32、63 | システムがアイドル状態のときにカーネルが1つのCPUで割り込みを実行できるようにします。 | 
| idle | poll | アイドル状態から抜け出すまでのレイテンシを最小化します。 | 
| iommu | pt | vfioをdpdkインタフェースに使用できるようにします。 | 
| intel_iommu | on | vfioをVFに使用できるようにします。 | 
| hugepagesz | 1G | Huge Pageのサイズを1Gに設定できるようにします。 | 
| hugepages | 40 | 前に定義したHuge Pageの数。 | 
| default_hugepagesz | 1G | Huge Pageを有効にする場合のデフォルト値。 | 
| nowatchdog | ウォッチドッグを無効にします。 | |
| nmi_watchdog | 0 | NMIウォッチドッグを無効にします。 | 
- 次のsystemdサービスは、以下のサービスを有効にするために使用します。 - rke2-preinstall.service- プロビジョニングプロセス中にIronicの情報を利用して- BAREMETALHOST_UUIDと- node-nameを自動的に置き換えます。
- cpu-partitioning.service-- CPUの分離コアを有効にします(例:- 1-30,33-62)。
- performance-settings.service- CPUのパフォーマンス調整を有効にします。
- sriov-custom-auto-vfs.service-- sriovHelmチャートをインストールし、カスタムリソースが作成されるまで待機し、- /var/sriov-auto-filler.shを実行して設定マップ- sriov-custom-auto-configの値を置き換えてワークロードが使用する- sriovnetworknodepolicyを作成します。
 
- ${RKE2_VERSION}は使用する- RKE2のバージョンであり、この値は置き換えます(例:- v1.32.4+rke2r1)。
これらの変更をすべて行うと、capi-provisioning-example.yamlのRKE2ControlPlaneブロックは次のようになります。
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: single-node-cluster
  namespace: default
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3MachineTemplate
    name: single-node-cluster-controlplane
  replicas: 1
  version: ${RKE2_VERSION}
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  serverConfig:
    cni: calico
    cniMultusEnable: true
  preRKE2Commands:
    - modprobe vfio-pci enable_sriov=1 disable_idle_d3=1
  agentConfig:
    format: ignition
    additionalUserData:
      config: |
        variant: fcos
        version: 1.4.0
        storage:
          files:
            - path: /var/lib/rancher/rke2/server/manifests/configmap-sriov-custom-auto.yaml
              overwrite: true
              contents:
                inline: |
                  apiVersion: v1
                  kind: ConfigMap
                  metadata:
                    name: sriov-custom-auto-config
                    namespace: kube-system
                  data:
                    config.json: |
                      [
                         {
                           "resourceName": "${RESOURCE_NAME1}",
                           "interface": "${SRIOV-NIC-NAME1}",
                           "pfname": "${PF_NAME1}",
                           "driver": "${DRIVER_NAME1}",
                           "numVFsToCreate": ${NUM_VFS1}
                         },
                         {
                           "resourceName": "${RESOURCE_NAME2}",
                           "interface": "${SRIOV-NIC-NAME2}",
                           "pfname": "${PF_NAME2}",
                           "driver": "${DRIVER_NAME2}",
                           "numVFsToCreate": ${NUM_VFS2}
                         }
                      ]
              mode: 0644
              user:
                name: root
              group:
                name: root
            - path: /var/lib/rancher/rke2/server/manifests/sriov-crd.yaml
              overwrite: true
              contents:
                inline: |
                  apiVersion: helm.cattle.io/v1
                  kind: HelmChart
                  metadata:
                    name: sriov-crd
                    namespace: kube-system
                  spec:
                    chart: oci://registry.suse.com/edge/charts/sriov-crd
                    targetNamespace: sriov-network-operator
                    version: 303.0.2+up1.5.0
                    createNamespace: true
            - path: /var/lib/rancher/rke2/server/manifests/sriov-network-operator.yaml
              overwrite: true
              contents:
                inline: |
                  apiVersion: helm.cattle.io/v1
                  kind: HelmChart
                  metadata:
                    name: sriov-network-operator
                    namespace: kube-system
                  spec:
                    chart: oci://registry.suse.com/edge/charts/sriov-network-operator
                    targetNamespace: sriov-network-operator
                    version: 303.0.2+up1.5.0
                    createNamespace: true
        kernel_arguments:
          should_exist:
            - intel_iommu=on
            - iommu=pt
            - idle=poll
            - mce=off
            - hugepagesz=1G hugepages=40
            - hugepagesz=2M hugepages=0
            - default_hugepagesz=1G
            - irqaffinity=${NON-ISOLATED_CPU_CORES}
            - isolcpus=domain,nohz,managed_irq,${ISOLATED_CPU_CORES}
            - nohz_full=${ISOLATED_CPU_CORES}
            - rcu_nocbs=${ISOLATED_CPU_CORES}
            - rcu_nocb_poll
            - nosoftlockup
            - nowatchdog
            - nohz=on
            - nmi_watchdog=0
            - skew_tick=1
            - quiet
        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
            - name: cpu-partitioning.service
              enabled: true
              contents: |
                [Unit]
                Description=cpu-partitioning
                Wants=network-online.target
                After=network.target network-online.target
                [Service]
                Type=oneshot
                User=root
                ExecStart=/bin/sh -c "echo isolated_cores=${ISOLATED_CPU_CORES} > /etc/tuned/cpu-partitioning-variables.conf"
                ExecStartPost=/bin/sh -c "tuned-adm profile cpu-partitioning"
                ExecStartPost=/bin/sh -c "systemctl enable tuned.service"
                [Install]
                WantedBy=multi-user.target
            - name: performance-settings.service
              enabled: true
              contents: |
                [Unit]
                Description=performance-settings
                Wants=network-online.target
                After=network.target network-online.target cpu-partitioning.service
                [Service]
                Type=oneshot
                User=root
                ExecStart=/bin/sh -c "/opt/performance-settings/performance-settings.sh"
                [Install]
                WantedBy=multi-user.target
            - name: sriov-custom-auto-vfs.service
              enabled: true
              contents: |
                [Unit]
                Description=SRIOV Custom Auto VF Creation
                Wants=network-online.target  rke2-server.target
                After=network.target network-online.target rke2-server.target
                [Service]
                User=root
                Type=forking
                TimeoutStartSec=900
                ExecStart=/bin/sh -c "while ! /var/lib/rancher/rke2/bin/kubectl --kubeconfig=/etc/rancher/rke2/rke2.yaml wait --for condition=ready nodes --all ; do sleep 2 ; done"
                ExecStartPost=/bin/sh -c "while [ $(/var/lib/rancher/rke2/bin/kubectl --kubeconfig=/etc/rancher/rke2/rke2.yaml get sriovnetworknodestates.sriovnetwork.openshift.io --ignore-not-found --no-headers -A | wc -l) -eq 0 ]; do sleep 1; done"
                ExecStartPost=/bin/sh -c "/opt/sriov/sriov-auto-filler.sh"
                RemainAfterExit=yes
                KillMode=process
                [Install]
                WantedBy=multi-user.target
    kubelet:
      extraArgs:
        - provider-id=metal3://BAREMETALHOST_UUID
    nodeName: "localhost.localdomain"前の各ブロックを結合してファイルを作成したら、管理クラスタで次のコマンドを実行し、通信機能を使用する新しいダウンストリームクラスタのプロビジョニングを開始する必要があります。
$ kubectl apply -f capi-provisioning-example.yaml42.8 プライベートレジストリ #
ワークロードで使用するイメージのミラーとしてプライベートレジストリを設定できます。
そのために、ダウンストリームクラスタで使用するプライベートレジストリに関する情報を含むシークレットを作成します。
apiVersion: v1
kind: Secret
metadata:
  name: private-registry-cert
  namespace: default
data:
  tls.crt: ${TLS_CERTIFICATE}
  tls.key: ${TLS_KEY}
  ca.crt: ${CA_CERTIFICATE}
type: kubernetes.io/tls
---
apiVersion: v1
kind: Secret
metadata:
  name: private-registry-auth
  namespace: default
data:
  username: ${REGISTRY_USERNAME}
  password: ${REGISTRY_PASSWORD}tls.crt、tls.key、およびca.crtは、プライベートレジストリを認証するために使用する証明書です。usernameおよびpasswordは、プライベートレジストリを認証するために使用する資格情報です。
tls.crt、tls.key、ca.crt、username、およびpasswordは、シークレットで使用する前にbase64形式でエンコードする必要があります。
これらの変更をすべて行うと、capi-provisioning-example.yamlのRKE2ControlPlaneブロックは次のようになります。
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: single-node-cluster
  namespace: default
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3MachineTemplate
    name: single-node-cluster-controlplane
  replicas: 1
  version: ${RKE2_VERSION}
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  privateRegistriesConfig:
    mirrors:
      "registry.example.com":
        endpoint:
          - "https://registry.example.com:5000"
    configs:
      "registry.example.com":
        authSecret:
          apiVersion: v1
          kind: Secret
          namespace: default
          name: private-registry-auth
        tls:
          tlsConfigSecret:
            apiVersion: v1
            kind: Secret
            namespace: default
            name: private-registry-cert
  serverConfig:
    cni: calico
    cniMultusEnable: true
  agentConfig:
    format: ignition
    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
    kubelet:
      extraArgs:
        - provider-id=metal3://BAREMETALHOST_UUID
    nodeName: "localhost.localdomain"ここで、registry.example.comは、ダウンストリームクラスタで使用するプライベートレジストリの名前の例です。これは実際の値に置き換える必要があります。
42.9 エアギャップシナリオでのダウンストリームクラスタのプロビジョニング #
ダイレクトネットワークプロビジョニングワークフローでは、エアギャップシナリオでのダウンストリームクラスタのプロビジョニングを自動化できます。
42.9.1 エアギャップシナリオの要件 #
- EIBを使用して生成された- 生のイメージには、エアギャップシナリオでダウンストリームクラスタを実行するために必要な特定のコンテナイメージ(HelmチャートOCIイメージとコンテナイメージ)を含める必要があります。詳細については、こちらのセクション(42.3項 「エアギャップシナリオ用のダウンストリームクラスタイメージの準備」)を参照してください。
- SR-IOVまたはその他のカスタムワークロードを使用する場合、プライベートレジストリへのプリロードに関するセクション(42.3.2.7項 「エアギャップシナリオおよびSR-IOV (オプション)に必要なイメージのプライベートレジストリへのプリロード」)に従って、ワークロードを実行するために必要なイメージをプライベートレジストリにプリロードする必要があります。 
42.9.2 エアギャップシナリオでのベアメタルホストの登録 #
管理クラスタにベアメタルホストを登録するプロセスは、前のセクション(42.4項 「ダイレクトネットワークプロビジョニングを使用したダウンストリームクラスタのプロビジョニング(シングルノード)」)で説明したプロセスと同じです。
42.9.3 エアギャップシナリオでのダウンストリームクラスタのプロビジョニング #
エアギャップシナリオでダウンストリームクラスタをプロビジョニングするために必要となる重要な変更がいくつかあります。
- capi-provisioning-example.yamlファイルの- RKE2ControlPlaneブロックに- spec.agentConfig.airGapped: trueディレクティブを含める必要があります。
- プライベートレジストリに関するセクション(42.8項 「プライベートレジストリ」)に従って、プライベートレジストリの設定を - capi-provisioning-airgap-example.yamlファイルの- RKE2ControlPlaneブロックに含める必要があります。
- SR-IOV、またはHelmチャートをインストールする必要があるその他の - AdditionalUserData設定(combustionスクリプト)を使用している場合、内容を変更して、パブリックレジストリを使用するのではなくプライベートレジストリを参照する必要があります。
次の例は、プライベートレジストリを参照するために必要な変更を行った、capi-provisioning-airgap-example.yamlファイルのAdditionalUserDataブロックのSR-IOVの設定を示しています。
- プライベートレジストリのシークレットの参照 
- パブリックOCIイメージではなくプライベートレジストリを使用するHelmチャートの定義 
# secret to include the private registry certificates
apiVersion: v1
kind: Secret
metadata:
  name: private-registry-cert
  namespace: default
data:
  tls.crt: ${TLS_BASE64_CERT}
  tls.key: ${TLS_BASE64_KEY}
  ca.crt: ${CA_BASE64_CERT}
type: kubernetes.io/tls
---
# secret to include the private registry auth credentials
apiVersion: v1
kind: Secret
metadata:
  name: private-registry-auth
  namespace: default
data:
  username: ${REGISTRY_USERNAME}
  password: ${REGISTRY_PASSWORD}
---
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: single-node-cluster
  namespace: default
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3MachineTemplate
    name: single-node-cluster-controlplane
  replicas: 1
  version: ${RKE2_VERSION}
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  privateRegistriesConfig:       # Private registry configuration to add your own mirror and credentials
    mirrors:
      docker.io:
        endpoint:
          - "https://$(PRIVATE_REGISTRY_URL)"
    configs:
      "192.168.100.22:5000":
        authSecret:
          apiVersion: v1
          kind: Secret
          namespace: default
          name: private-registry-auth
        tls:
          tlsConfigSecret:
            apiVersion: v1
            kind: Secret
            namespace: default
            name: private-registry-cert
          insecureSkipVerify: false
  serverConfig:
    cni: calico
    cniMultusEnable: true
  preRKE2Commands:
    - modprobe vfio-pci enable_sriov=1 disable_idle_d3=1
  agentConfig:
    airGapped: true       # Airgap true to enable airgap mode
    format: ignition
    additionalUserData:
      config: |
        variant: fcos
        version: 1.4.0
        storage:
          files:
            - path: /var/lib/rancher/rke2/server/manifests/configmap-sriov-custom-auto.yaml
              overwrite: true
              contents:
                inline: |
                  apiVersion: v1
                  kind: ConfigMap
                  metadata:
                    name: sriov-custom-auto-config
                    namespace: sriov-network-operator
                  data:
                    config.json: |
                      [
                         {
                           "resourceName": "${RESOURCE_NAME1}",
                           "interface": "${SRIOV-NIC-NAME1}",
                           "pfname": "${PF_NAME1}",
                           "driver": "${DRIVER_NAME1}",
                           "numVFsToCreate": ${NUM_VFS1}
                         },
                         {
                           "resourceName": "${RESOURCE_NAME2}",
                           "interface": "${SRIOV-NIC-NAME2}",
                           "pfname": "${PF_NAME2}",
                           "driver": "${DRIVER_NAME2}",
                           "numVFsToCreate": ${NUM_VFS2}
                         }
                      ]
              mode: 0644
              user:
                name: root
              group:
                name: root
            - path: /var/lib/rancher/rke2/server/manifests/sriov.yaml
              overwrite: true
              contents:
                inline: |
                  apiVersion: v1
                  data:
                    .dockerconfigjson: ${REGISTRY_AUTH_DOCKERCONFIGJSON}
                  kind: Secret
                  metadata:
                    name: privregauth
                    namespace: kube-system
                  type: kubernetes.io/dockerconfigjson
                  ---
                  apiVersion: v1
                  kind: ConfigMap
                  metadata:
                    namespace: kube-system
                    name: example-repo-ca
                  data:
                    ca.crt: |-
                      -----BEGIN CERTIFICATE-----
                      ${CA_BASE64_CERT}
                      -----END CERTIFICATE-----
                  ---
                  apiVersion: helm.cattle.io/v1
                  kind: HelmChart
                  metadata:
                    name: sriov-crd
                    namespace: kube-system
                  spec:
                    chart: oci://${PRIVATE_REGISTRY_URL}/sriov-crd
                    dockerRegistrySecret:
                      name: privregauth
                    repoCAConfigMap:
                      name: example-repo-ca
                    createNamespace: true
                    set:
                      global.clusterCIDR: 192.168.0.0/18
                      global.clusterCIDRv4: 192.168.0.0/18
                      global.clusterDNS: 10.96.0.10
                      global.clusterDomain: cluster.local
                      global.rke2DataDir: /var/lib/rancher/rke2
                      global.serviceCIDR: 10.96.0.0/12
                    targetNamespace: sriov-network-operator
                    version: 303.0.2+up1.5.0
                  ---
                  apiVersion: helm.cattle.io/v1
                  kind: HelmChart
                  metadata:
                    name: sriov-network-operator
                    namespace: kube-system
                  spec:
                    chart: oci://${PRIVATE_REGISTRY_URL}/sriov-network-operator
                    dockerRegistrySecret:
                      name: privregauth
                    repoCAConfigMap:
                      name: example-repo-ca
                    createNamespace: true
                    set:
                      global.clusterCIDR: 192.168.0.0/18
                      global.clusterCIDRv4: 192.168.0.0/18
                      global.clusterDNS: 10.96.0.10
                      global.clusterDomain: cluster.local
                      global.rke2DataDir: /var/lib/rancher/rke2
                      global.serviceCIDR: 10.96.0.0/12
                    targetNamespace: sriov-network-operator
                    version: 303.0.2+up1.5.0
              mode: 0644
              user:
                name: root
              group:
                name: root
        kernel_arguments:
          should_exist:
            - intel_iommu=on
            - iommu=pt
            - idle=poll
            - mce=off
            - hugepagesz=1G hugepages=40
            - hugepagesz=2M hugepages=0
            - default_hugepagesz=1G
            - irqaffinity=${NON-ISOLATED_CPU_CORES}
            - isolcpus=domain,nohz,managed_irq,${ISOLATED_CPU_CORES}
            - nohz_full=${ISOLATED_CPU_CORES}
            - rcu_nocbs=${ISOLATED_CPU_CORES}
            - rcu_nocb_poll
            - nosoftlockup
            - nowatchdog
            - nohz=on
            - nmi_watchdog=0
            - skew_tick=1
            - quiet
        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
            - name: cpu-partitioning.service
              enabled: true
              contents: |
                [Unit]
                Description=cpu-partitioning
                Wants=network-online.target
                After=network.target network-online.target
                [Service]
                Type=oneshot
                User=root
                ExecStart=/bin/sh -c "echo isolated_cores=${ISOLATED_CPU_CORES} > /etc/tuned/cpu-partitioning-variables.conf"
                ExecStartPost=/bin/sh -c "tuned-adm profile cpu-partitioning"
                ExecStartPost=/bin/sh -c "systemctl enable tuned.service"
                [Install]
                WantedBy=multi-user.target
            - name: performance-settings.service
              enabled: true
              contents: |
                [Unit]
                Description=performance-settings
                Wants=network-online.target
                After=network.target network-online.target cpu-partitioning.service
                [Service]
                Type=oneshot
                User=root
                ExecStart=/bin/sh -c "/opt/performance-settings/performance-settings.sh"
                [Install]
                WantedBy=multi-user.target
            - name: sriov-custom-auto-vfs.service
              enabled: true
              contents: |
                [Unit]
                Description=SRIOV Custom Auto VF Creation
                Wants=network-online.target  rke2-server.target
                After=network.target network-online.target rke2-server.target
                [Service]
                User=root
                Type=forking
                TimeoutStartSec=1800
                ExecStart=/bin/sh -c "while ! /var/lib/rancher/rke2/bin/kubectl --kubeconfig=/etc/rancher/rke2/rke2.yaml wait --for condition=ready nodes --timeout=30m --all ; do sleep 10 ; done"
                ExecStartPost=/bin/sh -c "/opt/sriov/sriov-auto-filler.sh"
                RemainAfterExit=yes
                KillMode=process
                [Install]
                WantedBy=multi-user.target
    kubelet:
      extraArgs:
        - provider-id=metal3://BAREMETALHOST_UUID
    nodeName: "localhost.localdomain"
