18.10. 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 にすることができます。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 にすることができます。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 ファイルを使用して、storage.bu ファイルを作成します。

   variant: fcos
   version: 1.3.0
   storage:
     disks:
     - device: /dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0 1
       wipe_table: false
       partitions:
       - label: var-lib-containers
         start_mib: <start_of_partition> 2
         size_mib: <partition_size> 3
     filesystems:
       - path: /var/lib/containers
         device: /dev/disk/by-partlabel/var-lib-containers
         format: xfs
         wipe_filesystem: true
         with_mount_unit: true
         mount_options:
           - defaults
           - prjquota

   1

   ルートディスクを指定します。

   2

   パーティションの開始を MiB 単位で指定します。値が小さすぎるとインストールは失敗します。

   3

   パーティションのサイズを指定します。値が小さすぎると、デプロイメントは失敗します。

2. 次のコマンドを実行して、storage.bu を Ignition ファイルに変換します。

   $ butane storage.bu

   出力例

   {"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0","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"}]}}

3. JSON Pretty Print などのツールを使用して、出力を JSON 形式に変換します。

4. 出力を SiteConfig CR の .spec.clusters.nodes.ignitionConfigOverride フィールドにコピーします。

   例

   [...]
   spec:
     clusters:
       - nodes:
           - ignitionConfigOverride: |
             {
               "ignition": {
                 "version": "3.2.0"
               },
               "storage": {
                 "disks": [
                   {
                     "device": "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0",
                     "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"
                   }
                 ]
               }
             }
   [...]

   注記

   .spec.clusters.nodes.ignitionConfigOverride フィールドが存在しない場合は、作成します。

検証

1. インストール中またはインストール後に、次のコマンドを実行して、ハブクラスターで BareMetalHost オブジェクトにアノテーションが表示されていることを確認します。

   $ oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]

   出力例

   "{\"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\"}]}}"

2. インストール後、シングルノード OpenShift ディスクのステータスを確認します。

   1. 次のコマンドを実行して、シングルノード OpenShift ノードでデバッグセッションを開始します。

      この手順は、<node_name>-debug というデバッグ Pod をインスタンス化します。

      $ oc debug node/my-sno-node

      1. 次のコマンドを実行して、デバッグシェル内で /host をルートディレクトリーとして設定します。

         デバッグ Pod は、Pod 内の /host にホストの root ファイルシステムをマウントします。root ディレクトリーを /host に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。

         # chroot /host

      2. 次のコマンドを実行して、使用可能なすべてのブロックデバイスに関する情報をリスト表示します。

         # lsblk

         出力例

         NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
         sda      8:0    0 446.6G  0 disk
         ├─sda1   8:1    0     1M  0 part
         ├─sda2   8:2    0   127M  0 part
         ├─sda3   8:3    0   384M  0 part /boot
         ├─sda4   8:4    0 243.6G  0 part /var
         │                                /sysroot/ostree/deploy/rhcos/var
         │                                /usr
         │                                /etc
         │                                /
         │                                /sysroot
         └─sda5   8:5    0 202.5G  0 part /var/lib/containers

      3. 次のコマンドを実行して、ファイルシステムのディスク領域の使用状況に関する情報を表示します。

         # df -h

         出力例

         Filesystem      Size  Used Avail Use% Mounted on
         devtmpfs        4.0M     0  4.0M   0% /dev
         tmpfs           126G   84K  126G   1% /dev/shm
         tmpfs            51G   93M   51G   1% /run
         /dev/sda4       244G  5.2G  239G   3% /sysroot
         tmpfs           126G  4.0K  126G   1% /tmp
         /dev/sda5       203G  119G   85G  59% /var/lib/containers
         /dev/sda3       350M  110M  218M  34% /boot
         tmpfs            26G     0   26G   0% /run/user/1000

手順

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