67 Metal3 #
67.1 `BareMetalHost`の選択とクラスターの関連付け #
Metalˆ3ˆクラスターオブジェクトとその対応する関連オブジェクトが作成されると、どの`BareMetalHost`をクラスターの一部にするかを選択するプロセスが実行されます。 このプロセスは、標準の Kubernetesラベルおよびセレクターを使用して、`BareMetalHost`と特定の`Metal3MachineTemplate`を接続します。
例として、各`BareMetalHost`には、そのプロパティと対象のクラスターを識別するためのラベルが付けられます(例:クラスターロール、クラスター名、場所など)。
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
name: mynode1
labels:
cluster-role: control-plane
cluster: foobar
location: madrid
datacenter: xyz
<snip>
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
name: mynode2
labels:
cluster-role: worker
cluster: foobar
location: madrid
datacenter: xyz
<snip>
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
name: mynode3
labels:
cluster-role: worker
cluster: foobar2
location: madrid
datacenter: xyz
<snip>
...次に、`Metal3MachineTemplate`オブジェクトは spec.hostSelectorフィールドを使用して、目的の`BareMetalHost`と照合します。
matchLabels(完全なキーと値の一致用)と matchExpressions(より複雑なルール用)の両方を使用できます。
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: Metal3MachineTemplate
metadata:
name: foobar-cluster-controlplane
namespace: mynamespace
spec:
template:
spec:
hostSelector:
matchLabels:
cluster-role: control-plane
cluster: foobar
<snip>
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: Metal3MachineTemplate
metadata:
name: foobar-cluster-worker
namespace: mynamespace
spec:
template:
spec:
hostSelector:
matchExpressions:
- { key: cluster-role, operator: In, values: [worker] }
- { key: cluster, operator: In, values: [foobar] }
<snip>Kubernetesネームスペースを使用して、さまざまなオブジェクトをより適切に整理することもできます。
67.2 古いEFIブートエントリーのクリーンアップ #
UEFIブートマネージャーには、おそらくもう不要な古いオペレーティングシステムの項目が複数含まれていることがあります(特に、ホストが何度も再プロビジョニングされる場合に顕著です)。 以下のいずれかの手順に従って、それらの古い項目をクリーンアップできます。
BIOS/EFIセットアップインターフェース上で直接削除します(正確な手順はハードウェアによって異なります)。
UEFI
bcfgシェルを次のように実行します。# List the entries bcfg boot dump -b # Delete entry number X bcfg boot rm X # X is the number associated the entry to remove. For example, if the entry is "Boot0002 foobar", then X is 2.Linuxシステム上で`efibootmgr`を次のように使用します。
# List the entries efibootmgr -v # Delete entry number X efibootmgr -b X -B
このプロセスにより、EFIシステムパーティション(ESP)に孤立したファイルが残る場合があります。これらは通常、ベンダー名(例: EFI/opensuse`や`EFI/Microsoft)のサブディレクトリにあります。
これらのファイルは一般的に無害ですが、過剰な容量を消費している場合は、新しいOSのインストールやブートマネージャーの更新を妨げる可能性があるため、削除する必要があります。
削除するには、ESPを明示的にマウントする必要がある場合があります。通常、Linuxシステムでは`/boot/efi/EFI`としてマウントされます。
67.3 2つのシークレットアプローチを使用したカスタムネットワーク構成 #
Metal3がベアメタルノードをプロビジョニングする際、それぞれ異なるネットワーク構成が必要となる可能性のある2つの明確なフェーズを経由します。
IPAフェーズ:ハードウェアの検査およびプロビジョニング中にIronic Python Agent(IPA)ラムディスクが実行されるフェーズ
ターゲットOSフェーズ。デプロイされたSLE Microシステムが初回起動後に実行されるフェーズです。
2つのシークレットを使用するアプローチは、各フェーズごとに個別のネットワーク設定用シークレットを許可することでこの問題に対処します。IPAフェーズには`preprovisioningNetworkDataName`フィールドを、ターゲットOSフェーズには`networkData`フィールドを使用します。 これは、IPAカーネルとSLE Microカーネルが同じハードウェアを異なる名前で検出するため、フェーズ間でインターフェース名が異なる場合に特に便利です。
67.3.1 VLANのインターフェース名変更の例 #
一般的なシナリオとしては、ハードウェアが`enp1s0np123`のような長いPCIベースのインターフェース名を取得する場合があります。 その上にVLANを追加すると、Linuxカーネルのインターフェース名に対するハード制限である*15文字*を超える可能性があります。
enp1s0np123.100 = 15 chars (barely fits, risky)
enp1s0np123.3669 = 17 chars (exceeds limit, fails)
eth0.3669 = 9 chars (works)IPAフェーズでは`enp1s0np123`(カーネルが検出した名前)を参照する必要があり、ターゲットOSでは`eth0`のような短い名前を使用して`eth0.3669`が制限内に収まるようにします。nmc(nm-configurator)は、名前ではなくMACアドレスでインターフェースを照合することで2つのフェーズを橋渡しします。つまり、ハードウェアMACアドレスと一緒に`name: eth0`を宣言し、`nmc`はカーネルが何を割り当てたかに関係なく、目的の名前でNetworkManagerプロファイルを作成します。
67.3.2 前提条件: #
67.3.2.1 EIBイメージのセットアップ #
静的ネットワーク設定ガイドに従い、EIBイメージには、プロビジョニング中にMetal3が書き込む`config-2`パーティションからネットワーク設定を読み取る初回起動用スクリプトを含める必要があります。 次のスクリプトを`/opt/EIB/network/configure-network.sh`に作成してください。
#!/bin/bash
set -eux
# Source: https://documentation.suse.com/suse-edge/3.6/html/edge/quickstart-metal3.html#metal3-add-network-eib
CONFIG_DRIVE=$(blkid --label config-2 || true)
if [ -z "${CONFIG_DRIVE}" ]; then
echo "No config-2 device found, skipping network configuration"
exit 0
fi
mount -o ro $CONFIG_DRIVE /mnt
NETWORK_DATA_FILE="/mnt/openstack/latest/network_data.json"
if [ ! -f "${NETWORK_DATA_FILE}" ]; then
umount /mnt
echo "No network_data.json found, skipping network configuration"
exit 0
fi
DESIRED_HOSTNAME=$(cat /mnt/openstack/latest/meta_data.json | tr ',{}' '\n' | grep '\"metal3-name\"' | sed 's/.*\"metal3-name\": \"\(.*\)\"/\1/')
echo "${DESIRED_HOSTNAME}" > /etc/hostname
mkdir -p /tmp/nmc/{desired,generated}
cp ${NETWORK_DATA_FILE} /tmp/nmc/desired/_all.yaml
umount /mnt
./nmc generate --config-dir /tmp/nmc/desired --output-dir /tmp/nmc/generated
./nmc apply --config-dir /tmp/nmc/generated次に、それを実行可能にしてから、通常通りEIBイメージをビルドします。
mkdir -p /opt/EIB/network
chmod +x /opt/EIB/network/configure-network.sh=== EIBは`network/`ディレクトリからスクリプトを自動的に取得します。Combustionは、完全なOSが起動する前のinitramfs内で初回起動時にそれらを実行します。 ===
=== このスクリプトは、Metal3の`metal3-name`メタデータフィールドからノードのホスト名も設定します。 ===
67.3.3 2つのシークレットの設定 #
以下の例では、データNIC MAC aa:bb:cc:11:22:33、ブートNIC MAC aa:bb:cc:44:55:66、ノードIP 10.0.0.10/24、ゲートウェイ 10.0.0.1、DNS 10.0.0.53、VLAN ID 100、BMCアドレス `10.1.0.10`のダミー値を使用しています。
シークレット1 — IPAフェーズ (static-networkdata-ipa.yaml):カーネルが割り当てたインターフェース名を参照します。ハードウェア検出中にシンプルに保つため、ここではDHCPを使用します。
apiVersion: v1
kind: Secret
metadata:
name: static-networkdata-ipa
namespace: default
type: Opaque
stringData:
networkData: |
interfaces:
- name: enp1s0np123
type: ethernet
state: up
mac-address: "aa:bb:cc:11:22:33"
ipv4:
enabled: true
dhcp: true
dns-resolver:
config:
server:
- 10.0.0.53シークレット2 — ターゲットOSフェーズ (static-networkdata-os.yaml):目的の短い名前を参照し、VLANを宣言します。`nmc`がインターフェースを照合できるように、同じMACアドレスが使用されます。
apiVersion: v1
kind: Secret
metadata:
name: static-networkdata-os
namespace: default
type: Opaque
stringData:
networkData: |
interfaces:
- name: eth0
type: ethernet
state: up
mac-address: "aa:bb:cc:11:22:33"
mtu: 1500
ipv4:
enabled: false
dhcp: false
- name: eth0.100
type: vlan
state: up
mtu: 1500
vlan:
base-iface: eth0
id: 100
ipv4:
address:
- ip: 10.0.0.10
prefix-length: 24
enabled: true
dhcp: false
dns-resolver:
config:
server:
- 10.0.0.53
routes:
config:
- destination: 0.0.0.0/0
next-hop-address: 10.0.0.1
next-hop-interface: eth0.100`BareMetalHost`オブジェクトは両方のシークレットを参照します。
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
name: my-node
namespace: default
spec:
online: true
bootMACAddress: "aa:bb:cc:44:55:66"
rootDeviceHints:
deviceName: /dev/nvme0n1
bmc:
address: redfish-virtualmedia://10.1.0.10/redfish/v1/Systems/1/
disableCertificateVerification: true
credentialsName: my-node-credentials
preprovisioningNetworkDataName: static-networkdata-ipa
networkData:
name: static-networkdata-os`preprovisioningNetworkDataName`はプレーンな文字列フィールドですが、`networkData`は`name:`サブキーを必要とするSecretReferenceオブジェクトです。 両者の構文は異なっており、エラーの一般的な原因となっています。
すべてのオブジェクトを適用します:
kubectl apply -f bmc-credentials.yaml
kubectl apply -f static-networkdata-ipa.yaml
kubectl apply -f static-networkdata-os.yaml
kubectl apply -f baremetalhost.yamlプロビジョニング後、ノードにSSH接続して以下を確認してください:
# Interface names
ip link show
# Expected: eth0 and eth0.100@eth0
# IP on VLAN interface
ip addr show eth0.100
# NetworkManager profiles
nmcli connection show
# VLAN details
nmcli connection show eth0.100 | grep -E '(vlan.parent|vlan.id)'