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


SiteConfig カスタムリソース (CR) を使用して、インストール時にマネージドクラスターにカスタム機能と設定をデプロイできます。

22.9.1. GitOps ZTP パイプラインでの追加インストールマニフェストのカスタマイズ

GitOps Zero Touch Provisioning (ZTP) パイプラインのインストールフェーズに追加するマニフェストセットを定義できます。これらのマニフェストは SiteConfig カスタムリソース (CR) にリンクされ、インストール時にクラスターに適用されます。インストール時に MachineConfig CR を含めると、インストール作業が効率的になります。

前提条件

  • カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。

手順

  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
    Copy to Clipboard Toggle word wrap
    注記

    全体で使用されているサブディレクトリー名 /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
    Copy to Clipboard Toggle word wrap
    1
    ztp-site-generate コンテナーからコピーされたマニフェストのフォルダー。
    2
    カスタムマニフェストのフォルダー。
  5. SiteConfig/extra-manifest、および /custom-manifest CR を保存し、サイト設定リポジトリーにプッシュします。

クラスターのプロビジョニング中に、GitOps ZTP パイプラインは、/custom-manifest ディレクトリー内の CR を、extra-manifest/ に保存されている追加マニフェストのデフォルトのセットに追加します。

注記

バージョン 4.14 以降、extraManifestPath には非推奨の警告が表示されます。

extraManifestPath は引き続きサポートされていますが、extraManifests.searchPaths を使用することを推奨します。SiteConfig ファイルで extraManifests.searchPaths を定義すると、GitOps ZTP パイプラインはサイトのインストール中に ztp-site-generate コンテナーからマニフェストを取得しません。

Siteconfig CR で extraManifestPathextraManifests.searchPaths の両方を定義した場合は、extraManifests.searchPaths に定義された設定が優先されます。

/extra-manifest の内容を ztp-site-generate コンテナーから抽出し、GIT リポジトリーにプッシュすることを強く推奨します。

22.9.2. SiteConfig フィルターを使用したカスタムリソースのフィルタリング

フィルターを使用すると、SiteConfig カスタムリソース (CR) を簡単にカスタマイズして、GitOps Zero Touch Provisioning (ZTP) パイプラインのインストールフェーズで使用する他の CR を追加または除外できます。

SiteConfig CR の inclusionDefault 値として include または exclude を指定し、さらに、含めたり除外したりする特定の extraManifest RAN CR のリストを指定することもできます。inclusionDefaultinclude に設定すると、GitOps ZTP パイプラインはインストール中に /source-crs/extra-manifest 内のすべてのファイルを適用します。inclusionDefaultexclude に設定すると、その逆になります。

デフォルトで含まれている /source-crs/extra-manifest フォルダーから個々の CR を除外できます。以下の例では、インストール時に /source-crs/extra-manifest/03-sctp-machine-config-worker.yaml CR を除外するようにカスタムのシングルノード OpenShift SiteConfig CR を設定します。

また、いくつかのオプションのフィルタリングシナリオも説明されています。

前提条件

  • 必要なインストール CR とポリシー CR を生成するためにハブクラスターを設定している。
  • カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。

手順

  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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    1
    <custom_manifest_folder> を、カスタムインストール CR を含むフォルダーの名前 (user-custom-manifest/ など) に置き換えます。
    2
    インストール中に GitOps ZTP パイプラインが /source-crs/extra-manifest 内のファイルを適用しないようにするには、inclusionDefaultexclude に設定します。

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

    siteconfig
      ├── site1-sno-du.yaml
      └── user-custom-manifest
            └── custom-sctp-machine-config-worker.yaml
    Copy to Clipboard Toggle word wrap

22.9.3. SiteConfig CR を使用してノードを削除する

SiteConfig カスタムリソース (CR) を使用すると、ノードを削除して再プロビジョニングできます。この方法は、手動でノードを削除するよりも効率的です。

前提条件

  • 必要なインストールおよびポリシー CR を生成するようにハブクラスターを設定している。
  • カスタムサイト設定データを管理できる Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。

手順

  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
    # ...
    Copy to Clipboard Toggle word wrap
  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"]'
    Copy to Clipboard Toggle word wrap

    出力例

    true
    Copy to Clipboard Toggle word wrap

  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
    # ...
    Copy to Clipboard Toggle word wrap
  4. 変更を Git リポジトリーにプッシュし、プロビジョニング解除が開始するまで待ちます。BareMetalHost CR のステータスが deprovisioning に変更されるはずです。BareMetalHost のプロビジョニング解除が完了し、完全に削除されるまで待ちます。

検証

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

    $ oc get bmh -n <cluster-ns>
    Copy to Clipboard Toggle word wrap
    $ oc get agent -n <cluster-ns>
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、スポーククラスターからノードレコードが削除されたことを確認します。

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
    注記

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

次のステップ

ノードを再プロビジョニングするには、以前に SiteConfig に追加された変更を削除し、変更を Git リポジトリーにプッシュして、同期が完了するまで待機します。これにより、ワーカーノードの BareMetalHost CR が再生成され、ノードの再インストールがトリガーされます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat