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

手順

1. out/argocd/example/policygentemplates にある group-du-sno-ranGen.yaml 参照ファイルの PerformanceProfile の PolicyGenTemplate エントリーを次のように更新して、パフォーマンスモードを設定します。

   - fileName: PerformanceProfile.yaml
     policyName: "config-policy"
     metadata:
       [...]
     spec:
       [...]
       workloadHints:
            realTime: true
            highPowerConsumption: false
            perPodPowerManagement: false

2. Git で PolicyGenTemplate 変更をコミットし、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。

手順

1. out/argocd/example/policygentemplates にある group-du-sno-ranGen.yaml 参照ファイルの PerformanceProfile の PolicyGenTemplate エントリーを次のように更新して、高パフォーマンスモードを設定します。

   - fileName: PerformanceProfile.yaml
     policyName: "config-policy"
     metadata:
       [...]
     spec:
       [...]
       workloadHints:
            realTime: true
            highPowerConsumption: true
            perPodPowerManagement: false

2. Git で PolicyGenTemplate 変更をコミットし、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。

手順

1. out/argocd/example/policygentemplates にある group-du-sno-ranGen.yaml 参照ファイルの PerformanceProfile の PolicyGenTemplate エントリーを次のように更新して、省電力モードを設定します。追加のカーネル引数オブジェクトを使用して、省電力モード用に CPU ガバナーを設定することを推奨します。

   - fileName: PerformanceProfile.yaml
     policyName: "config-policy"
     metadata:
       [...]
     spec:
       [...]
       workloadHints:
            realTime: true
            highPowerConsumption: false
            perPodPowerManagement: true
       [...]
       additionalKernelArgs:
          - [...]
          - "cpufreq.default_governor=schedutil" 1

   1

   schedutil ガバナーが推奨されますが、使用できる他のガバナーには ondemand と powersave が含まれます。

2. Git で PolicyGenTemplate 変更をコミットし、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。

検証

1. 次のコマンドを使用して、識別されたノードのリストから、デプロイされたクラスター内のワーカーノードを選択します。

   $ oc get nodes

2. 次のコマンドを使用して、ノードにログインします。

   $ oc debug node/<node-name>

   <node-name> を、電源状態を確認するノードの名前に置き換えます。

3. /host をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の /host にホストの root ファイルシステムをマウントします。次の例に示すように、ルートディレクトリーを /host に変更すると、ホストの実行可能パスに含まれるバイナリーを実行できます。

   # chroot /host

4. 次のコマンドを実行して、適用された電源状態を確認します。

   # cat /proc/cmdline

手順

1. out/argocd/example/policygentemplates の group-du-sno-ranGen.yaml 参照ファイルで、TunedPerformancePatch の PolicyGenTemplate エントリーを更新します。電力を最大限に節約するには、次の例に示すように max_perf_pct を追加します。

   - fileName: TunedPerformancePatch.yaml
         policyName: "config-policy"
         spec:
           profile:
             - name: performance-patch
               data: |
                 [...]
                 [sysfs]
                 /sys/devices/system/cpu/intel_pstate/max_perf_pct=<x> 1

   1

   max_perf_pct は、cpufreq ドライバーが設定できる最大周波数を、サポートされている最大 CPU 周波数のパーセンテージとして制御します。この値はすべての CPU に適用されます。サポートされている最大周波数は /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq で確認できます。開始点として、All Cores Turbo 周波数ですべての CPU を制限する割合を使用できます。All Cores Turbo 周波数は、すべてのコアがすべて使用されているときに全コアが実行される周波数です。

   注記

   省電力を最大化するには、より低い値を設定します。max_perf_pct の値を低く設定すると、最大 CPU 周波数が制限されるため、消費電力が削減されますが、パフォーマンスに影響を与える可能性もあります。さまざまな値を試し、システムのパフォーマンスと消費電力を監視して、ユースケースに最適な設定を見つけてください。

2. Git で PolicyGenTemplate 変更をコミットし、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。

手順

1. 要件に応じて、以下の PolicyGenTemplate の変更を group-du-3node-ranGen.yaml、group-du-sno-ranGen.yaml、または group-du-standard-ranGen.yaml ファイルに適用してください。

   1. .sourceFiles に、トランスポートホストを設定する PtpOperatorConfig CR ファイルを追加します。

      - fileName: PtpOperatorConfigForEvent.yaml
        policyName: "config-policy"
        spec:
          daemonNodeSelector: {}
          ptpEventConfig:
            enableEventPublisher: true
            transportHost: http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043

      注記

      OpenShift Container Platform 4.13 以降では、PTP イベントに HTTP トランスポートを使用するときに、PtpOperatorConfig リソースの transportHost フィールドを設定する必要はありません。

   2. PTP クロックの種類とインターフェイスに linuxptp と phc2sys を設定します。たとえば、以下のスタンザを .sourceFiles に追加します。

      - fileName: PtpConfigSlave.yaml 1
        policyName: "config-policy"
        metadata:
          name: "du-ptp-slave"
        spec:
          profile:
          - name: "slave"
            interface: "ens5f1" 2
            ptp4lOpts: "-2 -s --summary_interval -4" 3
            phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 4
          ptpClockThreshold: 5
            holdOverTimeout: 30 #secs
            maxOffsetThreshold: 100  #nano secs
            minOffsetThreshold: -100 #nano secs

      1

      必要に応じて、PtpConfigMaster.yaml、PtpConfigSlave.yaml、または PtpConfigSlaveCvl.yaml のいずれか 1 つを指定できます。PtpConfigSlaveCvl.yaml は、Intel E810 Columbiaville NIC の linuxptp サービスを設定します。group-du-sno-ranGen.yaml および group-du-3node-ranGen.yaml に基づいて設定する場合は、PtpConfigSlave.yaml を使用します。

      2

      デバイス固有のインターフェイス名。

      3

      PTP 高速イベントを有効にするには、.spec.sourceFiles.spec.profile の ptp4lOpts に --summary_interval -4 値を追加する必要があります。

      4

      phc2sysOpts の値が必要です。-m はメッセージを stdout に出力します。linuxptp-daemon DaemonSet はログを解析し、Prometheus メトリックを生成します。

      5

      オプション: ptpClockThreshold スタンザが存在しない場合は、ptpClockThreshold フィールドにデフォルト値が使用されます。スタンザは、デフォルトの ptpClockThreshold 値を示します。ptpClockThreshold 値は、PTP マスタークロックが PTP イベントが発生する前に切断されてからの期間を設定します。holdOverTimeout は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態が FREERUN に変わるまでの時間値 (秒単位) です。maxOffsetThreshold および minOffsetThreshold 設定は、CLOCK_REALTIME (phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4l または phc2sys のオフセット値がこの範囲外の場合、PTP クロックの状態が FREERUN に設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態が LOCKED に設定されます。

2. 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
3. 変更をサイト設定リポジトリーにプッシュし、GitOps ZTP を使用して PTP 高速イベントを新規サイトにデプロイします。

手順

1. common-ranGen.yaml ファイルの .spec.sourceFiles に以下の YAML を追加し、AMQP Operator を設定します。

   #AMQ interconnect operator for fast events
   - fileName: AmqSubscriptionNS.yaml
     policyName: "subscriptions-policy"
   - fileName: AmqSubscriptionOperGroup.yaml
     policyName: "subscriptions-policy"
   - fileName: AmqSubscription.yaml
     policyName: "subscriptions-policy"

2. 要件に応じて、以下の PolicyGenTemplate の変更を group-du-3node-ranGen.yaml、group-du-sno-ranGen.yaml、または group-du-standard-ranGen.yaml ファイルに適用してください。

   1. .sourceFiles に、AMQ トランスポートホストを設定する PtpOperatorConfig CR ファイルを config-policy に追加します。

      - fileName: PtpOperatorConfigForEvent.yaml
        policyName: "config-policy"
        spec:
          daemonNodeSelector: {}
          ptpEventConfig:
            enableEventPublisher: true
            transportHost: "amqp://amq-router.amq-router.svc.cluster.local"

   2. PTP クロックの種類とインターフェイスに linuxptp と phc2sys を設定します。たとえば、以下のスタンザを .sourceFiles に追加します。

      - fileName: PtpConfigSlave.yaml 1
        policyName: "config-policy"
        metadata:
          name: "du-ptp-slave"
        spec:
          profile:
          - name: "slave"
            interface: "ens5f1" 2
            ptp4lOpts: "-2 -s --summary_interval -4" 3
            phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 4
          ptpClockThreshold: 5
            holdOverTimeout: 30 #secs
            maxOffsetThreshold: 100  #nano secs
            minOffsetThreshold: -100 #nano secs

      1

      要件に応じて、PtpConfigMaster.yaml、PtpConfigSlave.yaml、または PtpConfigSlaveCvl.yaml を 1 つ指定できます。PtpConfigSlaveCvl.yaml は、Intel E810 Columbiaville NIC の linuxptp サービスを設定します。group-du-sno-ranGen.yaml および group-du-3node-ranGen.yaml に基づいて設定する場合は、PtpConfigSlave.yaml を使用します。

      2

      デバイス固有のインターフェイス名。

      3

      PTP 高速イベントを有効にするには、.spec.sourceFiles.spec.profile の ptp4lOpts に --summary_interval -4 値を追加する必要があります。

      4

      phc2sysOpts の値が必要です。-m はメッセージを stdout に出力します。linuxptp-daemon DaemonSet はログを解析し、Prometheus メトリックを生成します。

      5

      オプション: ptpClockThreshold スタンザが存在しない場合は、ptpClockThreshold フィールドにデフォルト値が使用されます。スタンザは、デフォルトの ptpClockThreshold 値を示します。ptpClockThreshold 値は、PTP マスタークロックが PTP イベントが発生する前に切断されてからの期間を設定します。holdOverTimeout は、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態が FREERUN に変わるまでの時間値 (秒単位) です。maxOffsetThreshold および minOffsetThreshold 設定は、CLOCK_REALTIME (phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4l または phc2sys のオフセット値がこの範囲外の場合、PTP クロックの状態が FREERUN に設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態が LOCKED に設定されます。

3. 以下の PolicyGenTemplate の変更を、特定のサイトの YAML ファイル (例: example-sno-site.yaml) に適用してください。

   1. .sourceFiles に、AMQ ルーターを設定する Interconnect CR ファイルを config-policy に追加します。

      - fileName: AmqInstance.yaml
        policyName: "config-policy"

4. 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
5. 変更をサイト設定リポジトリーにプッシュし、GitOps ZTP を使用して PTP 高速イベントを新規サイトにデプロイします。

手順

1. 次の YAML を common-ranGen.yaml ファイルの spec.sourceFiles に追加して、Bare Metal Event Relay Operator を設定します。

   # Bare Metal Event Relay operator
   - fileName: BareMetalEventRelaySubscriptionNS.yaml
     policyName: "subscriptions-policy"
   - fileName: BareMetalEventRelaySubscriptionOperGroup.yaml
     policyName: "subscriptions-policy"
   - fileName: BareMetalEventRelaySubscription.yaml
     policyName: "subscriptions-policy"

2. たとえば、group-du-sno-ranGen.yaml ファイルの特定のグループ設定ファイルで、HardwareEvent CR を spec.sourceFiles に追加します。

   - fileName: HardwareEvent.yaml 1
     policyName: "config-policy"
     spec:
       nodeSelector: {}
       transportHost: "http://hw-event-publisher-service.openshift-bare-metal-events.svc.cluster.local:9043"
       logLevel: "info"

   1

   各ベースボード管理コントローラー (BMC) では、1 つの HardwareEvent CR のみ必要です。

   注記

   OpenShift Container Platform 4.13 以降では、ベアメタルイベントで HTTP トランスポートを使用する場合、HardwareEvent カスタムリソース (CR) の TransportHost フィールドを設定する必要はありません。

3. 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
4. 変更をサイト設定リポジトリーにプッシュし、GitOps ZTP を使用してベアメタルイベントを新しいサイトにデプロイします。

5. 次のコマンドを実行して Redfish シークレットを作成します。

   $ oc -n openshift-bare-metal-events create secret generic redfish-basic-auth \
   --from-literal=username=<bmc_username> --from-literal=password=<bmc_password> \
   --from-literal=hostaddr="<bmc_host_ip_addr>"

手順

1. AMQ Interconnect Operator と Bare Metal Event Relay Operator を設定するには、次の YAML を common-ranGen.yaml ファイルの spec.sourceFiles に追加します。

   # AMQ interconnect operator for fast events
   - fileName: AmqSubscriptionNS.yaml
     policyName: "subscriptions-policy"
   - fileName: AmqSubscriptionOperGroup.yaml
     policyName: "subscriptions-policy"
   - fileName: AmqSubscription.yaml
     policyName: "subscriptions-policy"
   # Bare Metal Event Rely operator
   - fileName: BareMetalEventRelaySubscriptionNS.yaml
     policyName: "subscriptions-policy"
   - fileName: BareMetalEventRelaySubscriptionOperGroup.yaml
     policyName: "subscriptions-policy"
   - fileName: BareMetalEventRelaySubscription.yaml
     policyName: "subscriptions-policy"

2. Interconnect CR をサイト設定ファイルの .spec.sourceFiles (example-sno-site.yaml ファイルなど) に追加します。

   - fileName: AmqInstance.yaml
     policyName: "config-policy"

3. たとえば、group-du-sno-ranGen.yaml ファイルの特定のグループ設定ファイルで、HardwareEvent CR を spec.sourceFiles に追加します。

   - fileName: HardwareEvent.yaml
     policyName: "config-policy"
     spec:
       nodeSelector: {}
       transportHost: "amqp://<amq_interconnect_name>.<amq_interconnect_namespace>.svc.cluster.local" 1
       logLevel: "info"

   1

   transportHost URL は、既存の AMQ Interconnect CR name と namespace で設定されます。たとえば、transportHost: "amqp://amq-router.amq-router.svc.cluster.local" では、AMQ Interconnect の name と namespace の両方が amq-router に設定されます。

   注記

   各ベースボード管理コントローラー (BMC) には、単一の HardwareEvent リソースのみが必要です。

4. Git で PolicyGenTemplate の変更をコミットし、その変更をサイト設定リポジトリーにプッシュして、GitOps ZTP を使用してベアメタルイベント監視を新しいサイトにデプロイします。

5. 次のコマンドを実行して Redfish シークレットを作成します。

   $ oc -n openshift-bare-metal-events create secret generic redfish-basic-auth \
   --from-literal=username=<bmc_username> --from-literal=password=<bmc_password> \
   --from-literal=hostaddr="<bmc_host_ip_addr>"

手順

1. ホストディスクのパーティショニングを記述する次の YAML を、マネージドクラスターのインストールに使用する SiteConfig CR に追加します。

   nodes:
       rootDeviceHints:
         wwn: "0x62cea7f05c98c2002708a0a22ff480ea"
       diskPartition:
         - device: /dev/disk/by-id/wwn-0x62cea7f05c98c2002708a0a22ff480ea 1
           partitions:
             - mount_point: /var/imageregistry
               size: 102500 2
               start: 344844 3

   1

   この設定は、ハードウェアによって異なります。設定には、シリアル番号またはデバイス名を指定できます。この値は、rootDeviceHints に設定された値と一致する必要があります。

   2

   size の最小値は 102500 MiB です。

   3

   start の最小値は 25000 MiB です。size と start の合計値がディスクサイズを超えてはなりません。超えると、インストールが失敗します。

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

手順

1. 適切な PolicyGenTemplate CR で、ストレージクラス、永続ボリューム要求、永続ボリューム、およびイメージレジストリー設定を設定します。たとえば、個々のサイトを設定するには、次の YAML をファイル example-sno-site.yaml に追加します。

   sourceFiles:
     # storage class
     - fileName: StorageClass.yaml
       policyName: "sc-for-image-registry"
       metadata:
         name: image-registry-sc
         annotations:
           ran.openshift.io/ztp-deploy-wave: "100" 1
     # persistent volume claim
     - fileName: StoragePVC.yaml
       policyName: "pvc-for-image-registry"
       metadata:
         name: image-registry-pvc
         namespace: openshift-image-registry
         annotations:
           ran.openshift.io/ztp-deploy-wave: "100"
       spec:
         accessModes:
           - ReadWriteMany
         resources:
           requests:
             storage: 100Gi
         storageClassName: image-registry-sc
         volumeMode: Filesystem
     # persistent volume
     - fileName: ImageRegistryPV.yaml 2
       policyName: "pv-for-image-registry"
       metadata:
         annotations:
           ran.openshift.io/ztp-deploy-wave: "100"
     - fileName: ImageRegistryConfig.yaml
       policyName: "config-for-image-registry"
       complianceType: musthave
       metadata:
         annotations:
           ran.openshift.io/ztp-deploy-wave: "100"
       spec:
         storage:
           pvc:
             claim: "image-registry-pvc"

   1

   サイト、共通、またはグループレベルでイメージレジストリーを設定するかどうかに応じて、ztp-deploy-wave に適切な値を設定します。ztp-deploy-wave: "100" は、参照されるソースファイルをグループ化できるため、開発またはテストに適しています。

   2

   ImageRegistryPV.yaml で、spec.local.path フィールドが /var/imageregistry に設定され、SiteConfig CR の mount_point フィールドに設定された値と一致することを確認します。

   重要

   - fileName: ImageRegistryConfig.yaml 設定には、complianceType: mustonlyhave を設定しないでください。これにより、レジストリー Pod のデプロイが失敗する可能性があります。

2. Git で PolicyGenTemplate 変更をコミットし、GitOps ZTP ArgoCD アプリケーションによって監視される Git リポジトリーにプッシュします。

手順

1. ホストのグループの NIC を記述する ConfigMap リソースを作成します。以下に例を示します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: sriovdata
     namespace: ztp-site
     annotations:
       argocd.argoproj.io/sync-options: Replace=true 1
   data:
     example-sno-du_fh-numVfs: "8"
     example-sno-du_fh-pf: ens1f0
     example-sno-du_fh-priority: "10"
     example-sno-du_fh-vlan: "140"
     example-sno-du_mh-numVfs: "8"
     example-sno-du_mh-pf: ens3f0
     example-sno-du_mh-priority: "10"
     example-sno-du_mh-vlan: "150"

   1

   argocd.argoproj.io/sync-options アノテーションは、ConfigMap のサイズが 1 MiB より大きい場合にのみ必要です。

   注記

   ConfigMap は、ハブテンプレートの置換を持つポリシーと同じ namespace にある必要があります。

2. Git で ConfigMap CR をコミットし、Argo CD アプリケーションによって監視されている Git リポジトリーにプッシュします。

3. テンプレートを使用して ConfigMap オブジェクトから必要なデータを取得するサイト PGT CR を作成します。以下に例を示します。

   apiVersion: ran.openshift.io/v1
   kind: PolicyGenTemplate
   metadata:
     name: "site"
     namespace: "ztp-site"
   spec:
     remediationAction: inform
     bindingRules:
       group-du-sno: ""
     mcp: "master"
     sourceFiles:
       - fileName: SriovNetwork.yaml
         policyName: "config-policy"
         metadata:
           name: "sriov-nw-du-fh"
         spec:
           resourceName: du_fh
           vlan: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-vlan" .ManagedClusterName) | toInt hub}}'
       - fileName: SriovNetworkNodePolicy.yaml
         policyName: "config-policy"
         metadata:
           name: "sriov-nnp-du-fh"
         spec:
           deviceType: netdevice
           isRdma: true
           nicSelector:
             pfNames:
             - '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-pf" .ManagedClusterName) | autoindent hub}}'
           numVfs: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-numVfs" .ManagedClusterName) | toInt hub}}'
           priority: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-priority" .ManagedClusterName) | toInt hub}}'
           resourceName: du_fh
       - fileName: SriovNetwork.yaml
         policyName: "config-policy"
         metadata:
           name: "sriov-nw-du-mh"
         spec:
           resourceName: du_mh
           vlan: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-vlan" .ManagedClusterName) | toInt hub}}'
       - fileName: SriovNetworkNodePolicy.yaml
         policyName: "config-policy"
         metadata:
           name: "sriov-nnp-du-mh"
         spec:
           deviceType: vfio-pci
           isRdma: false
           nicSelector:
             pfNames:
             - '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-pf" .ManagedClusterName)  hub}}'
           numVfs: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-numVfs" .ManagedClusterName) | toInt hub}}'
           priority: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-priority" .ManagedClusterName) | toInt hub}}'
           resourceName: du_mh

4. サイトの PolicyGenTemplate CR を Git にコミットし、ArgoCD アプリケーションによって監視されている Git リポジトリーにプッシュします。

   注記

   参照された ConfigMap CR に対するその後の変更は、適用されたポリシーに自動的に同期されません。新しい ConfigMap の変更を手動で同期して、既存の PolicyGenTemplate CR を更新する必要があります。「新しい ConfigMap の変更を既存の PolicyGenTemplate CR に同期する」を参照してください。

手順

1. クラスターホストのグループの VLAN ID を記述する ConfigMap CR を作成します。以下に例を示します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: site-data
     namespace: ztp-group
     annotations:
       argocd.argoproj.io/sync-options: Replace=true 1
   data:
     site-1-vlan: "101"
     site-2-vlan: "234"

   1

   argocd.argoproj.io/sync-options アノテーションは、ConfigMap のサイズが 1 MiB より大きい場合にのみ必要です。

   注記

   ConfigMap は、ハブテンプレートの置換を持つポリシーと同じ namespace にある必要があります。

2. Git で ConfigMap CR をコミットし、Argo CD アプリケーションによって監視されている Git リポジトリーにプッシュします。

3. ハブテンプレートを使用して ConfigMap オブジェクトから必要な VLAN ID を取得するグループ PGT CR を作成します。たとえば、次の YAML スニペットをグループ PGT CR に追加します。

   - fileName: SriovNetwork.yaml
       policyName: "config-policy"
       metadata:
         name: "sriov-nw-du-mh"
         annotations:
           ran.openshift.io/ztp-deploy-wave: "10"
       spec:
         resourceName: du_mh
         vlan: '{{hub fromConfigMap "" "site-data" (printf "%s-vlan" .ManagedClusterName) | toInt hub}}'

4. グループ PolicyGenTemplate CR を Git でコミットしてから、Argo CD アプリケーションによって監視されている Git リポジトリーにプッシュします。

   注記

   参照された ConfigMap CR に対するその後の変更は、適用されたポリシーに自動的に同期されません。新しい ConfigMap の変更を手動で同期して、既存の PolicyGenTemplate CR を更新する必要があります。「新しい ConfigMap の変更を既存の PolicyGenTemplate CR に同期する」を参照してください。

手順

1. ConfigMap CR の内容を更新し、変更をハブクラスターに適用します。

2. 更新された ConfigMap CR の内容をデプロイされたポリシーに同期するには、次のいずれかを実行します。

   1. オプション 1: 既存のポリシーを削除します。ArgoCD は PolicyGenTemplate CR を使用して、削除されたポリシーをすぐに再作成します。たとえば、以下のコマンドを実行します。

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

   2. オプション 2: ConfigMap を更新するたびに、特別なアノテーション policy.open-cluster-management.io/trigger-update を異なる値でポリシーに適用します。以下に例を示します。

      $ oc annotate policy <policy_name> -n <policy_namespace> policy.open-cluster-management.io/trigger-update="1"

      注記

      変更を有効にするには、更新されたポリシーを適用する必要があります。詳細については、再処理のための特別なアノテーション を参照してください。

3. オプション: 存在する場合は、ポリシーを含む ClusterGroupUpdate CR を削除します。以下に例を示します。

   $ oc delete clustergroupupgrade <cgu_name> -n <cgu_namespace>

   1. 更新された ConfigMap の変更を適用するポリシーを含む新しい ClusterGroupUpdate CR を作成します。たとえば、次の YAML をファイル cgr-example.yaml に追加します。

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: <cgr_name>
        namespace: <policy_namespace>
      spec:
        managedPolicies:
          - <managed_policy>
        enable: true
        clusters:
        - <managed_cluster_1>
        - <managed_cluster_2>
        remediationStrategy:
          maxConcurrency: 2
          timeout: 240

   2. 更新されたポリシーを適用します。

      $ oc apply -f cgr-example.yaml