第3章 制限およびスケーラビリティー
このドキュメントでは、Red Hat OpenShift Service on AWS (ROSA) クラスターでテストされたクラスターの最大値について、最大値のテストに使用されたテスト環境と設定に関する情報とともに詳しく説明します。コントロールプレーンとインフラストラクチャーノードのサイズ設定とスケーリングに関する情報も提供されます。
3.1. ROSA テスト済みのクラスターの最大値
Red Hat OpenShift Service on AWS (ROSA) クラスターのインストールを計画するときは、以下のテスト済みオブジェクトの最大値を考慮してください。この表は、(ROSA) クラスターでテストされた各タイプの最大制限を示しています。
これらのガイドラインは、複数のアベイラビリティーゾーン設定のコンピューティング (ワーカーとも呼ばれる) ノード 102 個のクラスターに基づいています。小規模なクラスターの場合、最大値はこれより低くなります。
すべてのテストで使用される OpenShift Container Platform バージョンは OCP 4.8.0 です。
表3.1 テスト済みのクラスターの最大値
| 最大値のタイプ | 4.8 テスト済みの最大値 |
|---|---|
| ノード数 | 102 |
| Pod 数 [1] | 1.7 |
| ノードあたりの Pod 数 | 250 |
| コアあたりの Pod 数 | デフォルト値はありません。 |
| namespace 数 [2] | 3,400 |
| namespace あたりの Pod 数 [3] | 1.7 |
| サービス数 [4] | 10,000 |
| namespace あたりのサービス数 | 10,000 |
| サービスあたりのバックエンド数 | 10,000 |
| namespace あたりのデプロイメント数 [3] | 1,000 |
- ここで表示される Pod 数はテスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、およびストレージ要件により異なります。
- 有効なプロジェクトが多数ある場合は、キースペースが過度に大きくなり、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを利用できるようにするには、デフラグを含む etcd の定期的なメンテナンスを行うことが強く推奨されます。
- システムには、状態の変更に対する対応として特定の namespace にある全オブジェクトに対して反復する多数のコントロールループがあります。単一の namespace にタイプのオブジェクトの数が多くなると、ループのコストが上昇し、状態変更を処理する速度が低下します。この制限については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。
- 各サービスポートと各サービスのバックエンドには、iptables の対応するエントリーがあります。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。
OpenShift Container Platform 4.8 では、CPU コア (500 ミリコア) の半分がシステムによって予約されます (OpenShift Container Platform の以前のバージョンと比較)。