10.2. 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. spec.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 を設定します。たとえば、次の YAML を spec.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 # seconds
            maxOffsetThreshold: 100  # nano seconds
            minOffsetThreshold: -100

      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. spec.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 を設定します。たとえば、次の YAML を spec.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 # seconds
            maxOffsetThreshold: 100  # nano seconds
            minOffsetThreshold: -100

      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. spec.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 Relay Operator
   - fileName: BareMetalEventRelaySubscriptionNS.yaml
     policyName: "subscriptions-policy"
   - fileName: BareMetalEventRelaySubscriptionOperGroup.yaml
     policyName: "subscriptions-policy"
   - fileName: BareMetalEventRelaySubscription.yaml
     policyName: "subscriptions-policy"

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

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

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

   - path: HardwareEvent.yaml
     patches:
       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. 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

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

      # chroot /host

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

      # 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

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

      # 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 リポジトリーにプッシュします。