第4章 RHACM および SiteConfig リソースを使用したマネージドクラスターのインストール
Red Hat Advanced Cluster Management (RHACM) を使用して OpenShift Container Platform クラスターを大規模にプロビジョニングするには、アシストサービスと、コア削減テクノロジーが有効になっている GitOps プラグインポリシージェネレーターを使用します。GitOps Zero Touch Provisioning (ZTP) パイプラインは、クラスターのインストールを実行します。GitOps ZTP は、非接続環境で使用できます。
PolicyGenTemplate CR を使用してポリシーを管理し、マネージドクラスターにデプロイすることは、OpenShift Container Platform の今後のリリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator CR を使用する場合に利用できます。
PolicyGenerator リソースの詳細は、RHACM の ポリシージェネレーターの統合 ドキュメントを参照してください。
4.1. GitOps ZTP および Topology Aware Lifecycle Manager リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) は、Git に格納されたマニフェストからインストールと設定の CR を生成します。これらのアーティファクトは、Red Hat Advanced Cluster Management (RHACM)、アシストサービス、および Topology Aware Lifecycle Manager (TALM) が CR を使用してマネージドクラスターをインストールおよび設定する中央ハブクラスターに適用されます。GitOps ZTP パイプラインの設定フェーズでは、TALM を使用してクラスターに対する設定 CR の適用のオーケストレーションを行います。GitOps ZTP と TALM の間には、いくつかの重要な統合ポイントがあります。
- Inform ポリシー
-
デフォルトでは、GitOps ZTP は、
informの修復アクションですべてのポリシーを作成します。これらのポリシーにより、RHACM はポリシーに関連するクラスターのコンプライアンスステータスを報告しますが、必要な設定は適用されません。GitOps ZTP プロセスの中で OpenShift をインストールした後に、TALM は作成された各informポリシーを確認し、これらのポリシーをターゲットのマネージドクラスターに適用します。これにより、設定がマネージドクラスターに適用されます。クラスターライフサイクルの GitOps ZTP フェーズ以外では、影響を受けるマネージドクラスターで変更をすぐにロールアウトするリスクなしに、ポリシーを変更できます。TALM を使用して、修復されたクラスターのタイミングとセットを制御できます。 - ClusterGroupUpgrade CR の自動作成
新しくデプロイされたクラスターの初期設定を自動化するために、TALM はハブクラスター上のすべての
ManagedClusterCR の状態を監視します。新規に作成されたManagedClusterCR を含むztp-doneラベルを持たないManagedClusterCR が適用されると、TALM は以下の特性でClusterGroupUpgradeCR を自動的に作成します。-
ClusterGroupUpgradeCR がztp-installnamespace に作成され、有効にされます。 -
ClusterGroupUpgradeCR の名前はManagedClusterCR と同じになります。 -
クラスターセレクターには、その
ManagedClusterCR に関連付けられたクラスターのみが含まれます。 -
管理ポリシーのセットには、
ClusterGroupUpgradeの作成時に RHACM がクラスターにバインドされているすべてのポリシーが含まれます。 - 事前キャッシュは無効です。
- タイムアウトを 4 時間 (240 分) に設定。
有効な
ClusterGroupUpgradeの自動生成により、ユーザーの介入を必要としないゼロタッチのクラスター展開が可能になります。さらに、ztp-doneラベルのないManagedClusterに対してClusterGroupUpgradeCR が自動的に作成されるため、そのクラスターのClusterGroupUpgradeCR を削除するだけで失敗した GitOps ZTP インストールを再開できます。-
- Waves
PolicyGeneratorまたはPolicyGentemplateCR から生成された各ポリシーには、ztp-deploy-waveアノテーションが含まれます。このアノテーションは、そのポリシーに含まれる各 CR と同じアノテーションに基づいています。wave アノテーションは、自動生成されたClusterGroupUpgradeCR でポリシーを順序付けするために使用されます。wave アノテーションは、自動生成されたClusterGroupUpgradeCR 以外には使用されません。注記同じポリシーのすべての CR には
ztp-deploy-waveアノテーションに同じ設定が必要です。各 CR のこのアノテーションのデフォルト値は、PolicyGeneratorまたはPolicyGentemplateでオーバーライドできます。ソース CR の wave アノテーションは、ポリシーの wave アノテーションを判別し、設定するために使用されます。このアノテーションは、実行時に生成されるポリシーに含まれるビルドされる各 CR から削除されます。TALM は、wave アノテーションで指定された順序で設定ポリシーを適用します。TALM は、各ポリシーが準拠しているのを待ってから次のポリシーに移動します。各 CR の wave アノテーションは、それらの CR がクラスターに適用されるための前提条件を確実に考慮することが重要である。たとえば、Operator は Operator の設定前後にインストールする必要があります。同様に、Operator 用
CatalogSourceは、Operator 用サブスクリプションの前または同時にウェーブにインストールする必要があります。各 CR のデフォルトの波動値は、これらの前提条件を考慮したものです。複数の CR およびポリシーは同じアンブ番号を共有できます。ポリシーの数を少なくすることで、デプロイメントを高速化し、CPU 使用率を低減させることができます。多くの CR を比較的少なくするのがベストプラクティスです。
各ソース CR でデフォルトの wave 値を確認するには、ztp-site-generate コンテナーイメージからデプロイメントした out/source-crs ディレクトリーに対して以下のコマンドを実行します。
grep -r "ztp-deploy-wave" out/source-crs
$ grep -r "ztp-deploy-wave" out/source-crs
- フェーズラベル
ClusterGroupUpgradeCR は自動的に作成され、そこには GitOps ZTP プロセスの開始時と終了時にManagedClusterCR をラベルでアノテートするディレクティブが含まれています。インストール後に GitOps ZTP 設定が開始すると、
ManagedClusterにztp-runningラベルが適用されます。すべてのポリシーがクラスターに修復され、完全に準拠されると、TALM はztp-runningラベルを削除し、ztp-doneラベルを適用します。informDuValidatorポリシーを使用するデプロイメントでは、クラスターが完全にアプリケーションをデプロイするための準備が整った時点でztp-doneラベルが適用されます。これには、GitOps ZTP が適用された設定 CR の調整および影響がすべて含まれます。ztp-doneラベルは、TALM によるClusterGroupUpgradeCR の自動作成に影響します。クラスターの最初の GitOps ZTP インストール後は、このラベルを操作しないでください。- リンクされた CR
-
自動的に作成された
ClusterGroupUpgradeCR には所有者の参照が、そこから派生したManagedClusterとして設定されます。この参照により、ManagedClusterCR を削除すると、ClusterGroupUpgradeのインスタンスがサポートされるリソースと共に削除されるようにします。