第4章 制限およびスケーラビリティー
このドキュメントでは、Red Hat OpenShift Service on AWS (ROSA) クラスターでテストされたクラスターの最大値について、最大値のテストに使用されたテスト環境と設定に関する情報とともに詳しく説明します。コントロールプレーンとインフラストラクチャーノードのサイズ設定とスケーリングに関する情報も提供されます。
4.1. クラスターの最大値
Red Hat OpenShift Service on AWS (ROSA) クラスターのインストールを計画するときは、以下のテスト済みオブジェクトの最大値を考慮してください。この表は、(ROSA) クラスターでテストされた各タイプの最大制限を示しています。
これらのガイドラインは、複数のアベイラビリティーゾーン設定のコンピューティング (ワーカーとも呼ばれる) ノード 180 個のクラスターに基づいています。小規模なクラスターの場合、最大値はこれより低くなります。
| 最大値のタイプ | 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に対応するエントリーがあります。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。
