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

手順

1. パフォーマンスモードを設定するには、out/argocd/example/acmpolicygenerator// の acm-group-du-sno-ranGen.yaml 参照ファイルで PerformanceProfile の PolicyGenerator エントリーを以下のように更新します。

   - path: source-crs/PerformanceProfile.yaml
     patches:
       - spec:
           workloadHints:
                realTime: true
                highPowerConsumption: false
                perPodPowerManagement: false

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

手順

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

   - path: source-crs/PerformanceProfile.yaml
     patches:
       - spec:
           workloadHints:
                realTime: true
                highPowerConsumption: true
                perPodPowerManagement: false

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

手順

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

   - path: source-crs/PerformanceProfile.yaml
     patches:
       - spec:
           # ...
           workloadHints:
             realTime: true
             highPowerConsumption: false
             perPodPowerManagement: true
           # ...
           additionalKernelArgs:
             - # ...
             - "cpufreq.default_governor=schedutil" 1

   1

   schedutil ガバナーが推奨されますが、ondemand や powersave などの他のガバナーを使用することもできます。

2. Git で PolicyGenerator 変更をコミットしてから、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/acmpolicygenerator/ の acm-group-du-sno-ranGen.yaml 参照ファイルで、TunedPerformancePatch の PolicyGenerator エントリーを更新します。電力を最大限に節約するには、次の例に示すように max_perf_pct を追加します。

   - path: source-crs/TunedPerformancePatch.yaml
     patches:
       - 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 で PolicyGenerator 変更をコミットしてから、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。

手順

1. 要件に応じて、次の PolicyGenerator 変更を acm-group-du-3node-ranGen.yaml、acm-group-du-sno-ranGen.yaml、または acm-group-du-standard-ranGen.yaml ファイルに適用します。

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

      - path: source-crs/PtpOperatorConfigForEvent.yaml
        patches:
        - metadata:
            name: default
            namespace: openshift-ptp
            annotations:
              ran.openshift.io/ztp-deploy-wave: "10"
          spec:
            daemonNodeSelector:
              node-role.kubernetes.io/$mcp: ""
            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 を policies.manifests に追加します。

      - path: source-crs/PtpConfigSlave.yaml 1
        patches:
        - metadata:
            name: "du-ptp-slave"
          spec:
            recommend:
            - match:
              - nodeLabel: node-role.kubernetes.io/master
              priority: 4
              profile: slave
            profile:
            - name: "slave"
              # This interface must match the hardware in this group
              interface: "ens5f0" 2
              ptp4lOpts: "-2 -s --summary_interval -4" 3
              phc2sysOpts: "-a -r -n 24" 4
              ptpSchedulingPolicy: SCHED_FIFO
              ptpSchedulingPriority: 10
              ptpSettings:
                logReduce: "true"
              ptp4lConf: |
                [global]
                #
                # Default Data Set
                #
                twoStepFlag 1
                slaveOnly 1
                priority1 128
                priority2 128
                domainNumber 24
                #utc_offset 37
                clockClass 255
                clockAccuracy 0xFE
                offsetScaledLogVariance 0xFFFF
                free_running 0
                freq_est_interval 1
                dscp_event 0
                dscp_general 0
                dataset_comparison G.8275.x
                G.8275.defaultDS.localPriority 128
                #
                # Port Data Set
                #
                logAnnounceInterval -3
                logSyncInterval -4
                logMinDelayReqInterval -4
                logMinPdelayReqInterval -4
                announceReceiptTimeout 3
                syncReceiptTimeout 0
                delayAsymmetry 0
                fault_reset_interval -4
                neighborPropDelayThresh 20000000
                masterOnly 0
                G.8275.portDS.localPriority 128
                #
                # Run time options
                #
                assume_two_step 0
                logging_level 6
                path_trace_enabled 0
                follow_up_info 0
                hybrid_e2e 0
                inhibit_multicast_service 0
                net_sync_monitor 0
                tc_spanning_tree 0
                tx_timestamp_timeout 50
                unicast_listen 0
                unicast_master_table 0
                unicast_req_duration 3600
                use_syslog 1
                verbose 0
                summary_interval 0
                kernel_leap 1
                check_fup_sync 0
                clock_class_threshold 7
                #
                # Servo Options
                #
                pi_proportional_const 0.0
                pi_integral_const 0.0
                pi_proportional_scale 0.0
                pi_proportional_exponent -0.3
                pi_proportional_norm_max 0.7
                pi_integral_scale 0.0
                pi_integral_exponent 0.4
                pi_integral_norm_max 0.3
                step_threshold 2.0
                first_step_threshold 0.00002
                max_frequency 900000000
                clock_servo pi
                sanity_freq_limit 200000000
                ntpshm_segment 0
                #
                # Transport options
                #
                transportSpecific 0x0
                ptp_dst_mac 01:1B:19:00:00:00
                p2p_dst_mac 01:80:C2:00:00:0E
                udp_ttl 1
                udp6_scope 0x0E
                uds_address /var/run/ptp4l
                #
                # Default interface options
                #
                clock_type OC
                network_transport L2
                delay_mechanism E2E
                time_stamping hardware
                tsproc_mode filter
                delay_filter moving_median
                delay_filter_length 10
                egressLatency 0
                ingressLatency 0
                boundary_clock_jbod 0
                #
                # Clock description
                #
                productDescription ;;
                revisionData ;;
                manufacturerIdentity 00:00:00
                userDescription ;
                timeSource 0xA0
            ptpClockThreshold: 5
              holdOverTimeout: 30 # seconds
              maxOffsetThreshold: 100  # nano seconds
              minOffsetThreshold: -100

      1

      要件に応じて、PtpConfigMaster.yaml または PtpConfigSlave.yaml を指定できます。acm-group-du-sno-ranGen.yaml または acm-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. 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. 適切な PolicyGenerator CR で、ストレージクラス、永続ボリューム要求、永続ボリューム、およびイメージレジストリー設定を設定します。たとえば、個々のサイトを設定するには、次の YAML を acm-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 で PolicyGenerator 変更をコミットしてから、GitOps ZTP ArgoCD アプリケーションによって監視される Git リポジトリーにプッシュします。