第11章 クラスターごとのテスト済み最大数
OpenShift Container Platform クラスターの計画時に以下のテスト済みのクラスターオブジェクトの最大値を考慮します。
これらのガイドラインは、可能な限り規模の大きいクラスターをベースにしています。小規模なクラスターの場合、最大値は比例して低くなります。指定のしきい値に影響を与える要因には、etcd バージョンやストレージデータ形式などの多数の要因があります。
多くの場合、これらの数値を超えると、全体的にパフォーマンスが低下します。これは、必ずしもクラスターに障害が発生する訳ではありません。
OpenShift Container Platform 3.x のテスト済みクラウドプラットフォーム: Red Hat OpenStack、Amazon Web Services および Microsoft Azure
11.1. メジャーリリースについての OpenShift Container Platform のテスト済みクラスターの最大値
| 最大値のタイプ | 3.x テスト済みの最大値 |
|---|---|
|
ノード数 |
2,000 |
|
Pod 数 [1] |
150,000 |
|
250 | |
|
デフォルト値はありません。 | |
|
namespaces 数 |
10,000 |
|
ビルド数: パイプラインストラテジー |
10,000 (デフォルトの Pod: メモリー 512Mi) |
|
namespace ごとの Pod 数 [2] |
25,000 |
|
サービス数 [3] |
10,000 |
|
namespace ごとのサービス数 |
5,000 |
|
サービスごとのバックエンド数 |
5,000 |
|
namespace ごとのデプロイメント数 [2] |
2,000 |
- ここで表示される Pod 数はテスト Pod の数です。Pod の実際の数は、アプリケーションのメモリー、CPU およびストレージの要件によって異なります。
- 状態の変更に対する対応として、特定の namespace にある全オブジェクトに対して反復する必要のある、システム内のコントロールループが多数あります。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この最大値については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。]
- 各サービスポートと各サービスのバックエンドに対応するエントリーが含まれます。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。
11.2. OpenShift Container Platform のテスト済みのクラスターの最大値
| 最大値のタイプ | 3.7 テスト済みの最大値 | 3.9 テスト済みの最大値 | 3.10 テスト済みの最大値 | 3.11 テスト済みの最大値 |
|---|---|---|---|---|
|
ノード数 |
2,000 |
2,000 |
2,000 |
2,000 |
|
Pod 数 [1] |
120,000 |
120,000 |
150,000 |
150,000 |
|
250 |
250 |
250 |
250 | |
|
デフォルト値は 10 です。 |
デフォルト値は 10 です。 |
デフォルト値はありません。 |
デフォルト値はありません。 | |
|
namespaces 数 |
10,000 |
10,000 |
10,000 |
10,000 |
|
ビルド数: パイプラインストラテジー |
該当なし |
10,000 (デフォルトの Pod: メモリー 512Mi) |
10,000 (デフォルトの Pod: メモリー 512Mi) |
10,000 (デフォルトの Pod: メモリー 512Mi) |
|
namespace ごとの Pod 数 [2] |
3,000 |
3,000 |
3,000 |
25,000 |
|
サービス数 [3] |
10,000 |
10,000 |
10,000 |
10,000 |
|
namespace ごとのサービス数 |
該当なし |
該当なし |
5,000 |
5,000 |
|
サービスごとのバックエンド数 |
5,000 |
5,000 |
5,000 |
5,000 |
|
namespace ごとのデプロイメント数 [2] |
2,000 |
2,000 |
2,000 |
2,000 |
- ここで表示される Pod 数はテスト Pod の数です。Pod の実際の数は、アプリケーションのメモリー、CPU およびストレージの要件によって異なります。
- 状態の変更に対する対応として、特定の namespace にある全オブジェクトに対して反復する必要のある、システム内のコントロールループが多数あります。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この最大値については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。]
- 各サービスポートおよび各サービスバックエンドには、iptable のバックエンドに対応するエントリーが含まれます。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。
11.2.1. ルートの最大値
OpenShift Container Platform 3.11.53 では、ルーターのテストは Amazon Web Services（AWS）の 3 ノード環境で実行されました。100 の HTTP ルート、具体的には 100 のバックエンド Nginx Pod があり、keepalive は 100 に設定されます。結果は以下のようになります。
- ターゲットルートごとに 1 接続= 1 秒あたり 24,327 要求
- ターゲットルートごとに 40 接続= 1 秒あたり 20,729要求
- ターゲットルートごとに 200 接続= 1 秒あたり 17,253要求
11.3. OpenShift Container Platform クラスターの最大値をテストする環境および設定
サービスプロバイダーとしてのインフラストラクチャー: OpenStack
| ノード | vCPU | RAM(MiB) | ディスクサイズ (GiB) | パススルーディスク | カウント |
|---|---|---|---|---|---|
|
Master/Etcd [1] |
16 |
124672 |
128 |
Yes、NVMe |
3 |
|
Infra [2] |
40 |
163584 |
256 |
Yes、NVMe |
3 |
|
クラスター DNS |
1 |
1740 |
71 |
No |
1 |
|
ロードバランサー |
4 |
16128 |
96 |
No |
1 |
|
Container Native Storage [3] |
16 |
65280 |
200 |
Yes、NVMe |
3 |
|
Bastion [4] |
16 |
65280 |
200 |
No |
1 |
|
ワーカー |
2 |
7936 |
96 |
No |
2000 |
- マスター/etcd ノードは、etcd は I/O 集約型でレイテンシーの影響を受けるため、NVMe ディスクでサポートされます。
- インフラストラクチャーノードはルーター、レジストリー、ロギング、およびモニタリングをホストし、NVMe ディスクでサポートされます。
- Container Native Storage または Ceph ストレージノードは NVMe ディスクでサポートされます。
- Bastion ノードは OpenShift Container Platform ネットワークの一部であり、パフォーマンスおよびスケーリングテストのオーケストレーションに使用されます。
11.4. クラスターの最大値に合わせた環境計画
ノードでの物理リソースの過剰なサブスクライブは、Kubernetes スケジューラーが Pod の配置時に行うリソース保証に影響を与えます。swap メモリーを無効にするために実行できる処置について確認してください。
一部の最大値については、単一の namespace/ユーザーが作成するオブジェクトでのみ変更されます。これらの制限はクラスター上で数多くのオブジェクトが実行されている場合には異なる可能性があります。
本書で示されている数字は、Red Hat のテスト方法論、セットアップ、設定、およびチューニングに基づくものです。これらの数字は、独自のセットアップや環境によって異なります。
環境の計画時に、ノードに配置できる Pod の数を判断します。
クラスターごとの最大 Pod 数 / ノードごとの予想 Pod 数 = ノード数合計
ノードで適合する Pod 数は、アプリケーション自体により異なります。アプリケーションのメモリー、CPU、ストレージ要件を検討してください。
シナリオ例
クラスターごとに 2200 の Pod を設定する場合に、ノードごとに最大 250 の Pod があることを前提として、最低でも 9 のノードが必要になります。
2200 / 250 = 8.8
ノード数を 20 に増やす場合は、Pod 配分がノードごとに 110 の Pod に変わります。
2200 / 20 = 110
11.5. アプリケーション要件に合わせた環境計画
アプリケーション環境の例を考えてみましょう。
| Pod タイプ | Pod 数 | 最大メモリー | CPU コア | 永続ストレージ |
|---|---|---|---|---|
|
apache |
100 |
500MB |
0.5 |
1 GB |
|
node.js |
200 |
1 GB |
1 |
1 GB |
|
postgresql |
100 |
1 GB |
2 |
10GB |
|
JBoss EAP |
100 |
1 GB |
1 |
1 GB |
推定要件: CPU コア 550 個、メモリー 450GB およびストレージ 1.4TB
ノードのインスタンスサイズは、希望に応じて増減を調整できます。ノードのリソースはオーバーコミットされることが多く、デプロイメントシナリオでは、小さいノードで数を増やしたり、大きいノードで数を減らしたりして、同じリソース量を提供することもできます。運用上の敏捷性やインスタンスごとのコストなどの要因を考慮する必要があります。
| ノードタイプ | 数量 | CPU | RAM (GB) |
|---|---|---|---|
|
ノード (オプション 1) |
100 |
4 |
16 |
|
ノード (オプション 2) |
50 |
8 |
32 |
|
ノード (オプション 3) |
25 |
16 |
64 |
アプリケーションによっては オーバーコミット の環境に適しているものもあれば、そうでないものもあります。たとえば、Java アプリケーションや Huge Page を使用するアプリケーションの多くは、オーバーコミットに対応できません。対象のメモリーは、他のアプリケーションに使用できません。上記の例では、環境については一般的な比率として約 30 % オーバーコミットされています。