Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

Topology Aware Lifecycle Manager は、GitOps Zero Touch Provisioning (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 では、さまざまな オープンソースコミュニティー機能 も利用できます。

10.11.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}}

ハブテンプレートを使用して、マネージドクラスターに適用される生成済みポリシーにグループとサイトの値を入力することで、ConfigMap CR でクラスターのフリート設定を管理できます。PolicyGenTemplate (PGT) CR のサイトでハブテンプレートを使用すると、サイトごとに PolicyGenTemplate CR を作成する必要がなくなります。

ハードウェアの種類や地域などのユースケースに応じて、フリート内のクラスターをさまざまなカテゴリーにグループ化できます。各クラスターには、そのクラスターが属するグループ (複数可) に対応するラベルが必要です。各グループの設定値を異なる ConfigMap CR で管理する場合、ハブテンプレートを使用してグループ内のすべてのクラスターに変更を適用するには、1 つのグループ PolicyGenTemplate CR のみ必要です。

次の例は、3 つの ConfigMap CR と 1 つの PolicyGenTemplate CR グループを使用して、サイトとグループの両方の設定を、ハードウェアタイプとリージョンごとにグループ化されたクラスターに適用する方法を示しています。

注記

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

前提条件

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

手順

  1. グループとサイトの設定を含む 3 つの ConfigMap CR を作成します。

    1. group-hardware-types-configmap という名前の ConfigMap CR を作成して、ハードウェア固有の設定を保持します。以下に例を示します。 

      apiVersion: v1
kind: ConfigMap
metadata:
  name: group-hardware-types-configmap
  namespace: ztp-group
  annotations:
    argocd.argoproj.io/sync-options: Replace=true
      1 
      
data:
  # SriovNetworkNodePolicy.yaml
  hardware-type-1-sriov-node-policy-pfNames-1: "[\"ens5f0\"]"
  hardware-type-1-sriov-node-policy-pfNames-2: "[\"ens7f0\"]"
  # PerformanceProfile.yaml
  hardware-type-1-cpu-isolated: "2-31,34-63"
  hardware-type-1-cpu-reserved: "0-1,32-33"
  hardware-type-1-hugepages-default: "1G"
  hardware-type-1-hugepages-size: "1G"
  hardware-type-1-hugepages-count: "32"
      1
      argocd.argoproj.io/sync-options アノテーションは、ConfigMap のサイズが 1 MiB より大きい場合にのみ必要です。

    2. group-zones-configmap という名前の ConfigMap CR を作成して、地域設定を保持します。以下に例を示します。 

      apiVersion: v1
kind: ConfigMap
metadata:
  name: group-zones-configmap
  namespace: ztp-group
data:
  # ClusterLogForwarder.yaml
  zone-1-cluster-log-fwd-outputs: "[{\"type\":\"kafka\", \"name\":\"kafka-open\", \"url\":\"tcp://10.46.55.190:9092/test\"}]"
  zone-1-cluster-log-fwd-pipelines: "[{\"inputRefs\":[\"audit\", \"infrastructure\"], \"labels\": {\"label1\": \"test1\", \"label2\": \"test2\", \"label3\": \"test3\", \"label4\": \"test4\"}, \"name\": \"all-to-default\", \"outputRefs\": [\"kafka-open\"]}]"

    3. site-data-configmap という名前の ConfigMap CR を作成して、サイト固有の設定を保持します。以下に例を示します。 

      apiVersion: v1
kind: ConfigMap
metadata:
  name: site-data-configmap
  namespace: ztp-group
data:
  # SriovNetwork.yaml
  du-sno-1-zone-1-sriov-network-vlan-1: "140"
  du-sno-1-zone-1-sriov-network-vlan-2: "150"
    注記

    各 ConfigMap CR は、PolicyGenTemplate CR グループから生成されるポリシーと同じ namespace に配置される必要があります。

  2. Git で ConfigMap CR をコミットし、Argo CD アプリケーションが監視する Git リポジトリーにプッシュします。

  3. ハードウェアタイプとリージョンラベルをクラスターに適用します。次のコマンドは、du-sno-1-zone-1 という名前のシングルクラスターに適用され、"hardware-type": "hardware-type-1" および "group-du-sno-zone": "zone-1" のラベルが選択されます。 

    $ oc patch managedclusters.cluster.open-cluster-management.io/du-sno-1-zone-1 --type merge -p '{"metadata":{"labels":{"hardware-type": "hardware-type-1", "group-du-sno-zone": "zone-1"}}}'

  4. ハブテンプレートを使用して ConfigMap オブジェクトから必要なデータを取得する PolicyGenTemplate CR グループを作成します。例として挙げたこの PolicyGenTemplate CR は、spec.bindingRules の下にリストされているラベルに一致するクラスターのロギング、VLAN ID、NIC、およびパフォーマンスプロファイルを設定します。 

    apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: group-du-sno-pgt
  namespace: ztp-group
spec:
  bindingRules:
    # These policies will correspond to all clusters with these labels
    group-du-sno-zone: "zone-1"
    hardware-type: "hardware-type-1"
  mcp: "master"
  sourceFiles:
    - fileName: ClusterLogForwarder.yaml # wave 10
      policyName: "group-du-sno-cfg-policy"
      spec:
        outputs: '{{hub fromConfigMap "" "group-zones-configmap" (printf "%s-cluster-log-fwd-outputs" (index .ManagedClusterLabels "group-du-sno-zone")) | toLiteral hub}}'
        pipelines: '{{hub fromConfigMap "" "group-zones-configmap" (printf "%s-cluster-log-fwd-pipelines" (index .ManagedClusterLabels "group-du-sno-zone")) | toLiteral hub}}'

    - fileName: PerformanceProfile.yaml # wave 10
      policyName: "group-du-sno-cfg-policy"
      metadata:
        name: openshift-node-performance-profile
      spec:
        additionalKernelArgs:
        - rcupdate.rcu_normal_after_boot=0
        - vfio_pci.enable_sriov=1
        - vfio_pci.disable_idle_d3=1
        - efi=runtime
        cpu:
          isolated: '{{hub fromConfigMap "" "group-hardware-types-configmap" (printf "%s-cpu-isolated" (index .ManagedClusterLabels "hardware-type")) hub}}'
          reserved: '{{hub fromConfigMap "" "group-hardware-types-configmap" (printf "%s-cpu-reserved" (index .ManagedClusterLabels "hardware-type")) hub}}'
        hugepages:
          defaultHugepagesSize: '{{hub fromConfigMap "" "group-hardware-types-configmap" (printf "%s-hugepages-default" (index .ManagedClusterLabels "hardware-type")) hub}}'
          pages:
            - size: '{{hub fromConfigMap "" "group-hardware-types-configmap" (printf "%s-hugepages-size" (index .ManagedClusterLabels "hardware-type")) hub}}'
              count: '{{hub fromConfigMap "" "group-hardware-types-configmap" (printf "%s-hugepages-count" (index .ManagedClusterLabels "hardware-type")) | toInt hub}}'
        realTimeKernel:
          enabled: true

    - fileName: SriovNetwork.yaml # wave 100
      policyName: "group-du-sno-sriov-policy"
      metadata:
        name: sriov-nw-du-fh
      spec:
        resourceName: du_fh
        vlan: '{{hub fromConfigMap "" "site-data-configmap" (printf "%s-sriov-network-vlan-1" .ManagedClusterName) | toInt hub}}'

    - fileName: SriovNetworkNodePolicy.yaml # wave 100
      policyName: "group-du-sno-sriov-policy"
      metadata:
        name: sriov-nnp-du-fh
      spec:
        deviceType: netdevice
        isRdma: false
        nicSelector:
          pfNames: '{{hub fromConfigMap "" "group-hardware-types-configmap" (printf "%s-sriov-node-policy-pfNames-1" (index .ManagedClusterLabels "hardware-type")) | toLiteral hub}}'
        numVfs: 8
        priority: 10
        resourceName: du_fh

    - fileName: SriovNetwork.yaml # wave 100
      policyName: "group-du-sno-sriov-policy"
      metadata:
        name: sriov-nw-du-mh
      spec:
        resourceName: du_mh
        vlan: '{{hub fromConfigMap "" "site-data-configmap" (printf "%s-sriov-network-vlan-2" .ManagedClusterName) | toInt hub}}'

    - fileName: SriovNetworkNodePolicy.yaml # wave 100
      policyName: "group-du-sno-sriov-policy"
      metadata:
        name: sriov-nw-du-fh
      spec:
        deviceType: netdevice
        isRdma: false
        nicSelector:
          pfNames: '{{hub fromConfigMap "" "group-hardware-types-configmap" (printf "%s-sriov-node-policy-pfNames-2" (index .ManagedClusterLabels "hardware-type")) | toLiteral hub}}'
        numVfs: 8
        priority: 10
        resourceName: du_fh
    注記

    サイト固有の設定値を取得するには、.ManagedClusterName フィールドを使用します。これは、ターゲットマネージドクラスターの名前に設定されたテンプレートコンテキスト値です。

    グループ固有の設定を取得するには、.ManagedClusterLabels フィールドを使用します。これは、マネージドクラスターのラベルの値に設定されたテンプレートコンテキスト値です。

  5. サイトの PolicyGenTemplate CR を Git にコミットし、ArgoCD アプリケーションによって監視されている Git リポジトリーにプッシュします。

    注記

    参照された ConfigMap CR に対するその後の変更は、適用されたポリシーに自動的に同期されません。新しい ConfigMap の変更を手動で同期して、既存の PolicyGenTemplate CR を更新する必要があります。「新しい ConfigMap の変更を既存の PolicyGenTemplate CR に同期する」を参照してください。

    複数のクラスターに同じ PolicyGenTemplate CR を使用できます。設定に変更がある場合、各クラスターの設定とマネージドクラスターのラベルを保持する ConfigMap オブジェクトのみ変更する必要があります。

10.11.3. 新しい 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
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る