17.3. RHACM および SiteConfig リソースを使用したマネージドクラスターのインストール

• ホストオペレーティングシステム (RHCOS) の空のサーバーへのインストール。
• OpenShift Container Platform のデプロイ
• クラスターポリシーおよびサイトサブスクリプションの作成
• サーバーオペレーティングシステムに必要なネットワーク設定を行う
• プロファイル Operator をデプロイし、パフォーマンスプロファイル、PTP、SR-IOV などの必要なソフトウェア関連の設定を実行します。

前提条件

• OpenShift CLI (oc) がインストールされている。
• cluster-admin 権限を持つユーザーとしてクラスターにログインしている。

前提条件

• OpenShift CLI (oc) がインストールされている。
• cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。
• 必要なインストール CR とポリシー CR を生成するためにハブクラスターを設定している。

• カスタムサイトの設定データを管理する Git リポジトリーを作成しています。リポジトリーはハブクラスターからアクセスできる必要があり、ArgoCD アプリケーションのソースリポジトリーとして設定する必要があります。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。

  注記

  ソースリポジトリーを作成するときは、ztp-site-generate コンテナーから抽出した argocd/deployment/argocd-openshift-gitops-patch.json パッチファイルを使用して ArgoCD アプリケーションにパッチを適用してください。「ArgoCD を使用したハブクラスターの設定」を参照してください。

• マネージドクラスターをプロビジョニングする準備を整えるには、各ベアメタルホストごとに次のものが必要です。

  ネットワーク接続

  ネットワークには DNS が必要です。マネージドクラスターホストは、ハブクラスターから到達可能である必要があります。ハブクラスターとマネージドクラスターホストの間にレイヤー 3 接続が存在することを確認します。

  Baseboard Management Controller (BMC) の詳細

  GitOps ZTP は、BMC のユーザー名とパスワードの詳細を使用して、クラスターのインストール中に BMC に接続します。GitOps ZTP プラグインは、サイトの Git リポジトリーの SiteConfig CR に基づいて、ハブクラスター上の ManagedCluster CR を管理します。ホストごとに個別の BMCSecret CR を手動で作成します。

  手順

  1. ハブクラスターで必要なマネージドクラスターシークレットを作成します。これらのリソースは、クラスター名と一致する名前を持つネームスペースに存在する必要があります。たとえば、out/argocd/example/siteconfig/example-sno.yaml では、クラスター名と namespace が example-sno になっています。

     1. 次のコマンドを実行して、クラスター namespace をエクスポートします。

        $ export CLUSTERNS=example-sno

     2. namespace を作成します。

        $ oc create namespace $CLUSTERNS

  2. マネージドクラスターのプルシークレットと BMC Secret CR を作成します。プルシークレットには、OpenShift Container Platform のインストールに必要なすべての認証情報と、必要なすべての Operator を含める必要があります。詳細は、「マネージドベアメタルホストシークレットの作成」を参照してください。

     注記

     シークレットは、名前で SiteConfig カスタムリソース (CR) から参照されます。namespace は SiteConfig namespace と一致する必要があります。

  3. Git リポジトリーのローカルクローンに、クラスターの SiteConfig CR を作成します。

     1. out/argocd/example/siteconfig/ フォルダーから CR の適切な例を選択します。フォルダーには、単一ノード、3 ノード、標準クラスターのサンプルファイルが含まれます。

        • example-sno.yaml
        • example-3node.yaml
        • example-standard.yaml

     2. サンプルファイルのクラスターおよびホスト詳細を、必要なクラスタータイプに一致するように変更します。以下に例を示します。

        単一ノードの OpenShift クラスター SiteConfig CR の例

        apiVersion: ran.openshift.io/v1
        kind: SiteConfig
        metadata:
          name: "<site_name>"
          namespace: "<site_name>"
        spec:
          baseDomain: "example.com"
          pullSecretRef:
            name: "assisted-deployment-pull-secret" 1
          clusterImageSetNameRef: "openshift-4.13" 2
          sshPublicKey: "ssh-rsa AAAA..." 3
          clusters:
          - clusterName: "<site_name>"
            networkType: "OVNKubernetes"
            clusterLabels: 4
              common: true
              group-du-sno: ""
              sites : "<site_name>"
            clusterNetwork:
              - cidr: 1001:1::/48
                hostPrefix: 64
            machineNetwork:
              - cidr: 1111:2222:3333:4444::/64
            serviceNetwork:
              - 1001:2::/112
            additionalNTPSources:
              - 1111:2222:3333:4444::2
            #crTemplates:
            #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 5
            nodes:
              - hostName: "example-node.example.com" 6
                role: "master"
                bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 7
                bmcCredentialsName:
                  name: "bmh-secret" 8
                bootMACAddress: "AA:BB:CC:DD:EE:11"
                bootMode: "UEFI" 9
                rootDeviceHints: 10
                  wwn: "0x11111000000asd123"
                cpuset: "0-1,52-53"  11
                nodeNetwork: 12
                  interfaces:
                    - name: eno1
                      macAddress: "AA:BB:CC:DD:EE:11"
                  config:
                    interfaces:
                      - name: eno1
                        type: ethernet
                        state: up
                        ipv4:
                          enabled: false
                        ipv6: 13
                          enabled: true
                          address:
                          - ip: 1111:2222:3333:4444::aaaa:1
                            prefix-length: 64
                    dns-resolver:
                      config:
                        search:
                        - example.com
                        server:
                        - 1111:2222:3333:4444::2
                    routes:
                      config:
                      - destination: ::/0
                        next-hop-interface: eno1
                        next-hop-address: 1111:2222:3333:4444::1
                        table-id: 254

        1

        SiteConfig CR と同じ namespace を使用して、assisted-deployment-pull-secret CR を作成します。

        2

        clusterImageSetNameRef は、ハブクラスターで使用可能なイメージセットを定義します。ハブクラスターでサポートされるバージョンの一覧を表示するには、oc get clusterimagesets を実行します。

        3

        クラスターへのアクセスに使用する SSH 公開鍵を設定します。

        4

        クラスターラベルは、定義した PolicyGenTemplate CR の bindingRules フィールドに対応している必要があります。たとえば、policygentemplates/common-ranGen.yaml は common: true が設定されたすべてのクラスターに適用され、policygentemplates/group-du-sno-ranGen.yaml は group-du-sno: "" が設定されたすべてのクラスターに適用されます。

        5

        オプション: KlusterletAddonConfig で指定された CR は、クラスター用に作成されたデフォルトの KlusterletAddonConfig をオーバーライドするために使用されます。

        6

        単一ノードの導入では、単一のホストを定義します。3 ノードのデプロイメントの場合、3 台のホストを定義します。標準のデプロイメントでは、role: master と、role: worker で定義される 2 つ以上のホストを持つ 3 つのホストを定義します。

        7

        ホストへのアクセスに使用する BMC アドレス。すべてのクラスタータイプに適用されます。GitOps ZTP は、Redfish または IPMI プロトコルを使用して iPXE および仮想メディアの起動をサポートします。iPXE ブートを使用するには、RHACM 2.8 以降を使用する必要があります。BMC アドレッシングの詳細については、その他のリソース セクションを参照してください。

        8

        ホスト BMC クレデンシャルを使用して個別に作成する bmh-secret CR の名前。bmh-secret CR を作成するときは、ホストをプロビジョニングする SiteConfig CR と同じ namespace を使用します。

        9

        ホストのブートモードを設定します。デフォルト値は UEFI です。UEFISecureBoot を使用して、ホストでセキュアブートを有効にします。

        10

        導入するデバイスを指定します。再起動後も安定した識別子が推奨されます (例 : wwn: <disk_wwn> または deviceName:/dev/disk/by-path/<device_path>)。安定した識別子の詳細なリストは、About root device hints セクションを参照してください。

        11

        cpuset は、ワークロードの分割のためにクラスターの PerformanceProfile CR .spec.cpu.reserved フィールドに設定された値と同じにする必要があります。

        12

        ノードのネットワーク設定を指定します。

        13

        ホストの IPv6 アドレスを設定します。静的 IP アドレスを持つ単一ノードの OpenShift クラスターの場合、ノード固有の API と Ingress IP は同じである必要があります。

     3. out/argocd/extra-manifest で extra-manifest MachineConfig CR のデフォルトセットを検査できます。これは、インストール時にクラスターに自動的に適用されます。

     4. オプション: プロビジョニングされたクラスターに追加のインストール時マニフェストをプロビジョニングするには、Git リポジトリーに sno-extra-manifest/ などのディレクトリーを作成し、このディレクトリーにカスタムマニフェストの CR を追加します。SiteConfig.yaml が extraManifestPath フィールドでこのディレクトリーを参照する場合、この参照ディレクトリーの CR はすべて、デフォルトの追加マニフェスト セットに追加されます。

        crun OCI コンテナーランタイムの有効化

        クラスターのパフォーマンスを最適化するには、シングルノード OpenShift、追加のワーカーノードを備えたシングルノード OpenShift、3 ノード OpenShift、および標準クラスターのマスターノードとワーカーノードで crun を有効にします。

        クラスターの再起動を回避するには、追加の Day-0 インストール時マニフェストとして ContainerRuntimeConfig CR で crun を有効にします。

        enable-crun-master.yaml および enable-crun-worker.yaml CR ファイルは、ztp-site-generate コンテナーから抽出できる out/source-crs/optional-extra-manifest/ フォルダーにあります。詳細は、「GitOps ZTP パイプラインでの追加インストールマニフェストのカスタマイズ」を参照してください。

  4. out/argocd/example/siteconfig/kustomization.yaml に示す例のように、generators セクションの kustomization.yaml ファイルに SiteConfig CR を追加してください。

  5. SiteConfig CR と関連する kustomization.yaml の変更を Git リポジトリーにコミットし、変更をプッシュします。

     ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。

前提条件

• OpenShift CLI (oc) がインストールされている。
• cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。

前提条件

• OpenShift CLI (oc) がインストールされている。
• cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。

前提条件

• OpenShift CLI (oc) がインストールされている。
• cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。

前提条件

• OpenShift CLI (oc) がインストールされている。
• cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。

前提条件

• OpenShift CLI (oc) がインストールされている。
• cluster-admin 権限を持つユーザーとしてクラスターにログインしていることを確認します。