5.16. ハブクラスターのコンポーネント
5.16.1. Red Hat Advanced Cluster Management (RHACM) リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
Red Hat Advanced Cluster Management (RHACM) は、マルチクラスターエンジンによるインストールと、デプロイされたクラスターの継続的なライフサイクル管理機能を提供します。管理者は、メンテナンス期間中に
Policy
カスタムリソース (CR) をクラスターに適用することで、クラスターの設定とアップグレードを宣言的に管理できます。RHACM は次のような機能を提供します。
- RHACM のマルチクラスターエンジンコンポーネントを使用したゼロタッチプロビジョニング (ZTP) とクラスターの継続的なスケーリング。
- RHACM ポリシーコントローラーを介した設定、アップグレード、およびクラスターのステータス。
-
RHACM は、マネージドクラスターのインストール中に、
ClusterInstance
CR を通じて設定されたとおりに個々のノードにラベルを適用できます。 - RHACM の Topology Aware Lifecycle Manager コンポーネントは、マネージドクラスターへの設定変更を段階的にロールアウトします。
- RHACM のマルチクラスターエンジンの可観測性コンポーネントは、選択的な監視、ダッシュボード、アラート、およびメトリクスを提供します。
シングルノード OpenShift クラスターの場合、推奨されるインストール方法は、マルチクラスターエンジンでのイメージベースのインストール方法です。この方法では、クラスター定義に
ClusterInstance
CR を使用します。シングルノード OpenShift の場合、推奨されるアップグレード方法は、イメージベースのアップグレード方法です。
注記RHACM のマルチクラスターエンジンの可観測性コンポーネントを使用すると、すべてのマネージドクラスターの健全性とステータスを一元的に表示できます。デフォルトでは、すべてのマネージドクラスターは、Cluster Monitoring Operator (CMO) によって作成されたメトリクスとアラートを可観測性に送信することができます。詳細は、「可観測性」を参照してください。
- 制限と要件
- 1 つのハブクラスターによって管理されるクラスターの数の制限に関する詳細は、「通信事業者管理ハブクラスターの使用モデル」を参照してください。
ハブによって実際に管理できるマネージドクラスターの数は、次のようなさまざまな要因によって異なります。
- 各マネージドクラスターにおけるリソースの可用性
- ポリシーの複雑さとクラスターのサイズ
- ネットワーク使用量
- ワークロードの要求と分散
- ハブとマネージドクラスターの間に、十分な双方向接続が確立されている必要があります。
- エンジニアリングに関する考慮事項
- サードパーティーのリソースを含めるようにクラスターのバックアップおよび復元 Operator を設定できます。
- ポリシーを通じて設定を定義するときは、RHACM ハブ側のテンプレートを使用することを強く推奨します。この機能は、クラスターごとまたはグループごとに有効にすることで、クラスター群の管理に必要なポリシーの数を削減します。たとえば、地域のコンテンツやハードウェアタイプのコンテンツをポリシーでテンプレート化し、クラスターまたはグループごとに置換します。
-
マネージドクラスターには、通常、個々のクラスターに固有の設定値がいくつかあります。このような設定値は、クラスター名に基づいて
ConfigMap
CR から取得した値を使用して、RHACM ポリシーハブ側のテンプレートを使用して管理してください。
5.16.2. Topology Aware Lifecycle Manager リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
TALM は、ハブクラスター上でのみ実行される Operator であり、クラスターのアップグレード、Operator のアップグレード、クラスター設定などの変更をネットワークにロールアウトする方法を管理します。TALM は次の機能をサポートしています。
- ユーザーが設定可能なバッチで、クラスター群にポリシー更新を段階的にロールアウトします。
-
クラスターごとのアクションにより、マネージドクラスターの設定変更に従って、
ztp-done
ラベルまたはその他のユーザー設定可能なラベルを追加します。 TALM は、アップグレードを開始する前に、OpenShift Container Platform、OLM Operator、および追加イメージを、シングルノード OpenShift クラスターに必要に応じて事前キャッシュする機能をサポートしています。シングルノード OpenShift クラスターのアップグレードに推奨されるイメージベースのアップグレード方法を使用する場合、事前キャッシュ機能は適用されません。
-
オプションの事前キャッシュ設定は、
PreCachingConfig
CR を使用して指定します。 - イメージのフィルタリングを設定して未使用のコンテンツを除外できます。
- 事前キャッシュの前後に、定義された容量要件パラメーターを使用してストレージが検証されます。
-
オプションの事前キャッシュ設定は、
- 制限と要件
- TALM は、500 個のバッチでの同時クラスターアップグレードをサポートしています。
- 事前キャッシュは、シングルノード OpenShift クラスタートポロジーに限られています。
- エンジニアリングに関する考慮事項
-
PreCachingConfig
カスタムリソース (CR) は任意です。OpenShift Container Platform や OLM などのプラットフォーム関連のイメージのみを事前キャッシュする場合、これを作成する必要はありません。 - TALM は、Red Hat Advanced Cluster Management のポリシーによるハブ側テンプレートの使用をサポートしています。
-
5.16.3. GitOps Operator および GitOps ZTP リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
GitOps Operator と GitOps ZTP は、クラスターのデプロイメントと設定を管理するための GitOps ベースのインフラストラクチャーを提供します。クラスターの定義と設定は、Git で宣言的な状態として維持されます。
ClusterInstance
カスタムリソース (CR) をハブクラスターに適用すると、SiteConfig
Operator によってその CR をインストール CR としてレンダリングできます。以前のリリースでは、GitOps ZTP プラグインはSiteConfig
CR からのインストール CR の生成をサポートしていました。このプラグインは現在非推奨です。PolicyGenerator
またはPolicyGenTemplate
CR に基づいて設定 CR をポリシーに自動的にラップできるようにする別の GitOps ZTP プラグインが利用可能です。ベースラインリファレンス設定 CR を使用して、マネージドクラスターに OpenShift Container Platform の複数のバージョンをデプロイおよび管理できます。ベースライン CR と並行してカスタム CR を使用できます。複数のバージョンごとのポリシーを同時に維持するには、Git を使用して、
PolicyGenerator
またはPolicyGenTemplate
CR でソース CR とポリシー CR のバージョンを管理します。- 制限と要件
-
各 ArgoCD アプリケーションに対して 300 個のシングルノード
SiteConfig
CR を同期できます。複数のアプリケーションを使用すると、1 つのハブクラスターでサポートされるクラスターの最大数を実現できます。 - クラスターまたはノードの削除時に、マネージドクラスターとその関連リソースを一貫して完全にクリーンアップするには、バックグラウンド削除モードを使用するように ArgoCD を設定する必要があります。
-
各 ArgoCD アプリケーションに対して 300 個のシングルノード
- エンジニアリングに関する考慮事項
-
コンテンツを更新するときに混乱や意図しない上書きを避けるために、
source-crs
ディレクトリーと追加のマニフェスト内のカスタム CR には、一意で区別できる名前を使用してください。 - リファレンスソース CR をカスタム CR と別のディレクトリーに保存します。これにより、必要に応じてリファレンス CR を簡単に更新できるようになります。
- 複数のバージョンに対応し、OpenShift Container Platform の各バージョンに対して一貫したポリシーが生成されるように、すべてのソース CR とポリシー作成 CR を、バージョン管理された Git リポジトリーに保存してください。
-
コンテンツを更新するときに混乱や意図しない上書きを避けるために、
5.16.4. Local Storage Operator リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
-
Local Storage Operator を使用して、アプリケーションで
PVC
リソースとして使用できる永続ボリュームを作成できます。作成するPV
リソースの数とタイプは、要件によって異なります。 - エンジニアリングに関する考慮事項
-
永続ボリュームを作成する前に、
PV
CR のバックアップストレージを作成してください。これは、パーティション、ローカルボリューム、LVM ボリューム、または完全なディスクにすることができます。 -
ディスクとパーティションが正しく割り当てられていることを確認するには、各デバイスへのアクセスに使用されるハードウェアパス別に
LocalVolume
CR 内のデバイスリストを参照します (例:/dev/disk/by-path/<id>
)。論理名 (例:/dev/sda
) は、ノードの再起動後も一貫性が保たれるとは限りません。
-
永続ボリュームを作成する前に、
5.16.5. Red Hat OpenShift Data Foundation リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
- Red Hat OpenShift Data Foundation は、ハブクラスターにファイル、ブロック、およびオブジェクトストレージサービスを提供します。
- 制限と要件
- 内部モードの Red Hat OpenShift Data Foundation (ODF) では、必要な基盤となるストレージを提供するストレージクラスを Local Storage Operator が定義する必要があります。
- 通信事業者管理クラスターの計画を立てる際には、ODF インフラストラクチャーとネットワーク要件を考慮してください。
- デュアルスタックのサポートは限定的です。ODF IPv4 はデュアルスタッククラスターでサポートされています。
- エンジニアリングに関する考慮事項
- ストレージ容量が不足すると回復が困難になる可能性があるため、容量の警告にはすぐに対処してください。容量のプランニング を参照してください。
5.16.6. ロギング リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
- リモートアーカイブと分析のために、ログを収集してノードから送信するには、Cluster Logging Operator を使用します。リファレンス設定では、Kafka を使用して監査ログとインフラストラクチャーログをリモートアーカイブに送信します。
- 制限と要件
- リファレンス設定には、ローカルのログストレージは含まれていません。
- リファレンス設定には、ハブクラスターでのマネージドクラスターログの集約は含まれていません。
- エンジニアリングに関する考慮事項
- クラスターの CPU 使用率の影響は、生成されるログの数またはサイズと、設定されたログフィルタリングの量によって決まります。
- リファレンス設定には、アプリケーションログの送信は含まれていません。設定にアプリケーションログを含めるには、アプリケーションのロギングレートを評価し、予約セットに十分な追加の CPU リソースを割り当てる必要があります。
5.16.7. OpenShift API for Data Protection リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
バックアップ機能が有効な場合、OpenShift API for Data Protection (OADP) Operator は Red Hat Advanced Cluster Management (RHACM) によって自動的にインストールされ、管理されます。
OADP Operator は、OpenShift Container Platform クラスター内のワークロードのバックアップと復元を容易にします。アップストリームのオープンソースプロジェクト Velero をベースとしており、永続ボリュームを含む特定のプロジェクトの Kubernetes リソースをすべてバックアップおよび復元できます。
ハブクラスターに OADP Operator を配置することは必須ではありません。しかし、ハブクラスターのクラスターバックアップ、障害復旧、および高可用性アーキテクチャーのために、これを配置することを強く推奨します。RHACM の障害復旧ソリューションを使用するには、OADP Operator を有効にする必要があります。リファレンス設定では、RHACM Operator によって提供される
MultiClusterHub
カスタムリソース (CR) を介してバックアップ (OADP) が有効になります。- 制限と要件
- クラスターには OADP の 1 つのバージョンのみインストールできます。RHACM の障害復旧機能には、RHACM によってインストールされたバージョンを使用する必要があります。
- エンジニアリングに関する考慮事項
- このリリースではエンジニアリングに関する考慮事項の更新はありません。