9.2. OpenShift Container Platform のテスト済みのクラスターの最大値

最大値のタイプ4.1 および 4.2 テスト済みの最大値4.3 テスト済みの最大値4.4 テスト済みの最大値4.5 テスト済みの最大値4.6 テスト済みの最大値

ノード数

2,000

2,000

250

500

500

Pod 数 [1]

150,000

150,000

62,500

62,500

62,500

ノードあたりの Pod 数

250

500

500

500

500

コアあたりの Pod 数

デフォルト値はありません。

デフォルト値はありません。

デフォルト値はありません。

デフォルト値はありません。

デフォルト値はありません。

namespace 数 [2]

10,000

10,000

10,000

10,000

10,000

ビルド数

10,000(デフォルト Pod RAM 512 Mi)- Pipeline ストラテジー

10,000(デフォルト Pod RAM 512 Mi)- Source-to-Image (S2I) ビルドストラテジー

10,000(デフォルト Pod RAM 512 Mi)- Source-to-Image (S2I) ビルドストラテジー

10,000(デフォルト Pod RAM 512 Mi)- Source-to-Image (S2I) ビルドストラテジー

10,000(デフォルト Pod RAM 512 Mi)- Source-to-Image (S2I) ビルドストラテジー

namespace ごとの Pod 数 [3]

25,000

25,000

25,000

25,000

25,000

サービス数[4]

10,000

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

5,000

5,000

namespace ごとのデプロイメント数[3]

2,000

2,000

2,000

2,000

2,000

  1. ここで表示される Pod 数はテスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、ストレージ要件により異なります。
  2. 有効なプロジェクトが多数ある場合、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを解放するために、デフラグを含む etcd の定期的なメンテナンスを行うことを強くお勧めします。
  3. システムには、状態の変更に対する対応として特定の namespace にある全オブジェクトに対して反復する多数のコントロールループがあります。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この制限については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。
  4. 各サービスポートと各サービスのバックエンドには、iptables の対応するエントリーがあります。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。

OpenShift Container Platform 4.6 では、CPU コア(500 ミリコア)の半分がシステムによって予約されます(OpenShift Container Platform 3.11 以前のバージョンと比較)。