|Index|SUSE Telco Cloud ドキュメント|ヒントとトラブルシューティング|Metal3
適用項目 SUSE Telco Cloud 3.6

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