42 完全に自動化されたダイレクトネットワークプロビジョニング #
42.1 はじめに #
ダイレクトネットワークプロビジョニングは、ダウンストリームクラスタのプロビジョニングを自動化できる機能です。この機能は、プロビジョニングするダウンストリームクラスタが多数あり、そのプロセスを自動化したい場合に便利です。
管理クラスタ(第40章 「管理クラスタの設定」)は、次のコンポーネントのデプロイメントを自動化します。
SUSE Linux Micro RT(OS)。ユースケースに応じて、ネットワーキング、ストレージ、ユーザ、カーネル引数などの設定をカスタマイズできます。RKE2(Kubernetesクラスタ)。デフォルトのCNIプラグインはCiliumです。ユースケースに応じて、特定のCNIプラグイン(Cilium+Multusなど)を使用できます。SUSE StorageSUSE SecurityMetalLB。高可用性マルチノードクラスタのロードバランサとして使用できます。
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"
