第5章 ROSA with HCP の制限とスケーラビリティー
このドキュメントでは、Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Plane のテスト済みクラスターの最大値と、最大値のテストに使用したテスト環境および設定について詳しく説明します。ROSA with HCP クラスターの場合、コントロールプレーンはサービス AWS アカウントで完全に管理され、クラスターとともに自動的にスケーリングされます。
5.1. ROSA with HCP クラスターの最大値
Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Plane クラスターのインストールを計画するときは、次のテスト済みオブジェクトの最大値を考慮してください。この表は、ROSA with HCP クラスターでテストされた各タイプの上限を示しています。
このガイドラインは、500 個のコンピュート (ワーカー) ノードからなるクラスターに基づいています。小規模なクラスターの場合、最大値はこれより低くなります。
ROSA with HCP 4.14.x および 4.15.x クラスターを実行しているお客様は、500 ワーカーノードに拡張するには、少なくとも z-stream バージョン 4.14.28 または 4.15.15 以降が必要です。それ以前のバージョンの場合、ワーカーノードの最大数は 90 です。
最大値のタイプ | 4.x テスト済みの最大値 |
---|---|
Pod 数 [1] | 25,000 |
ノードあたりの Pod 数 | 250 |
コアあたりの Pod 数 | デフォルト値はありません。 |
namespace 数 [2] | 5,000 |
namespace あたりの Pod 数 [3] | 25,000 |
サービス数 [4] | 10,000 |
namespace ごとのサービス数 | 5,000 |
サービスごとのバックエンド数 | 5,000 |
namespace ごとのデプロイメント数 [3] | 2,000 |
- ここで表示される Pod 数はテスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、およびストレージ要件により異なります。
- 有効なプロジェクトが多数ある場合は、キースペースが過度に大きくなり、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを利用できるようにするには、デフラグを含む etcd の定期的なメンテナンスを行うことが強く推奨されます。
- システムには、状態遷移への対応として、指定された namespace 内のすべてのオブジェクトに対して反復処理する必要がある制御ループがいくつかあります。単一の namespace にタイプのオブジェクトの数が多くなると、ループのコストが上昇し、状態変更を処理する速度が低下します。この制限については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。
-
各サービスポートと各サービスのバックエンドには、
iptables
に対応するエントリーがあります。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。