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

PolicyGenTemplate CR を使用して、マネージドクラスターにカスタム機能をデプロイできます。

17.9.1. 追加の変更のクラスターへのデプロイ

GitOps ZTP パイプラインの基本設定以外のクラスター設定の変更が必要な場合、3 つのオプションがあります。

ZTP パイプラインが完了した後に、追加設定を適用します。
GitOps ZTP パイプラインのデプロイが完了すると、デプロイされたクラスターはアプリケーションのワークロードに対応できるようになります。この時点で、Operator を追加インストールし、お客様の要件に応じた設定を適用することができます。追加のコンフィギュレーションがプラットフォームのパフォーマンスや割り当てられた CPU バジェットに悪影響を与えないことを確認する。
追加する、追加 ZTP ライブラリーにコンテンツを追加します。
GitOps ZTP パイプラインでデプロイするベースソースのカスタムリソース (CR) は、必要に応じてカスタムコンテンツで拡張できます。
クラスターインストール用の追加マニフェストの作成
インストール時に余分なマニフェストが適用され、インストール作業を効率化することができます。
重要

追加のソース CR を提供したり、既存のソース CR を変更したりすると、OpenShift Container Platform のパフォーマンスまたは CPU プロファイルに大きな影響を与える可能性があります。

17.9.2. PolicyGenTemplate CR を使用して、ソース CR の内容を上書きする。

PolicyGenTemplate カスタムリソース (CR) を使用すると、ztp-site-generate コンテナーの GitOps プラグインで提供されるベースソース CR の上に追加の設定の詳細をオーバーレイできます。PolicyGenTemplate CR は、ベース CR の論理マージまたはパッチとして解釈できます。PolicyGenTemplate CR を使用して、ベース CR の単一フィールドを更新するか、ベース CR の内容全体をオーバーレイします。ベース CR にない値の更新やフィールドの挿入が可能です。

以下の手順例では、group-du-sno-ranGen.yaml ファイル内の PolicyGenTemplate CR に基づいて、参照設定用に生成された PerformanceProfile CR のフィールドを更新する方法について説明します。この手順を元に、PolicyGenTemplate の 他の部分をお客様のご要望に応じて変更してください。

前提条件

  • カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD のソースリポジトリーとして定義されている必要があります。

手順

  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.12.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 リファレンスファイルの PerformanceProfilePolicyGenTemplate エントリーを更新します。次の例の 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 リポジトリーにプッシュします。

出力例

ZTP アプリケーションは、生成された PerformanceProfile CR を含む RHACM ポリシーを生成します。この CR の内容は, PolicyGenTemplatePerformanceProfile エントリーから metadataspec の内容をソース CR にマージすることで得られるものである.作成される CR には以下のコンテンツが含まれます。

---
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
    name: openshift-node-performance-profile
spec:
    additionalKernelArgs:
        - idle=poll
        - rcupdate.rcu_normal_after_boot=0
    cpu:
        isolated: 2-19,22-39
        reserved: 0-1,20-21
    globallyDisableIrqLoadBalancing: false
    hugepages:
        defaultHugepagesSize: 1G
        pages:
            - count: 10
              size: 1G
    machineConfigPoolSelector:
        pools.operator.machineconfiguration.openshift.io/master: ""
    net:
        userLevelNetworking: true
    nodeSelector:
        node-role.kubernetes.io/master: ""
    numa:
        topologyPolicy: restricted
    realTimeKernel:
        enabled: true
注記

ztp-site-generate コンテナーからデプロイメントした /source-crs フォルダーでは、$ 構文が暗示するテンプレート置換は使用されません。むしろ、policyGen ツールが文字列の $ 接頭辞を認識し、関連する PolicyGenTemplate CR でそのフィールドの値を指定しない場合、そのフィールドは出力 CR から完全に省かれます。

例外として、/source-crs YAML ファイル内の $mcp 変数は、PolicyGenTemplate CR から mcp の 指定値で代用されます。例えば、example/policygentemplates/group-du-standard-ranGen.yaml では、mcp の 値は worker となって います。

spec:
  bindingRules:
    group-du-standard: ""
  mcp: "worker"

policyGen ツールは、$mcp のインスタンスを出力 CR の worker に置き換えます。

17.9.3. GitOps ZTP パイプラインへのカスタムコンテンツの追加

ZTP パイプラインに新しいコンテンツを追加するには、次の手順を実行します。

手順

  1. PolicyGenTemplate カスタムリソース (CR) の kustomization.yaml ファイルが含まれるディレクトリーに、source-crs という名前のサブディレクトリーを作成します。
  2. 以下の例のように、カスタム CR を source-crs サブディレクトリーに追加します。

    example
    └── policygentemplates
        ├── dev.yaml
        ├── kustomization.yaml
        ├── mec-edge-sno1.yaml
        ├── sno.yaml
        └── source-crs 1
            ├── PaoCatalogSource.yaml
            ├── PaoSubscription.yaml
            ├── custom-crs
            |   ├── apiserver-config.yaml
            |   └── disable-nic-lldp.yaml
            └── elasticsearch
                ├── ElasticsearchNS.yaml
                └── ElasticsearchOperatorGroup.yaml
    1
    source-crs サブディレクトリーは、kustomization.yaml ファイルと同じディレクトリーにある必要があります。
    重要

    独自のリソースを使用するには、カスタム CR 名が ZTP コンテナーで提供されるデフォルトのソース CR とは異なることを確認してください。

  3. 必要な PolicyGenTemplate CR を更新して、source-crs/custom-crs および source-crs/elasticsearch ディレクトリーに追加したコンテンツへの参照を含めます。以下に例を示します。

    apiVersion: ran.openshift.io/v1
    kind: PolicyGenTemplate
    metadata:
      name: "group-dev"
      namespace: "ztp-clusters"
    spec:
      bindingRules:
        dev: "true"
      mcp: "master"
      sourceFiles:
        # These policies/CRs come from the internal container Image
        #Cluster Logging
        - fileName: ClusterLogNS.yaml
          remediationAction: inform
          policyName: "group-dev-cluster-log-ns"
        - fileName: ClusterLogOperGroup.yaml
          remediationAction: inform
          policyName: "group-dev-cluster-log-operator-group"
        - fileName: ClusterLogSubscription.yaml
          remediationAction: inform
          policyName: "group-dev-cluster-log-sub"
        #Local Storage Operator
        - fileName: StorageNS.yaml
          remediationAction: inform
          policyName: "group-dev-lso-ns"
        - fileName: StorageOperGroup.yaml
          remediationAction: inform
          policyName: "group-dev-lso-operator-group"
        - fileName: StorageSubscription.yaml
          remediationAction: inform
          policyName: "group-dev-lso-sub"
        #These are custom local polices that come from the source-crs directory in the git repo
        # Performance Addon Operator
        - fileName: PaoSubscriptionNS.yaml
          remediationAction: inform
          policyName: "group-dev-pao-ns"
        - fileName: PaoSubscriptionCatalogSource.yaml
          remediationAction: inform
          policyName: "group-dev-pao-cat-source"
          spec:
            image: <image_URL_here>
        - fileName: PaoSubscription.yaml
          remediationAction: inform
          policyName: "group-dev-pao-sub"
        #Elasticsearch Operator
        - fileName: elasticsearch/ElasticsearchNS.yaml 1
          remediationAction: inform
          policyName: "group-dev-elasticsearch-ns"
        - fileName: elasticsearch/ElasticsearchOperatorGroup.yaml
          remediationAction: inform
          policyName: "group-dev-elasticsearch-operator-group"
        #Custom Resources
        - fileName: custom-crs/apiserver-config.yaml 2
          remediationAction: inform
          policyName: "group-dev-apiserver-config"
        - fileName: custom-crs/disable-nic-lldp.yaml
          remediationAction: inform
          policyName: "group-dev-disable-nic-lldp"
    1 2
    fileName フィールドを設定して、/source-crs 親ディレクトリーからのファイルへの相対パスを追加します。
  4. Git で PolicyGenTemplate の変更をコミットし、GitOps ZTP Argo CD ポリシーアプリケーションが監視する Git リポジトリーにプッシュします。
  5. ClusterGroupUpgrade CR を更新して、変更された PolicyGenTemplate を含め、cgu-test.yaml として保存します。次の例は、生成された cgu-test.yaml ファイルを示しています。

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: custom-source-cr
      namespace: ztp-clusters
    spec:
      managedPolicies:
        - group-dev-config-policy
      enable: true
      clusters:
      - cluster1
      remediationStrategy:
        maxConcurrency: 2
        timeout: 240
  6. 次のコマンドを実行して、更新された ClusterGroupUpgrade CR を適用します。

    $ oc apply -f cgu-test.yaml

検証

  • 次のコマンドを実行して、更新が成功したことを確認します。

    $ oc get cgu -A

    出力例

    NAMESPACE     NAME               AGE   STATE        DETAILS
    ztp-clusters  custom-source-cr   6s    InProgress   Remediating non-compliant policies
    ztp-install   cluster1           19h   Completed    All clusters are compliant with all the managed policies

17.9.4. PolicyGenTemplate CR のポリシーコンプライアンス評価タイムアウトの設定

ハブクラスターにインストールされた Red Hat Advanced Cluster Management (RHACM) を使用して、管理対象クラスターが適用されたポリシーに準拠しているかどうかを監視および報告します。RHACM は、ポリシーテンプレートを使用して、定義済みのポリシーコントローラーとポリシーを適用します。ポリシーコントローラーは Kubernetes のカスタムリソース定義 (CRD) インスタンスです。

デフォルトのポリシー評価間隔は、PolicyGenTemplate カスタムリソース (CR) でオーバーライドできます。RHACM が適用されたクラスターポリシーを再評価する前に、ConfigurationPolicy CR がポリシー準拠または非準拠の状態を維持できる期間を定義する期間設定を設定します。

ゼロタッチプロビジョニング (ZTP) ポリシージェネレーターは、事前定義されたポリシー評価間隔で ConfigurationPolicy CR ポリシーを生成します。noncompliant 状態のデフォルト値は 10 秒です。compliant 状態のデフォルト値は 10 分です。評価間隔を無効にするには、値を never に設定します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • カスタムサイトの設定データを管理する Git リポジトリーを作成しています。

手順

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

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

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

17.9.5. バリデーターインフォームポリシーを使用した ZTP クラスターデプロイメントの完了のシグナリング

デプロイされたクラスターのゼロタッチプロビジョニング (ZTP) のインストールと設定が完了したときに通知するバリデーター通知ポリシーを作成します。このポリシーは、単一ノード OpenShift クラスター、3 ノードクラスター、および標準クラスターのデプロイメントに使用できます。

手順

  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 オブジェクトの名前。この名前は、placementBindingplacementRule、および要求された 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 リポジトリーにコミットし、変更をプッシュします。

17.9.6. PolicyGenTemplate CR を使用した PTP イベントの設定

GitOps ZTP パイプラインを使用して、HTTP または AMQP トランスポートを使用する PTP イベントを設定できます。

注記

HTTP トランスポートは、PTP およびベアメタルイベントのデフォルトのトランスポートです。可能な場合、PTP およびベアメタルイベントには AMQP ではなく HTTP トランスポートを使用してください。AMQ Interconnect は、2024 年 6 月 30 日で EOL になります。AMQ Interconnect の延長ライフサイクルサポート (ELS) は 2029 年 11 月 29 日に終了します。詳細は、Red Hat AMQ Interconnect のサポートステータス を参照してください。

17.9.6.1. HTTP トランスポートを使用する PTP イベントの設定

GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してデプロイしたマネージドクラスター上で、HTTP トランスポートを使用する PTP イベントを設定できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • カスタムサイトの設定データを管理する Git リポジトリーを作成しています。

手順

  1. 要件に応じて、以下の PolicyGenTemplate の変更を group-du-3node-ranGen.yamlgroup-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.12 以降では、PTP イベントに HTTP トランスポートを使用するときに、PtpOperatorConfig リソースの transportHost フィールドを設定する必要はありません。

    2. PTP クロックの種類とインターフェイスに linuxptpphc2sys を設定します。たとえば、以下のスタンザを .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.yamlPtpConfigSlave.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.profileptp4lOpts--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 高速イベントを新規サイトにデプロイします。

17.9.6.2. AMQP トランスポートを使用する PTP イベントの設定

GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してデプロイするマネージドクラスター上で、AMQP トランスポートを使用する PTP イベントを設定できます。

注記

HTTP トランスポートは、PTP およびベアメタルイベントのデフォルトのトランスポートです。可能な場合、PTP およびベアメタルイベントには AMQP ではなく HTTP トランスポートを使用してください。AMQ Interconnect は、2024 年 6 月 30 日で EOL になります。AMQ Interconnect の延長ライフサイクルサポート (ELS) は 2029 年 11 月 29 日に終了します。詳細は、Red Hat AMQ Interconnect のサポートステータス を参照してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • カスタムサイトの設定データを管理する 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.yamlgroup-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 クロックの種類とインターフェイスに linuxptpphc2sys を設定します。たとえば、以下のスタンザを .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.yamlPtpConfigSlave.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.profileptp4lOpts--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 高速イベントを新規サイトにデプロイします。

17.9.7. PolicyGenTemplate CR を使用したベアメタルイベントの設定

GitOps ZTP パイプラインを使用して、HTTP または AMQP トランスポートを使用するベアメタルイベントを設定できます。

注記

HTTP トランスポートは、PTP およびベアメタルイベントのデフォルトのトランスポートです。可能な場合、PTP およびベアメタルイベントには AMQP ではなく HTTP トランスポートを使用してください。AMQ Interconnect は、2024 年 6 月 30 日で EOL になります。AMQ Interconnect の延長ライフサイクルサポート (ELS) は 2029 年 11 月 29 日に終了します。詳細は、Red Hat AMQ Interconnect のサポートステータス を参照してください。

17.9.7.1. HTTP トランスポートを使用するベアメタルイベントの設定

GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してデプロイしたマネージドクラスター上で、HTTP トランスポートを使用するベアメタルイベントを設定できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • カスタムサイトの設定データを管理する Git リポジトリーを作成しています。

手順

  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.12 以降では、ベアメタルイベントで 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>"

17.9.7.2. AMQP トランスポートを使用するベアメタルイベントの設定

GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してデプロイしたマネージドクラスター上で、AMQP トランスポートを使用するベアメタルイベントを設定できます。

注記

HTTP トランスポートは、PTP およびベアメタルイベントのデフォルトのトランスポートです。可能な場合、PTP およびベアメタルイベントには AMQP ではなく HTTP トランスポートを使用してください。AMQ Interconnect は、2024 年 6 月 30 日で EOL になります。AMQ Interconnect の延長ライフサイクルサポート (ELS) は 2029 年 11 月 29 日に終了します。詳細は、Red Hat AMQ Interconnect のサポートステータス を参照してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • カスタムサイトの設定データを管理する Git リポジトリーを作成しています。

手順

  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 namenamespace で設定されます。たとえば、transportHost: "amqp://amq-router.amq-router.svc.cluster.local" では、AMQ Interconnect の namenamespace の両方が 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>"

17.9.8. イメージをローカルにキャッシュするための Image Registry Operator の設定

OpenShift Container Platform は、ローカルレジストリーを使用してイメージのキャッシュを管理します。エッジコンピューティングのユースケースでは、クラスターは集中型のイメージレジストリーと通信するときに帯域幅の制限を受けることが多く、イメージのダウンロード時間が長くなる可能性があります。

初期デプロイメント中はダウンロードに時間がかかることは避けられません。時間の経過とともに、予期しないシャットダウンが発生した場合に CRI-O が /var/lib/containers/storage ディレクトリーを消去するリスクがあります。長いイメージダウンロード時間に対処するために、GitOps ZTP を使用してリモートマネージドクラスター上にローカルイメージレジストリーを作成できます。これは、クラスターがネットワークの遠端にデプロイメントされるエッジコンピューティングシナリオで役立ちます。

GitOps ZTP を使用してローカルイメージレジストリーをセットアップする前に、リモートマネージドクラスターのインストールに使用する SiteConfig CR でディスクパーティショニングを設定する必要があります。インストール後、PolicyGenTemplate CR を使用してローカルイメージレジストリーを設定します。次に、ZTP パイプラインは永続ボリューム (PV) と永続ボリューム要求 (PVC) CR を作成し、imageregistry 設定にパッチを適用します。

注記

ローカルイメージレジストリーは、ユーザーアプリケーションイメージにのみ使用でき、OpenShift Container Platform または Operator Lifecycle Manager Operator イメージには使用できません。

17.9.8.1. SiteConfig を使用したディスクパーティショニングの設定

SiteConfig CR と GitOps ZTP を使用して、マネージドクラスターのディスクパーティショニングを設定します。SiteConfig CR のディスクパーティションの詳細は、基になるディスクと一致する必要があります。

注記

再起動のたびに /dev/sda/dev/sdb などのデバイス名が切り替わらないように、デバイスに永続的な名前を付けます。rootDeviceHints を使用して起動可能なデバイスを選択し、同じデバイスを使用してさらにパーティショニングすることができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • GitOps Zero Touch Provisioning (ZTP) で使用するカスタムサイト設定データを管理する Git リポジトリーを作成している。

手順

  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 です。sizestart の合計値がディスクサイズを超えてはなりません。超えると、インストールが失敗します。
  2. SiteConfig CR を保存し、サイト設定リポジトリーにプッシュします。

ZTP パイプラインは、SiteConfig CR を使用してクラスターをプロビジョニングし、ディスクパーティションを設定します。

17.9.8.2. PolicyGenTemplate CR を使用してイメージレジストリーを設定する

PolicyGenTemplate (PGT) CR を使用して、イメージレジストリーの設定に必要な CR を適用し、imageregistry 設定にパッチを適用します。

前提条件

  • 管理対象クラスターでディスクパーティションを設定しました。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • GitOps Zero Touch Provisioning (ZTP) で使用するカスタムサイト設定データを管理する Git リポジトリーを作成している。

手順

  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. マネージドクラスター名をエクスポートします。

      $ cluster=<managed_cluster_name>
    2. マネージドクラスター kubeconfig の詳細を取得します。

      $ oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster
    3. クラスター kubeconfig をダウンロードしてエクスポートします。

      $ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster
    4. マネージドクラスターからイメージレジストリーへのアクセスを確認します。レジストリーへのアクセスを参照してください。
  • imageregistry.operator.openshift.io グループインスタンスの Config CRD がエラーを報告していないことを確認します。マネージドクラスターにログインしているときに、次のコマンドを実行します。

    $ oc get image.config.openshift.io cluster -o yaml

    出力例

    apiVersion: config.openshift.io/v1
    kind: Image
    metadata:
      annotations:
        include.release.openshift.io/ibm-cloud-managed: "true"
        include.release.openshift.io/self-managed-high-availability: "true"
        include.release.openshift.io/single-node-developer: "true"
        release.openshift.io/create-only: "true"
      creationTimestamp: "2021-10-08T19:02:39Z"
      generation: 5
      name: cluster
      resourceVersion: "688678648"
      uid: 0406521b-39c0-4cda-ba75-873697da75a4
    spec:
      additionalTrustedCA:
        name: acm-ice

  • 管理対象クラスターの PersistentVolumeClaim にデータが入力されていることを確認します。マネージドクラスターにログインしているときに、次のコマンドを実行します。

    $ oc get pv image-registry-sc
  • registry* Pod が実行中であり、openshift-image-registry namespace にあることを確認します。

    $ oc get pods -n openshift-image-registry | grep registry*

    出力例

    cluster-image-registry-operator-68f5c9c589-42cfg   1/1     Running     0          8d
    image-registry-5f8987879-6nx6h                     1/1     Running     0          8d

  • マネージドクラスターのディスクパーティションが正しいことを確認します。

    1. マネージドクラスターへのデバッグシェルを開きます。

      $ oc debug node/sno-1.example.com
    2. lsblk を実行して、ホストディスクパーティションを確認します。

      sh-4.4# lsblk
      NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
      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 336.3G  0 part /sysroot
        `-sda5   8:5    0 100.1G  0 part /var/imageregistry 1
      sdb      8:16   0 446.6G  0 disk
      sr0     11:0    1   104M  0 rom
      1
      /var/imageregistry は、ディスクが正しくパーティショニングされていることを示します。

17.9.9. PolicyGenTemplate CR でのハブテンプレートの使用

Topology Aware Lifecycle Manager は、GitOps ZTP で使用される設定ポリシーで、部分的な Red Hat Advanced Cluster Management (RHACM) ハブクラスターテンプレート機能をサポートします。

ハブ側のクラスターテンプレートを使用すると、ターゲットクラスターに合わせて動的にカスタマイズできる設定ポリシーを定義できます。これにより、設定は似ているが値が異なる多くのクラスターに対して個別のポリシーを作成する必要がなくなります。

重要

ポリシーテンプレートは、ポリシーが定義されている namespace と同じ namespace に制限されています。これは、ハブテンプレートで参照されるオブジェクトを、ポリシーが作成されたのと同じ namespace に作成する必要があることを意味します。

TALM を使用する GitOps ZTP では、次のサポートされているハブテンプレート関数を使用できます。

  • fromConfigmap は、指定された ConfigMap リソースで提供されたデータキーの値を返します。

    注記

    ConfigMap CR には 1 MiB のサイズ制限 があります。ConfigMap CR の有効サイズは、last-applied-configuration アノテーションによってさらに制限されます。last-applied-configuration 制限を回避するには、次のアノテーションをテンプレート ConfigMap に追加します。

    argocd.argoproj.io/sync-options: Replace=true
  • base64enc は、base64 でエンコードされた入力文字列の値を返します
  • base64dec は、base64 でエンコードされた入力文字列のデコードされた値を返します
  • indent は、インデントスペースが追加された入力文字列を返します
  • autoindent は、親テンプレートで使用されているスペースに基づいてインデントスペースを追加した入力文字列を返します。
  • toInt は、入力値の整数値をキャストして返します
  • toBool は入力文字列をブール値に変換し、ブール値を返します

GitOps ZTP では、さまざまな オープンソースコミュニティー機能 も利用できます。

17.9.9.1. ハブテンプレートの例

次のコード例は、有効なハブテンプレートです。これらの各テンプレートは、default namespace で test-config という名前の ConfigMap CR から値を返します。

  • キー common-key を持つ値を返します。

    {{hub fromConfigMap "default" "test-config" "common-key" hub}}
  • .ManagedClusterName フィールドと文字列 -name の連結値を使用して、文字列を返します。

    {{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) hub}}
  • .ManagedClusterName フィールドと文字列 -name の連結値からブール値をキャストして返します。

    {{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) | toBool hub}}
  • .ManagedClusterName フィールドと文字列 -name の連結値から整数値をキャストして返します。

    {{hub (printf "%s-name" .ManagedClusterName) | fromConfigMap "default" "test-config" | toInt hub}}

17.9.9.2. ハブクラスターテンプレートを使用したサイト PolicyGenTemplate CR でのホスト NIC の指定

単一の ConfigMap CR でホスト NIC を管理し、ハブクラスターテンプレートを使用して、クラスターホストに適用される生成されたポリシーにカスタム NIC 値を設定できます。サイト PolicyGenTemplate (PGT) CR でハブクラスターテンプレートを使用すると、サイトごとに複数の単一サイト PGT CR を作成する必要がなくなります。

次の例は、単一の ConfigMap CR を使用してクラスターホスト NIC を管理し、単一の PolicyGenTemplate サイト CR を使用してそれらをポリシーとしてクラスターに適用する方法を示しています。

注記

fromConfigmap 関数を使用する場合、printf 変数はテンプレートリソース data キーフィールドでのみ使用できます。name および namespace フィールドでは使用できません。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • カスタムサイトの設定データを管理する Git リポジトリーを作成しています。リポジトリーはハブクラスターからアクセスでき、GitOps ZTP ArgoCD アプリケーションのソースリポジトリーとして定義されている必要があります。

手順

  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 に同期する」を参照してください。

17.9.9.3. ハブクラスターテンプレートを使用したグループ PolicyGenTemplate CR での VLAN ID の指定

管理対象クラスターの VLAN ID を 1 つの ConfigMap CR で管理し、ハブクラスターテンプレートを使用して、クラスターに適用される生成されたポリシーに VLAN ID を入力できます。

次の例は、単一の ConfigMap CR で VLAN ID を管理し、単一の PolicyGenTemplate グループ CR を使用して個々のクラスターポリシーに適用する方法を示しています。

注記

fromConfigmap 関数を使用する場合、printf 変数はテンプレートリソース data キーフィールドでのみ使用できます。name および namespace フィールドでは使用できません。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • カスタムサイトの設定データを管理する Git リポジトリーを作成しています。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。

手順

  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 に同期する」を参照してください。

17.9.9.4. 新しい ConfigMap の変更を既存の PolicyGenTemplate CR に同期する

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • ハブクラスターテンプレートを使用して ConfigMap CR から情報を取得する 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