6.2. OpenShift Container Platform のテスト済みのクラスターの最大値
| 制限の種類 | 3.9 テスト済みの最大値 | 3.10 テスト済みの最大値 | 3.11 テスト済みの最大値 | 4.1 テスト済みの最大値 |
|---|---|---|---|---|
| ノード数 | 2,000 | 2,000 | 2,000 | 2,000 |
| Pod 数 [a] | 150,000 | 150,000 | 150,000 | 150,000 |
| ノードあたりの Pod 数 | 250 | 250 | 250 | 250 |
| コアあたりの Pod 数 | デフォルト値はありません。 | デフォルト値はありません。 | デフォルト値はありません。 | デフォルト値はありません。 |
| namespace 数 [b] | 10,000 | 10,000 | 10,000 | 10,000 |
| ビルド数 | 10,000 (デフォルトの Pod RAM: 512 Mi) | 10,000 (デフォルトの Pod RAM: 512 Mi) | 10,000 (デフォルトの Pod RAM: 512 Mi) | 10,000 (デフォルトの Pod RAM: 512 Mi) |
| namespace ごとの Pod 数 [c] | 3,000 | 3,000 | 25,000 | 25,000 |
| サービス数 [d] | 10,000 | 10,000 | 10,000 | 10,000 |
| namespace ごとのサービス数 | 5,000 | 5,000 | 5,000 | 5,000 |
| サービスごとのバックエンド数 | 5,000 | 5,000 | 5,000 | 5,000 |
| namespace ごとのデプロイメント数 [c] | 2,000 | 2,000 | 2,000 | 2,000 |
[a]
ここで表示される Pod 数はテスト Pod の数です。実際の Pod 数は、アプリケーションのメモリー、CPU、ストレージ要件により異なります。
[b]
有効なプロジェクトが多数ある場合、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを解放するために、デフラグを含む etcd の定期的なメンテナンスを行うことを強くお勧めします。
[c]
システムには、状態の変更に対する対応として特定の namespace にある全オブジェクトに対して反復する多数のコントロールループがあります。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この制限については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。
[d]
各サービスポートと各サービスのバックエンドには、iptables の対応するエントリーがあります。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。
| ||||
OpenShift Container Platform 4.1 では、CPU コア (500 ミリコア) の半分がシステムによって予約されます (OpenShift Container Platform 3.11 以前のバージョンと比較)。
OpenShift Container Platform 4.1 では、テスト済みのノード制限は、スケーリングテストが高いノード数で実行できるようになるまで低く設定されます。
