Red Hat Summit第6章 オブジェクトの最大値に合わせた環境計画
OpenShift Container Platform クラスターの計画時に以下のテスト済みのオブジェクトの最大値を考慮します。
これらのガイドラインは、最大規模のクラスターに基づいています。小規模なクラスターの場合、最大値はこれより低くなります。指定のしきい値に影響を与える要因には、etcd バージョンやストレージデータ形式などの多数の要因があります。
ほとんど場合、これらの制限値を超えると、パフォーマンスが全体的に低下します。ただし、これによって必ずしもクラスターに障害が発生する訳ではありません。
Pod の起動および停止が多数あるクラスターなど、急速な変更が生じるクラスターは、実質的な最大サイズが記録よりも小さくなることがあります。
6.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 数 | 2,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) の数 | 1,024 [7] |
- 一時停止 Pod は、2000 ノードスケールで OpenShift Container Platform のコントロールプレーンコンポーネントにストレスをかけるためにデプロイされました。同様の数値にスケーリングできるかどうかは、特定のデプロイメントとワークロードのパラメーターによって異なります。
- ここで表示される Pod 数はテスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、およびストレージ要件により異なります。
-
これは、31 台のサーバー (3 つのコントロールプレーン、2 つのインフラストラクチャーノード、および 26 のワーカーノード) を備えたクラスターでテストされました。2,500 のユーザー Pod が必要な場合は、各ノードが 2000 超の Pod を内包できる規模のネットワークを割り当てるために
hostPrefixを20に設定し、カスタム kubelet 設定でmaxPodsを2500に設定する必要があります。詳細は、OCP 4.13 でノードごとに 2500 Pod を実行する を参照してください。 - 有効なプロジェクトが多数ある場合、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを解放するために、デフラグを含む etcd の定期的なメンテナンスを行うことを強く推奨します。
- システムには、状態遷移への対応として、指定された namespace 内のすべてのオブジェクトに対して反復処理する必要がある制御ループがいくつかあります。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この制限については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。
-
各サービスポートと各サービスのバックエンドには、
iptablesに対応するエントリーがあります。特定のサービスのバックエンドの数は、Endpointsオブジェクトのサイズに影響を与え、システム全体に送信されるデータのサイズに影響を与えます。 -
29 台のサーバーでテストされたクラスター：3 つのコントロールプレーン、2 つのインフラストラクチャーノード、および 24 ワーカーノード。クラスターには 500 の namespace がありました。OpenShift Container Platform では、OpenShift Container Platform によってインストールされるカスタムリソース定義 (CRD)、OpenShift Container Platform と統合される製品、およびユーザーが作成した CRD を含むカスタムリソース定義 (CRD) の合計数が 1,024 に制限されます。作成された CRD の数が 1,024 を超える場合、
ocコマンドリクエストのスロットリングが適用される可能性があります。
6.1.1. シナリオ例
例として、OpenShift Container Platform 4.18、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]))
-
5 分間のウィンドウでの 1 秒あたりの Pod 作成リクエストの Prometheus クエリー:
- CPU のクラスターノードリソース消費量
- メモリーのクラスターノードリソース消費量
