3.8. 通信事業者コア RDS のコンポーネント

Cluster Network Operator (CNO) は、クラスターのインストール中に、デフォルトの OVN-Kubernetes ネットワークプラグインを含むクラスターネットワークコンポーネントをデプロイおよび管理します。CNO を使用すると、プライマリーインターフェイスの MTU 設定、Pod の Egress にノードルーティングテーブルを使用するための OVN ゲートウェイ設定、および MACVLAN などの追加のセカンダリーネットワークを設定できます。

ネットワークトラフィックの分離をサポートするために、CNO を通じて複数のネットワークインターフェイスが設定されます。これらのインターフェイスへのトラフィックステアリングは、NMState Operator を使用して適用される静的ルートを通じて設定されます。Pod トラフィックが適切にルーティングされるように、OVN-K は routingViaHost オプションを有効にして設定されます。この設定では、Pod の Egress トラフィックに OVN ではなくカーネルルーティングテーブルと適用された静的ルートを使用します。

Whereabouts CNI プラグインは、DHCP サーバーを使用せずに、追加の Pod ネットワークインターフェイスに動的な IPv4 および IPv6 アドレス指定を提供するために使用されます。

OpenShift Data Foundation は、コンテナー向けのソフトウェア定義ストレージサービスです。OpenShift Data Foundation は、次のどちらかのモードでデプロイできます。* 内部モード: OpenShift Data Foundation のソフトウェアコンポーネントが、他のコンテナー化されたアプリケーションとともに、OpenShift Container Platform クラスターノード上にソフトウェアコンテナーとして直接デプロイされます。* 外部モード: OpenShift Data Foundation は専用のストレージクラスター (通常は Red Hat Enterprise Linux (RHEL) 上で実行される別の Red Hat Ceph Storage クラスター) にデプロイされます。これらのストレージサービスは、アプリケーションワークロードクラスターの外部で実行されます。

通信事業者コアクラスターの場合、ストレージのサポートは、次の理由により、外部モードで実行される OpenShift Data Foundation ストレージサービスによって提供されます。

OpenShift Data Foundation は、セカンダリー CNI ネットワークを使用したストレージトラフィックの分離をサポートします。

RHACM は、デプロイされたクラスターに対して、Multi Cluster Engine (MCE) のインストールと継続的な GitOps ZTP ライフサイクル管理を提供します。管理者は、メンテナンス期間中に Policy カスタムリソース (CR) をクラスターに適用することで、クラスターの設定とアップグレードを宣言的に管理します。

管理者は、TALM によって管理される RHACM ポリシーコントローラーを使用してポリシーを適用します。設定、アップグレード、およびクラスターのステータスは、ポリシーコントローラーを通じて管理されます。

マネージドクラスターをインストールすると、RHACM は、カスタムディスクパーティション分割、ロールの割り当て、マシン設定プールへの割り当てをサポートするために、個々のノードにラベルと初期イグニッション設定を適用します。これらの設定は、SiteConfig または ClusterInstance CR を使用して定義します。

TALM は、ハブクラスター上でのみ実行される Operator です。TALM は、クラスターや Operator のアップグレード、設定などの変更をネットワーク内のマネージドクラスターにどのようにデプロイするかを管理します。TALM には次のコア機能があります。

GitOps Operator は、クラスターのデプロイメントと設定を管理するための GitOps 駆動型インフラストラクチャーを提供します。クラスターの定義と設定は Git リポジトリーで管理されます。

ZTP プラグインは、SiteConfig CR から Installation CR を生成し、RHACM の PolicyGenerator CR に基づいてポリシーに設定 CR を自動的にラップすることをサポートします。

SiteConfig Operator は、ClusterInstance CR からの Installation CR の生成に対するサポートを強化します。

必要なすべてのアーティファクト (SiteConfig、ClusterInstance、PolicyGenerator、PolicyGenTemplate、および補助的なリファレンス CR) を含めて、リリースバージョンに応じて Git リポジトリーを設定する必要があります。これにより、複数のバージョンの OpenShift Container Platform と設定バージョンを、同時に、またアップグレードを通じてクラスターにデプロイして管理できるようになります。

Git の構造に関しては、お客様またはパートナーが提供するコンテンツとは別のディレクトリーにリファレンス CR を保管することが推奨されます。これにより、既存のコンテンツを上書きするだけで参照の更新をインポートできます。お客様またはパートナーが提供する CR は、生成された設定ポリシーに簡単に組み込めるように、リファレンス CR と同じ階層のディレクトリーで提供できます。

OpenShift Container Platform には Cluster Monitoring Operator (CMO) がデフォルトで含まれています。CMO は、プラットフォームコンポーネントと、必要に応じてユーザープロジェクトのモニタリング (メトリクス、ダッシュボード、アラート) を提供します。

管理者は、デフォルトのログ保持期間、カスタムアラートルールなどをカスタマイズできます。

アップストリームの Kubernetes と cAdvisor に基づく、Pod の CPU およびメモリーメトリクスのデフォルト処理では、メトリクスの精度よりも古いデータを優先するというトレードオフが行われます。これによりレポートが急増し、ユーザーが指定したしきい値によっては、誤ったアラートが作成される可能性があります。

OpenShift Container Platform は、オプトイン方式の Dedicated Service Monitor 機能をサポートしています。この機能は、上記のような動作の影響を受けない、Pod の CPU およびメモリーメトリクスの追加セットを作成するものです。詳細は、Red Hat ナレッジベースソリューション Dedicated Service Monitors - Questions and Answers を参照してください。

デフォルト設定に加えて、通信事業者コアクラスターには次のメトリクスが設定されることが予想されます。