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 は、マネージドクラスターのインストール中に、ClusterInstance CR を通じて設定されたとおりに個々のノードにラベルを適用できます。

シングルノードの OpenShift クラスターの場合、推奨されるインストール方法は、MCE で利用できるイメージベースのインストーラー方式です。この方法では、クラスターの定義に ClusterInstance CR を使用します。

シングルノードの OpenShift クラスターの場合、推奨されるアップグレード方法は、イメージベースのアップグレード方法です。

制限と要件
  • 単一のハブクラスターは、各クラスターに 5 つの Policy CR がバインドされた、最大 3500 個のデプロイされたシングルノード OpenShift クラスターをサポートします。
エンジニアリングに関する考慮事項
  • RHACM ポリシーハブ側テンプレートを使用して、クラスター設定をより適切にスケーリングします。グループおよびクラスターごとの値がテンプレートに置き換えられる単一のグループポリシーまたは少数の一般的なグループポリシーを使用することで、ポリシーの数を大幅に削減できます。
  • クラスター固有の設定: マネージドクラスターには通常、個々のクラスターに固有の設定値がいくつかあります。これらの設定は、クラスター名に基づいて ConfigMap CR から取得された値を使用して、RHACM ポリシーハブ側テンプレートを使用して管理する必要があります。
  • マネージドクラスターの CPU リソースを節約するには、クラスターの GitOps ZTP インストール後に、静的設定を適用するポリシーをマネージドクラスターからアンバインドする必要があります。

4.7.2. SiteConfig Operator

このリリースの変更点
  • このリリースでは RDS の更新はありません。
説明

SiteConfig Operator は、テンプレートを中心としたソリューションであり、さまざまなインストール方法でクラスターをプロビジョニングするように設計されています。この Operator は、非推奨の SiteConfig API に代わる統合された ClusterInstance API を導入します。SiteConfig Operator は ClusterInstance API を活用し、次の機能を提供することでクラスターのプロビジョニングを改善します。

  • 定義とインストール方法の分離の改善
  • 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

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

Topology Aware Lifecycle Manager は、ハブクラスター上でのみ実行され、クラスターのアップグレード、Operator のアップグレード、クラスター設定などの変更をネットワークにデプロイする方法を管理するための Operator です。TALM は次の機能をサポートしています。

  • ユーザーが設定可能なバッチで、クラスター群にポリシー更新を段階的にロールアウトします。
  • クラスターごとのアクションにより、マネージドクラスターの設定変更に従って、ztp-done ラベルまたはその他のユーザー設定可能なラベルを追加します。
  • シングルノード OpenShift クラスターイメージの事前キャッシュ: TALM は、アップグレードを開始する前に、OpenShift、OLM Operator、および追加のユーザーイメージを、シングルノード OpenShift クラスターに必要に応じて事前キャッシュする機能をサポートしています。シングルノード OpenShift クラスターのアップグレードに推奨されるイメージベースのアップグレード方法を使用する場合、事前キャッシュ機能は適用されません。

    • オプションの事前キャッシュ設定は、PreCachingConfig CR を使用して指定します。詳細は、サンプルの PreCachingConfig リファレンス CR を参照してください。
    • 設定可能なフィルタリングにより未使用のイメージを除外します。
    • 設定可能な space-required パラメーターを使用して、事前キャッシュの前後のストレージ領域検証を有効にします。
制限と要件
  • 400 個のバッチでクラスターを同時にデプロイできます。
  • 事前キャッシュとバックアップは、シングルノード OpenShift クラスターのみを対象としています。
エンジニアリングに関する考慮事項
  • PreCachingConfig CR は任意です。プラットフォーム関連の OpenShift および OLM Operator イメージのみを事前キャッシュする必要がある場合、作成する必要はありません。
  • ClusterGroupUpgrade CR で参照する前に、PreCachingConfig CR を適用する必要があります。
  • クラスターのインストール中に、ran.openshift.io/ztp-deploy-wave アノテーションが付いたポリシーのみが TALM によって自動的に適用されます。
  • ユーザーが作成した ClusterGroupUpgrade CR の制御下で、TALM によって任意のポリシーを修正できます。

4.7.4. GitOps Operator および GitOps ZTP

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

GitOps Operator と GitOps ZTP は、クラスターのデプロイメントと設定を管理するための GitOps ベースのインフラストラクチャーを提供します。クラスターの定義と設定は、Git で宣言的な状態として維持されます。ClusterInstance CR をハブクラスターに適用すると、SiteConfig Operator がそれをインストール CR としてレンダリングします。以前のリリースでは、GitOps ZTP プラグインは SiteConfig CR からのインストール CR の生成をサポートしていました。このプラグインは現在非推奨です。PolicyGenerator または PolicyGenTemplate CR に基づいて設定 CR をポリシーに自動的にラップできるようにする別の GitOps ZTP プラグインが利用可能です。

ベースラインリファレンス設定 CR を使用して、マネージドクラスターに OpenShift Container Platform の複数のバージョンをデプロイおよび管理できます。ベースライン CR と並行してカスタム CR を使用できます。複数のバージョンごとのポリシーを同時に維持するには、Git を使用して、PolicyGenerator または PolicyGenTemplate CR でソース CR とポリシー CR のバージョンを管理します。

制限と要件
  • ClusterInstance CR の数は、ArgoCD アプリケーションごとに 300 個です。複数のアプリケーションを使用すると、1 つのハブクラスターでサポートされるクラスターの最大数を実現できます。
  • Git の source-crs/ ディレクトリーの内容は、ZTP プラグインコンテナーで提供される内容よりも優先されます。検索パスで Git が優先されるためです。
  • source-crs/ ディレクトリーは、ジェネレーターとして PolicyGenerator または PolicyGenTemplate CR を含む kustomization.yaml ファイルと同じディレクトリーに配置することが明確に求められます。このコンテキストでは、source-crs/ ディレクトリーを別の場所に配置することはできません。
エンジニアリングに関する考慮事項
  • マルチノードクラスターのアップグレードの場合、paused フィールドを true に設定することで、メンテナンス期間中に MachineConfigPool (MCP) CR を一時停止できます。MCP CR で maxUnavailable 設定を指定することで、MCP CR ごとの同時に更新されるノードの数を増やすことができます。MaxUnavailable フィールドは、MachineConfig の更新中に同時に使用できなくなるプール内のノードのパーセンテージを定義します。maxUnavailable を最大許容値に設定します。これにより、アップグレード中にクラスター内で再起動する回数が減り、アップグレード時間が短縮されます。最終的に MCP CR の一時停止を解除すると、変更されたすべての設定が 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 内の追加マニフェストには、一意で区別できる名前を使用することを強く推奨します。
  • 追加のインストールマニフェストは、ConfigMap CR を通じて ClusterInstance CR で参照されます。ConfigMap CR は、ClusterInstance CR とともに、クラスターの信頼できる唯一の情報源として機能する Git に保存する必要があります。必要に応じて、ConfigMap ジェネレーターを使用して ConfigMap CR を作成できます。

4.7.5. Agent-based Installer

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
オプションの Agent-based Installer コンポーネントは、一元的なインフラストラクチャーなしでインストール機能を提供するものです。インストールプログラムは、サーバーにマウントする ISO イメージを作成します。サーバーが起動すると、OpenShift Container Platform と提供された追加のマニフェストがインストールされます。Agent-based Installer を使用すると、ハブクラスターなしで OpenShift Container Platform をインストールできます。クラスターのインストールにはコンテナーイメージレジストリーが必要です。
制限と要件
  • インストール時に、追加のマニフェストの限定されたセットを提供できます。
  • RAN DU ユースケースに必要な MachineConfiguration CR を含める必要があります。
エンジニアリングに関する考慮事項
  • Agent-based Installer は、ベースラインの OpenShift Container Platform インストールを提供します。
  • インストール後に、Day 2 Operator と残りの RAN DU ユースケース設定をインストールします。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat