検索

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

download PDF

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

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

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

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

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

関連情報

19.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:v{product-version}.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 に置き換えます。

19.9.3. GitOps ZTP パイプラインへの新規コンテンツの追加

GitOps ZTP サイトジェネレーターコンテナーのソース CR は、RAN 分散ユニット (DU) アプリケーションの重要な機能とノードチューニング設定の一式を提供します。これらは、ZTP でデプロイするクラスターに適用されます。ztp-site-generate コンテナー内の既存のソース CR を追加または変更するには、ztp-site-generate コンテナーを再構築し、通常はハブクラスターに関連付けられた切断されたレジストリーから、ハブクラスターで利用できるようにします。有効な OpenShift Container Platform CR を追加できます。

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

手順

  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.10
    
    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.10-custom-1
  4. ビルドしたコンテナーイメージを非接続レジストリーにプッシュします。以下に例を示します。

    $ podman push localhost/ztp-site-generate-rhel8-custom:v4.10-custom-1 registry.example.com:5000/ztp-site-generate-rhel8-custom:v4.10-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.10-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 が終了するまで待機する必要があります。

関連情報

  • または、パッチファイルを適用する前に、更新された initContainer イメージで argocd-openshift-gitops-patch.json を変更することにより、ArgoCD を使用したハブクラスターの設定 で説明されているように、ArgoCD インスタンスにパッチを適用できます。

19.9.4. バリデーターインフォームポリシーを使用した 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 リポジトリーにコミットし、変更をプッシュします。

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

GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してデプロイされた vRAN クラスターに PTP ファストイベントを設定することができます。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.yamlgroup-du-sno-ranGen.yaml、または group-du-standard-ranGen.yaml ファイルに適用してください。

    1. .sourceFiles に、AMQ トランスポートホストを設定する PtpOperatorConfig CR ファイルを config-policy に追加します。

      - fileName: PtpOperatorConfigForEvent.yaml
        policyName: "config-policy"
    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 高速イベントを新規サイトにデプロイします。

関連情報

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

GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してデプロイされた vRAN クラスターに、ベアメタルハードウェアイベントを設定することができます。

前提条件

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

関連情報

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.