検索

第9章 PolicyGenerator リソースを使用したクラスターポリシーの管理

download PDF

9.1. PolicyGenerator リソースを使用したマネージドクラスターポリシーの設定

適用された Policy カスタムリソース (CR) は、プロビジョニングするマネージドクラスターを設定します。Red Hat Advanced Cluster Management (RHACM) が PolicyGenerator CR を使用して、適用される Policy CR を生成する方法をカスタマイズできます。

重要

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

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

注記

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

9.1.1. RHACM PolicyGenerator と PolicyGenTemplate リソースのパッチ適用の比較

PolicyGenerator カスタムリソース (CR) と PolicyGenTemplate CR を GitOps ZTP で使用して、マネージドクラスターの RHACM ポリシーを生成できます

GitOps ZTP を使用して OpenShift Container Platform リソースにパッチを適用する場合、PolicyGenTemplate CR よりも PolicyGenerator CR を使用する方が利点があります。RHACM PolicyGenerator API を使用すると、PolicyGenTemplate リソースでは不可能な、リソースにパッチを適用する一般的な方法が提供されます。

PolicyGenerator API は、Open Cluster Management 標準の一部ですが、PolicyGenTemplate API はその一部ではありません。次の表では、PolicyGeneratorPolicyGenTemplate リソースのパッチ適用および配置ストラテジーの比較を説明します。

重要

PolicyGenTemplate CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator CR を使用する場合に利用できます。

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

表9.1 RHACM PolicyGenerator と PolicyGenTemplate のパッチ適用の比較
PolicyGenerator のパッチ適用PolicyGenTemplate のパッチ適用

リソースのマージには Kustomize ストラテジーマージを使用します。詳細は、Kustomize を使用した Kubernetes オブジェクトの宣言的管理 を参照してください。

変数をパッチで定義された値に置き換えることによって機能します。これは Kustomize マージストラテジーよりも柔軟性が低くなります。

ManagedClusterSet および Binding リソースをサポートします。

ManagedClusterSet および Binding リソースはサポートされません。

パッチ適用のみに依存し、埋め込み変数の置換は必要ありません。

パッチで定義された変数値を上書きします。

マージパッチ内のリストのマージはサポートされません。マージパッチ内のリストの置き換えはサポートされています。

リストのマージと置換は制限付きでサポートされており、リスト内の 1 つのオブジェクトのみをマージできます。

現在、リソースのパッチ適用に OpenAPI 仕様 はサポートされていません。つまり、PtpConfig リソースなど、スキーマに従わないコンテンツをマージするには、パッチに追加のディレクティブが必要になります。

フィールドと値をパッチで定義された値に置き換えることによって機能します。

スキーマに従わないコンテンツをマージするには、パッチ内で $patch: replace などの追加のディレクティブが必要です。

ソース CR で定義されたフィールドと値を、パッチで定義された値 (例: $name) に置き換えます。

参照ソース CR で定義された NameNamespace フィールドにパッチを適用できますが、CR ファイルにシングルオブジェクトがある場合に限られます。

参照ソース CR で定義された NameNamespace フィールドにパッチを適用できます。

9.1.2. PolicyGenerator CRD について

PolicyGenerator カスタムリソース定義 (CRD) は、PolicyGen ポリシージェネレーターに、クラスター設定に含めるカスタムリソース (CR)、生成されたポリシーに CR を統合する方法、およびオーバーレイコンテンツで更新する必要がある CR 内の項目を指示します。

次の例は、ztp-site-generate 参照コンテナーから抽出された PolicyGenerator CR (acm-common-du-ranGen.yaml) を示しています。acm-common-du-ranGen.yaml ファイルは、2 つの Red Hat Advanced Cluster Management (RHACM) ポリシーを定義します。ポリシーは、CR 内の policyName の一意の値ごとに 1 つずつ、設定 CR のコレクションを管理します。acm-common-du-ranGen.yaml は、policyDefaults.placement.labelSelector セクションにリストされているラベルに基づいて、ポリシーをクラスターにバインドするための単一の配置バインディングと配置ルールを作成します。

PolicyGenerator CR の例 - acm-common-ranGen.yaml

apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
    name: common-latest
placementBindingDefaults:
    name: common-latest-placement-binding 1
policyDefaults:
    namespace: ztp-common
    placement:
        labelSelector:
            matchExpressions:
                - key: common
                  operator: In
                  values:
                    - "true"
                - key: du-profile
                  operator: In
                  values:
                    - latest
    remediationAction: inform
    severity: low
    namespaceSelector:
        exclude:
            - kube-*
        include:
            - '*'
    evaluationInterval:
        compliant: 10m
        noncompliant: 10s
policies:
    - name: common-latest-config-policy
      policyAnnotations:
        ran.openshift.io/ztp-deploy-wave: "1"
      manifests:
        - path: source-crs/ReduceMonitoringFootprint.yaml
        - path: source-crs/DefaultCatsrc.yaml 2
          patches:
            - metadata:
                name: redhat-operators-disconnected
              spec:
                displayName: disconnected-redhat-operators
                image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.9
        - path: source-crs/DisconnectedICSP.yaml
          patches:
            - spec:
                repositoryDigestMirrors:
                    - mirrors:
                        - registry.example.com:5000
                      source: registry.redhat.io
    - name: common-latest-subscriptions-policy
      policyAnnotations:
        ran.openshift.io/ztp-deploy-wave: "2"
      manifests: 3
        - path: source-crs/SriovSubscriptionNS.yaml
        - path: source-crs/SriovSubscriptionOperGroup.yaml
        - path: source-crs/SriovSubscription.yaml
        - path: source-crs/SriovOperatorStatus.yaml
        - path: source-crs/PtpSubscriptionNS.yaml
        - path: source-crs/PtpSubscriptionOperGroup.yaml
        - path: source-crs/PtpSubscription.yaml
        - path: source-crs/PtpOperatorStatus.yaml
        - path: source-crs/ClusterLogNS.yaml
        - path: source-crs/ClusterLogOperGroup.yaml
        - path: source-crs/ClusterLogSubscription.yaml
        - path: source-crs/ClusterLogOperatorStatus.yaml
        - path: source-crs/StorageNS.yaml
        - path: source-crs/StorageOperGroup.yaml
        - path: source-crs/StorageSubscription.yaml
        - path: source-crs/StorageOperatorStatus.yaml

1
このラベルを持つすべてのクラスターにポリシーを適用します。
2
DefaultCatsrc.yaml ファイルには、非接続レジストリーのカタログソースと関連するレジストリー設定の詳細が含まれています。
3
policies.manifests の下にリストされているファイルは、インストールされたクラスターの Operator ポリシーを作成します。

PolicyGenerator CR は、任意の数の CR を含めて構築できます。次の例の CR をハブクラスターに適用して、単一の CR を含むポリシーを生成します。

apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
  name: group-du-sno
placementBindingDefaults:
  name: group-du-sno-placement-binding
policyDefaults:
  namespace: ztp-group
  placement:
    labelSelector:
      matchExpressions:
        - key: group-du-sno
          operator: Exists
  remediationAction: inform
  severity: low
  namespaceSelector:
    exclude:
      - kube-*
    include:
      - '*'
  evaluationInterval:
    compliant: 10m
    noncompliant: 10s
policies:
  - name: group-du-sno-config-policy
    policyAnnotations:
      ran.openshift.io/ztp-deploy-wave: '10'
    manifests:
      - path: source-crs/PtpConfigSlave-MCP-master.yaml
        patches:
          - metadata: null
            name: du-ptp-slave
            namespace: openshift-ptp
            annotations:
              ran.openshift.io/ztp-deploy-wave: '10'
            spec:
              profile:
                - name: slave
                  interface: $interface
                  ptp4lOpts: '-2 -s'
                  phc2sysOpts: '-a -r -n 24'
                  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
              recommend:
                - profile: slave
                  priority: 4
                  match:
                    - nodeLabel: node-role.kubernetes.io/master

ソースファイル PtpConfigSlave.yaml を例として使用すると、ファイルは PtpConfig CR を定義します。PtpConfigSlave サンプルの生成ポリシーは group-du-sno-config-policy という名前です。生成された group-du-sno-config-policy に定義される PtpConfig CR は du-ptp-slave という名前です。PtpConfigSlave.yaml で定義された spec は、du-ptp-slave の下に、ソースファイルで定義された他の spec 項目と共に配置されます。

次の例は、group-du-sno-config-policy CR を示しています。

---
apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
    name: du-upgrade
placementBindingDefaults:
    name: du-upgrade-placement-binding
policyDefaults:
    namespace: ztp-group-du-sno
    placement:
        labelSelector:
            matchExpressions:
                - key: group-du-sno
                  operator: Exists
    remediationAction: inform
    severity: low
    namespaceSelector:
        exclude:
            - kube-*
        include:
            - '*'
    evaluationInterval:
        compliant: 10m
        noncompliant: 10s
policies:
    - name: du-upgrade-operator-catsrc-policy
      policyAnnotations:
        ran.openshift.io/ztp-deploy-wave: "1"
      manifests:
        - path: source-crs/DefaultCatsrc.yaml
          patches:
            - metadata:
                name: redhat-operators
              spec:
                displayName: Red Hat Operators Catalog
                image: registry.example.com:5000/olm/redhat-operators:v4.14
                updateStrategy:
                    registryPoll:
                        interval: 1h
              status:
                connectionState:
                    lastObservedState: READY

9.1.3. PolicyGenerator CR をカスタマイズする際の推奨事項

サイト設定の PolicyGenerator カスタムリソース (CR) をカスタマイズするときは、以下のベストプラクティスを考慮してください。

  • 必要な数のポリシーを使用します。使用するポリシーが少ないほど、必要なリソースが少なくなります。追加のポリシーごとに、ハブクラスターとデプロイされたマネージドクラスターの CPU 負荷が増加します。CR は PolicyGenerator CR の policyName フィールドに基づいてポリシーに統合されます。同じ PolicyGenerator 内で policyName の値が同じ CR は、シングルポリシーで管理されます。
  • 非接続環境では、すべての Operator を含む単一のインデックスとしてレジストリーを設定することにより、すべての Operator に対して単一のカタログソースを使用します。マネージドクラスターに CatalogSource CR を追加するたびに、CPU 使用率が増加します。
  • MachineConfig CR は、インストール時に適用されるように SiteConfig CR に extraManifests として組み込む必要があります。これにより、クラスターがアプリケーションをデプロイする準備ができるまで全体的な時間がかかる可能性があります。
  • PolicyGenerator CR は、チャネルフィールドをオーバーライドして、目的のバージョンを明示的に識別する必要があります。これにより、アップグレード時にソース CR が変更されても、生成されたサブスクリプションが更新されないようになります。

関連情報

注記

ハブクラスターで多数のスポーククラスターを管理する場合は、ポリシーの数を最小限に抑えてリソースの消費を減らします。

複数のコンフィギュレーション CR を 1 つまたは限られた数のポリシーにグループ化することは、ハブクラスター上のポリシーの総数を減らすための 1 つの方法です。サイト設定の管理に共通、グループ、サイトというポリシーの階層を使用する場合は、サイト固有の設定を 1 つのポリシーにまとめることが特に重要である。

9.1.4. RAN デプロイメント用の PolicyGenerator CR

PolicyGenerator カスタムリソース (CR) を使用し、GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してクラスターに適用される設定をカスタマイズします。PolicyGenerator CR を使用すると、クラスター群の設定 CR のセットを管理するための 1 つ以上のポリシーを生成できます。PolicyGenerator CR は、マネージド CR のセットを識別し、それらをポリシーにバンドルして、それらの CR をラップするポリシーをビルドし、ラベルバインディングルールを使用してポリシーをクラスターに関連付けます。

GitOps ZTP コンテナーから取得した参照設定は、RAN (Radio Access Network) 分散ユニット (DU) アプリケーションに典型的な厳しいパフォーマンスとリソース利用制約をクラスターが確実にサポートできるように、重要な機能とノードのチューニング設定のセットを提供するように設計されています。ベースライン設定の変更または省略は、機能の可用性、パフォーマンス、およびリソースの利用に影響を与える可能性があります。参照 PolicyGenerator CR をベースに使用して、お客様のサイト要件に合わせた設定ファイルの階層を作成します。

RAN DU クラスター設定に定義されているベースライン PolicyGenerator CR は、GitOps ZTP ztp-site-generate コンテナーから抽出することが可能です。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。

PolicyGenerator CR は、./out/argocd/example/acmpolicygenerator/ フォルダーにあります。参照アーキテクチャーには、common、group、および site 固有の設定 CR があります。各 PolicyGenerator CR は、./out/source-crs フォルダーにある他の CR を参照します。

以下で、RAN クラスター設定に関連する PolicyGenerator CR を説明します。シングルノード、3 ノードのコンパクト、および標準のクラスター設定の違いに対応するために、グループ PolicyGenerator CR にバリアントが提供されています。同様に、シングルノードクラスターとマルチノード (コンパクトまたはスタンダード) クラスターについても、サイト固有の設定バリエーションが提供されています。デプロイメントに関連するグループおよびサイト固有の設定バリアントを使用します。

表9.2 RAN デプロイメント用の PolicyGenerator CR
PolicyGenerator CR説明

acm-example-multinode-site.yaml

マルチノードクラスターに適用される一連の CR が含まれています。これらの CR は、RAN インストールに典型的な SR-IOV 機能を設定します。

acm-example-sno-site.yaml

シングルノード OpenShift クラスターに適用される一連の CR が含まれています。これらの CR は、RAN インストールに典型的な SR-IOV 機能を設定します。

acm-common-mno-ranGen.yaml

マルチノードクラスターに適用される共通の RAN ポリシー設定のセットが含まれています。

acm-common-ranGen.yaml

すべてのクラスターに適用される共通の RAN CR のセットが含まれています。これらの CR は、RAN の典型的なクラスター機能とベースラインクラスターのチューニングを提供する Operator のセットをサブスクライブします。

acm-group-du-3node-ranGen.yaml

3 ノードクラスター用の RAN ポリシーのみが含まれています。

acm-group-du-sno-ranGen.yaml

シングルノードクラスター用の RAN ポリシーのみが含まれています。

acm-group-du-standard-ranGen.yaml

標準的な 3 つのコントロールプレーンクラスターの RAN ポリシーが含まれています。

acm-group-du-3node-validator-ranGen.yaml

PolicyGenerator CR は、3 ノードクラスターに必要なさまざまなポリシーを生成するために使用されます。

acm-group-du-standard-validator-ranGen.yaml

標準クラスターに必要なさまざまなポリシーを生成するために使用される PolicyGenerator CR。

acm-group-du-sno-validator-ranGen.yaml

シングルノード OpenShift クラスターに必要なさまざまなポリシーを生成するために使用される PolicyGenerator CR。

9.1.5. PolicyGenerator CR を使用したマネージドクラスターのカスタマイズ

次の手順を使用して、GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してプロビジョニングするマネージドクラスターに適用されるポリシーをカスタマイズします。

前提条件

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

手順

  1. サイト固有の設定 CR 用の PolicyGenerator CR を作成します。

    1. out/argocd/example/acmpolicygenerator/ フォルダーから CR に適した例 (acm-example-sno-site.yaml または acm-example-multinode-site.yaml など) を選択します。
    2. サンプルファイルの policyDefaults.placement.labelSelector フィールドを、SiteConfig CR に含まれるサイト固有のラベルと一致するように変更します。サンプルの SiteConfig ファイルでは、サイト固有のラベルは sites: example-sno です。

      注記

      PolicyGeneratorpolicyDefaults.placement.labelSelector フィールドで定義されているラベルが、関連するマネージドクラスターの SiteConfig CR で定義されているラベルに対応していることを確認します。

    3. サンプルファイルの内容を目的の設定に合わせて変更します。
  2. オプション: クラスター群全体に適用される一般的な設定 CR の PolicyGenerator CR を作成します。

    1. out/argocd/example/acmpolicygenerator/ フォルダーから CR に適切な例 (acm-common-ranGen.yaml など) を選択します。
    2. 必要な設定に合わせてサンプルファイルの内容を変更します。
  3. オプション: クラスター群の特定のグループに適用されるグループ設定 CR の PolicyGenerator CR を作成します。

    オーバーレイド仕様ファイルの内容が必要な終了状態と一致することを確認します。参考までに、out/source-crs ディレクトリーには、PolicyGenerator テンプレートで含めたりオーバーレイしたりできる source-crs の完全なリストが含まれています。

    注記

    クラスターの特定の要件に応じて、クラスターのタイプごとに 1 つ以上のグループポリシーが必要になる場合があります。特に、サンプルのグループポリシーにはそれぞれ単一の PerformancePolicy.yaml ファイルがあり、それらのクラスターが同一のハードウェア設定で構成されている場合にのみ、クラスターのセット全体で共有できることを考慮すると、これが当てはまります。

    1. out/argocd/example/acmpolicygenerator/ フォルダーから CR に適切な例 (acm-group-du-sno-ranGen.yaml など) を選択します。
    2. 必要な設定に合わせてサンプルファイルの内容を変更します。
  4. オプション: GitOps ZTP のインストールとデプロイされたクラスターの設定が完了したときに通知するバリデーター通知ポリシー PolicyGenerator CR を作成します。詳細は、「バリデーター通知ポリシーの作成」を参照してください。
  5. サンプルの out/argocd/example/acmpolicygenerator//ns.yaml ファイルと同様の YAML ファイルですべてのポリシー namespace を定義します。

    重要

    Namespace CR を PolicyGenerator CR と同じファイルに含めないでください。

  6. out/argocd/example/acmpolicygenerator/kustomization.yaml に示されている例と同様に、PolicyGenerator CR と Namespace CR を、ジェネレーターセクションの kustomization.yaml ファイルに追加します。
  7. PolicyGenerator CR、Namespace CR、および関連する kustomization.yaml ファイルを Git リポジトリーにコミットし、変更をプッシュします。

    ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。変更を SiteConfig CR と PolicyGenerator CR に同時にプッシュできます。

9.1.6. マネージドクラスターポリシーのデプロイメントの進行状況の監視

ArgoCD パイプラインは、Git の PolicyGenerator CR を使用して RHACM ポリシーを生成し、ハブクラスターに同期します。支援されたサービスが OpenShift Container Platform をマネージドクラスターにインストールした後、マネージドクラスターのポリシー同期の進行状況をモニターできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。

手順

  1. Topology Aware Lifecycle Manager (TALM) は、クラスターにバインドされている設定ポリシーを適用します。

    クラスターのインストールが完了し、クラスターが Ready になると、ran.openshift.io/ztp-deploy-wave アノテーションで定義された順序付きポリシーのリストで、このクラスターに対応する ClusterGroupUpgrade CR が TALM により自動的に作成されます。クラスターのポリシーは、ClusterGroupUpgrade CR に記載されている順序で適用されます。

    以下のコマンドを使用して、設定ポリシー調整のハイレベルの進捗を監視できます。

    $ export CLUSTER=<clusterName>
    $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq

    出力例

    {
      "lastTransitionTime": "2022-11-09T07:28:09Z",
      "message": "Remediating non-compliant policies",
      "reason": "InProgress",
      "status": "True",
      "type": "Progressing"
    }

  2. RHACM ダッシュボードまたはコマンドラインを使用して、詳細なクラスターポリシーのコンプライアンスステータスを監視できます。

    1. oc を使用してポリシーのコンプライアンスを確認するには、次のコマンドを実行します。

      $ oc get policies -n $CLUSTER

      出力例

      NAME                                                     REMEDIATION ACTION   COMPLIANCE STATE   AGE
      ztp-common.common-config-policy                          inform               Compliant          3h42m
      ztp-common.common-subscriptions-policy                   inform               NonCompliant       3h42m
      ztp-group.group-du-sno-config-policy                     inform               NonCompliant       3h42m
      ztp-group.group-du-sno-validator-du-policy               inform               NonCompliant       3h42m
      ztp-install.example1-common-config-policy-pjz9s          enforce              Compliant          167m
      ztp-install.example1-common-subscriptions-policy-zzd9k   enforce              NonCompliant       164m
      ztp-site.example1-config-policy                          inform               NonCompliant       3h42m
      ztp-site.example1-perf-policy                            inform               NonCompliant       3h42m

    2. RHACM Web コンソールからポリシーのステータスを確認するには、次のアクションを実行します。

      1. ガバナンス ポリシーの検索 をクリックします。
      2. クラスターポリシーをクリックして、ステータスを確認します。

すべてのクラスターポリシーが準拠すると、クラスターの GitOps ZTP のインストールと設定が完了します。ztp-done ラベルがクラスターに追加されます。

参照設定では、準拠する最終的なポリシーは、*-du-validator-policy ポリシーで定義されたものです。このポリシーは、クラスターに準拠する場合、すべてのクラスター設定、Operator のインストール、および Operator 設定が完了します。

9.1.7. 設定ポリシー CR の生成の検証

Policy カスタムリソース (CR) は、作成元の PolicyGenerator と同じ namespace に生成されます。以下のコマンドを使用して示すように、ztp-commonztp-group、または ztp-site ベースのいずれであるかにかかわらず、PolicyGenerator から生成されたすべてのポリシー CR に同じトラブルシューティングフローが適用されます。

$ export NS=<namespace>
$ oc get policy -n $NS

予想される policy-wrapped CR のセットが表示されるはずです。

ポリシーの同期に失敗した場合は、以下のトラブルシューティング手順を使用します。

手順

  1. ポリシーの詳細情報を表示するには、次のコマンドを実行します。

    $ oc describe -n openshift-gitops application policies
  2. Status: Conditions: の有無を確認し、エラーログを表示します。たとえば、無効な sourceFile エントリーを fileName: に設定すると、以下次に示すエラーが生成されます。

    Status:
      Conditions:
        Last Transition Time:  2021-11-26T17:21:39Z
        Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1
        Type:  ComparisonError
  3. Status: Sync: をチェックします。Status: Conditions:: でログエラーが発生した場合 Status: Sync:Unknown または Error と表示されます。

    Status:
      Sync:
        Compared To:
          Destination:
            Namespace:  policies-sub
            Server:     https://kubernetes.default.svc
          Source:
            Path:             policies
            Repo URL:         https://git.com/ran-sites/policies/.git
            Target Revision:  master
        Status:               Error
  4. Red Hat Advanced Cluster Management (RHACM) が ManagedCluster オブジェクトにポリシーが適用されることを認識すると、ポリシー CR オブジェクトがクラスターネームスペースに適用されます。ポリシーがクラスターネームスペースにコピーされたかどうかを確認します。

    $ oc get policy -n $CLUSTER

    出力例

    NAME                                         REMEDIATION ACTION   COMPLIANCE STATE   AGE
    ztp-common.common-config-policy              inform               Compliant          13d
    ztp-common.common-subscriptions-policy       inform               Compliant          13d
    ztp-group.group-du-sno-config-policy         inform               Compliant          13d
    ztp-group.group-du-sno-validator-du-policy   inform               Compliant          13d
    ztp-site.example-sno-config-policy           inform               Compliant          13d

    RHACM は、適用可能なすべてのポリシーをクラスターの namespace にコピーします。コピーされたポリシー名の形式は、<PolicyGenerator.Namespace>.<PolicyGenerator.Name>-<policyName> です。

  5. クラスター namespace にコピーされないポリシーの配置ルールを確認します。これらのポリシーの PlacementmatchSelector は、ManagedCluster オブジェクトのラベルと一致する必要があります。

    $ oc get Placement -n $NS
  6. Placement 名は、以下のコマンドを使用して、不足しているポリシー (common、group、または site) に適した名前であることに注意してください。

    $ oc get Placement -n $NS <placement_rule_name> -o yaml
    • status-decisions にはクラスター名が含まれている必要があります。
    • spec の matchSelector の key-value ペアは、マネージドクラスター上のラベルと一致する必要があります。
  7. 以下のコマンドを使用して、ManagedCluster オブジェクトのラベルを確認します。

    $ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
  8. 次のコマンドを使用して、どのポリシーが準拠しているかを確認します。

    $ oc get policy -n $CLUSTER

    NamespaceOperatorGroup、および Subscription ポリシーが準拠しているが Operator 設定ポリシーが該当しない場合、Operator はマネージドクラスターにインストールされていない可能性があります。このため、スポークに CRD がまだ適用されていないため、Operator 設定ポリシーの適用に失敗します。

9.1.8. ポリシー調整の再開

たとえば、ClusterGroupUpgrade カスタムリソース (CR) がタイムアウトした場合など、予期しないコンプライアンスの問題が発生した場合は、ポリシー調整を再開できます。

手順

  1. ClusterGroupUpgrade CR は、管理クラスターの状態が Ready になった後に Topology Aware Lifecycle Manager によって namespace ztp-install に生成されます。

    $ export CLUSTER=<clusterName>
    $ oc get clustergroupupgrades -n ztp-install $CLUSTER
  2. 予期せぬ問題が発生し、設定されたタイムアウト (デフォルトは 4 時間) 内にポリシーが苦情にならなかった場合、ClusterGroupUpgrade CR のステータスは UpgradeTimedOut と 表示されます。

    $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
  3. UpgradeTimedOut 状態の ClusterGroupUpgrade CR は、1 時間ごとにポリシー照合を自動的に再開します。ポリシーを変更した場合は、既存の ClusterGroupUpgrade CR を削除して再試行をすぐに開始できます。これにより、ポリシーをすぐに調整する新規 ClusterGroupUpgrade CR の自動作成がトリガーされます。

    $ oc delete clustergroupupgrades -n ztp-install $CLUSTER

ClusterGroupUpgrade CR が UpgradeCompleted ステータスで完了し、マネージドクラスターに ztp-done ラベルが適用されている場合は、PolicyGenerator を使用して追加の設定変更が可能な点に注意してください。既存の ClusterGroupUpgrade CR を削除しても、TALM は新規 CR を生成しません。

この時点で、GitOps ZTP はクラスターとの対話を完了しました。それ以降の対話は更新として扱われ、ポリシーの修復のために新しい ClusterGroupUpgrade CR が作成されます。

関連情報

  • Topology Aware Lifecycle Manager (TALM) を使用して独自の ClusterGroupUpgrade CR を作成する方法は、ClusterGroupUpgrade CR について を参照してください。

9.1.9. ポリシーを使用して適用済みマネージドクラスター CR を変更する

ポリシーを使用して、マネージドクラスターにデプロイされたカスタムリソース (CR) からコンテンツを削除できます。

PolicyGenerator CR から作成されたすべての Policy CR は、complianceType フィールドがデフォルトで musthave に設定されています。マネージドクラスター上の CR には指定されたコンテンツがすべて含まれているため、コンテンツが削除されていない musthave ポリシーは依然として準拠しています。この設定では、CR からコンテンツを削除すると、TALM はポリシーからコンテンツを削除しますが、そのコンテンツはマネージドクラスター上の CR からは削除されません。

complianceType フィールドを mustonlyhave に設定することで、ポリシーはクラスター上の CR がポリシーで指定されている内容と完全に一致するようにします。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • RHACM を実行しているハブクラスターからマネージドクラスターをデプロイしている。
  • ハブクラスターに Topology Aware Lifecycle Manager がインストールされている。

手順

  1. 影響を受ける CR から不要になったコンテンツを削除します。この例では、SriovOperatorConfig CR から disableDrain: false 行が削除されました。

    CR の例:

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      configDaemonNodeSelector:
        "node-role.kubernetes.io/$mcp": ""
      disableDrain: true
      enableInjector: true
      enableOperatorWebhook: true

  2. acm-group-du-sno-ranGen.yaml ファイルで、影響を受けるポリシーの complianceTypemustonlyhave に変更します。

    サンプル YAML

    # ...
    policyDefaults:
      complianceType: "mustonlyhave"
    # ...
    policies:
      - name: config-policy
        policyAnnotations:
          ran.openshift.io/ztp-deploy-wave: ""
        manifests:
          - path: source-crs/SriovOperatorConfig.yaml

  3. ClusterGroupUpdates CR を作成し、CR の変更を受け取る必要があるクラスターを指定します。

    ClusterGroupUpdates CR の例

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-remove
      namespace: default
    spec:
      managedPolicies:
        - ztp-group.group-du-sno-config-policy
      enable: false
      clusters:
      - spoke1
      - spoke2
      remediationStrategy:
        maxConcurrency: 2
        timeout: 240
      batchTimeoutAction:

  4. 以下のコマンドを実行して ClusterGroupUpgrade CR を作成します。

    $ oc create -f cgu-remove.yaml
  5. たとえば適切なメンテナンス期間中などに変更を適用する準備が完了したら、次のコマンドを実行して spec.enable フィールドの値を true に変更します。

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \
    --patch '{"spec":{"enable":true}}' --type=merge

検証

  1. 以下のコマンドを実行してポリシーのステータスを確認します。

    $ oc get <kind> <changed_cr_name>

    出力例

    NAMESPACE   NAME                                                   REMEDIATION ACTION   COMPLIANCE STATE   AGE
    default     cgu-ztp-group.group-du-sno-config-policy               enforce                                 17m
    default     ztp-group.group-du-sno-config-policy                   inform               NonCompliant       15h

    ポリシーの COMPLIANCE STATECompliant の場合、CR が更新され、不要なコンテンツが削除されたことを意味します。

  2. マネージドクラスターで次のコマンドを実行して、対象クラスターからポリシーが削除されたことを確認します。

    $ oc get <kind> <changed_cr_name>

    結果がない場合、CR はマネージドクラスターから削除されます。

9.1.10. GitOps ZTP インストール完了の表示

GitOps Zero Touch Provisioning (ZTP) は、クラスターの GitOps ZTP インストールステータスを確認するプロセスを単純化します。GitOps ZTP ステータスは、クラスターのインストール、クラスター設定、GitOps ZTP 完了の 3 つのフェーズを遷移します。

クラスターインストールフェーズ
クラスターのインストールフェーズは、ManagedCluster CR の ManagedClusterJoined および ManagedClusterAvailable 条件によって示されます。ManagedCluster CR にこの条件がない場合や、条件が False に設定されている場合、クラスターはインストールフェーズに残ります。インストールに関する追加情報は、AgentClusterInstall および ClusterDeployment CR から入手できます。詳細は、「GitOps ZTP のトラブルシューティング」を参照してください。
クラスター設定フェーズ
クラスター設定フェーズは、クラスターの ManagedCluster CR に適用される ztp-running ラベルで示されます。
GitOps ZTP 完了

クラスターのインストールと設定は、GitOps ZTP 完了フェーズで実行されます。これは、ztp-running ラベルを削除し、ManagedCluster CR に ztp-done ラベルを追加することで表示されます。ztp-done ラベルは、設定が適用され、ベースライン DU 設定が完了したことを示しています。

GitOps ZTP 完了状態への変更は、Red Hat Advanced Cluster Management (RHACM) バリデーター通知ポリシーの準拠状態が条件となります。このポリシーは、完了したインストールの既存の基準をキャプチャし、マネージドクラスターの GitOps ZTP プロビジョニングが完了したときにのみ、準拠した状態に移行することを検証するものです。

バリデータ通知ポリシーは、クラスターの設定が完全に適用され、Operator が初期化を完了したことを確認します。ポリシーは以下を検証します。

  • ターゲット MachineConfigPool には予想されるエントリーが含まれ、更新が完了しました。全ノードが利用可能で、低下することはありません。
  • SR-IOV Operator は、syncStatus: Succeeded の 1 つ以上の SriovNetworkNodeState によって示されているように初期化を完了しています。
  • PTP Operator デーモンセットが存在する。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.