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

手順

1. 既存のコンテンツのベースラインソース CR を確認します。参考となる PolicyGenTemplate CR に記載されているソース CR を ZTP (zero touch provisioning) コンテナーから抽出し、確認することができます。

   1. /out フォルダーを作成します。

      $ mkdir -p ./out

   2. ソース CR を抽出します。

      $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.11.1 extract /home/ztp --tar | tar x -C ./out

2. ./out/source-crs/PerformanceProfile.yaml にあるベースライン PerformanceProfile CR を確認します。

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: $name
     annotations:
       ran.openshift.io/ztp-deploy-wave: "10"
   spec:
     additionalKernelArgs:
     - "idle=poll"
     - "rcupdate.rcu_normal_after_boot=0"
     cpu:
       isolated: $isolated
       reserved: $reserved
     hugepages:
       defaultHugepagesSize: $defaultHugepagesSize
       pages:
         - size: $size
           count: $count
           node: $node
     machineConfigPoolSelector:
       pools.operator.machineconfiguration.openshift.io/$mcp: ""
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/$mcp: ''
     numa:
       topologyPolicy: "restricted"
     realTimeKernel:
       enabled: true

   注記

   ソース CR のフィールドで $... を含むものは、PolicyGenTemplate CR で提供されない場合、生成された CR から削除されます。

3. group-du-sno-ranGen.yaml リファレンスファイルの PerformanceProfile の PolicyGenTemplate エントリーを更新します。次の例の PolicyGenTemplate CR スタンザは、適切な CPU 仕様を提供し、hugepages 設定を設定し、globallyDisableIrqLoadBalancing を false に設定する新しいフィールドを追加しています。

   - fileName: PerformanceProfile.yaml
     policyName: "config-policy"
     metadata:
       name: openshift-node-performance-profile
     spec:
       cpu:
         # These must be tailored for the specific hardware platform
         isolated: "2-19,22-39"
         reserved: "0-1,20-21"
       hugepages:
         defaultHugepagesSize: 1G
         pages:
           - size: 1G
             count: 10
       globallyDisableIrqLoadBalancing: false

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

手順

1. 更新した ztp-site-generate コンテナーに含めるソース CR YAML ファイルが含まれるディレクトリーを作成します。以下に例を示します。

   ztp-update/
   ├── example-cr1.yaml
   ├── example-cr2.yaml
   └── ztp-update.in

2. 以下の内容を ztp-update.in Containerfile に追加します。

   FROM registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.11
   
   ADD example-cr2.yaml /kustomize/plugin/ran.openshift.io/v1/policygentemplate/source-crs/
   ADD example-cr1.yaml /kustomize/plugin/ran.openshift.io/v1/policygentemplate/source-crs/

3. ztp-update/ フォルダーでターミナルを開き、コンテナーを再ビルドします。

   $ podman build -t ztp-site-generate-rhel8-custom:v4.11-custom-1

4. ビルドしたコンテナーイメージを非接続レジストリーにプッシュします。以下に例を示します。

   $ podman push localhost/ztp-site-generate-rhel8-custom:v4.11-custom-1 registry.example.com:5000/ztp-site-generate-rhel8-custom:v4.11-custom-1

5. ハブクラスターの Argo CD インスタンスにパッチを適用し、新たにビルドされたコンテナーイメージを参照します。

   $ oc patch -n openshift-gitops argocd openshift-gitops --type=json -p '[{"op": "replace", "path":"/spec/repo/initContainers/0/image", "value": "registry.example.com:5000/ztp-site-generate-rhel8-custom:v4.11-custom-1"} ]'

   Argo CD インスタンスにパッチを適用すると、openshift-gitops-repo-server Pod は自動的に再起動します。

検証

1. 新規の openshift-gitops-repo-server Pod の初期化が完了し、以前のリポジトリー Pod が終了していることを確認します。

   $ oc get pods -n openshift-gitops | grep openshift-gitops-repo-server

   出力例

   openshift-gitops-server-7df86f9774-db682          1/1     Running   	     1          28s

   新規の openshift-gitops-repo-server Pod の初期化が完了し、新たに追加されたコンテナーイメージコンテンツが利用可能になる前に以前の Pod が終了するまで待機する必要があります。

手順

1. PolicyGenTemplate CR のすべてのポリシーの評価間隔を設定するには、evaluationInterval を spec フィールドに追加し、適切な compliant 値と noncompliant 値を設定します。以下に例を示します。

   spec:
     evaluationInterval:
       compliant: 30m
       noncompliant: 20s

2. PolicyGenTemplate CR で spec.sourceFiles オブジェクトの評価間隔を設定するには、次の例のように、evaluationInterval を sourceFiles フィールドに追加します。

   spec:
     sourceFiles:
      - fileName: SriovSubscription.yaml
        policyName: "sriov-sub-policy"
        evaluationInterval:
          compliant: never
          noncompliant: 10s

3. PolicyGenTemplate CR ファイルを Git リポジトリーにコミットし、変更をプッシュします。

1. 管理対象クラスターで cluster-admin 権限を持つユーザーとしてログインします。

2. open-cluster-management-agent-addon namespace で実行されている Pod を取得します。以下のコマンドを実行します。

   $ oc get pods -n open-cluster-management-agent-addon

   出力例

   NAME                                         READY   STATUS    RESTARTS        AGE
   config-policy-controller-858b894c68-v4xdb    1/1     Running   22 (5d8h ago)   10d

3. config-policy-controller Pod のログで、適用されたポリシーが予想される間隔で評価されていることを確認します。

   $ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb

   出力例

   2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-config-policy-config"}
   2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-common-compute-1-catalog-policy-config"}

手順

1. ソースファイル validatorCRs/informDuValidator.yaml を含むスタンドアロンの PolicyGenTemplate カスタムリソース (CR) を作成します。スタンドアロン PolicyGenTemplate CR は、各クラスタータイプに 1 つだけ必要です。たとえば、次の CR は、単一ノードの OpenShift クラスターにバリデータ通知ポリシーを適用します。

   単一ノードクラスターバリデータ通知ポリシー CR の例 (group-du-sno-validator-ranGen.yaml)

   apiVersion: ran.openshift.io/v1
   kind: PolicyGenTemplate
   metadata:
     name: "group-du-sno-validator" 1
     namespace: "ztp-group" 2
   spec:
     bindingRules:
       group-du-sno: "" 3
     bindingExcludedRules:
       ztp-done: "" 4
     mcp: "master" 5
     sourceFiles:
       - fileName: validatorCRs/informDuValidator.yaml
         remediationAction: inform 6
         policyName: "du-policy" 7

   1

   PolicyGenTemplates オブジェクトの名前。この名前は、placementBinding、placementRule、および要求された namespace で作成される policy の一部としても使用されます。

   2

   この値は、グループ PolicyGenTemplates で使用される namespace と一致する必要があります。

   3

   bindingRules で定義された group-du-* ラベルは SiteConfig ファイルに存在している必要があります。

   4

   bindingExcludedRules で定義されたラベルは 'ztp-done:' でなければなりません。ztp-done ラベルは、Topology Aware Lifecycle Manager と調整するために使用されます。

   5

   mcp はソースファイル validatorCRs/informDuValidator.yaml で使用される MachineConfigPool オブジェクトを定義する。これは、単一ノードの場合は master であり、標準のクラスターデプロイメントの場合は 3 ノードクラスターデプロイメントおよび worker である必要があります。

   6

   オプション: デフォルト値は inform です。

   7

   この値は、生成された RHACM ポリシーの名前の一部として使用されます。単一ノードの例の生成されたバリデーターポリシーは group-du-sno-validator-du-policy という名前です。

2. PolicyGenTemplate CR ファイルを Git リポジトリーにコミットし、変更をプッシュします。

手順

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"

   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. 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>"