18.9. SiteConfig リソースを使用した高度なマネージドクラスター設定

手順

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.14"
     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 同期が完了したら、ノードのクリーンアップ後にのみシークレットを削除します。