17.4. ポリシーと PolicyGenTemplate リソースを使用したマネージドクラスターの設定

適用されたポリシーのカスタムリソース (CR) は、プロビジョニングするマネージドクラスターを設定します。Red Hat Advanced Cluster Management (RHACM) が PolicyGenTemplate CR を使用して、適用されるポリシー CR を生成する方法をカスタマイズできます。

17.4.1. PolicyGenTemplate CRD について

PolicyGenTemplate カスタムリソース定義 (CRD) は、PolicyGen ポリシージェネレーターに、どのカスタムリソース (CR) をクラスター設定に含めるか、CR を生成されたポリシーに結合する方法、およびこれらの CR 内のどのアイテムをオーバーレイコンテンツで更新する必要があるかを伝えます。

次の例は、ztp-site-generate 参照コンテナーから抽出された PolicyGenTemplate CR (common-du-ranGen.yaml) を示しています。common-du-ranGen.yaml ファイルは、2 つの Red Hat Advanced Cluster Management (RHACM) ポリシーを定義します。ポリシーは、CR 内の policyName の一意の値ごとに 1 つずつ、設定 CR のコレクションを管理します。common-du-ranGen.yaml は、単一の配置バインディングと配置ルールを作成して、bindingRules セクションにリストされているラベルに基づいてポリシーをクラスターにバインドします。

PolicyGenTemplate CR の例 - common-du-ranGen.yaml

---
apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "common"
  namespace: "ztp-common"
spec:
  bindingRules:
    common: "true" 1
  sourceFiles: 2
    - fileName: SriovSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogNS.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageNS.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: ReduceMonitoringFootprint.yaml
      policyName: "config-policy"
    - fileName: OperatorHub.yaml 3
      policyName: "config-policy"
    - fileName: DefaultCatsrc.yaml 4
      policyName: "config-policy" 5
      metadata:
        name: redhat-operators
      spec:
        displayName: disconnected-redhat-operators
        image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.9
    - fileName: DisconnectedICSP.yaml
      policyName: "config-policy"
      spec:
        repositoryDigestMirrors:
        - mirrors:
          - registry.example.com:5000
          source: registry.redhat.io

1
common: true は、このラベルを持つすべてのクラスターにポリシーを適用します。
2
sourceFiles の下にリストされているファイルは、インストールされたクラスターの Operator ポリシーを作成します。
3
OperatorHub.yaml は、切断されたレジストリーの OperatorHub を設定します。
4
DefaultCatsrc.yaml は、切断されたレジストリーのカタログソースを設定します。
5
policyName: "config-policy" は、Operator サブスクリプションを設定します。OperatorHub CR はデフォルトを無効にし、この CR は redhat-operators を切断されたレジストリーを指す CatalogSource CR に置き換えます。

PolicyGenTemplate CR は、任意の数の組み込み CR で設定できます。次の例の CR をハブクラスターに適用して、単一の CR を含むポリシーを生成します。

apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "group-du-sno"
  namespace: "ztp-group"
spec:
  bindingRules:
    group-du-sno: ""
  mcp: "master"
  sourceFiles:
    - fileName: PtpConfigSlave.yaml
      policyName: "config-policy"
      metadata:
        name: "du-ptp-slave"
      spec:
        profile:
        - name: "slave"
          interface: "ens5f0"
          ptp4lOpts: "-2 -s --summary_interval -4"
          phc2sysOpts: "-a -r -n 24"

ソースファイル PtpConfigSlave.yaml を例として使用すると、ファイルは PtpConfig CR を定義します。PtpConfigSlave サンプルの生成ポリシーは group-du-sno-config-policy という名前です。生成された group-du-sno-config-policy に定義される PtpConfig CR は du-ptp-slave という名前です。PtpConfigSlave.yaml で定義された spec は、du-ptp-slave の下に、ソースファイルで定義された他の spec 項目と共に配置されます。

次の例は、group-du-sno-config-policy CR を示しています。

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: group-du-ptp-config-policy
  namespace: groups-sub
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
spec:
    remediationAction: inform
    disabled: false
    policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
                name: group-du-ptp-config-policy-config
            spec:
                remediationAction: inform
                severity: low
                namespaceselector:
                    exclude:
                        - kube-*
                    include:
                        - '*'
                object-templates:
                    - complianceType: musthave
                      objectDefinition:
                        apiVersion: ptp.openshift.io/v1
                        kind: PtpConfig
                        metadata:
                            name: du-ptp-slave
                            namespace: openshift-ptp
                        spec:
                            recommend:
                                - match:
                                - nodeLabel: node-role.kubernetes.io/worker-du
                                  priority: 4
                                  profile: slave
                            profile:
                                - interface: ens5f0
                                  name: slave
                                  phc2sysOpts: -a -r -n 24
                                  ptp4lConf: |
                                    [global]
                                    #
                                    # Default Data Set
                                    #
                                    twoStepFlag 1
                                    slaveOnly 0
                                    priority1 128
                                    priority2 128
                                    domainNumber 24
                                    .....

17.4.2. PolicyGenTemplate CR をカスタマイズする際の推奨事項

サイト設定の PolicyGenTemplate カスタムリソース (CR) をカスタマイズするときは、次のベストプラクティスを考慮してください。

  • 必要な数のポリシーを使用します。使用するポリシーが少ないほど、必要なリソースが少なくなります。追加ポリシーごとに、ハブクラスターと、デプロイされたマネージドクラスターのオーバーヘッドが発生します。CR は PolicyGenTemplate CR の policyName フィールドに基づいてポリシーに統合されます。policyName に同じ値を持つ同じ PolicyGenTemplate の CR は単一のポリシーで管理されます。
  • 切断された環境では、すべての Operator を含む単一のインデックスとしてレジストリーを設定することにより、すべての Operator に対して単一のカタログソースを使用します。マネージドクラスターに CatalogSource CR を追加するたびに、CPU 使用率が増加します。
  • MachineConfig CR は、インストール時に適用されるように SiteConfig CR に 追加の Manifest として組み込む必要があります。これにより、クラスターがアプリケーションをデプロイする準備ができるまで全体的な時間がかかる可能性があります。
  • PolicyGenTemplates は、必要なバージョンを明示的に指定するために channel フィールドを上書きする必要があります。これにより、アップグレード時にソース CR が変更されても、生成されたサブスクリプションが更新されないようになります。

関連情報

注記

ハブクラスターで多数のスポーククラスターを管理する場合は、ポリシーの数を最小限に抑えてリソースの消費を減らします。

複数のコンフィギュレーション CR を 1 つまたは限られた数のポリシーにグループ化することは、ハブクラスター上のポリシーの総数を減らすための 1 つの方法です。サイト設定の管理に共通、グループ、サイトというポリシーの階層を使用する場合は、サイト固有の設定を 1 つのポリシーにまとめることが特に重要である。

17.4.3. RAN デプロイメントの PolicyGenTemplate CR

PolicyGenTemplate (PGT) カスタムリソース (CR) を使用して、GitOps ゼロトゥオッチプロビジョニング (ZTP) パイプラインを使用してクラスターに適用される設定をカスタマイズします。PGT CR を使用すると、1 つ以上のポリシーを生成して、クラスターのフリートで設定 CR のセットを管理できます。PGT は、管理された CR のセットを識別し、それらをポリシーにバンドルし、それらの CR をラップするポリシーを構築し、ラベルバインディングルールを使用してポリシーをクラスターに関連付けます。

GitOps ZTP コンテナーから取得した参照設定は、RAN (Radio Access Network) 分散ユニット (DU) アプリケーションに典型的な厳しいパフォーマンスとリソース利用制約をクラスターが確実にサポートできるように、重要な機能とノードのチューニング設定のセットを提供するように設計されています。ベースライン設定の変更または省略は、機能の可用性、パフォーマンス、およびリソースの利用に影響を与える可能性があります。参照 PolicyGenTemplate CR をベースに、お客様のサイト要件に合わせた設定ファイルの階層を作成します。

RAN DU クラスター設定に定義されているベースライン PolicyGenTemplate CR は、GitOps ZTP ztp-site-generate コンテナーから抽出することが可能です。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。

PolicyGenTemplate の CR は、./out/argocd/example/policygentemplates フォルダーに格納されています。参照アーキテクチャーには、common、group、および site 固有の設定 CR があります。各 PolicyGenTemplate CR は ./out/source-crs フォルダーにある他の CR を参照します。

RAN クラスター設定に関連する PolicyGenTemplate CR は以下で説明されています。バリアントは、単一ノード、3 ノードのコンパクト、および標準のクラスター設定の相違点に対応するために、グループ PolicyGenTemplate CR に提供されます。同様に、シングルノードクラスターとマルチノード (コンパクトまたはスタンダード) クラスターについても、サイト固有の設定バリエーションが提供されています。デプロイメントに関連するグループおよびサイト固有の設定バリアントを使用します。

表17.4 RAN デプロイメントの PolicyGenTemplate CR

PolicyGenTemplate CR説明

example-multinode-site.yaml

マルチノードクラスターに適用される一連の CR が含まれています。これらの CR は、RAN インストールに典型的な SR-IOV 機能を設定します。

example-sno-site.yaml

単一ノードの OpenShift クラスターに適用される一連の CR が含まれています。これらの CR は、RAN インストールに典型的な SR-IOV 機能を設定します。

common-ranGen.yaml

すべてのクラスターに適用される共通の RAN CR のセットが含まれています。これらの CR は、RAN の典型的なクラスター機能とベースラインクラスターのチューニングを提供する Operator のセットをサブスクライブします。

group-du-3node-ranGen.yaml

3 ノードクラスター用の RAN ポリシーのみが含まれています。

group-du-sno-ranGen.yaml

シングルノードクラスター用の RAN ポリシーのみが含まれています。

group-du-standard-ranGen.yaml

標準的な 3 つのコントロールプレーンクラスターの RAN ポリシーが含まれています。

group-du-3node-validator-ranGen.yaml

PolicyGenTemplate CR は、3 ノードクラスターに必要なさまざまなポリシーを生成するために使用されます。

group-du-standard-validator-ranGen.yaml

標準クラスターに必要なさまざまなポリシーを生成するために使用される PolicyGenTemplate CR。

group-du-sno-validator-ranGen.yaml

PolicyGenTemplate CR は、単一ノードの OpenShift クラスターに必要なさまざまなポリシーを生成するために使用されます。

17.4.4. PolicyGenTemplate CR を使用したマネージドクラスターのカスタマイズ

次の手順を使用して、ゼロタッチプロビジョニング (ZTP) パイプラインを使用してプロビジョニングするマネージドクラスターに適用されるポリシーをカスタマイズします。

前提条件

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

手順

  1. サイト固有の設定 CR の PolicyGenTemplate CR を作成します。

    1. CR の適切な例を out/argocd/example/policygentemplates フォルダーから選択します (example-sno-site.yaml または example-multinode-site.yaml)。
    2. サンプルファイルの bindingRules フィールドを、SiteConfig CR に含まれるサイト固有のラベルと一致するように変更します。サンプルの SiteConfig ファイルでは、サイト固有のラベルは sites: example-sno です。

      注記

      PolicyGenTemplate bindingRules フィールドで定義されているラベルが、関連するマネージドクラスターの SiteConfig CR で定義されているラベルに対応していることを確認してください。

    3. サンプルファイルの内容を目的の設定に合わせて変更します。
  2. オプション: クラスターのフリート全体に適用される一般的な設定 CR の PolicyGenTemplate CR を作成します。

    1. out/argocd/example/policygentemplates フォルダーから CR の適切な例を選択します (例: common-ranGen.yaml)
    2. サンプルファイルの内容を目的の設定に合わせて変更します。
  3. オプション: フリート内のクラスターの特定のグループに適用されるグループ設定 CR の PolicyGenTemplate CR を作成します。

    オーバーレイド仕様ファイルの内容が必要な終了状態と一致することを確認します。out/source-crs ディレクトリーには、PolicyGenTemplate テンプレートに含めることができる source-crs の完全な一覧が含まれます。

    注記

    クラスターの特定の要件に応じて、クラスターの種類ごとに 1 つ以上のグループポリシーが必要になる場合があります。特に、サンプルのグループポリシーにはそれぞれ単一の PerformancePolicy.yaml ファイルがあり、それらのクラスターが同一のハードウェア設定である場合にのみクラスターのセット全体で共有できることを考慮しています。

    1. out/argocd/example/policygentemplates フォルダーから CR の適切な例を選択します (例: group-du-sno-ranGen.yaml)。
    2. サンプルファイルの内容を目的の設定に合わせて変更します。
  4. オプション:ZTP のインストールとデプロイされたクラスターの設定が完了したときに通知するバリデータ通知ポリシー PolicyGenTemplate CR を作成します。詳細は、バリデータ通知ポリシーの作成を参照してください。
  5. out/argocd/example/policygentemplates/ns.yaml ファイルの例と同様の YAML ファイルで、すべてのポリシーの namespace を定義してください。

    重要

    Namespace CR を PolicyGenTemplate CR と同じファイルに含めないでください。

  6. out/argocd/example/policygentemplates/kustomization.yaml に示されている例と同様に、PolicyGenTemplate CR と Namespace CR をジェネレーターセクションの kustomization.yaml ファイルに追加します。
  7. PolicyGenTemplate CR、Namespace CR、および関連する kustomization.yaml ファイルを Git リポジトリーにコミットし、変更をプッシュします。

    ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。SiteConfig CR と PolicyGenTemplate CR に同時に変更をプッシュすることができます。

17.4.5. マネージドクラスターポリシーのデプロイメントの進行状況の監視

ArgoCD パイプラインは、Git の PolicyGenTemplate CR を使用して RHACM ポリシーを生成し、ハブクラスターに同期します。支援されたサービスが OpenShift Container Platform をマネージドクラスターにインストールした後、管理対象クラスターのポリシー Synchronization の進行状況をモニターできます。

前提条件

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

手順

  1. Topology Aware Lifecycle Manager (TALM) は、クラスターにバインドされている設定ポリシーを適用します。

    クラスターのインストールが完了し、クラスターが Ready になると、ran.openshift.io/ztp-deploy-wave アノテーションで 定義された順序付きポリシーのリストで、このクラスターに対応する ClusterGroupUpgrade CR が TALM により自動的に作成されます。クラスターのポリシーは、ClusterGroupUpgrade CR に記載されている順序で適用されます。

    以下のコマンドを使用して、設定ポリシー調整のハイレベルの進捗を監視できます。

    $ export CLUSTER=<clusterName>
    $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq

    出力例

    {
      "lastTransitionTime": "2022-11-09T07:28:09Z",
      "message": "Remediating non-compliant policies",
      "reason": "InProgress",
      "status": "True",
      "type": "Progressing"
    }

  2. RHACM ダッシュボードまたはコマンドラインを使用して、詳細なクラスターポリシーのコンプライアンスステータスを監視できます。

    1. oc を使用してポリシーのコンプライアンスを確認するには、次のコマンドを実行します。

      $ oc get policies -n $CLUSTER

      出力例

      NAME                                                     REMEDIATION ACTION   COMPLIANCE STATE   AGE
      ztp-common.common-config-policy                          inform               Compliant          3h42m
      ztp-common.common-subscriptions-policy                   inform               NonCompliant       3h42m
      ztp-group.group-du-sno-config-policy                     inform               NonCompliant       3h42m
      ztp-group.group-du-sno-validator-du-policy               inform               NonCompliant       3h42m
      ztp-install.example1-common-config-policy-pjz9s          enforce              Compliant          167m
      ztp-install.example1-common-subscriptions-policy-zzd9k   enforce              NonCompliant       164m
      ztp-site.example1-config-policy                          inform               NonCompliant       3h42m
      ztp-site.example1-perf-policy                            inform               NonCompliant       3h42m

    2. RHACM Web コンソールからポリシーのステータスを確認するには、次のアクションを実行します。

      1. ガバナンスポリシーの検索 をクリックします。
      2. クラスターポリシーをクリックして、ステータスを確認します。

すべてのクラスターポリシーが準拠すると、クラスターの ZTP のインストールと設定が完了します。ztp-done ラベルがクラスターに追加されます。

参照設定では、準拠する最終的なポリシーは、*-du-validator-policy ポリシーで定義されたものです。このポリシーは、クラスターに準拠する場合、すべてのクラスター設定、Operator のインストール、および Operator 設定が完了します。

17.4.6. 設定ポリシー CR の生成の検証

ポリシーのカスタムリソース (CR) は、作成元の PolicyGenTemplate と同じネームスペースで生成される。以下のコマンドを使用して示すように、ztp-commonztp-group、または ztp-site ベースのいずれであるかにかかわらず、PolicyGenTemplate から生成されたすべてのポリシー CR に同じトラブルシューティングフローが適用されます。

$ export NS=<namespace>
$ oc get policy -n $NS

予想される policy-wraped CR のセットが表示されるはずです。

ポリシーの同期に失敗した場合は、以下のトラブルシューティング手順を使用します。

手順

  1. ポリシーの詳細情報を表示するには、次のコマンドを実行します。

    $ oc describe -n openshift-gitops application policies
  2. Status: Conditions: の有無を確認し、エラーログを表示します。例えば、無効な sourceFile→fileName: を設定すると、以下のようなエラーが発生します。

    Status:
      Conditions:
        Last Transition Time:  2021-11-26T17:21:39Z
        Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1
        Type:  ComparisonError
  3. Status: Sync: をチェックします。Status: Conditions:: でログエラーが発生した場合 Status: Sync:Unknown または Error と表示されます。

    Status:
      Sync:
        Compared To:
          Destination:
            Namespace:  policies-sub
            Server:     https://kubernetes.default.svc
          Source:
            Path:             policies
            Repo URL:         https://git.com/ran-sites/policies/.git
            Target Revision:  master
        Status:               Error
  4. Red Hat Advanced Cluster Management (RHACM) が ManagedCluster オブジェクトにポリシーが適用されることを認識すると、ポリシー CR オブジェクトがクラスターネームスペースに適用されます。ポリシーがクラスターネームスペースにコピーされたかどうかを確認します。

    $ oc get policy -n $CLUSTER

    出力例:

    NAME                                         REMEDIATION ACTION   COMPLIANCE STATE   AGE
    ztp-common.common-config-policy              inform               Compliant          13d
    ztp-common.common-subscriptions-policy       inform               Compliant          13d
    ztp-group.group-du-sno-config-policy         inform               Compliant          13d
    Ztp-group.group-du-sno-validator-du-policy   inform               Compliant          13d
    ztp-site.example-sno-config-policy           inform               Compliant          13d

    RHACM は、適用可能なすべてのポリシーをクラスターの namespace にコピーします。コピーされたポリシー名の形式は <policyGenTemplate.Namespace>.<policyGenTemplate.Name>-<policyName> です。

  5. クラスター namespace にコピーされないポリシーの配置ルールを確認します。これらのポリシーの PlacementRulematchSelectorManagedCluster オブジェクトのラベルと一致する必要があります。

    $ oc get placementrule -n $NS
  6. PlacementRule 名は、以下のコマンドを使用して、不足しているポリシー (common、group、または site) に適した名前であることに注意してください。

    $ oc get placementrule -n $NS <placementRuleName> -o yaml
    • status-decisions にはクラスター名が含まれている必要があります。
    • spec の matchSelector の key-value ペアは、マネージドクラスター上のラベルと一致する必要があります。
  7. 以下のコマンドを使用して、ManagedCluster オブジェクトのラベルを確認します。

    $ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
  8. 以下のコマンドを使用して、準拠しているポリシーを確認します。

    $ oc get policy -n $CLUSTER

    NamespaceOperatorGroup、および Subscription ポリシーが準拠しているが Operator 設定ポリシーが該当しない場合、Operator はマネージドクラスターにインストールされていない可能性があります。このため、スポークに CRD がまだ適用されていないため、Operator 設定ポリシーの適用に失敗します。

17.4.7. ポリシー調整の再開

たとえば、ClusterGroupUpgrade カスタムリソース (CR) がタイムアウトした場合など、予期しないコンプライアンスの問題が発生した場合は、ポリシー調整を再開できます。

手順

  1. ClusterGroupUpgrade CR は、管理クラスターの状態が Ready になった後に Topology Aware Lifecycle Manager によって namespace ztp-install に生成されます。

    $ export CLUSTER=<clusterName>
    $ oc get clustergroupupgrades -n ztp-install $CLUSTER
  2. 予期せぬ問題が発生し、設定されたタイムアウト (デフォルトは 4 時間) 内にポリシーが苦情にならなかった場合、ClusterGroupUpgrade CR のステータスは UpgradeTimedOut と 表示されます。

    $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
  3. UpgradeTimedOut 状態の ClusterGroupUpgrade CR は、1 時間ごとにポリシー照合を自動的に再開します。ポリシーを変更した場合は、既存の ClusterGroupUpgrade CR を削除して再試行をすぐに開始できます。これにより、ポリシーをすぐに調整する新規 ClusterGroupUpgrade CR の自動作成がトリガーされます。

    $ oc delete clustergroupupgrades -n ztp-install $CLUSTER

ClusterGroupUpgrade CR が UpgradeCompleted のステータスで完了し、管理対象のクラスターに ztp-done ラベルが適用されると、PolicyGenTemplate を使用して追加の設定変更を行うことができます。既存の ClusterGroupUpgrade CR を削除しても、TALM は新規 CR を生成しません。

この時点で、ZTP はクラスターとの対話を完了しました。それ以降の対話は更新として扱われ、ポリシーの修復のために新しい ClusterGroupUpgrade CR が作成されます。

関連情報

  • Topology Aware Lifecycle Manager (TALM) を使用して独自の ClusterGroupUpgrade CR を作成する方法は、ClusterGroupUpgrade CR について を参照してください。

17.4.8. ポリシーを使用して適用済みマネージドクラスター CR を変更する

ポリシーを使用して、マネージドクラスターにデプロイされたカスタムリソース (CR) からコンテンツを削除できます。

PolicyGenTemplate CR から作成されたすべての Policy CR は、complianceType フィールドがデフォルトで musthave に設定されています。マネージドクラスター上の CR には指定されたコンテンツがすべて含まれているため、コンテンツが削除されていない musthave ポリシーは依然として準拠しています。この設定では、CR からコンテンツを削除すると、TALM はポリシーからコンテンツを削除しますが、そのコンテンツはマネージドクラスター上の CR からは削除されません。

complianceType フィールドを Mustonlyhave に設定することで、ポリシーはクラスター上の CR がポリシーで指定されている内容と完全に一致するようにします。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • RHACM を実行しているハブクラスターからマネージドクラスターをデプロイしている。
  • ハブクラスターに Topology Aware Lifecycle Manager がインストールされている。

手順

  1. 影響を受ける CR から不要になったコンテンツを削除します。この例では、SriovOperatorConfig CR から disableDrain: false 行が削除されました。

    CR の例:

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      configDaemonNodeSelector:
        "node-role.kubernetes.io/$mcp": ""
      disableDrain: true
      enableInjector: true
      enableOperatorWebhook: true

  2. group-du-sno-ranGen.yaml ファイル内で、影響を受けるポリシーの complianceTypemustonlyhave に変更します。

    サンプル YAML

    # ...
    - fileName: SriovOperatorConfig.yaml
      policyName: "config-policy"
      complianceType: mustonlyhave
    # ...

  3. ClusterGroupUpdates CR を作成し、CR の変更を受け取る必要があるクラスターを指定します。

    ClusterGroupUpdates CR の例

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-remove
      namespace: default
    spec:
      managedPolicies:
        - ztp-group.group-du-sno-config-policy
      enable: false
      clusters:
      - spoke1
      - spoke2
      remediationStrategy:
        maxConcurrency: 2
        timeout: 240
      batchTimeoutAction:

  4. 以下のコマンドを実行して ClusterGroupUpgrade CR を作成します。

    $ oc create -f cgu-remove.yaml
  5. たとえば適切なメンテナンス期間中などに変更を適用する準備が完了したら、次のコマンドを実行して spec.enable フィールドの値を true に変更します。

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \
    --patch '{"spec":{"enable":true}}' --type=merge

検証

  1. 以下のコマンドを実行してポリシーのステータスを確認します。

    $ oc get <kind> <changed_cr_name>

    出力例

    NAMESPACE   NAME                                                   REMEDIATION ACTION   COMPLIANCE STATE   AGE
    default     cgu-ztp-group.group-du-sno-config-policy               enforce                                 17m
    default     ztp-group.group-du-sno-config-policy                   inform               NonCompliant       15h

    ポリシーの COMPLIANCE STATECompliant の場合、CR が更新され、不要なコンテンツが削除されたことを意味します。

  2. マネージドクラスターで次のコマンドを実行して、対象クラスターからポリシーが削除されたことを確認します。

    $ oc get <kind> <changed_cr_name>

    結果がない場合、CR はマネージドクラスターから削除されます。

17.4.9. ZTP インストールの実行内容の表示

Zero touch provisioning (ZTP) は、クラスターの ZTP インストール状況を確認するプロセスを簡素化します。ZTP の状態は、クラスターのインストール、クラスターの設定、ZTP の完了の 3 つのフェーズで推移します。

クラスターインストールフェーズ
クラスターのインストールフェーズは、ManagedCluster CR の ManagedClusterJoined および ManagedClusterAvailable 条件によって示されます。ManagedCluster CR にこの条件がない場合や、条件が False に設定されている場合、クラスターはインストールフェーズに残ります。インストールに関する追加情報は、AgentClusterInstall および ClusterDeployment CR から入手できます。詳細は、Troubleshooting GitOps ZTP を参照してください。
クラスター設定フェーズ
クラスター設定フェーズは、クラスターの ManagedCluster CR に適用される ztp-running ラベルで示されます。
ZTP が完了

クラスターのインストールと設定は、ZTP の実行フェーズで実行されます。これは、ztp-running ラベルを削除し、ManagedCluster CR に ztp-done ラベルを追加することで表示されます。ztp-done ラベルは、設定が適用され、ベースライン DU 設定が完了したことを示しています。

ZTP done 状態への遷移は、Red Hat Advanced Cluster Management (RHACM) のバリデータのインフォームドポリシーの準拠状態が条件となります。このポリシーは、完了したインストールの既存の基準をキャプチャし、マネージドクラスターの ZTP プロビジョニングが完了したときにのみ、準拠した状態に移行することを検証するものです。

バリデータ通知ポリシーは、クラスターの設定が完全に適用され、Operator が初期化を完了したことを確認します。ポリシーは以下を検証します。

  • ターゲット MachineConfigPool には予想されるエントリーが含まれ、更新が完了しました。全ノードが利用可能で、低下することはありません。
  • SR-IOV Operator は、syncStatus: Succeeded の 1 つ以上の SriovNetworkNodeState によって示されているように初期化を完了しています。
  • PTP Operator デーモンセットが存在する。