第2章 オブジェクトの最大値に合わせた環境計画

OpenShift Container Platform クラスターの計画時に以下のテスト済みのオブジェクトの最大値を考慮します。

これらのガイドラインは、最大規模のクラスターに基づいています。小規模なクラスターの場合、最大値はこれより低くなります。指定のしきい値に影響を与える要因には、etcd バージョンやストレージデータ形式などの多数の要因があります。

ほとんど場合、これらの制限値を超えると、パフォーマンスが全体的に低下します。ただし、これによって必ずしもクラスターに障害が発生する訳ではありません。

警告

Pod の起動および停止が多数あるクラスターなど、急速な変更が生じるクラスターは、実質的な最大サイズが記録よりも小さくなることがあります。

2.1. メジャーリリースについての OpenShift Container Platform のテスト済みクラスターの最大値

注記

Red Hat は、OpenShift Container Platform クラスターのサイズ設定に関する直接的なガイダンスを提供していません。これは、クラスターが OpenShift Container Platform のサポート範囲内にあるかどうかを判断するには、クラスターのスケールを制限するすべての多次元な要因を慎重に検討する必要があるためです。

OpenShift Container Platform は、クラスターの絶対最大値ではなく、テスト済みのクラスター最大値をサポートします。OpenShift Container Platform のバージョン、コントロールプレーンのワークロード、およびネットワークプラグインのすべての組み合わせがテストされているわけではないため、以下の表は、すべてのデプロイメントの規模の絶対的な期待値を表すものではありません。すべてのディメンションを同時に最大にスケーリングすることはできない場合があります。この表には、特定のワークロードとデプロイメント設定に対してテストされた最大値が含まれており、同様のデプロイメントで何が期待できるかについてのスケールガイドとして機能します。

最大値のタイプ4.x テスト済みの最大値

ノード数

2,000 [1]

Pod の数[2]

150,000

ノードあたりの Pod 数

500 [3]

コアあたりの Pod 数

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

namespace の数[4]

10,000

ビルド数

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

namespace ごとの Pod の数[5]

25,000

Ingress Controller ごとのルートとバックエンドの数

ルーターあたり 2,000

シークレットの数

80,000

config map の数

90,000

サービスの数[6]

10,000

namespace ごとのサービス数

5,000

サービスごとのバックエンド数

5,000

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

2,000

ビルド設定の数

12,000

カスタムリソース定義 (CRD) の数

512 [7]

  1. 一時停止 Pod は、2000 ノードスケールで OpenShift Container Platform のコントロールプレーンコンポーネントにストレスをかけるためにデプロイされました。同様の数値にスケーリングできるかどうかは、特定のデプロイメントとワークロードのパラメーターによって異なります。
  2. ここで表示される Pod 数はテスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、ストレージ要件により異なります。
  3. これは、ワーカーノードごとに 500 の Pod を持つ 100 ワーカーノードを含むクラスターでテストされています。デフォルトの maxPods は 250 です。500 maxPods に到達するには、クラスターはカスタム kubelet 設定を使用し、maxPods が 500 に設定された状態で作成される必要があります。500 ユーザー Pod が必要な場合は、ノード上に 10-15 のシステム Pod がすでに実行されているため、hostPrefix が 22 である必要があります。永続ボリューム要求 (PVC) が割り当てられている Pod の最大数は、PVC の割り当て元のストレージバックエンドによって異なります。このテストでは、OpenShift Data Foundation v4 (OCS v4) のみが、本書で説明されているノードごとの Pod 数に対応することができました。
  4. 有効なプロジェクトが多数ある場合、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを解放するために、デフラグを含む etcd の定期的なメンテナンスを行うことを強く推奨します。
  5. システムには、状態の変更に対する対応として特定の namespace にある全オブジェクトに対して反復する多数のコントロールループがあります。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この制限については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。
  6. 各サービスポートと各サービスのバックエンドには、iptables の対応するエントリーがあります。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。
  7. OpenShift Container Platform には、OpenShift Container Platform によってインストールされたもの、OpenShift Container Platform と統合された製品、およびユーザー作成の CRD を含め、合計 512 のカスタムリソース定義 (CRD) の制限があります。512 を超える CRD が作成されている場合は、oc コマンドリクエストのスロットリングが適用される可能性があります。

2.1.1. シナリオ例

例として、OpenShift Container Platform 4.12、OVN-Kubernetes ネットワークプラグイン、および以下のワークロードオブジェクトを使用して、500 個のワーカーノード (m5.2xl) がテストされ、サポートされています。

  • デフォルトに加えて、200 個の namespace
  • ノードあたり 60 Pod。30 台のサーバーと 30 台のクライアント Pod (合計 30k)
  • 57 イメージストリーム/ns (合計 11.4k)
  • サーバー Pod によってサポートされる 15 サービス/ns (合計 3k)
  • 以前のサービスに裏打ちされた 15 ルート/ns (合計 3k)
  • 20 シークレット/ns (合計 4k)
  • 10 設定マップ/ns (合計 2k)
  • 6 つのネットワークポリシー/ns (すべて拒否、イングレスから許可、ネームスペース内ルールを含む)
  • 57 ビルド/ns

次の要因は、クラスターのワークロードのスケーリングにプラスまたはマイナスの影響を与えることがわかっており、デプロイメントを計画するときにスケールの数値に考慮する必要があります。追加情報とガイダンスについては、営業担当者または Red Hat サポート にお問い合わせください。

  • ノードあたりの Pod 数
  • Pod あたりのコンテナー数
  • 使用されるプローブのタイプ (liveness/readiness、exec/http など)
  • ネットワークポリシーの数
  • プロジェクトまたは namespace の数
  • プロジェクトあたりのイメージストリーム数
  • プロジェクトあたりのビルド数
  • サービス/エンドポイントの数とタイプ
  • ルート数
  • シャード数
  • シークレットの数
  • config map の数

  • API 呼び出しのレート、またはクラスターのチャーン。これは、クラスター設定内で物事が変化する速さの推定値です。

    • 5 分間のウィンドウでの 1 秒あたりの Pod 作成リクエストの Prometheus クエリー: sum(irate(apiserver_request_count{resource="pods",verb="POST"}[5m]))
    • 5 分間のウィンドウで 1 秒あたりのすべての API リクエストに対する Prometheus クエリー: sum(irate(apiserver_request_count{}[5m]))
  • CPU のクラスターノードリソース消費量
  • メモリーのクラスターノードリソース消費量