4.7. 通信事業者 RAN DU デプロイメントのコンポーネント
次のセクションでは、RHACM を使用してハブクラスターを設定するために使用するさまざまな OpenShift Container Platform コンポーネントと設定を説明します。
4.7.1. Red Hat Advanced Cluster Management リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
RHACM は、デプロイされたクラスターに対して、Multi Cluster Engine (MCE) のインストールと継続的なライフサイクル管理機能を提供します。管理者は、メンテナンス期間中に
Policyカスタムリソース (CR) をクラスターに適用することで、クラスターの設定とアップグレードを宣言的に管理します。RHACM は次の機能を提供します。
- RHACM の MCE コンポーネントを使用したクラスターのゼロタッチプロビジョニング (ZTP)。
- RHACM ポリシーコントローラーを介した設定、アップグレード、およびクラスターのステータス。
-
RHACM は、マネージドクラスターのインストール中に、
ClusterInstanceCR を通じて設定されたとおりに個々のノードにラベルを適用できます。
シングルノードの OpenShift クラスターの場合、推奨されるインストール方法は、MCE で利用できるイメージベースのインストール方式です。この方法では、クラスターの定義に
ClusterInstanceCR を使用します。シングルノードの OpenShift クラスターの場合、推奨されるアップグレード方法は、イメージベースのアップグレード方法です。
- 制限と要件
-
単一のハブクラスターは、各クラスターに 5 つの
PolicyCR がバインドされた、最大 3500 個のデプロイされたシングルノード OpenShift クラスターをサポートします。
-
単一のハブクラスターは、各クラスターに 5 つの
- エンジニアリングに関する考慮事項
- RHACM ポリシーハブ側テンプレートを使用して、クラスター設定をより適切にスケーリングします。グループおよびクラスターごとの値がテンプレートに置き換えられる単一のグループポリシーまたは少数の一般的なグループポリシーを使用することで、ポリシーの数を大幅に削減できます。
-
クラスター固有の設定: マネージドクラスターには通常、個々のクラスターに固有の設定値がいくつかあります。これらの設定は、クラスター名に基づいて
ConfigMapCR から取得された値を使用して、RHACM ポリシーハブ側テンプレートを使用して管理する必要があります。 - マネージドクラスターの CPU リソースを節約するには、クラスターの GitOps ZTP インストール後に、静的設定を適用するポリシーをマネージドクラスターからアンバインドする必要があります。
4.7.2. SiteConfig Operator リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
SiteConfig Operator は、テンプレートを中心としたソリューションであり、さまざまなインストール方法でクラスターをプロビジョニングするように設計されています。この Operator は、非推奨の
SiteConfigAPI に代わる統合されたClusterInstanceAPI を導入します。SiteConfig Operator はClusterInstanceAPI を活用し、次の機能を提供することでクラスターのプロビジョニングを改善します。- 定義とインストール方法の分離の改善
- Git ワークフローと非 Git ワークフローの統合
- インストール方法を問わず一貫した API
- スケーラビリティーの向上
- カスタムインストールテンプレートによる柔軟性の向上
- デプロイメントの問題のトラブルシューティングに役立つ詳細情報
SiteConfig Operator は、検証済みのデフォルトのインストールテンプレートを提供します。このテンプレートにより、Assisted Installer と Image-based Installer の両方のプロビジョニング方法で、クラスターのデプロイが容易になります。
- Assisted Installer は、事前定義された設定と検証済みのホスト設定を活用して、OpenShift Container Platform クラスターのデプロイを自動化します。これにより、ターゲットインフラストラクチャーを OpenShift Container Platform の要件に確実に準拠させることができます。Assisted Installer は、手動セットアップに比べて時間と複雑さを最小限に抑えながらインストールプロセスを合理化します。
- Image-based Installer は、事前設定および検証済みの OpenShift Container Platform シードイメージを利用して、シングルノード OpenShift クラスターのデプロイを迅速化します。シードイメージはターゲットホストにプリインストールされているため、迅速な再設定とデプロイが可能になります。Image-based Installer は、クラスターの作成プロセスを簡素化し、デプロイ時間を大幅に短縮するため、リモート環境や非接続環境に特に適しています。
- 制限と要件
- 1 つのハブクラスターによってサポートされるのは、最大 3500 個のデプロイ済みシングルノード OpenShift クラスターです。
4.7.3. Topology Aware Lifecycle Manager リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
TALM は、ハブクラスター上でのみ実行される Operator であり、クラスターのアップグレード、Operator のアップグレード、クラスター設定などの変更をネットワークにロールアウトする方法を管理します。TALM は次の機能をサポートしています。
- ユーザーが設定可能なバッチで、クラスター群にポリシー更新を段階的にロールアウトします。
-
クラスターごとのアクションにより、マネージドクラスターの設定変更に従って、
ztp-doneラベルまたはその他のユーザー設定可能なラベルを追加します。 シングルノード OpenShift クラスターイメージの事前キャッシュ: TALM は、アップグレードを開始する前に、OpenShift、OLM Operator、および追加のユーザーイメージを、シングルノード OpenShift クラスターに必要に応じて事前キャッシュする機能をサポートしています。シングルノード OpenShift クラスターのアップグレードに推奨されるイメージベースのアップグレード方法を使用する場合、事前キャッシュ機能は適用されません。
-
オプションの事前キャッシュ設定は、
PreCachingConfigCR を使用して指定します。詳細は、サンプルのPreCachingConfigリファレンス CR を参照してください。 - 設定可能なフィルタリングにより未使用のイメージを除外します。
- 設定可能な space-required パラメーターを使用して、事前キャッシュの前後のストレージ領域検証を有効にします。
-
オプションの事前キャッシュ設定は、
- 制限と要件
- 400 個のバッチでクラスターを同時にデプロイできます。
- 事前キャッシュとバックアップは、シングルノード OpenShift クラスターのみを対象としています。
- エンジニアリングに関する考慮事項
-
PreCachingConfigCR は任意です。プラットフォーム関連の OpenShift および OLM Operator イメージのみを事前キャッシュする必要がある場合、作成する必要はありません。 -
ClusterGroupUpgradeCR で参照する前に、PreCachingConfigCR を適用する必要があります。 -
クラスターのインストール中に、
ran.openshift.io/ztp-deploy-waveアノテーションが付いたポリシーのみが TALM によって自動的に適用されます。 -
ユーザーが作成した
ClusterGroupUpgradeCR の制御下で、TALM によって任意のポリシーを修正できます。
-
4.7.4. GitOps Operator および GitOps ZTP リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- 説明
GitOps Operator と GitOps ZTP は、クラスターのデプロイメントと設定を管理するための GitOps ベースのインフラストラクチャーを提供します。クラスターの定義と設定は、Git で宣言的な状態として維持されます。
ClusterInstanceCR をハブクラスターに適用すると、SiteConfigOperator がそれをインストール CR としてレンダリングします。以前のリリースでは、GitOps ZTP プラグインはSiteConfigCR からのインストール CR の生成をサポートしていました。このプラグインは現在非推奨です。PolicyGeneratorまたはPolicyGenTemplateCR に基づいて設定 CR をポリシーに自動的にラップできるようにする別の GitOps ZTP プラグインが利用可能です。ベースラインリファレンス設定 CR を使用して、マネージドクラスターに OpenShift Container Platform の複数のバージョンをデプロイおよび管理できます。ベースライン CR と並行してカスタム CR を使用できます。複数のバージョンごとのポリシーを同時に維持するには、Git を使用して、
PolicyGeneratorまたはPolicyGenTemplateCR でソース CR とポリシー CR のバージョンを管理します。OpenShift Container Platform 4.19 リリース以降では、RHACM のPolicyGeneratorが推奨されるジェネレータープラグインです。- 制限と要件
-
ClusterInstanceCR の数は、ArgoCD アプリケーションごとに 1000 個です。複数のアプリケーションを使用すると、1 つのハブクラスターでサポートされるクラスターの最大数を実現できます。 -
Git の
source-crs/ディレクトリーの内容は、ZTP プラグインコンテナーで提供される内容よりも優先されます。検索パスで Git が優先されるためです。 -
source-crs/ディレクトリーは、ジェネレーターとしてPolicyGeneratorCR を含むkustomization.yamlファイルと同じディレクトリーに配置する必要があります。このコンテキストでは、source-crs/ディレクトリーを別の場所に配置することはできません。
-
- エンジニアリングに関する考慮事項
-
マルチノードクラスターのアップグレードの場合、
pausedフィールドをtrueに設定することで、メンテナンス期間中にMachineConfigPool(MCP) CR を一時停止できます。MCPCR でmaxUnavailable設定を指定することで、MCPCR ごとの同時に更新されるノードの数を増やすことができます。MaxUnavailableフィールドは、MachineConfigの更新中に同時に使用できなくなるプール内のノードのパーセンテージを定義します。maxUnavailableを最大許容値に設定します。これにより、アップグレード中にクラスター内で再起動する回数が減り、アップグレード時間が短縮されます。最終的にMCPCR の一時停止を解除すると、変更されたすべての設定が 1 回の再起動で適用されます。 -
クラスターのインストール中に、paused フィールドを true に設定し、
maxUnavailableを 100% に設定することで、カスタムの MCP CR を一時停止し、インストール時間を短縮できます。 リファレンス CR とカスタム CR を別々のディレクトリーに保存してください。これを行うと、カスタム CR に触れることなく、ディレクトリーのすべてのコンテンツを簡単に置き換えるだけで、リファレンス CR にパッチを適用して更新できます。複数のバージョンを管理する場合は、次のベストプラクティスが推奨されます。
- すべてのソース CR とポリシー作成 CR を Git リポジトリーに保存して、各 OpenShift Container Platform バージョンのポリシーが Git のコンテンツのみに基づいて一貫して生成されるようにします。
- リファレンスソース CR をカスタム CR と別のディレクトリーに保存します。これにより、必要に応じてリファレンス CR を簡単に更新できるようになります。
-
コンテンツを更新する際の混乱や意図しない上書きを避けるため、
source-crs/ディレクトリー内のカスタム CR と Git 内の追加マニフェストには、一意で区別できる名前を使用することを強く推奨します。 -
追加のインストールマニフェストは、
ConfigMapCR を通じてClusterInstanceCR で参照されます。ConfigMapCR は、ClusterInstanceCR とともに、クラスターの信頼できる唯一の情報源として機能する Git に保存する必要があります。必要に応じて、ConfigMapジェネレーターを使用してConfigMapCR を作成できます。
-
マルチノードクラスターのアップグレードの場合、
4.7.5. Agent-based Installer リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
- オプションの Agent-based Installer コンポーネントは、一元的なインフラストラクチャーなしでインストール機能を提供するものです。インストールプログラムは、サーバーにマウントする ISO イメージを作成します。サーバーが起動すると、OpenShift Container Platform と提供された追加のマニフェストがインストールされます。Agent-based Installer を使用すると、ハブクラスターなしで OpenShift Container Platform をインストールできます。クラスターのインストールにはコンテナーイメージレジストリーが必要です。
- 制限と要件
- インストール時に、追加のマニフェストの限定されたセットを提供できます。
-
RAN DU ユースケースに必要な
MachineConfigurationCR を含める必要があります。
- エンジニアリングに関する考慮事項
- Agent-based Installer は、ベースラインの OpenShift Container Platform インストールを提供します。
- インストール後に、Day 2 Operator と残りの RAN DU ユースケース設定をインストールします。