検索

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

download PDF

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

重要

GitOps ZTP での PolicyGenerator リソースの使用は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

注記

PolicyGenerator リソースの詳細は、RHACM Policy Generator のドキュメントを参照してください。

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

基本の GitOps Zero Touch Provisioning (ZTP) パイプライン設定以外のクラスター設定を変更する必要がある場合、次の 3 つのオプションを実行できます。

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

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

9.2.2. PolicyGenerator CR を使用したソース CR コンテンツのオーバーライド

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

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

前提条件

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

手順

  1. 既存のコンテンツのベースラインソース CR を確認します。参照 PolicyGenerator CR にリストされているソース CR を GitOps Zero Touch Provisioning (ZTP) コンテナーから抽出し、確認できます。

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

      $ mkdir -p ./out
    2. ソース CR を抽出します。

      $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.16.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 のフィールドで $... を含むものは、PolicyGenerator CR で提供されない場合、生成された CR から削除されます。

  3. acm-group-du-sno-ranGen.yaml 参照ファイル内の PerformanceProfilePolicyGenerator エントリーを更新します。以下の例の PolicyGenerator CR スタンザは、適切な CPU 仕様を指定し、hugepages を設定して、globallyDisableIrqLoadBalancing を false に設定する新しいフィールドを追加します。

    - path: source-crs/PerformanceProfile.yaml
      patches:
        - spec:
            # These must be tailored for the specific hardware platform
            cpu:
              isolated: "2-19,22-39"
              reserved: "0-1,20-21"
            hugepages:
              defaultHugepagesSize: 1G
              pages:
              - size: 1G
                count: 10
            globallyDisableIrqLoadBalancing: false
  4. Git で PolicyGenerator 変更をコミットし、GitOps ZTP argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。

    出力例

    GitOps ZTP アプリケーションは、生成された PerformanceProfile CR を含む RHACM ポリシーを生成します。その CR の内容は、PolicyGeneratorPerformanceProfile エントリーの metadata および spec 内容をソース 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 ツールが文字列の $ 接頭辞を認識し、関連する PolicyGenerator CR でそのフィールドの値を指定しない場合、そのフィールドは出力 CR から完全に省略されます。

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

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

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

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

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

手順

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

    example
    └── acmpolicygenerator
        ├── 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 ファイルと同じディレクトリーにある必要があります。
  3. 必要な PolicyGenerator CR を更新して、source-crs/custom-crs および source-crs/elasticsearch ディレクトリーに追加したコンテンツへの参照を含めます。以下に例を示します。

    apiVersion: policy.open-cluster-management.io/v1
    kind: PolicyGenerator
    metadata:
        name: group-dev
    placementBindingDefaults:
        name: group-dev-placement-binding
    policyDefaults:
        namespace: ztp-clusters
        placement:
            labelSelector:
                matchExpressions:
                    - key: dev
                      operator: In
                      values:
                        - "true"
        remediationAction: inform
        severity: low
        namespaceSelector:
            exclude:
                - kube-*
            include:
                - '*'
        evaluationInterval:
            compliant: 10m
            noncompliant: 10s
    policies:
        - name: group-dev-group-dev-cluster-log-ns
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: source-crs/ClusterLogNS.yaml
        - name: group-dev-group-dev-cluster-log-operator-group
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: source-crs/ClusterLogOperGroup.yaml
        - name: group-dev-group-dev-cluster-log-sub
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: source-crs/ClusterLogSubscription.yaml
        - name: group-dev-group-dev-lso-ns
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: source-crs/StorageNS.yaml
        - name: group-dev-group-dev-lso-operator-group
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: source-crs/StorageOperGroup.yaml
        - name: group-dev-group-dev-lso-sub
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: source-crs/StorageSubscription.yaml
        - name: group-dev-group-dev-pao-cat-source
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "1"
          manifests:
            - path: source-crs/PaoSubscriptionCatalogSource.yaml
              patches:
                - spec:
                    image: <container_image_url>
        - name: group-dev-group-dev-pao-ns
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: source-crs/PaoSubscriptionNS.yaml
        - name: group-dev-group-dev-pao-sub
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: source-crs/PaoSubscription.yaml
        - name: group-dev-group-dev-elasticsearch-ns
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: elasticsearch/ElasticsearchNS.yaml 1
        - name: group-dev-group-dev-elasticsearch-operator-group
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: elasticsearch/ElasticsearchOperatorGroup.yaml
        - name: group-dev-group-dev-apiserver-config
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: custom-crs/apiserver-config.yaml 2
        - name: group-dev-group-dev-disable-nic-lldp
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: custom-crs/disable-nic-lldp.yaml
    1 2
    /source-crs 親ディレクトリーからのファイルへの相対パスを含めるように、policies.manifests.path を設定します。
  4. Git で PolicyGenerator 変更をコミットしてから、GitOps ZTP Argo CD ポリシーアプリケーションが監視する Git リポジトリーにプッシュします。
  5. 変更された PolicyGenerator を含めるように ClusterGroupUpgrade CR を更新し、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

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

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

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

GitOps Zero Touch Provisioning (ZTP) ポリシージェネレーターは、事前定義されたポリシー評価間隔で ConfigurationPolicy CR ポリシーを生成します。noncompliant 状態のデフォルト値は 10 秒です。compliant 状態のデフォルト値は 10 分です。評価間隔を無効にするには、値を never に設定します。

前提条件

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

手順

  1. PolicyGenerator CR 内のすべてのポリシーの評価間隔を設定するには、evaluationInterval フィールドに適切な compliantnoncompliant 値を設定します。以下に例を示します。

    policyDefaults:
      evaluationInterval:
        compliant: 30m
        noncompliant: 45s
    注記

    また、compliant フィールドと noncompliant フィールドを never に設定して、特定の準拠状態に達した後にポリシーの評価を停止することもできます。

  2. PolicyGenerator CR 内の個々のポリシーオブジェクトの評価間隔を設定するには、evaluationInterval フィールドを追加し、適切な値を設定します。以下に例を示します。

    policies:
      - name: "sriov-sub-policy"
        manifests:
          - path: "SriovSubscription.yaml"
            evaluationInterval:
              compliant: never
              noncompliant: 10s
  3. Git リポジトリー内の PolicyGenerator CR ファイルをコミットし、変更をプッシュします。

検証

マネージドスポーククラスターポリシーが予想される間隔で監視されていることを確認します。

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

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

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

手順

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

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

    apiVersion: policy.open-cluster-management.io/v1
    kind: PolicyGenerator
    metadata:
        name: group-du-sno-validator-latest
    placementBindingDefaults:
        name: group-du-sno-validator-latest-placement-binding
    policyDefaults:
        namespace: ztp-group
        placement:
            labelSelector:
                matchExpressions:
                    - key: du-profile
                      operator: In
                      values:
                        - latest
                    - key: group-du-sno
                      operator: Exists
                    - key: ztp-done
                      operator: DoesNotExist
        remediationAction: inform
        severity: low
        namespaceSelector:
            exclude:
                - kube-*
            include:
                - '*'
        evaluationInterval:
            compliant: 10m
            noncompliant: 10s
    policies:
        - name: group-du-sno-validator-latest-du-policy
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "10000"
          evaluationInterval:
            compliant: 5s
          manifests:
            - path: source-crs/validatorCRs/informDuValidator-MCP-master.yaml

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

9.2.6. PolicyGenerator CR を使用した電源状態の設定

低レイテンシーで高パフォーマンスのエッジデプロイメントでは、C ステートと P ステートを無効にするか制限する必要があります。この設定では、CPU は一定の周波数 (通常は最大ターボ周波数) で実行されます。これにより、CPU が常に最大速度で実行され、高いパフォーマンスと低レイテンシーが実現されます。これにより、ワークロードのレイテンシーが最適化されます。ただし、これは最大の電力消費にもつながり、すべてのワークロードに必要ではない可能性があります。

ワークロードはクリティカルまたは非クリティカルとして分類できます。クリティカルなワークロードでは、高パフォーマンスと低レイテンシーのために C ステートと P ステートの設定を無効にする必要があります。クリティカルでないワークロードでは、C ステートと P ステートの設定を使用して、いくらかのレイテンシーとパフォーマンスを犠牲にします。GitOps Zero Touch Provisioning (ZTP) を使用して、次の 3 つの電源状態を設定できます。

  • 高性能モードは、最大の消費電力で超低遅延を提供します。
  • パフォーマンスモードは、比較的高い電力消費で低遅延を提供します。
  • 省電力は、消費電力の削減と遅延の増加のバランスをとります。

デフォルトの設定は、低遅延のパフォーマンスモードです。

PolicyGenerator カスタムリソース (CR) を使用すると、ztp-site-generate コンテナー内の GitOps プラグインで提供されるベースソース CR の上に追加の設定の詳細をオーバーレイできます。

acm-group-du-sno-ranGen.yamlPolicyGenerator CR に基づいて、参照設定用に生成された PerformanceProfile CR の workloadHints フィールドを更新して、電源状態を設定します。

次の共通の前提条件は、3 つの電源状態すべての設定に適用されます。

前提条件

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

9.2.6.1. PolicyGenerator CR を使用したパフォーマンスモードの設定

この例に従って、acm-group-du-sno-ranGen.yamlPolicyGenerator CR に基づき、参照設定用に生成された PerformanceProfile CR の workloadHints フィールドを更新して、パフォーマンスモードを設定します。

パフォーマンスモードは、比較的高い電力消費で低遅延を提供します。

前提条件

  • 「低遅延および高パフォーマンスのためのホストファームウェアの設定」のガイダンスに従って、パフォーマンス関連の設定で BIOS を設定している。

手順

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

    - path: source-crs/PerformanceProfile.yaml
      patches:
        - spec:
            workloadHints:
                 realTime: true
                 highPowerConsumption: false
                 perPodPowerManagement: false
  2. Git で PolicyGenerator 変更をコミットしてから、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。

9.2.6.2. PolicyGenerator CR を使用した高パフォーマンスモードの設定

この例に従って、acm-group-du-sno-ranGen.yamlPolicyGenerator CR に基づき、参照設定用に生成された PerformanceProfile CR の workloadHints フィールドを更新して、高パフォーマンスモードを設定します。

高パフォーマンスモードは、最大の消費電力で超低遅延を提供します。

前提条件

  • 「低遅延および高パフォーマンスのためのホストファームウェアの設定」のガイダンスに従って、パフォーマンス関連の設定で BIOS を設定している。

手順

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

    - path: source-crs/PerformanceProfile.yaml
      patches:
        - spec:
            workloadHints:
                 realTime: true
                 highPowerConsumption: true
                 perPodPowerManagement: false
  2. Git で PolicyGenerator 変更をコミットしてから、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。

9.2.6.3. PolicyGenerator CR を使用した省電力モードの設定

この例に従って、acm-group-du-sno-ranGen.yamlPolicyGenerator CR に基づき、参照設定用に生成された PerformanceProfile CR の workloadHints フィールドを更新して、省電力モードを設定します。

省電力モードは、消費電力の削減と遅延の増加のバランスをとります。

前提条件

  • BIOS で C ステートと OS 制御の P ステートを有効化している。

手順

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

    - path: source-crs/PerformanceProfile.yaml
      patches:
        - spec:
            # ...
            workloadHints:
              realTime: true
              highPowerConsumption: false
              perPodPowerManagement: true
            # ...
            additionalKernelArgs:
              - # ...
              - "cpufreq.default_governor=schedutil" 1
    1
    schedutil ガバナーが推奨されますが、ondemandpowersave などの他のガバナーを使用することもできます。
  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

予想される出力

  • 省電力モードの intel_pstate=passive

9.2.6.4. 省電力の最大化

最大の CPU 周波数を制限して、最大の電力節約を実現することを推奨します。最大 CPU 周波数を制限せずに重要でないワークロード CPU で C ステートを有効にすると、重要な CPU の周波数が高くなるため、消費電力の節約の多くが無効になります。

sysfs プラグインフィールドを更新し、リファレンス設定の TunedPerformancePatch CR で max_perf_pct に適切な値を設定することで、電力の節約を最大化します。acm-group-du-sno-ranGen.yaml に基づくこの例では、最大 CPU 周波数を制限するための手順を説明します。

前提条件

  • 「PolicyGenerator CR を使用した省電力モードの設定」の説明に従って、省電力モードを設定している。

手順

  1. out/argocd/example/acmpolicygenerator/acm-group-du-sno-ranGen.yaml 参照ファイルで、TunedPerformancePatchPolicyGenerator エントリーを更新します。電力を最大限に節約するには、次の例に示すように 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 リポジトリーにプッシュします。

9.2.7. PolicyGenerator CR を使用した LVM Storage の設定

GitOps Zero Touch Provisioning (ZTP) を使用して、デプロイするマネージドクラスターの論理ボリュームマネージャー (LVM) ストレージを設定できます。

注記

HTTP トランスポートで PTP イベントまたはベアメタルハードウェアイベントを使用する場合、LVM Storage を使用してイベントサブスクリプションを永続化します。

分散ユニットでローカルボリュームを使用する永続ストレージには、Local Storage Operator を使用します。

前提条件

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

手順

  1. 新しいマネージドクラスターの LVM Storage を設定するには、acm-common-ranGen.yaml ファイルの policies.manifests に次の YAML を追加します。

    - name: subscription-policies
      policyAnnotations:
        ran.openshift.io/ztp-deploy-wave: "2"
      manifests:
        - path: source-crs/StorageLVMOSubscriptionNS.yaml
        - path: source-crs/StorageLVMOSubscriptionOperGroup.yaml
        - path: source-crs/StorageLVMOSubscription.yaml
          spec:
            name: lvms-operator
            channel: stable-4.16
    注記

    Storage LVMO サブスクリプションは非推奨になりました。OpenShift Container Platform の将来のリリースでは、ストレージ LVMO サブスクリプションは利用できなくなります。代わりに、Storage LVMS サブスクリプションを使用する必要があります。

    OpenShift Container Platform 4.16 では、LVMO サブスクリプションの代わりに Storage LVMS サブスクリプションを使用できます。LVMS サブスクリプションでは、acm-common-ranGen.yaml ファイルを手動でオーバーライドする必要はありません。Storage LVMS サブスクリプションを使用するには、acm-common-ranGen.yaml ファイルの policies.manifests に次の YAML を追加します。

    - path: source-crs/StorageLVMSubscriptionNS.yaml
    - path: source-crs/StorageLVMSubscriptionOperGroup.yaml
    - path: source-crs/StorageLVMSubscription.yaml
  2. 特定のグループまたは個々のサイト設定ファイルの policies.manifestsLVMCluster CR を追加します。たとえば、acm-group-du-sno-ranGen.yaml ファイルに以下を追加します。

    - fileName: StorageLVMCluster.yaml
      policyName: "lvms-config"
        metadata:
          name: "lvms-storage-cluster-config"
            spec:
              storage:
                deviceClasses:
                - name: vg1
                  thinPoolConfig:
                    name: thin-pool-1
                    sizePercent: 90
                    overprovisionRatio: 10

    この設定例では、OpenShift Container Platform がインストールされているディスクを除く、使用可能なすべてのデバイスを含むボリュームグループ (vg1) を作成します。シンプール論理ボリュームも作成されます。

  3. 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
  4. Git で PolicyGenerator の変更をコミットしてから、その変更をサイト設定リポジトリーにプッシュし、GitOps ZTP を使用して LVM Storage を新しいサイトにデプロイします。

9.2.8. PolicyGenerator 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 のサポートステータス を参照してください。

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

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

前提条件

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

手順

  1. 要件に応じて、次の PolicyGenerator 変更を acm-group-du-3node-ranGen.yamlacm-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 クロックの種類とインターフェイスに linuxptpphc2sys を設定します。たとえば、次の 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.yamlPtpConfigSlave.yaml、または PtpConfigSlaveCvl.yaml のいずれか 1 つを指定できます。PtpConfigSlaveCvl.yaml は、Intel E810 Columbiaville NIC の linuxptp サービスを設定します。acm-group-du-sno-ranGen.yaml または acm-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 高速イベントを新規サイトにデプロイします。

9.2.8.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. AMQP Operator を設定するには、acm-common-ranGen.yaml ファイルの policies.manifests に次の YAML を追加します。

    #AMQ Interconnect Operator for fast events
    - path: source-crs/AmqSubscriptionNS.yaml
    - path: source-crs/AmqSubscriptionOperGroup.yaml
    - path: source-crs/AmqSubscription.yaml
  2. 要件に応じて、次の PolicyGenerator 変更を acm-group-du-3node-ranGen.yamlacm-group-du-sno-ranGen.yaml、または acm-group-du-standard-ranGen.yaml ファイルに適用します。

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

      - 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: "amqp://amq-router.amq-router.svc.cluster.local"
    2. PTP クロックの種類とインターフェイスに linuxptpphc2sys を設定します。たとえば、次の 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.yamlPtpConfigSlave.yaml、または PtpConfigSlaveCvl.yaml のいずれか 1 つを指定できます。PtpConfigSlaveCvl.yaml は、Intel E810 Columbiaville NIC の linuxptp サービスを設定します。acm-group-du-sno-ranGen.yaml または acm-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. 次の PolicyGenerator の変更を特定のサイト YAML ファイル (例: acm-example-sno-site.yaml) に適用します。

    1. policies.manifests で、AMQ ルーターを設定する Interconnect CR ファイルを config-policy に追加します。

      - path: source-crs/AmqInstance.yaml
  4. 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
  5. 変更をサイト設定リポジトリーにプッシュし、GitOps ZTP を使用して PTP 高速イベントを新規サイトにデプロイします。

9.2.9. PolicyGenerator 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 のサポートステータス を参照してください。

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

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

前提条件

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

手順

  1. acm-common-ranGen.yaml ファイルの policies.manifests に次の YAML を追加して、Bare Metal Event Relay Operator を設定します。

    # Bare Metal Event Relay Operator
    - path: source-crs/BareMetalEventRelaySubscriptionNS.yaml
    - path: source-crs/BareMetalEventRelaySubscriptionOperGroup.yaml
    - path: source-crs/BareMetalEventRelaySubscription.yaml
  2. 特定のグループ設定ファイル (たとえば、acm-group-du-sno-ranGen.yaml ファイル) の policies.manifestsHardwareEvent CR を追加します。

    - path: source-crs/HardwareEvent.yaml 1
      patches:
        - spec:
            logLevel: debug
            nodeSelector: {}
            transportHost: http://hw-event-publisher-service.openshift-bare-metal-events.svc.cluster.local:9043
    1
    各ベースボード管理コントローラー (BMC) では、1 つの HardwareEvent CR のみ必要です。
    注記

    OpenShift Container Platform 4.13 以降では、ベアメタルイベントで 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>"

9.2.9.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 を設定するには、acm-common-ranGen.yaml ファイルの policies.manifests に次の YAML を追加します。

    # AMQ Interconnect Operator for fast events
    - path: source-crs/AmqSubscriptionNS.yaml
    - path: source-crs/AmqSubscriptionOperGroup.yaml
    - path: source-crs/AmqSubscription.yaml
    # Bare Metal Event Relay Operator
    - path: source-crs/BareMetalEventRelaySubscriptionNS.yaml
    - path: source-crs/BareMetalEventRelaySubscriptionOperGroup.yaml
    - path: source-crs/BareMetalEventRelaySubscription.yaml
  2. (acm-example-sno-site.yaml などの) サイト設定ファイルの policies.manifestsInterconnect CR を追加します。

    - path: source-crs/AmqInstance.yaml
  3. 特定のグループ設定ファイル (たとえば、acm-group-du-sno-ranGen.yaml ファイル) の policies.manifestsHardwareEvent CR を追加します。

    - path: HardwareEvent.yaml
      patches:
        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 で PolicyGenerator 変更をコミットしてから、その変更をサイト設定リポジトリーにプッシュして、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>"

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

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

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

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

注記

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

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

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

重要

インストール時にこの手順を完了する必要があります。

前提条件

  • Butane をインストールしている。

手順

  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

9.2.10.2. PolicyGenerator CR を使用したイメージレジストリーの設定

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

前提条件

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

手順

  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 リポジトリーにプッシュします。

検証

次の手順を使用して、マネージドクラスターのローカルイメージレジストリーに関するエラーをトラブルシューティングします。

  • マネージドクラスターにログインしているときに、レジストリーへのログインが成功したことを確認します。以下のコマンドを実行します。

    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 は、ディスクが正しくパーティショニングされていることを示します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.