5.4. プロビジョニングされていないノードが含まれるネットワーカーノードセットの OpenStackDataPlaneNodeSet CR を作成する

手順

1. Bare Metal Operator (BMO) は、デフォルトで openshift-machine-api namespace 内の BareMetalHost カスタムリソース (CR) を管理します。すべての namespace を監視するように Provisioning CR を更新します。

   $ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'

2. ベアメタルネットワーカーノードに仮想メディアブートを使用しており、ノードがプロビジョニングネットワークに接続されていない場合は、Provisioning CR を更新して virtualMediaViaExternalNetwork を有効にする必要があります。これにより、外部ネットワーク経由でベアメタル接続が有効になります。

   $ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"virtualMediaViaExternalNetwork": true }}'

3. ノードセット内の各ベアメタルネットワーカーノードのベースボード管理コントローラー (BMC) にアクセスするための認証情報を含む Secret CR を定義するファイルをワークステーションに作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: edpm-networker-0-bmc-secret
     namespace: openstack
   type: Opaque
   data:
     username: <base64_username>
     password: <base64_password>

   • <base64_username> と <base64_password> を base64 でエンコードされた文字列に置き換えます。次のコマンドを使用して、base64 でエンコードされた文字列を生成できます。

     $ echo -n <string> | base64

     ヒント

     ユーザー名とパスワードを base64 でエンコードする必要がない場合は、data フィールドの代わりに stringData フィールドを使用してユーザー名とパスワードを設定します。

4. ワークステーションに bmh_networker_nodes.yaml という名前のファイルを作成し、各ベアメタルネットワーカーノードの BareMetalHost CR を定義します。次の例では、プロビジョニング方法 Redfish 仮想メディアを使用して BareMetalHost CR を作成します。

   apiVersion: metal3.io/v1alpha1
   kind: BareMetalHost
   metadata:
     name: edpm-networker-0
     namespace: openstack
     labels: 

   1

   
       app: openstack-networker
       workload: networker
   spec:
   ...
     bmc:
       address: redfish-virtualmedia+http://192.168.111.1:8000/redfish/v1/Systems/e8efd888-f844-4fe0-9e2e-498f4ab7806d 

   2

   
       credentialsName: edpm-networker-0-bmc-secret 

   3

   
     bootMACAddress: 00:c7:e4:a7:e7:f3
     bootMode: UEFI
     online: false
    [preprovisioningNetworkDataName: <network_config_secret_name>] 

   4

   1

   app、workload、nodeName などのメタデータラベルは、ノードのラベル付けにさまざまなレベルの粒度を指定するためのキーと値のペアです。これらのラベルは、OpenStackDataPlaneNodeSet CR の作成時に使用して、プロビジョニングするベアメタルノードの設定を記述したり、ノードセット内のノードを定義したりできます。

   2

   ノードの BMC コントローラーと通信するための URL。他のプロビジョニング方法での BMC アドレス指定の詳細は、インストーラーでプロビジョニングされたクラスターのベアメタルへのデプロイ ガイドの BMC アドレス指定 を参照してください。

   3

   ノードの BMC にアクセスするために前の手順で作成した Secret CR の名前。

   4

   オプション: 事前にプロビジョニングされたイメージに渡す、ローカル namespace のネットワーク設定シークレットの名前。ネットワーク設定は nmstate 形式である必要があります。

   BareMetalHost CR を作成する方法の詳細は、RHOCP の インストール後の設定 ガイドの BareMetalHost リソースについて を参照してください。

5. BareMetalHost リソースを作成します。

   $ oc create -f bmh_networker_nodes.yaml

6. BareMetalHost リソースが作成され、Available 状態になっていることを確認します。

   $ oc get bmh
   NAME         STATE            CONSUMER              ONLINE   ERROR   AGE
   edpm-networker-0   Available      openstack-edpm        true             2d21h
   edpm-networker-1   Available      openstack-edpm        true             2d21h
   ...

手順

1. ワークステーションに openstack_unprovisioned_node_set.yaml という名前のファイルを作成し、OpenStackDataPlaneNodeSet CR を定義します。

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: openstack-data-plane 

   1

   
     namespace: openstack
   spec:
     tlsEnabled: true
     env: 

   2

   
       - name: ANSIBLE_FORCE_COLOR
         value: "True"

   1

   OpenStackDataPlaneNodeSet CR 名は、一意であり、小文字の英数字と - (ハイフン) または . (ピリオド) のみが含まれ、先頭と末尾は英数字で、最大長 53 文字である必要があります。この例の名前を、セット内のノードを表す名前に更新してください。

   2

   オプション: Pod に渡す環境変数のリスト。

2. データプレーンをコントロールプレーンネットワークに接続します。

   spec:
     ...
     networkAttachments:
       - ctlplane

3. このセット内のノードはプロビジョニングされていないため、リソースの作成時にプロビジョニングする必要があることを指定します。

     preProvisioned: false

4. リソース作成時にプロビジョニングする必要があるベアメタルノードの設定を記述するには、baremetalSetTemplate フィールドを定義します。

     baremetalSetTemplate:
       deploymentSSHSecret: dataplane-ansible-ssh-private-key-secret
       bmhNamespace: <bmh_namespace>
       cloudUserName: <ansible_ssh_user>
       bmhLabelSelector:
         app: <bmh_label>
       ctlplaneInterface: <interface>

   • <bmh_namespace> は、ノードの対応する BareMetalHost CR で定義されている namespace (例: openshift-machine-api) に置き換えます。
   • <ansible_ssh_user> は、Ansible SSH ユーザーのユーザー名 (例: cloud-admin) に置き換えます。
   • <bmh_label> は、ノードの対応する BareMetalHost CR で定義されているラベル (例: openstack-networker) に置き換えます。app、workload、nodeName などのメタデータラベルは、ノードのラベル付けにさまざまなレベルの粒度を指定するためのキーと値のペアです。対応する BareMetalHost CR 内のラベルと一致するラベルに基づいてデータプレーンノードを選択するには、bmhLabelSelector フィールドを設定します。
   • <interface> は、ノードが接続するコントロールプレーンインターフェイス (例: enp6s0) に置き換えます。

5. カスタム OpenStackProvisionServer CR を作成した場合は、それを baremetalSetTemplate 定義に追加します。

     baremetalSetTemplate:
       ...
       provisionServerName: my-os-provision-server

6. Ansible がデータプレーンノードに接続できるようにするために作成した SSH 鍵シークレットを追加します。

     nodeTemplate:
       ansibleSSHPrivateKeySecret: <secret-key>

   • <secret-key> は、<link>[データプレーンシークレットの作成] で作成した SSH 鍵の Secret CR の名前 (例: dataplane-ansible-ssh-private-key-secret) に置き換えます。
7. ログを保存するために、Red Hat OpenShift Container Platform (RHOCP) クラスターの openstack namespace に永続ボリューム要求 (PVC) を作成します。volumeMode を Filesystem に、accessModes を ReadWriteOnce に設定します。NFS ボリュームプラグインを使用する PersistentVolume (PV) からのログのストレージを要求しないでください。NFS は FIFO と互換性がないため、ansible-runner はログを保存するために書き込む FIFO ファイルを作成します。PVC の詳細は、RHOCP ストレージ ガイドの 永続ストレージについて、および デプロイメントのプランニング の Red Hat OpenShift Container Platform クラスターの要件 を参照してください。

8. データプレーンノードの永続的なロギングを有効にします。

     nodeTemplate:
       ...
       extraMounts:
         - extraVolType: Logs
           volumes:
           - name: ansible-logs
             persistentVolumeClaim:
               claimName: <pvc_name>
           mounts:
           - name: ansible-logs
             mountPath: "/runner/artifacts"

   • <pvc_name> を、RHOCP クラスター上の PVC ストレージの名前に置き換えます。

9. 管理ネットワークを指定します。

     nodeTemplate:
       ...
       managementNetwork: ctlplane

10. Red Hat カスタマーポータルに登録されていないノードのオペレーティングシステムを登録するためのユーザー名とパスワードの取得に使用する Secret CR を指定し、ノードのリポジトリーを有効にします。次の例は、ノードを Red Hat コンテンツ配信ネットワーク (CDN) に登録する方法を示しています。Red Hat Satellite 6.13 でノードを登録する方法については、ホストの管理 を参照してください。

      nodeTemplate:
        ansible:
          ansibleUser: cloud-admin 

    1

    
          ansiblePort: 22
          ansibleVarsFrom:
            - secretRef:
                name: subscription-manager
            - secretRef:
                name: redhat-registry
          ansibleVars: 

    2

    
            rhc_release: 9.4
            rhc_repositories:
                - {name: "*", state: disabled}
                - {name: "rhel-9-for-x86_64-baseos-eus-rpms", state: enabled}
                - {name: "rhel-9-for-x86_64-appstream-eus-rpms", state: enabled}
                - {name: "rhel-9-for-x86_64-highavailability-eus-rpms", state: enabled}
                - {name: "fast-datapath-for-rhel-9-x86_64-rpms", state: enabled}
                - {name: "rhoso-18.0-for-rhel-9-x86_64-rpms", state: enabled}
                - {name: "rhceph-7-tools-for-rhel-9-x86_64-rpms", state: enabled}
            edpm_bootstrap_release_version_package: []

    1

    <link>[データプレーンシークレットの作成] で作成したシークレットに関連付けられているユーザー。

    2

    ノードのセットをカスタマイズする Ansible 変数。使用できる Ansible 変数のリストは、https://openstack-k8s-operators.github.io/edpm-ansible/ を参照してください。

    Red Hat カスタマーポータル登録コマンドの完全なリストは、https://access.redhat.com/solutions/253273 を参照してください。registry.redhat.io にログインする方法は、https://access.redhat.com/RegistryAuthentication#creating-registry-service-accounts-6 を参照してください。

11. データプレーンノードに適用するネットワーク設定テンプレートを追加します。

      nodeTemplate:
        ...
        ansible:
          ...
           ansiblePort: 22
          ansibleUser: cloud-admin
          ansibleVars:
            ...
            edpm_enable_chassis_gw: true
            edpm_network_config_nmstate: true
            ...
            neutron_physical_bridge_name: br-ex
            neutron_public_interface_name: eth0
            edpm_network_config_update: false 

    1

    1

    ノードセットの初回デプロイ時には、edpm_network_config_update 変数を false に設定します。ノードセットを更新または導入する場合は、edpm_network_config_update 変数を true に設定して、更新時にネットワーク設定の変更を適用します。この変数は、更新後または導入後に false にリセットします。これを false にリセットしないと、configure-network サービスが含まれる OpenStackDataPlaneDeployment CR が作成されるたびに、更新されたネットワーク設定が再適用されます。

    次の例では、DPDK を使用してデータプレーンネットワーカーノードのセットに VLAN ネットワーク設定を適用します。

            edpm_network_config_template: |
              ...
              {% set mtu_list = [ctlplane_mtu] %}
              {% for network in nodeset_networks %}
              {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
              {%- endfor %}
              {% set min_viable_mtu = mtu_list | max %}
              network_config:
              - type: ovs_user_bridge
                name: {{ neutron_physical_bridge_name }}
                mtu: {{ min_viable_mtu }}
                use_dhcp: false
                dns_servers: {{ ctlplane_dns_nameservers }}
                domain: {{ dns_search_domains }}
                addresses:
                - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }}
                routes: {{ ctlplane_host_routes }}
                members:
                - type: ovs_dpdk_port
                  driver: mlx5_core
                  name: dpdk0
                  mtu: {{ min_viable_mtu }}
                  members:
                  - type: sriov_vf
                    device: nic6
                    vfid: 0
                - type: interface
                  name: nic1
                  mtu: {{ min_viable_mtu }}
                  # force the MAC address of the bridge to this interface
                  primary: true
              {% for network in nodeset_networks %}
                - type: vlan
                  mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
                  vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
                  addresses:
                  - ip_netmask:
                      {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
                  routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
              {% endfor %}

    次の例では、DPDK を使用せずに VLAN ネットワーク設定をデータプレーンネットワーカーノードのセットに適用します。

    edpm_network_config_template: |
              …---
              {% set mtu_list = [ctlplane_mtu] %}
              {% for network in nodeset_networks %}
              {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
              {%- endfor %}
              {% set min_viable_mtu = mtu_list | max %}
              network_config:
                - type: ovs_bridge
                  name: {{ neutron_physical_bridge_name }}
                  mtu: {{ min_viable_mtu }}
                  use_dhcp: false
                  dns_servers: {{ ctlplane_dns_nameservers }}
                  domain: {{ dns_search_domains }}
                  addresses:
                    - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }}
                  routes: {{ ctlplane_host_routes }}
                  members:
                    - type: interface
                      name: nic2
                      mtu: {{ min_viable_mtu }}
                      # force the MAC address of the bridge to this interface
                      primary: true
              {% for network in nodeset_networks %}
                    - type: vlan
                      mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
                      vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
                      addresses:
                        - ip_netmask: >-
                            {{
                              lookup('vars', networks_lower[network] ~ '_ip')
                            }}/{{
                              lookup('vars', networks_lower[network] ~ '_cidr')
                            }}
                      routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
              {% endfor %}

    データプレーンネットワーク設定の詳細は、ネットワークサービスの設定 の データプレーンネットワークのカスタマイズ を参照してください。

12. このグループ内のノードセットの共通設定を nodeTemplate セクションに追加します。この OpenStackDataPlaneNodeSet 内の各ノードがこの設定を継承します。共通のノード属性を設定するために使用できるプロパティーの詳細は、Red Hat OpenStack Services on OpenShift のデプロイ ガイドの OpenStackDataPlaneNodeSet CR の spec プロパティー を参照してください。

13. このノードセット内の各ノードを定義します。

      nodes:
        edpm-networker-0: 

    1

    
          hostName: networker-0
          networks: 

    2

    
          - name: ctlplane
            subnetName: subnet1
            defaultRoute: true
            fixedIP: 192.168.122.100 

    3

    
          - name: internalapi
            subnetName: subnet1
            fixedIP: 172.17.0.100
          - name: storage
            subnetName: subnet1
            fixedIP: 172.18.0.100
          - name: tenant
            subnetName: subnet1
            fixedIP: 172.19.0.100
          ansible:
            ansibleHost: 192.168.122.100
            ansibleUser: cloud-admin
            ansibleVars:
              fqdn_internal_api: edpm-networker-0.example.com
          bmhLabelSelector: 

    4

    
            nodeName: edpm-networker-0
        edpm-networker-1:
          hostName: edpm-networker-1
          networks:
          - name: ctlplane
            subnetName: subnet1
            defaultRoute: true
            fixedIP: 192.168.122.101
          - name: internalapi
            subnetName: subnet1
            fixedIP: 172.17.0.101
          - name: storage
            subnetName: subnet1
            fixedIP: 172.18.0.101
          - name: tenant
            subnetName: subnet1
            fixedIP: 172.19.0.101
          ansible:
            ansibleHost: 192.168.122.101
            ansibleUser: cloud-admin
            ansibleVars:
              fqdn_internal_api: edpm-networker-1.example.com
          bmhLabelSelector:
            nodeName: edpm-networker-1

    1

    ノード定義の参照 (例: edpm-networker-0)。ノードセット内の各ノードにノード定義が必要です。

    2

    ノードの IPAM と DNS レコードを定義します。

    3

    ネットワークの予測可能な IP アドレスを指定します。この場合、NetConfig CR でネットワークに定義された割り当て範囲内のアドレスでなければなりません。

    4

    オプション: データプレーンノードの BareMetalHost CR を選択する BareMetalHost CR メタデータラベル。ラベルは、BareMetalHost CR に対して定義されている任意のラベルにすることができます。このラベルは、baremetalSetTemplate 定義で設定された bmhLabelSelector ラベルとともに使用され、ノードの BareMetalHost を選択します。

    注記
    • nodes セクションに定義するノードには、nodeTemplate セクションで設定されているのと同じ Ansible 変数を設定できます。Ansible 変数が特定のノードと nodeTemplate セクション内の両方に設定されている場合は、ノード固有の値が nodeTemplate セクションの値をオーバーライドします。
    • ノードのすべての nodeTemplate Ansible 変数を複製してデフォルトをオーバーライドし、ノード固有の値を設定する必要はありません。設定する必要があるのは、オーバーライドするノードの Ansible 変数だけです。
    • 多くの ansibleVars の名前には edpm が含まれています。これは "External Data Plane Management (外部データプレーン管理)" の略です。

    共通のノード属性を設定するために使用できるプロパティーの詳細は、Red Hat OpenStack Services on OpenShift のデプロイ ガイドの OpenStackDataPlaneNodeSet CR の spec プロパティー を参照してください。

14. openstack_unprovisioned_node_set.yaml 定義ファイルを保存します。

15. データプレーンリソースを作成します。

    $ oc create --save-config -f openstack_unprovisioned_node_set.yaml -n openstack

16. ステータスが SetupReady であることを確認して、データプレーンリソースが作成されたことを確認します。

    $ oc wait openstackdataplanenodeset openstack-data-plane --for condition=SetupReady --timeout=10m

    ステータスが SetupReady の場合、コマンドは condition met メッセージを返し、それ以外の場合はタイムアウトエラーを返します。

    データプレーンの条件と状態の詳細は、Red Hat OpenStack Services on OpenShift のデプロイ の データプレーンの条件と状態 を参照してください。

17. ノードセットの Secret リソースが作成されたことを確認します。

    $ oc get secret -n openstack | grep openstack-data-plane
    dataplanenodeset-openstack-data-plane Opaque 1 3m50s

18. ノードが provisioned 状態に移行したことを確認します。

    $ oc get bmh
    NAME            STATE         CONSUMER               ONLINE   ERROR   AGE
    edpm-networker-0  provisioned   openstack-data-plane   true             3d21h

19. サービスが作成されたことを確認します。

    $ oc get openstackdataplaneservice -n openstack
    NAME                    AGE
    bootstrap               8m40s
    ceph-client             8m40s
    ceph-hci-pre            8m40s
    configure-network       8m40s
    configure-os            8m40s
    ...