第9章 PolicyGenerator リソースを使用したクラスターポリシーの管理
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 はその一部ではありません。次の表では、PolicyGenerator
と PolicyGenTemplate
リソースのパッチ適用および配置ストラテジーの比較を説明します。
PolicyGenTemplate
CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator
CR を使用する場合に利用できます。
PolicyGenerator
リソースの詳細は、RHACM Policy Generator のドキュメントを参照してください。
PolicyGenerator のパッチ適用 | PolicyGenTemplate のパッチ適用 |
---|---|
リソースのマージには Kustomize ストラテジーマージを使用します。詳細は、Kustomize を使用した Kubernetes オブジェクトの宣言的管理 を参照してください。 | 変数をパッチで定義された値に置き換えることによって機能します。これは Kustomize マージストラテジーよりも柔軟性が低くなります。 |
|
|
パッチ適用のみに依存し、埋め込み変数の置換は必要ありません。 | パッチで定義された変数値を上書きします。 |
マージパッチ内のリストのマージはサポートされません。マージパッチ内のリストの置き換えはサポートされています。 | リストのマージと置換は制限付きでサポートされており、リスト内の 1 つのオブジェクトのみをマージできます。 |
現在、リソースのパッチ適用に OpenAPI 仕様 はサポートされていません。つまり、 | フィールドと値をパッチで定義された値に置き換えることによって機能します。 |
スキーマに従わないコンテンツをマージするには、パッチ内で |
ソース CR で定義されたフィールドと値を、パッチで定義された値 (例: |
参照ソース CR で定義された |
参照ソース CR で定義された |
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
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 が変更されても、生成されたサブスクリプションが更新されないようになります。
関連情報
- RHACM を使用したクラスターのスケーリングに関する推奨事項は、パフォーマンスおよびスケーラビリティー を参照してください。
ハブクラスターで多数のスポーククラスターを管理する場合は、ポリシーの数を最小限に抑えてリソースの消費を減らします。
複数のコンフィギュレーション 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 にバリアントが提供されています。同様に、シングルノードクラスターとマルチノード (コンパクトまたはスタンダード) クラスターについても、サイト固有の設定バリエーションが提供されています。デプロイメントに関連するグループおよびサイト固有の設定バリアントを使用します。
PolicyGenerator CR | 説明 |
---|---|
| マルチノードクラスターに適用される一連の CR が含まれています。これらの CR は、RAN インストールに典型的な SR-IOV 機能を設定します。 |
| シングルノード OpenShift クラスターに適用される一連の CR が含まれています。これらの CR は、RAN インストールに典型的な SR-IOV 機能を設定します。 |
| マルチノードクラスターに適用される共通の RAN ポリシー設定のセットが含まれています。 |
| すべてのクラスターに適用される共通の RAN CR のセットが含まれています。これらの CR は、RAN の典型的なクラスター機能とベースラインクラスターのチューニングを提供する Operator のセットをサブスクライブします。 |
| 3 ノードクラスター用の RAN ポリシーのみが含まれています。 |
| シングルノードクラスター用の RAN ポリシーのみが含まれています。 |
| 標準的な 3 つのコントロールプレーンクラスターの RAN ポリシーが含まれています。 |
|
|
|
標準クラスターに必要なさまざまなポリシーを生成するために使用される |
|
シングルノード OpenShift クラスターに必要なさまざまなポリシーを生成するために使用される |
9.1.5. PolicyGenerator CR を使用したマネージドクラスターのカスタマイズ
次の手順を使用して、GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してプロビジョニングするマネージドクラスターに適用されるポリシーをカスタマイズします。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてハブクラスターにログインしている。 - 必要なインストール CR とポリシー CR を生成するためにハブクラスターを設定している。
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD アプリケーションのソースリポジトリーとして定義されている必要があります。
手順
サイト固有の設定 CR 用の
PolicyGenerator
CR を作成します。-
out/argocd/example/acmpolicygenerator/
フォルダーから CR に適した例 (acm-example-sno-site.yaml
またはacm-example-multinode-site.yaml
など) を選択します。 サンプルファイルの
policyDefaults.placement.labelSelector
フィールドを、SiteConfig
CR に含まれるサイト固有のラベルと一致するように変更します。サンプルのSiteConfig
ファイルでは、サイト固有のラベルはsites: example-sno
です。注記PolicyGenerator
のpolicyDefaults.placement.labelSelector
フィールドで定義されているラベルが、関連するマネージドクラスターのSiteConfig
CR で定義されているラベルに対応していることを確認します。- サンプルファイルの内容を目的の設定に合わせて変更します。
-
オプション: クラスター群全体に適用される一般的な設定 CR の
PolicyGenerator
CR を作成します。-
out/argocd/example/acmpolicygenerator/
フォルダーから CR に適切な例 (acm-common-ranGen.yaml
など) を選択します。 - 必要な設定に合わせてサンプルファイルの内容を変更します。
-
オプション: クラスター群の特定のグループに適用されるグループ設定 CR の
PolicyGenerator
CR を作成します。オーバーレイド仕様ファイルの内容が必要な終了状態と一致することを確認します。参考までに、
out/source-crs
ディレクトリーには、PolicyGenerator テンプレートで含めたりオーバーレイしたりできる source-crs の完全なリストが含まれています。注記クラスターの特定の要件に応じて、クラスターのタイプごとに 1 つ以上のグループポリシーが必要になる場合があります。特に、サンプルのグループポリシーにはそれぞれ単一の
PerformancePolicy.yaml
ファイルがあり、それらのクラスターが同一のハードウェア設定で構成されている場合にのみ、クラスターのセット全体で共有できることを考慮すると、これが当てはまります。-
out/argocd/example/acmpolicygenerator/
フォルダーから CR に適切な例 (acm-group-du-sno-ranGen.yaml
など) を選択します。 - 必要な設定に合わせてサンプルファイルの内容を変更します。
-
-
オプション: GitOps ZTP のインストールとデプロイされたクラスターの設定が完了したときに通知するバリデーター通知ポリシー
PolicyGenerator
CR を作成します。詳細は、「バリデーター通知ポリシーの作成」を参照してください。 サンプルの
out/argocd/example/acmpolicygenerator//ns.yaml
ファイルと同様の YAML ファイルですべてのポリシー namespace を定義します。重要Namespace
CR をPolicyGenerator
CR と同じファイルに含めないでください。-
out/argocd/example/acmpolicygenerator/kustomization.yaml
に示されている例と同様に、PolicyGenerator
CR とNamespace
CR を、ジェネレーターセクションのkustomization.yaml
ファイルに追加します。 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
権限を持つユーザーとしてハブクラスターにログインしている。
手順
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" }
RHACM ダッシュボードまたはコマンドラインを使用して、詳細なクラスターポリシーのコンプライアンスステータスを監視できます。
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
RHACM Web コンソールからポリシーのステータスを確認するには、次のアクションを実行します。
-
ガバナンス
ポリシーの検索 をクリックします。 - クラスターポリシーをクリックして、ステータスを確認します。
-
ガバナンス
すべてのクラスターポリシーが準拠すると、クラスターの GitOps ZTP のインストールと設定が完了します。ztp-done
ラベルがクラスターに追加されます。
参照設定では、準拠する最終的なポリシーは、*-du-validator-policy
ポリシーで定義されたものです。このポリシーは、クラスターに準拠する場合、すべてのクラスター設定、Operator のインストール、および Operator 設定が完了します。
9.1.7. 設定ポリシー CR の生成の検証
Policy
カスタムリソース (CR) は、作成元の PolicyGenerator
と同じ namespace に生成されます。以下のコマンドを使用して示すように、ztp-common
、ztp-group
、または ztp-site
ベースのいずれであるかにかかわらず、PolicyGenerator
から生成されたすべてのポリシー CR に同じトラブルシューティングフローが適用されます。
$ export NS=<namespace>
$ oc get policy -n $NS
予想される policy-wrapped CR のセットが表示されるはずです。
ポリシーの同期に失敗した場合は、以下のトラブルシューティング手順を使用します。
手順
ポリシーの詳細情報を表示するには、次のコマンドを実行します。
$ oc describe -n openshift-gitops application policies
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
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
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>
です。クラスター namespace にコピーされないポリシーの配置ルールを確認します。これらのポリシーの
Placement
のmatchSelector
は、ManagedCluster
オブジェクトのラベルと一致する必要があります。$ oc get Placement -n $NS
Placement
名は、以下のコマンドを使用して、不足しているポリシー (common、group、または site) に適した名前であることに注意してください。$ oc get Placement -n $NS <placement_rule_name> -o yaml
- status-decisions にはクラスター名が含まれている必要があります。
-
spec の
matchSelector
の key-value ペアは、マネージドクラスター上のラベルと一致する必要があります。
以下のコマンドを使用して、
ManagedCluster
オブジェクトのラベルを確認します。$ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
次のコマンドを使用して、どのポリシーが準拠しているかを確認します。
$ oc get policy -n $CLUSTER
Namespace
、OperatorGroup
、およびSubscription
ポリシーが準拠しているが Operator 設定ポリシーが該当しない場合、Operator はマネージドクラスターにインストールされていない可能性があります。このため、スポークに CRD がまだ適用されていないため、Operator 設定ポリシーの適用に失敗します。
9.1.8. ポリシー調整の再開
たとえば、ClusterGroupUpgrade
カスタムリソース (CR) がタイムアウトした場合など、予期しないコンプライアンスの問題が発生した場合は、ポリシー調整を再開できます。
手順
ClusterGroupUpgrade
CR は、管理クラスターの状態がReady
になった後に Topology Aware Lifecycle Manager によって namespaceztp-install
に生成されます。$ export CLUSTER=<clusterName>
$ oc get clustergroupupgrades -n ztp-install $CLUSTER
予期せぬ問題が発生し、設定されたタイムアウト (デフォルトは 4 時間) 内にポリシーが苦情にならなかった場合、
ClusterGroupUpgrade
CR のステータスはUpgradeTimedOut と
表示されます。$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
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 がインストールされている。
手順
影響を受ける 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
acm-group-du-sno-ranGen.yaml
ファイルで、影響を受けるポリシーのcomplianceType
をmustonlyhave
に変更します。サンプル YAML
# ... policyDefaults: complianceType: "mustonlyhave" # ... policies: - name: config-policy policyAnnotations: ran.openshift.io/ztp-deploy-wave: "" manifests: - path: source-crs/SriovOperatorConfig.yaml
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:
以下のコマンドを実行して
ClusterGroupUpgrade
CR を作成します。$ oc create -f cgu-remove.yaml
たとえば適切なメンテナンス期間中などに変更を適用する準備が完了したら、次のコマンドを実行して
spec.enable
フィールドの値をtrue
に変更します。$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \ --patch '{"spec":{"enable":true}}' --type=merge
検証
以下のコマンドを実行してポリシーのステータスを確認します。
$ 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 STATE
がCompliant
の場合、CR が更新され、不要なコンテンツが削除されたことを意味します。マネージドクラスターで次のコマンドを実行して、対象クラスターからポリシーが削除されたことを確認します。
$ 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 デーモンセットが存在する。
-
ターゲット