第6章 SiteConfig CR から ClusterInstance CR への移行
単一ノードの OpenShift クラスターを SiteConfig
カスタムリソース(CR)から ClusterInstance
CR に増分的に移行できます。移行時に、既存および新規パイプラインは並行して実行されるため、制御された段階的な方法で 1 つ以上のクラスターを一度に移行することができます。
-
SiteConfig
CR は OpenShift Container Platform バージョン 4.18 で非推奨になり、今後のバージョンで削除されます。 -
ClusterInstance
CR は、Red Hat Advanced Cluster Management (RHACM)バージョン 2.12 以降から入手できます。
6.1. SiteConfig CR から ClusterInstance CR への移行の概要 リンクのコピーリンクがクリップボードにコピーされました!
ClusterInstance
CR は、クラスターを定義するためのより統一された汎用的な方法を提供します。これは、GitOps ZTP ワークフローでクラスターデプロイメントを管理するための推奨される方法です。ClusterInstance
カスタムリソース(CR)を管理する SiteConfig Operator は、Red Hat Advanced Cluster Management (RHACM)内でアドオンとして提供される完全に開発されたコントローラーです。
SiteConfig Operator は ClusterInstance
オブジェクトの更新のみを調整します。コントローラーは、非推奨の SiteConfig
オブジェクトを監視または管理しません。
SiteConfig
CR から ClusterInstance
CR への移行により、拡張スケーラビリティーやクラスターデプロイメント方法からのクラスターパラメーターの明確な分離など、いくつかの改良が行われています。これらの改善と SiteConfig Operator の詳細は、SiteConfig を参照してください。
移行プロセスには、以下の概略的な手順が含まれます。
- リポジトリーに新しい Git フォルダー構造を作成し、対応する Argo CD プロジェクトおよびアプリケーションを作成して、並列パイプラインをセットアップします。
クラスターを段階的に移行するには、まず古いパイプラインから関連する
SiteConfig
CR を削除します。次に、対応するClusterInstance
CR を新しいパイプラインに追加します。注記最初の Argo CD アプリケーションで
prune=false
同期ポリシーを使用することにより、このアプリケーションからターゲットクラスターを削除した後でも、このパイプラインで管理されるリソースはそのまま残ります。このアプローチにより、既存のクラスターリソースが移行プロセス中も稼働し続けるようになります。-
必要に応じて、
siteconfig-converter
ツールを使用して、既存のSiteConfig
CR をClusterInstance
CR に自動的に変換します。
-
必要に応じて、
- クラスターの移行が完了したら、元の Argo プロジェクトおよびアプリケーションを削除し、関連するリソースを削除します。
以下のセクションでは、サンプルのクラスター sno1
を SiteConfig
CR の使用から ClusterInstance
CR に移行する方法を説明します。
以下の Git リポジトリーフォルダー構造は、この移行例のベースとして使用されます。