17.5. ZTP を使用した単一ノード OpenShift クラスターの手動インストール

手順

1. 次のコマンドを実行して、出力フォルダーを作成します。

   $ mkdir -p ./out

2. ztp-site-generate コンテナーイメージから argocd ディレクトリーをエクスポートします。

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.13 extract /home/ztp --tar | tar x -C ./out

   ./out ディレクトリーの out/argocd/example/ フォルダーには、参照 PolicyGenTemplate CR および SiteConfig CR があります。

   出力例

   out
    └── argocd
         └── example
              ├── policygentemplates
              │     ├── common-ranGen.yaml
              │     ├── example-sno-site.yaml
              │     ├── group-du-sno-ranGen.yaml
              │     ├── group-du-sno-validator-ranGen.yaml
              │     ├── kustomization.yaml
              │     └── ns.yaml
              └── siteconfig
                     ├── example-sno.yaml
                     ├── KlusterletAddonConfigOverride.yaml
                     └── kustomization.yaml

3. サイトインストール CR の出力フォルダーを作成します。

   $ mkdir -p ./site-install

4. インストールするクラスタータイプのサンプル SiteConfig CR を変更します。example-sno.yaml を site-1-sno.yaml にコピーし、インストールするサイトとベアメタルホストの詳細に一致するように CR を変更します。次に例を示します。

   単一ノードの 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 は同じである必要があります。

5. 次のコマンドを実行して、変更された SiteConfig CR site-1-sno.yaml を処理し、day-0 インストール CR を生成します。

   $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.13.1 generator install site-1-sno.yaml /output

   出力例

   site-install
   └── site-1-sno
       ├── site-1_agentclusterinstall_example-sno.yaml
       ├── site-1-sno_baremetalhost_example-node1.example.com.yaml
       ├── site-1-sno_clusterdeployment_example-sno.yaml
       ├── site-1-sno_configmap_example-sno.yaml
       ├── site-1-sno_infraenv_example-sno.yaml
       ├── site-1-sno_klusterletaddonconfig_example-sno.yaml
       ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml
       ├── site-1-sno_managedcluster_example-sno.yaml
       ├── site-1-sno_namespace_example-sno.yaml
       └── site-1-sno_nmstateconfig_example-node1.example.com.yaml

6. オプション: -E オプションを使用して参照 SiteConfig CR を処理することにより、特定のクラスタータイプの day-0 MachineConfig インストール CR のみを生成します。たとえば、以下のコマンドを実行します。

   1. MachineConfig CR の出力フォルダーを作成します。

      $ mkdir -p ./site-machineconfig

   2. MachineConfig インストール CR を生成します。

      $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.13.1 generator install -E site-1-sno.yaml /output

      出力例

      site-machineconfig
      └── site-1-sno
          ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
          ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
          └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml

7. 前のステップの参照 PolicyGenTemplate CR を使用して、day-2 の設定 CR を生成してエクスポートします。以下のコマンドを実行します。

   1. day-2 CR の出力フォルダーを作成します。

      $ mkdir -p ./ref

   2. day-2 設定 CR を生成してエクスポートします。

      $ podman run -it --rm -v `pwd`/out/argocd/example/policygentemplates:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.13.1 generator config -N . /output

      このコマンドは、単一ノード OpenShift、3 ノードクラスター、および標準クラスター用のサンプルグループおよびサイト固有の PolicyGenTemplate CR を ./ref フォルダーに生成します。

      出力例

      ref
       └── customResource
            ├── common
            ├── example-multinode-site
            ├── example-sno
            ├── group-du-3node
            ├── group-du-3node-validator
            │    └── Multiple-validatorCRs
            ├── group-du-sno
            ├── group-du-sno-validator
            ├── group-du-standard
            └── group-du-standard-validator
                 └── Multiple-validatorCRs

8. クラスターのインストールに使用する CR のベースとして、生成された CR を使用します。「単一のマネージドクラスターのインストール」で説明されているように、インストール CR をハブクラスターに適用します。設定 CR は、クラスターのインストールが完了した後にクラスターに適用できます。

手順

1. ホスト Baseboard Management Controller (BMC) の認証情報と、OpenShift およびすべてのアドオンクラスター Operator のインストールに必要なプルシークレットを含む YAML シークレットファイルを作成します。

   1. 次の YAML をファイル example-sno-secret.yaml として保存します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: example-sno-bmc-secret
        namespace: example-sno 1
      data: 2
        password: <base64_password>
        username: <base64_username>
      type: Opaque
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: pull-secret
        namespace: example-sno  3
      data:
        .dockerconfigjson: <pull_secret> 4
      type: kubernetes.io/dockerconfigjson

      1

      関連する SiteConfig CR で設定された namespace と一致する必要があります

      2

      password と username の Base64 エンコード値

      3

      関連する SiteConfig CR で設定された namespace と一致する必要があります

      4

      Base64 でエンコードされたプルシークレット

2. example-sno-secret.yaml への相対パスを、クラスターのインストールに使用する kustomization.yaml ファイルに追加します。

手順

1. InfraEnv CR の spec.kernelArguments 仕様を編集して、カーネル引数を設定します。

1. ターゲットホストとの SSH セッションを開始します。

   $ ssh -i /path/to/privatekey core@<host_name>

2. 次のコマンドを使用して、システムのカーネル引数を表示します。

   $ cat /proc/cmdline

手順

1. デプロイする特定のクラスターバージョンごとに ClusterImageSet を作成します (例: clusterImageSet-4.13.yaml)。ClusterImageSet のフォーマットは以下のとおりです。

   apiVersion: hive.openshift.io/v1
   kind: ClusterImageSet
   metadata:
     name: openshift-4.13.0 1
   spec:
      releaseImage: quay.io/openshift-release-dev/ocp-release:4.13.0-x86_64 2

   1

   デプロイする記述バージョン。

   2

   デプロイする releaseImage を指定し、オペレーティングシステムイメージのバージョンを決定します。検出 ISO は、releaseImage で設定されたイメージバージョン、または正確なバージョンが利用できない場合は最新バージョンに基づいています。

2. clusterImageSet CR を適用します。

   $ oc apply -f clusterImageSet-4.13.yaml

3. cluster-namespace.yaml ファイルに Namespace CR を作成します。

   apiVersion: v1
   kind: Namespace
   metadata:
        name: <cluster_name> 1
        labels:
           name: <cluster_name> 2

   1 2

   プロビジョニングするマネージドクラスターの名前。

4. 以下のコマンドを実行して Namespace CR を適用します。

   $ oc apply -f cluster-namespace.yaml

5. ztp-site-generate コンテナーから抽出し、要件を満たすようにカスタマイズした、生成された day-0 CR を適用します。

   $ oc apply -R ./site-install/site-sno-1

手順

1. マネージドクラスターのステータスを確認します。

   $ oc get managedcluster

   True はマネージドクラスターの準備が整っていることを示します。

2. エージェントのステータスを確認します。

   $ oc get agent -n <cluster_name>

3. describe コマンドを使用して、エージェントの条件に関する詳細な説明を指定します。認識できるステータスには、BackendError、InputError、ValidationsFailing、InstallationFailed、および AgentIsConnected が含まれます。これらのステータスは、Agent および AgentClusterInstall カスタムリソースに関連します。

   $ oc describe agent -n <cluster_name>

4. クラスターのプロビジョニングのステータスを確認します。

   $ oc get agentclusterinstall -n <cluster_name>

5. describe コマンドを使用して、クラスターのプロビジョニングステータスの詳細な説明を指定します。

   $ oc describe agentclusterinstall -n <cluster_name>

6. マネージドクラスターのアドオンサービスのステータスを確認します。

   $ oc get managedclusteraddon -n <cluster_name>

7. マネージドクラスターの kubeconfig ファイルの認証情報を取得します。

   $ oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfig

手順

1. マネージドクラスターのステータスを確認します。

   $ oc get managedcluster

   出力例

   NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED   AVAILABLE   AGE
   SNO-cluster     true                                   True     True      2d19h

   AVAILABLE 列のステータスが True の場合、マネージドクラスターはハブによって管理されます。

   AVAILABLE 列のステータスが Unknown の場合、マネージドクラスターはハブによって管理されていません。その他の情報を取得するには、以下の手順を使用します。

2. AgentClusterInstall インストールのステータスを確認します。

   $ oc get clusterdeployment -n <cluster_name>

   出力例

   NAME        PLATFORM            REGION   CLUSTERTYPE   INSTALLED    INFRAID    VERSION  POWERSTATE AGE
   Sno0026    agent-baremetal                               false                          Initialized
   2d14h

   INSTALLED 列のステータスが false の場合、インストールは失敗していました。

3. インストールが失敗した場合は、以下のコマンドを実行して AgentClusterInstall リソースのステータスを確認します。

   $ oc describe agentclusterinstall -n <cluster_name> <cluster_name>

4. エラーを解決し、クラスターをリセットします。

   1. クラスターのマネージドクラスターリソースを削除します。

      $ oc delete managedcluster <cluster_name>

   2. クラスターの namespace を削除します。

      $ oc delete namespace <cluster_name>

      これにより、このクラスター用に作成された namespace スコープのカスタムリソースがすべて削除されます。続行する前に、ManagedCluster CR の削除が完了するのを待つ必要があります。

   3. マネージドクラスターのカスタムリソースを再作成します。