エッジコンピューティング

手順

1. ミラーホストにログインします。

2. mirror.openshift.com から RHCOS ISO イメージおよび RootFS イメージを取得します。以下は例になります。

   1. 必要なイメージ名と OpenShift Container Platform のバージョンを環境変数としてエクスポートします。

      $ export ISO_IMAGE_NAME=<iso_image_name> 1

      $ export ROOTFS_IMAGE_NAME=<rootfs_image_name> 1

      $ export OCP_VERSION=<ocp_version> 1

      1

      ISO イメージ名 (例: rhcos-4.16.1-x86_64-live.x86_64.iso)

      1

      RootFS イメージ名 (例: rhcos-4.16.1-x86_64-live-rootfs.x86_64.img)

      1

      OpenShift Container Platform バージョン (例: 4.16.1)

   2. 必要なイメージをダウンロードします。

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.16/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.16/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}

手順

1. Provisioning リソースを有効にして、すべての namespace を監視し、非接続環境のミラーを設定します。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。

2. 以下のコマンドを実行して、AgentServiceConfig CR を更新します。

   $ oc edit AgentServiceConfig

3. CR の items.spec.osImages フィールドに次のエントリーを追加します。

   - cpuArchitecture: x86_64
       openshiftVersion: "4.16"
       rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
       url: https://<host>/<path>/rhcos-live.x86_64.iso

   ここでは、以下のようになります。

   <host>

   ターゲットミラーレジストリー HTTP サーバーの完全修飾ドメイン名 (FQDN) です。

   <path>

   ターゲットミラーレジストリー上のイメージへのパスです。

   エディターを保存して終了し、変更を適用します。

手順

1. ミラーレジストリー設定を含む ConfigMap を作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: assisted-installer-mirror-config
     namespace: multicluster-engine 1
     labels:
       app: assisted-service
   data:
     ca-bundle.crt: | 2
       -----BEGIN CERTIFICATE-----
       <certificate_contents>
       -----END CERTIFICATE-----
   
     registries.conf: | 3
       unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
   
       [[registry]]
          prefix = ""
          location = "quay.io/example-repository" 4
          mirror-by-digest-only = true
   
          [[registry.mirror]]
          location = "mirror1.registry.corp.com:5000/example-repository" 5

   1

   ConfigMap namespace は multicluster-engine に設定する必要があります。

   2

   ミラーレジストリーの作成時に使用されるミラーレジストリーの証明書。

   3

   ミラーレジストリーの設定ファイル。ミラーレジストリー設定は、検出イメージの /etc/containers/registries.conf ファイルにミラー情報を追加します。ミラー情報は、インストールプログラムに渡される際、install-config.yaml ファイルの imageContentSources セクションに保存されます。ハブクラスターで実行される Assisted Service Pod は、設定されたミラーレジストリーからコンテナーイメージをフェッチします。

   4

   ミラーレジストリーの URL。ミラーレジストリーを設定する場合は、oc adm release mirror コマンドを実行して、imageContentSources セクションの URL を使用する必要があります。詳細は、OpenShift Container Platform イメージリポジトリーのミラーリング セクションを参照してください。

   5

   registries.conf ファイルで定義されるレジストリーは、レジストリーではなくリポジトリーによってスコープが指定される必要があります。この例では、quay.io/example-repository リポジトリーと mirror1.registry.corp.com:5000/example-repository リポジトリーの両方のスコープが example-repository リポジトリーにより指定されます。

   これにより、以下のように AgentServiceConfig カスタムリソースの mirrorRegistryRef が更新されます。

   出力例

   apiVersion: agent-install.openshift.io/v1beta1
   kind: AgentServiceConfig
   metadata:
     name: agent
     namespace: multicluster-engine 1
   spec:
     databaseStorage:
       volumeName: <db_pv_name>
       accessModes:
       - ReadWriteOnce
       resources:
         requests:
           storage: <db_storage_size>
     filesystemStorage:
       volumeName: <fs_pv_name>
       accessModes:
       - ReadWriteOnce
       resources:
         requests:
           storage: <fs_storage_size>
     mirrorRegistryRef:
       name: assisted-installer-mirror-config 2
     osImages:
       - openshiftVersion: <ocp_version>
         url: <iso_url> 3

   1

   ConfigMap namespace と一致するように、AgentServiceConfig namespace を multicluster-engine に設定します。

   2

   関連する ConfigMap CR で指定された定義と一致するように、mirrorRegistryRef.name を設定します。

   3

   httpd サーバーでホストされる ISO の URL を設定します。

手順

1. 次のコマンドを実行して、AgentServiceConfig カスタムリソース (CR) を更新します。

   $ oc edit AgentServiceConfig agent

2. CR に unauthenticatedRegistries フィールドを追加します。

   apiVersion: agent-install.openshift.io/v1beta1
   kind: AgentServiceConfig
   metadata:
     name: agent
   spec:
     unauthenticatedRegistries:
     - example.registry.com
     - example.registry2.com
     ...

   非認証レジストリーは、AgentServiceConfig リソースの spec.unauthenticatedRegistries の下に一覧表示されます。このリストにあるレジストリーのエントリーは、スポーククラスターのインストールに使用されるプルシークレットに含める必要はありません。assisted-service は、インストールに使用されるすべてのイメージレジストリーの認証情報がプルシークレットに含まれていることを確認して、プルシークレットを検証します。

1. ハブクラスターへのデバッグシェルプロンプトを開きます。

   $ oc debug node/<node_name>

2. 次のコマンドを実行して、非認証レジストリーへのアクセスをテストします。

   sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>

   ここでは、以下のようになります。

   <unauthenticated_registry>

   unauthenticated-image-registry.openshift-image-registry.svc:5000 などの新しいレジストリーです。

   出力例

   Login Succeeded!

手順

1. ArgoCD パイプライン設定を準備します。

   1. example ディレクトリーと同様にディレクトリー構造で Git リポジトリーを作成します。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。

   2. ArgoCD UI を使用して、リポジトリーへのアクセスを設定します。Settings で以下を設定します。

      • リポジトリー: 接続情報を追加します。URL は .git などで終わっている必要があります。https://repo.example.com/repo.git と認証情報を指定します。
      • Certificates - 必要に応じて、リポジトリーのパブリック証明書を追加します。

   3. 2 つの ArgoCD アプリケーション、out/argocd/deployment/clusters-app.yaml と out/argocd/deployment/policies-app.yaml を、Git リポジトリーに基づいて修正します。

      • Git リポジトリーを参照するように URL を更新します。URL は .git で終わります (例: https://repo.example.com/repo.git)。
      • targetRevision は、監視する Git リポジトリーブランチを示します。
      • path は、それぞれ SiteConfig および PolicyGenerator または PolicyGentemplate CR へのパスを指定します。

2. GitOps ZTP プラグインをインストールするには、ハブクラスター内の ArgoCD インスタンスに、関連するマルチクラスターエンジン (MCE) サブスクリプションイメージをパッチ適用します。以前に out/argocd/deployment/ ディレクトリーに展開したパッチファイルを環境に合わせてカスタマイズします。

   1. RHACM バージョンに一致する multicluster-operators-subscription イメージを選択します。

      表2.5 multicluster-operators-subscription イメージバージョン

      OpenShift Container Platform バージョン	RHACM バージョン	MCE バージョン	MCE RHEL バージョン	MCE イメージ
      4.14、4.15、4.16	2.8、2.9	2.8、2.9	RHEL 8	registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.8 registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.9
      4.14、4.15、4.16	2.10	2.10	RHEL 9	registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10

      重要

      multicluster-operators-subscription イメージのバージョンは、RHACM バージョンと一致する必要があります。MCE 2.10 リリース以降、RHEL 9 は multicluster-operators-subscription イメージのベースイメージです。

   2. out/argocd/deployment/argocd-openshift-gitops-patch.json ファイルに次の設定を追加します。

      {
        "args": [
          "-c",
          "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 1
        ],
        "command": [
          "/bin/bash"
        ],
        "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 2 3
        "name": "policy-generator-install",
        "imagePullPolicy": "Always",
        "volumeMounts": [
          {
            "mountPath": "/.config",
            "name": "kustomize"
          }
        ]
      }

      1

      オプション: RHEL 9 イメージの場合、ArgoCD バージョンの /policy-generator/PolicyGenerator-not-fips-compliant フォルダーに必要なユニバーサル実行可能ファイルをコピーします。

      2

      multicluster-operators-subscription イメージを RHACM バージョンに一致させます。

      3

      非接続環境では、multicluster-operators-subscription イメージの URL を、ご使用の環境の非接続レジストリーに相当するものに置き換えます。

   3. ArgoCD インスタンスにパッチを適用します。以下のコマンドを実行します。

      $ oc patch argocd openshift-gitops \
      -n openshift-gitops --type=merge \
      --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json

3. RHACM 2.7 以降では、マルチクラスターエンジンはデフォルトで cluster-proxy-addon 機能を有効にします。次のパッチを適用して、cluster-proxy-addon 機能を無効にし、このアドオンに関連するハブクラスターとマネージド Pod を削除します。以下のコマンドを実行します。

   $ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json

4. 次のコマンドを実行して、パイプライン設定をハブクラスターに適用します。

   $ oc apply -k out/argocd/deployment

手順

1. SiteConfig と PolicyGenerator または PolicyGentemplate CR 用に個別のパスを持つディレクトリー構造を作成します。

   注記

   SiteConfig と PolicyGenerator または PolicyGentemplate CR を個別のディレクトリーに保存します。SiteConfig ディレクトリーと、PolicyGenerator または PolicyGentemplate ディレクトリーの両方に、そのディレクトリー内のファイルを明示的に含める kustomization.yaml ファイルが含まれている必要があります。

2. 以下のコマンドを使用して ztp-site-generate コンテナーイメージから argocd ディレクトリーをエクスポートします。

   $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.16

   $ mkdir -p ./out

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

3. out ディレクトリーに以下のサブディレクトリーが含まれていることを確認します。

   • out/extra-manifest には、SiteConfig が追加の manifest configMap の生成に使用するソース CR ファイルが含まれます。
   • out/source-crs には、PolicyGenerator が Red Hat Advanced Cluster Management (RHACM) ポリシーを生成するために使用するソース CR ファイルが含まれています。
   • out/argocd/deployment には、この手順の次のステップで使用するハブクラスターに適用するパッチおよび YAML ファイルが含まれます。
   • out/argocd/example には、推奨される設定を表す SiteConfig ファイルと、PolicyGenerator または PolicyGentemplate ファイルのサンプルが含まれています。
4. out/source-crs フォルダーとその内容を PolicyGenerator または PolicyGentemplate ディレクトリーにコピーします。

5. out/extra-manifests ディレクトリーには、RAN DU クラスターの参照マニフェストが含まれています。out/extra-manifests ディレクトリーを SiteConfig フォルダーにコピーします。このディレクトリーには、ztp-site-generate コンテナーからの CR のみを含める必要があります。ユーザー提供の CR をここに追加しないでください。ユーザー提供の CR を使用する場合は、そのコンテンツ用に別のディレクトリーを作成する必要があります。以下に例を示します。

   example/
     ├── acmpolicygenerator
     │   ├── kustomization.yaml
     │   └── source-crs/
     ├── policygentemplates 1
     │   ├── kustomization.yaml
     │   └── source-crs/
     └── siteconfig
           ├── extra-manifests
           └── kustomization.yaml

   1

   PolicyGenTemplate CR を使用してポリシーを管理およびデプロイし、クラスターを管理することは、OpenShift Container Platform の今後のリリースでは非推奨になります。Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator CR を使用すると、同等の機能および改善された機能が利用できます。

6. ディレクトリー構造と kustomization.yaml ファイルをコミットし、Git リポジトリーにプッシュします。Git への最初のプッシュには、kustomization.yaml ファイルが含まれている必要があります。

手順

1. SiteConfig CR と PolicyGenerator CR の個別のパスを持つディレクトリー構造を作成します。

2. PolicyGenerator ディレクトリー内に、使用可能にする OpenShift Container Platform バージョンごとにディレクトリーを作成します。バージョンごとに、次のリソースを作成します。

   • そのディレクトリー内のファイルを明示的に含む kustomization.yaml ファイル

   • source-crs ディレクトリーには、ztp-site-generate コンテナーからの参照 CR 設定ファイルが含まれます。

     ユーザー提供の CR を使用する場合は、CR 用に別のディレクトリーを作成する必要があります。

3. /siteconfig ディレクトリーに、使用可能にする OpenShift Container Platform バージョンごとにサブディレクトリーを作成します。バージョンごとに、コンテナーからコピーされる参照 CR 用のディレクトリーを少なくとも 1 つ作成します。ディレクトリーの名前や参照ディレクトリーの数に制限はありません。カスタムマニフェストを使用する場合は、個別のディレクトリーを作成する必要があります。

   次の例では、OpenShift Container Platform のさまざまなバージョンのユーザー提供のマニフェストと CR を使用した構造を説明します。

   ├── acmpolicygenerator
   │   ├── kustomization.yaml 1
   │   ├── version_4.13 2
   │   │   ├── common-ranGen.yaml
   │   │   ├── group-du-sno-ranGen.yaml
   │   │   ├── group-du-sno-validator-ranGen.yaml
   │   │   ├── helix56-v413.yaml
   │   │   ├── kustomization.yaml 3
   │   │   ├── ns.yaml
   │   │   └── source-crs/ 4
   │   │      └── reference-crs/ 5
   │   │      └── custom-crs/ 6
   │   └── version_4.14 7
   │       ├── common-ranGen.yaml
   │       ├── group-du-sno-ranGen.yaml
   │       ├── group-du-sno-validator-ranGen.yaml
   │       ├── helix56-v414.yaml
   │       ├── kustomization.yaml 8
   │       ├── ns.yaml
   │       └── source-crs/ 9
   │         └── reference-crs/ 10
   │         └── custom-crs/ 11
   └── siteconfig
       ├── kustomization.yaml
       ├── version_4.13
       │   ├── helix56-v413.yaml
       │   ├── kustomization.yaml
       │   ├── extra-manifest/ 12
       │   └── custom-manifest/ 13
       └── version_4.14
           ├── helix57-v414.yaml
           ├── kustomization.yaml
           ├── extra-manifest/ 14
           └── custom-manifest/ 15

   1

   最上位の kustomization YAML ファイルを作成します。

   2 7

   カスタム /acmpolicygenerator ディレクトリー内にバージョン固有のディレクトリーを作成します。

   3 8

   バージョンごとに kustomization.yaml ファイルを作成します。

   4 9

   ztp-site-generate コンテナーからの参照 CR を含めるために、バージョンごとに source-crs ディレクトリーを作成します。

   5 10

   ZTP コンテナーから展開されるポリシー CR の reference-crs ディレクトリーを作成します。

   6 11

   オプション: ユーザー提供の CR 用に custom-crs ディレクトリーを作成します。

   12 14

   カスタム /siteconfig ディレクトリー内にディレクトリーを作成し、ztp-site-generate コンテナーからの追加のマニフェストを含めます。

   13 15

   ユーザーによって提供されるマニフェストを保持するフォルダーを作成します。

   注記

   前の例では、カスタム /siteconfig ディレクトリー内の各バージョンサブディレクトリーにはさらに 2 つのサブディレクトリーが含まれており、1 つはコンテナーからコピーされた参照マニフェストを含み、もう 1 つは提供するカスタムマニフェスト用です。これらのディレクトリーに割り当てられた名前は一例です。ユーザー提供の CR を使用する場合は、SiteConfig CR の extraManifests.searchPaths の下にリストされている最後のディレクトリーが、ユーザー提供の CR を含むディレクトリーである必要があります。

4. SiteConfig CR を編集して、作成したディレクトリーの検索パスを含めます。extraManifests.searchPaths の下にリストされる最初のディレクトリーは、参照マニフェストを含むディレクトリーである必要があります。ディレクトリーがリストされている順序を考慮してください。ディレクトリーに同じ名前のファイルが含まれている場合は、最後のディレクトリーにあるファイルが優先されます。

   SiteConfig CR の例

   extraManifests:
       searchPaths:
       - extra-manifest/ 1
       - custom-manifest/ 2

   1

   参照マニフェストを含むディレクトリーは、extraManifests.searchPaths の下に最初にリストされる必要があります。

   2

   ユーザー提供の CR を使用している場合は、SiteConfig CR の extraManifests.searchPaths の下にリストされている最後のディレクトリーが、ユーザー提供の CR を含むディレクトリーである必要があります。

5. トップレベルの kustomization.yaml ファイルを編集して、アクティブな OpenShift Container Platform バージョンを制御します。以下は、最上位レベルの kustomization.yaml ファイルの例です。

   resources:
   - version_4.13 1
   #- version_4.14 2

   1

   バージョン 4.13 をアクティブ化します。

   2

   コメントを使用してバージョンを非アクティブ化します。

1. 既存のすべてのクラスターに ztp-done ラベルを付けます。
2. ArgoCD アプリケーションを停止します。
3. 新しい GitOps ZTP ツールをインストールします。
4. Git リポジトリーで必要なコンテンツおよびオプションの変更を更新します。
5. アプリケーション設定を更新して再起動します。

手順

1. GitOps ZTP で使用するために Red Hat OpenShift GitOps を設定するために使用されるカスタムリソース (CR) を持つ GitOps ZTP コンテナーの最新バージョンを取得します。

2. 次のコマンドを使用して、argocd/deployment ディレクトリーを抽出します。

   $ mkdir -p ./update

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

   /update ディレクトリーには、次のサブディレクトリーが含まれています。

   • update/extra-manifest: SiteConfig CR が追加のマニフェスト configMap を生成するために使用するソース CR ファイルが含まれています。
   • update/source-crs: PolicyGenerator または PolicyGentemplate CR が Red Hat Advanced Cluster Management (RHACM) ポリシーを生成するために使用するソース CR ファイルが含まれます。
   • update/argocd/deployment には、この手順の次のステップで使用するハブクラスターに適用するパッチおよび YAML ファイルが含まれます。
   • update/argocd/example: 推奨される設定を表す SiteConfig と、PolicyGenerator または PolicyGentemplate ファイルの例が含まれています。

3. clusters-app.yaml ファイルおよび policies-app.yaml ファイルを更新して、Git リポジトリーのアプリケーションおよび URL、ブランチ、およびパスを反映します。

   アップグレードにポリシーの廃止につながる変更が含まれている場合は、アップグレードを実行する前に、廃止されたポリシーを削除する必要があります。

4. /update フォルダー内の設定およびデプロイソース CR と、フリートサイト CR を管理する Git リポジトリーとの間の変更を比較します。必要な変更をサイトリポジトリーに適用してプッシュします。

   重要

   GitOps ZTP を最新バージョンに更新するときは、update/argocd/deployment ディレクトリーからサイトリポジトリーに変更を適用する必要があります。古いバージョンの argocd/deployment/ ファイルは使用しないでください。

手順

1. local-cluster!=true など、GitOps Zero Touch Provisioning (ZTP) でデプロイされたマネージドクラスターを一覧表示するラベルセレクターを見つけます。

   $ oc get managedcluster -l 'local-cluster!=true'

2. 結果のリストに、GitOps ZTP でデプロイされたすべてのマネージドクラスターが含まれていることを確認してから、そのセレクターを使用して ztp-done ラベルを追加します。

   $ oc label managedcluster -l 'local-cluster!=true' ztp-done=

手順

1. clusters アプリケーションで非カスケード削除を実行して、生成されたすべてのリソースをそのまま残します。

   $ oc delete -f update/argocd/deployment/clusters-app.yaml

2. policies アプリケーションでカスケード削除を実行して、以前のすべてのポリシーを削除します。

   $ oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge

   $ oc delete -f update/argocd/deployment/policies-app.yaml

手順

1. GitOps ZTP プラグインをインストールするには、ハブクラスター内の ArgoCD インスタンスに、関連するマルチクラスターエンジン (MCE) サブスクリプションイメージをパッチ適用します。以前に out/argocd/deployment/ ディレクトリーに展開したパッチファイルを環境に合わせてカスタマイズします。

   1. RHACM バージョンに一致する multicluster-operators-subscription イメージを選択します。

      表3.1 multicluster-operators-subscription イメージバージョン

      OpenShift Container Platform バージョン	RHACM バージョン	MCE バージョン	MCE RHEL バージョン	MCE イメージ
      4.14、4.15、4.16	2.8、2.9	2.8、2.9	RHEL 8	registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.8 registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.9
      4.14、4.15、4.16	2.10	2.10	RHEL 9	registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10

      重要

      multicluster-operators-subscription イメージのバージョンは、RHACM バージョンと一致する必要があります。MCE 2.10 リリース以降、RHEL 9 は multicluster-operators-subscription イメージのベースイメージです。

   2. out/argocd/deployment/argocd-openshift-gitops-patch.json ファイルに次の設定を追加します。

      {
        "args": [
          "-c",
          "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 1
        ],
        "command": [
          "/bin/bash"
        ],
        "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 2 3
        "name": "policy-generator-install",
        "imagePullPolicy": "Always",
        "volumeMounts": [
          {
            "mountPath": "/.config",
            "name": "kustomize"
          }
        ]
      }

      1

      オプション: RHEL 9 イメージの場合、ArgoCD バージョンの /policy-generator/PolicyGenerator-not-fips-compliant フォルダーに必要なユニバーサル実行可能ファイルをコピーします。

      2

      multicluster-operators-subscription イメージを RHACM バージョンに一致させます。

      3

      非接続環境では、multicluster-operators-subscription イメージの URL を、ご使用の環境の非接続レジストリーに相当するものに置き換えます。

   3. ArgoCD インスタンスにパッチを適用します。以下のコマンドを実行します。

      $ oc patch argocd openshift-gitops \
      -n openshift-gitops --type=merge \
      --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json

2. RHACM 2.7 以降では、マルチクラスターエンジンはデフォルトで cluster-proxy-addon 機能を有効にします。次のパッチを適用して、cluster-proxy-addon 機能を無効にし、このアドオンに関連するハブクラスターとマネージド Pod を削除します。以下のコマンドを実行します。

   $ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json

3. 次のコマンドを実行して、パイプライン設定をハブクラスターに適用します。

   $ oc apply -k out/argocd/deployment

1. Discovery イメージの ISO ファイルが生成され、ターゲットホストで起動します。
2. ISO ファイルがターゲットホストで正常に起動すると、ホストのハードウェア情報が RHACM にレポートされます。
3. すべてのホストの検出後に、OpenShift Container Platform がインストールされます。
4. OpenShift Container Platform のインストールが完了すると、ハブは klusterlet サービスをターゲットクラスターにインストールします。
5. 要求されたアドオンサービスがターゲットクラスターにインストールされている。

手順

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. 次の YAML を InfraEnv-example.yaml ファイルに保存します。

      注記

      この例の InfraEnv CR は、SiteConfig CR の値に基づいて入力される {{ .Cluster.ClusterName }} などのテンプレート構文を使用します。SiteConfig CR は、デプロイメント中にこれらのテンプレートの値を自動的に設定します。テンプレートを手動で編集しないでください。

      apiVersion: agent-install.openshift.io/v1beta1
      kind: InfraEnv
      metadata:
        annotations:
          argocd.argoproj.io/sync-wave: "1"
        name: "{{ .Cluster.ClusterName }}"
        namespace: "{{ .Cluster.ClusterName }}"
      spec:
        clusterRef:
          name: "{{ .Cluster.ClusterName }}"
          namespace: "{{ .Cluster.ClusterName }}"
        kernelArguments:
          - operation: append 1
            value: audit=0 2
          - operation: append
            value: trace=1
        sshAuthorizedKey: "{{ .Site.SshPublicKey }}"
        proxy: "{{ .Cluster.ProxySettings }}"
        pullSecretRef:
          name: "{{ .Site.PullSecretRef.Name }}"
        ignitionConfigOverride: "{{ .Cluster.IgnitionConfigOverride }}"
        nmStateConfigLabelSelector:
          matchLabels:
            nmstate-label: "{{ .Cluster.ClusterName }}"
        additionalNTPSources: "{{ .Cluster.AdditionalNTPSources }}"

      1

      カーネル引数を追加するには、追加操作を指定します。

      2

      設定するカーネル引数を指定します。この例では、audit カーネル引数と trace カーネル引数を設定します。

2. InfraEnv-example.yaml CR を、Git リポジトリー内の SiteConfig CR と同じ場所にコミットし、変更をプッシュします。次の例は、サンプルの Git リポジトリー構造を示しています。

   ~/example-ztp/install
             └── site-install
                  ├── siteconfig-example.yaml
                  ├── InfraEnv-example.yaml
                  ...

3. SiteConfig CR の spec.clusters.crTemplates 仕様を編集して、Git リポジトリーの InfraEnv-example.yaml CR を参照します。

   clusters:
     crTemplates:
       InfraEnv: "InfraEnv-example.yaml"

   SiteConfig CR をコミットおよびプッシュしてクラスターをデプロイする準備ができたら、ビルドパイプラインは Git リポジトリー内のカスタム InfraEnv-example CR を使用して、カスタムカーネル引数を含むインフラストラクチャー環境を設定します。

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

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

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

   $ cat /proc/cmdline

1. Assisted Service Operator は OpenShift Container Platform をクラスターにインストールします。次のコマンドを実行して、RHACM ダッシュボードまたはコマンドラインからクラスターのインストールの進行状況を監視できます。

   1. クラスター名をエクスポートします。

      $ export CLUSTER=<clusterName>

   2. マネージドクラスターの AgentClusterInstall CR をクエリーします。

      $ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq

   3. クラスターのインストールイベントを取得します。

      $ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}')  | jq '.[-2,-1]'

手順

1. インストール CR が作成されたことは、以下のコマンドで確認することができます。

   $ oc get AgentClusterInstall -n <cluster_name>

   オブジェクトが返されない場合は、以下の手順を使用して ArgoCD パイプラインフローを SiteConfig ファイルからインストール CR にトラブルシューティングします。

2. ハブクラスターで SiteConfig CR を使用して ManagedCluster CR が生成されたことを確認します。

   $ oc get managedcluster

3. ManagedCluster が見つからない場合は、clusters アプリケーションが Git リポジトリーからハブクラスターへのファイルの同期に失敗したかどうかを確認します。

   $ oc describe -n openshift-gitops application clusters

   1. Status.Conditions フィールドを確認して、マネージドクラスターのエラーログを表示します。たとえば、SiteConfig CR で extraManifestPath: に無効な値を設定すると、次のエラーが発生します。

      Status:
        Conditions:
          Last Transition Time:  2021-11-26T17:21:39Z
          Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/siteconfigs/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not create extra-manifest ranSite1.extra-manifest3 stat extra-manifest3: no such file or directory 2021/11/26 17:21:40 Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-913473579: stat extra-manifest3: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-913473579; exit status 1: exit status 1
          Type:  ComparisonError

   2. Status.Sync フィールドを確認します。ログエラーがある場合、Status.Sync フィールドは Unknown エラーを示している可能性があります。

      Status:
        Sync:
          Compared To:
            Destination:
              Namespace:  clusters-sub
              Server:     https://kubernetes.default.svc
            Source:
              Path:             sites-config
              Repo URL:         https://git.com/ran-sites/siteconfigs/.git
              Target Revision:  master
          Status:               Unknown

手順

1. 次のコマンドを実行して、Provisioning リソースの TLS を無効にします。

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

2. シングルノード OpenShift クラスターをデプロイする手順を続行します。

手順

1. kustomization.yaml ファイルから、関連する SiteConfig と、PolicyGenerator または PolicyGentemplate ファイルを削除して、サイトと関連する CR を削除します。

2. 次の syncOptions フィールドを SiteConfig アプリケーションに追加します。

   kind: Application
   spec:
     syncPolicy:
       syncOptions:
       - PrunePropagationPolicy=background

   GitOps ZTP パイプラインを再度実行すると、生成された CR は削除されます。

3. オプション: サイトを完全に削除する場合は、SiteConfig と、サイト固有の PolicyGenerator または PolicyGentemplate ファイルも Git リポジトリーから削除する必要があります。
4. オプション: サイトを再デプロイする場合など、一時的にサイトを削除する場合は、SiteConfig とサイト固有の PolicyGenerator または PolicyGentemplate CR を Git リポジトリーに残しておくことができます。

手順

1. 影響を受ける PolicyGenerator または PolicyGentemplate ファイルを Git リポジトリーから削除し、コミットしてリモートリポジトリーにプッシュします。
2. アプリケーションを介して変更が同期され、影響を受けるポリシーがハブクラスターから削除されるのを待ちます。

3. 更新された PolicyGenerator または PolicyGentemplate ファイルを Git リポジトリーに再び追加し、コミットしてリモートリポジトリーにプッシュします。

   注記

   Git リポジトリーから GitOps Zero Touch Provisioning (ZTP) ポリシーを削除し、その結果としてハブクラスターからもポリシーが削除されても、マネージドクラスターの設定には影響しません。ポリシーとそのポリシーによって管理される CR は、マネージドクラスターに残ります。

4. オプション: 別の方法として、PolicyGenerator または PolicyGentemplate CR に変更を加えたことでポリシーが古くなった場合は、これらのポリシーをハブクラスターから手動で削除できます。ポリシーの削除は、RHACM コンソールから Governance タブを使用するか、以下のコマンドを使用して行うことができます。

   $ oc delete policy -n <namespace> <policy_name>

手順

1. ハブクラスターの Red Hat Advanced Cluster Management (RHACM) からすべてのクラスターを切り離します。

2. 次のコマンドを使用して、deployment ディレクトリーの kustomization.yaml ファイルを削除します。

   $ oc delete -k out/argocd/deployment

3. 変更をコミットして、サイトリポジトリーにプッシュします。

手順

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

   $ mkdir -p ./out

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

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

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

   出力例

   out
    └── argocd
         └── example
              ├── acmpolicygenerator
              │     ├── {policy-prefix}common-ranGen.yaml
              │     ├── {policy-prefix}example-sno-site.yaml
              │     ├── {policy-prefix}group-du-sno-ranGen.yaml
              │     ├── {policy-prefix}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 を変更します。次に例を示します。

   # example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
   ---
   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "example-sno"
     namespace: "example-sno"
   spec:
     baseDomain: "example.com"
     pullSecretRef:
       name: "assisted-deployment-pull-secret"
     clusterImageSetNameRef: "openshift-4.16"
     sshPublicKey: "ssh-rsa AAAA..."
     clusters:
       - clusterName: "example-sno"
         networkType: "OVNKubernetes"
         # installConfigOverrides is a generic way of passing install-config
         # parameters through the siteConfig.  The 'capabilities' field configures
         # the composable openshift feature.  In this 'capabilities' setting, we
         # remove all the optional set of components.
         # Notes:
         # - OperatorLifecycleManager is needed for 4.15 and later
         # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
         # - Ingress is needed for 4.16 and later
         installConfigOverrides: |
           {
             "capabilities": {
               "baselineCapabilitySet": "None",
               "additionalEnabledCapabilities": [
                 "NodeTuning",
                 "OperatorLifecycleManager",
                 "Ingress"
               ]
             }
           }
         # It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+.
         # The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest.
         # extraManifestPath: sno-extra-manifest
         clusterLabels:
           # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples
           du-profile: "latest"
           # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates:
           # ../policygentemplates/common-ranGen.yaml will apply to all clusters with 'common: true'
           common: true
           # ../policygentemplates/group-du-sno-ranGen.yaml will apply to all clusters with 'group-du-sno: ""'
           group-du-sno: ""
           # ../policygentemplates/example-sno-site.yaml will apply to all clusters with 'sites: "example-sno"'
           # Normally this should match or contain the cluster name so it only applies to a single cluster
           sites: "example-sno"
         clusterNetwork:
           - cidr: 1001:1::/48
             hostPrefix: 64
         machineNetwork:
           - cidr: 1111:2222:3333:4444::/64
         serviceNetwork:
           - 1001:2::/112
         additionalNTPSources:
           - 1111:2222:3333:4444::2
         # Initiates the cluster for workload partitioning. Setting specific reserved/isolated CPUSets is done via PolicyTemplate
         # please see Workload Partitioning Feature for a complete guide.
         cpuPartitioningMode: AllNodes
         # Optionally; This can be used to override the KlusterletAddonConfig that is created for this cluster:
         #crTemplates:
         #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml"
         nodes:
           - hostName: "example-node1.example.com"
             role: "master"
             # Optionally; This can be used to configure desired BIOS setting on a host:
             #biosConfigRef:
             #  filePath: "example-hw.profile"
             bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
             bmcCredentialsName:
               name: "example-node1-bmh-secret"
             bootMACAddress: "AA:BB:CC:DD:EE:11"
             # Use UEFISecureBoot to enable secure boot
             bootMode: "UEFI"
             rootDeviceHints:
               deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0"
             # disk partition at `/var/lib/containers` with ignitionConfigOverride. Some values must be updated. See DiskPartitionContainer.md for more details
             ignitionConfigOverride: |
               {
                 "ignition": {
                   "version": "3.2.0"
                 },
                 "storage": {
                   "disks": [
                     {
                       "device": "/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62",
                       "partitions": [
                         {
                           "label": "var-lib-containers",
                           "sizeMiB": 0,
                           "startMiB": 250000
                         }
                       ],
                       "wipeTable": false
                     }
                   ],
                   "filesystems": [
                     {
                       "device": "/dev/disk/by-partlabel/var-lib-containers",
                       "format": "xfs",
                       "mountOptions": [
                         "defaults",
                         "prjquota"
                       ],
                       "path": "/var/lib/containers",
                       "wipeFilesystem": true
                     }
                   ]
                 },
                 "systemd": {
                   "units": [
                     {
                       "contents": "# Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target",
                       "enabled": true,
                       "name": "var-lib-containers.mount"
                     }
                   ]
                 }
               }
             nodeNetwork:
               interfaces:
                 - name: eno1
                   macAddress: "AA:BB:CC:DD:EE:11"
               config:
                 interfaces:
                   - name: eno1
                     type: ethernet
                     state: up
                     ipv4:
                       enabled: false
                     ipv6:
                       enabled: true
                       address:
                         # For SNO sites with static IP addresses, the node-specific,
                         # API and Ingress IPs should all be the same and configured on
                         # the interface
                         - 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

   注記

   ztp-site-generate コンテナーの out/extra-manifest ディレクトリーから参照 CR 設定ファイルを抽出したら、extraManifests.searchPaths を使用して、それらのファイルを含む git ディレクトリーへのパスを含めることができます。これにより、GitOps ZTP パイプラインはクラスターのインストール中にこれらの CR ファイルを適用できるようになります。searchPaths ディレクトリーを設定すると、GitOps ZTP パイプラインは、サイトのインストール中に ztp-site-generate コンテナーからマニフェストを取得しません。

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.16 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.16 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. 前の手順の参照 PolicyGenerator CR を使用して、Day 2 設定 CR を生成してエクスポートします。以下のコマンドを実行します。

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

      $ mkdir -p ./ref

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

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

      このコマンドは、シングルノード OpenShift、3 ノードクラスター、および標準クラスター用のサンプルグループおよびサイト固有の PolicyGenerator 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.16.yaml)。ClusterImageSet のフォーマットは以下のとおりです。

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

   1

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

   2

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

2. clusterImageSet CR を適用します。

   $ oc apply -f clusterImageSet-4.16.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. マネージドクラスターのカスタムリソースを再作成します。

手順

1. UEFI/BIOS Boot Mode を UEFI に設定します。
2. ホスト起動シーケンスの順序で、ハードドライブ を設定します。

3. ハードウェアに特定のファームウェア設定を適用します。次の表は、Intel FlexRAN 4G および 5G baseband PHY リファレンスデザインに基づく、Intel Xeon Skylake サーバーおよびそれ以降のハードウェア世代の代表的なファームウェア設定を示しています。

   重要

   ファームウェア設定は、実際のハードウェアおよびネットワークの要件によって異なります。以下の設定例は、説明のみを目的としています。

   表6.2 ファームウェア設定のサンプル

   ファームウェア設定	設定
   CPU パワーとパフォーマンスポリシー	パフォーマンス
   Uncore Frequency Scaling	Disabled
   パフォーマンスの制限	Disabled
   Intel SpeedStep ® Tech の強化	有効
   Intel Configurable TDP	有効
   設定可能な TDP レベル	レベル 2
   Intel® Turbo Boost Technology	有効
   Energy Efficient Turbo	Disabled
   Hardware P-States	Disabled
   Package C-State	C0/C1 の状態
   C1E	Disabled
   Processor C6	Disabled

手順

1. デフォルトの OperatorHub ソースが無効になっていることを確認します。以下のコマンドを実行します。

   $ oc get operatorhub cluster -o yaml

   出力例

   spec:
       disableAllDefaultSources: true

2. 次のコマンドを実行して、必要なすべての CatalogSource リソースにワークロードのパーティショニング (PreferredDuringScheduling) のアノテーションが付けられていることを確認します。

   $ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'

   出力例

   certified-operators -- {"effect": "PreferredDuringScheduling"}
   community-operators -- {"effect": "PreferredDuringScheduling"}
   ran-operators 1
   redhat-marketplace -- {"effect": "PreferredDuringScheduling"}
   redhat-operators -- {"effect": "PreferredDuringScheduling"}

   1

   アノテーションが付けられていない CatalogSource リソースも返されます。この例では、ran-operators CatalogSource リソースにはアノテーションが付けられておらず、PreferredDuringScheduling アノテーションがありません。

   注記

   適切に設定された vDU クラスターでは、単一のアノテーション付きカタログソースのみがリスト表示されます。

3. 該当するすべての OpenShift Container Platform Operator の namespace がワークロードのパーティショニング用にアノテーションされていることを確認します。これには、コア OpenShift Container Platform とともにインストールされたすべての Operator と、参照 DU チューニング設定に含まれる追加の Operator のセットが含まれます。以下のコマンドを実行します。

   $ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'

   出力例

   default --
   openshift-apiserver -- management
   openshift-apiserver-operator -- management
   openshift-authentication -- management
   openshift-authentication-operator -- management

   重要

   追加の Operator は、ワークロードパーティショニングのためにアノテーションを付けてはなりません。前のコマンドからの出力では、追加の Operator が -- セパレーターの右側に値なしでリストされている必要があります。

4. ClusterLogging 設定が正しいことを確認してください。以下のコマンドを実行します。

   1. 適切な入力ログと出力ログが設定されていることを確認します。

      $ oc get -n openshift-logging ClusterLogForwarder instance -o yaml

      出力例

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogForwarder
      metadata:
        creationTimestamp: "2022-07-19T21:51:41Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "1030342"
        uid: 8c1a842d-80c5-447a-9150-40350bdf40f0
      spec:
        inputs:
        - infrastructure: {}
          name: infra-logs
        outputs:
        - name: kafka-open
          type: kafka
          url: tcp://10.46.55.190:9092/test
        pipelines:
        - inputRefs:
          - audit
          name: audit-logs
          outputRefs:
          - kafka-open
        - inputRefs:
          - infrastructure
          name: infrastructure-logs
          outputRefs:
          - kafka-open
      ...

   2. キュレーションスケジュールがアプリケーションに適していることを確認します。

      $ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml

      出力例

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      metadata:
        creationTimestamp: "2022-07-07T18:22:56Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "235796"
        uid: ef67b9b8-0e65-4a10-88ff-ec06922ea796
      spec:
        collection:
          logs:
            fluentd: {}
            type: fluentd
        curation:
          curator:
            schedule: 30 3 * * *
          type: curator
        managementState: Managed
      ...

5. 次のコマンドを実行して、Web コンソールが無効になっている (managementState: Removed) ことを確認します。

   $ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"

   出力例

   Removed

6. 次のコマンドを実行して、クラスターノードで chronyd が無効になっていることを確認します。

   $ oc debug node/<node_name>

   ノードで chronyd のステータスを確認します。

   sh-4.4# chroot /host

   sh-4.4# systemctl status chronyd

   出力例

   ● chronyd.service - NTP client/server
       Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
       Active: inactive (dead)
         Docs: man:chronyd(8)
               man:chrony.conf(5)

7. linuxptp-daemon コンテナーへのリモートシェル接続と PTP Management Client (pmc) ツールを使用して、PTP インターフェイスがプライマリークロックに正常に同期されていることを確認します。

   1. 次のコマンドを実行して、$PTP_POD_NAME 変数に linuxptp-daemon Pod の名前を設定します。

      $ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)

   2. 次のコマンドを実行して、PTP デバイスの同期ステータスを確認します。

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

      出力例

      sending: GET PORT_DATA_SET
        3cecef.fffe.7a7020-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-1
          portState               SLAVE
          logMinDelayReqInterval  -4
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2
        3cecef.fffe.7a7020-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-2
          portState               LISTENING
          logMinDelayReqInterval  0
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2

   3. 次の pmc コマンドを実行して、PTP クロックのステータスを確認します。

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'

      出力例

      sending: GET TIME_STATUS_NP
        3cecef.fffe.7a7020-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
          master_offset              10 1
          ingress_time               1657275432697400530
          cumulativeScaledRateOffset +0.000000000
          scaledLastGmPhaseChange    0
          gmTimeBaseIndicator        0
          lastGmPhaseChange          0x0000'0000000000000000.0000
          gmPresent                  true 2
          gmIdentity                 3c2c30.ffff.670e00

      1

      master_offset は -100 から 100 ns の間である必要があります。

      2

      PTP クロックがマスターに同期されており、ローカルクロックがグランドマスタークロックではないことを示します。

   4. /var/run/ptp4l.0.config の値に対応する予期される master offset 値が linuxptp-daemon-container ログにあることを確認します。

      $ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container

      出力例

      phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset  -1731092 s2 freq -1546242 delay    497
      ptp4l[56020.390]: [ptp4l.1.config] master offset         -2 s2 freq   -5863 path delay       541
      ptp4l[56020.390]: [ptp4l.0.config] master offset         -8 s2 freq  -10699 path delay       533

8. 次のコマンドを実行して、SR-IOV 設定が正しいことを確認します。

   1. SriovOperatorConfig リソースの disableDrain 値が true に設定されていることを確認します。

      $ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"

      出力例

      true

   2. 次のコマンドを実行して、SriovNetworkNodeState 同期ステータスが Succeeded であることを確認します。

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"

      出力例

      Succeeded

   3. SR-IOV 用に設定された各インターフェイスの下の仮想機能 (Vfs) の予想される数と設定が、.status.interfaces フィールドに存在し、正しいことを確認します。以下に例を示します。

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml

      出力例

      apiVersion: v1
      items:
      - apiVersion: sriovnetwork.openshift.io/v1
        kind: SriovNetworkNodeState
      ...
        status:
          interfaces:
          ...
          - Vfs:
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.0
              vendor: "8086"
              vfID: 0
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.1
              vendor: "8086"
              vfID: 1
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.2
              vendor: "8086"
              vfID: 2
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.3
              vendor: "8086"
              vfID: 3
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.4
              vendor: "8086"
              vfID: 4
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.5
              vendor: "8086"
              vfID: 5
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.6
              vendor: "8086"
              vfID: 6
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.7
              vendor: "8086"
              vfID: 7

9. クラスターパフォーマンスプロファイルが正しいことを確認します。cpu セクションと hugepages セクションは、ハードウェア設定によって異なります。以下のコマンドを実行します。

   $ oc get PerformanceProfile openshift-node-performance-profile -o yaml

   出力例

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     creationTimestamp: "2022-07-19T21:51:31Z"
     finalizers:
     - foreground-deletion
     generation: 1
     name: openshift-node-performance-profile
     resourceVersion: "33558"
     uid: 217958c0-9122-4c62-9d4d-fdc27c31118c
   spec:
     additionalKernelArgs:
     - idle=poll
     - rcupdate.rcu_normal_after_boot=0
     - efi=runtime
     cpu:
       isolated: 2-51,54-103
       reserved: 0-1,52-53
     hugepages:
       defaultHugepagesSize: 1G
       pages:
       - count: 32
         size: 1G
     machineConfigPoolSelector:
       pools.operator.machineconfiguration.openshift.io/master: ""
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/master: ""
     numa:
       topologyPolicy: restricted
     realTimeKernel:
       enabled: true
   status:
     conditions:
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "True"
       type: Available
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "True"
       type: Upgradeable
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "False"
       type: Progressing
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "False"
       type: Degraded
     runtimeClass: performance-openshift-node-performance-profile
     tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-openshift-node-performance-profile

   注記

   CPU 設定は、サーバーで使用可能なコアの数に依存し、ワークロードパーティショニングの設定に合わせる必要があります。hugepages の設定は、サーバーとアプリケーションに依存します。

10. 次のコマンドを実行して、PerformanceProfile がクラスターに正常に適用されたことを確認します。

    $ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"

    出力例

    Available -- True
    Upgradeable -- True
    Progressing -- False
    Degraded -- False

11. 次のコマンドを実行して、Tuned パフォーマンスパッチの設定を確認します。

    $ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml

    出力例

    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      creationTimestamp: "2022-07-18T10:33:52Z"
      generation: 1
      name: performance-patch
      namespace: openshift-cluster-node-tuning-operator
      resourceVersion: "34024"
      uid: f9799811-f744-4179-bf00-32d4436c08fd
    spec:
      profile:
      - data: |
          [main]
          summary=Configuration changes profile inherited from performance created tuned
          include=openshift-node-performance-openshift-node-performance-profile
          [bootloader]
          cmdline_crash=nohz_full=2-23,26-47 1
          [sysctl]
          kernel.timer_migration=1
          [scheduler]
          group.ice-ptp=0:f:10:*:ice-ptp.*
          [service]
          service.stalld=start,enable
          service.chronyd=stop,disable
        name: performance-patch
      recommend:
      - machineConfigLabels:
          machineconfiguration.openshift.io/role: master
        priority: 19
        profile: performance-patch

    1

    cmdline=nohz_full= の cpu リストは、ハードウェア設定によって異なります。

12. 次のコマンドを実行して、クラスターネットワーク診断が無効になっていることを確認します。

    $ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'

    出力例

    true

13. Kubelet のハウスキーピング間隔が、遅い速度に調整されていることを確認します。これは、containerMountNS マシン設定で設定されます。以下のコマンドを実行します。

    $ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION

    出力例

    Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"

14. 次のコマンドを実行して、Grafana と alertManagerMain が無効になっていること、および Prometheus の保持期間が 24 時間に設定されていることを確認します。

    $ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"

    出力例

    grafana:
      enabled: false
    alertmanagerMain:
      enabled: false
    prometheusK8s:
       retention: 24h

    1. 次のコマンドを使用して、Grafana および alertManagerMain ルートがクラスター内に見つからないことを確認します。

       $ oc get route -n openshift-monitoring alertmanager-main

       $ oc get route -n openshift-monitoring grafana

       どちらのクエリーも Error from server (NotFound) メッセージを返す必要があります。

15. 次のコマンドを実行して、PerformanceProfile、Tuned performance-patch、ワークロードパーティショニング、およびカーネルコマンドライン引数のそれぞれに reserved として割り当てられた CPU が少なくとも 4 つあることを確認します。

    $ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"

    出力例

    0-3

    注記

    ワークロードの要件によっては、追加の予約済み CPU の割り当てが必要になる場合があります。

手順

1. GitOps ZTP パイプラインがクラスターインストールのカスタマイズ使用する、追加のマニフェスト CR のセットを作成します。

2. カスタム /siteconfig ディレクトリーに、追加のマニフェスト用のサブディレクトリー /custom-manifest を作成します。以下の例は、/custom-manifest フォルダーを持つ /siteconfig のサンプルを示しています。

   siteconfig
   ├── site1-sno-du.yaml
   ├── site2-standard-du.yaml
   ├── extra-manifest/
   └── custom-manifest
       └── 01-example-machine-config.yaml

   注記

   全体で使用されているサブディレクトリー名 /custom-manifest および /extra-manifest は、名前の例にすぎません。これらの名前を使用する必要はなく、これらのサブディレクトリーに名前を付ける方法に制限はありません。この例では、/extra-manifest は、ztp-site-generate コンテナーの /extra-manifest の内容を保存する Git サブディレクトリーを指します。

3. カスタムの追加マニフェスト CR を siteconfig/custom-manifest ディレクトリーに追加します。

4. SiteConfig CR で、extraManifests.searchPaths フィールドにディレクトリー名を入力します。例:

   clusters:
   - clusterName: "example-sno"
     networkType: "OVNKubernetes"
     extraManifests:
       searchPaths:
         - extra-manifest/ 1
         - custom-manifest/ 2

   1

   ztp-site-generate コンテナーからコピーされたマニフェストのフォルダー。

   2

   カスタムマニフェストのフォルダー。

5. SiteConfig、/extra-manifest、および /custom-manifest CR を保存し、サイト設定リポジトリーにプッシュします。

手順

1. GitOps ZTP パイプラインが 03-sctp-machine-config-worker.yaml CR ファイルを適用しないようにするには、SiteConfig CR で次の YAML を適用します。

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "site1-sno-du"
     namespace: "site1-sno-du"
   spec:
     baseDomain: "example.com"
     pullSecretRef:
       name: "assisted-deployment-pull-secret"
     clusterImageSetNameRef: "openshift-4.16"
     sshPublicKey: "<ssh_public_key>"
     clusters:
   - clusterName: "site1-sno-du"
     extraManifests:
       filter:
         exclude:
           - 03-sctp-machine-config-worker.yaml

   GitOps ZTP パイプラインは、インストール中に 03-sctp-machine-config-worker.yaml CR をスキップします。/source-crs/extra-manifest 内の他のすべての CR が適用されます。

2. SiteConfig CR を保存し、変更をサイト設定リポジトリーにプッシュします。

   GitOps ZTP パイプラインは、SiteConfig フィルター命令に基づいて適用する CR を監視および調整します。

3. オプション: クラスターのインストール中に GitOps ZTP パイプラインがすべての /source-crs/extra-manifest CR を適用しないようにするには、SiteConfig CR で次の YAML を適用します。

   - clusterName: "site1-sno-du"
     extraManifests:
       filter:
         inclusionDefault: exclude

4. オプション: インストール中にすべての /source-crs/extra-manifest RAN CR を除外し、代わりにカスタム CR ファイルを含めるには、カスタム SiteConfig CR を編集してカスタムマニフェストフォルダーと include ファイルを設定します。次に例を示します。

   clusters:
   - clusterName: "site1-sno-du"
     extraManifestPath: "<custom_manifest_folder>" 1
     extraManifests:
       filter:
         inclusionDefault: exclude  2
         include:
           - custom-sctp-machine-config-worker.yaml

   1

   <custom_manifest_folder> を、カスタムインストール CR を含むフォルダーの名前 (user-custom-manifest/ など) に置き換えます。

   2

   インストール中に GitOps ZTP パイプラインが /source-crs/extra-manifest 内のファイルを適用しないようにするには、inclusionDefault を exclude に設定します。

   次の例は、カスタムフォルダー構造を示しています。

   siteconfig
     ├── site1-sno-du.yaml
     └── user-custom-manifest
           └── custom-sctp-machine-config-worker.yaml

手順

1. SiteConfig CR を更新して bmac.agent-install.openshift.io/remove-agent-and-node-on-delete=true アノテーションを追加し、変更を Git リポジトリーにプッシュします。

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "cnfdf20"
     namespace: "cnfdf20"
   spec:
     clusters:
       nodes:
       - hostname: node6
         role: "worker"
         crAnnotations:
           add:
             BareMetalHost:
               bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: true
   # ...

2. 次のコマンドを実行して、BareMetalHost オブジェクトにアノテーションが付けられていることを確認します。

   oc get bmh -n <managed-cluster-namespace> <bmh-object> -ojsonpath='{.metadata}' | jq -r '.annotations["bmac.agent-install.openshift.io/remove-agent-and-node-on-delete"]'

   出力例

   true

3. SiteConfig CR を更新して crSuppression.BareMetalHost アノテーションを含めることで、BareMetalHost CR の生成を抑制します。

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "cnfdf20"
     namespace: "cnfdf20"
   spec:
     clusters:
     - nodes:
       - hostName: node6
         role: "worker"
         crSuppression:
         - BareMetalHost
   # ...

4. 変更を Git リポジトリーにプッシュし、プロビジョニング解除が開始するまで待ちます。BareMetalHost CR のステータスが deprovisioning に変更されるはずです。BareMetalHost のプロビジョニング解除が完了し、完全に削除されるまで待ちます。

検証

1. 次のコマンドを実行して、ワーカーノードの BareMetalHost および Agent CR がハブクラスターから削除されていることを確認します。

   $ oc get bmh -n <cluster-ns>

   $ oc get agent -n <cluster-ns>

2. 次のコマンドを実行して、スポーククラスターからノードレコードが削除されたことを確認します。

   $ oc get nodes

   注記

   シークレットを操作している場合は、シークレットを削除するのが早すぎると、ArgoCD が削除後に再同期を完了するためにシークレットを必要とするため、問題が発生する可能性があります。現在の ArgoCD 同期が完了したら、ノードのクリーンアップ後にのみシークレットを削除します。