Red Hat Training
A Red Hat training course is available for OpenShift Container Platform
第10章 クラスターの制限
10.1. 概要
以下のトピックでは、OpenShift Container Platform のオブジェクトの制限についてまとめています。
多くの場合、これらのしきい値を超えると、全体的にパフォーマンスが低下します。必ずしも、クラスターに障害が発生するわけではありません。
このトピックで紹介している制限によっては、最大限のクラスターを対象にしているものもあります。クラスターの規模が小さい場合には、制限も比例して少なくなります。
etcd バージョンやストレージデータ形式など、記載のしきい値に影響を与える要因は多数あります。
10.2. OpenShift Container Platform クラスターの制限
| 制限の種類 | 3.7 の制限 | 3.9 の制限 | 3.10 の制限 |
|---|---|---|---|
|
ノード数 [a] |
2,000 |
2,000 |
2,000 |
|
Pod 数 [b] |
120,000 |
120,000 |
150,000 |
|
250 |
250 |
250 | |
|
デフォルト値は 10 です。サポートしている最大値は、ノードごとの Pod 数と同じです。 |
デフォルト値は 10 です。サポートしている最大値は、ノードごとの Pod 数と同じです。 |
デフォルト値はありません。サポートしている最大値は、ノードごとの Pod 数と同じです。 | |
|
namespaces 数 |
10,000 |
10,000 |
10,000 |
|
ビルド数: パイプラインストラテジー |
該当なし |
10,000 (デフォルトの Pod: メモリー 512Mi) |
10,000 (デフォルトの Pod: メモリー 512Mi) |
|
namespace ごとの Pod 数[c] |
3,000 |
3,000 |
3,000 |
|
サービス数 [d] |
10,000 |
10,000 |
10,000 |
|
namespace ごとのサービス数 |
該当なし |
該当なし |
5,000 |
|
サービスごとのバックエンド数 |
5,000 |
5,000 |
5,000 |
|
namespace ごとのデプロイメント数[c] |
2,000 |
2,000 |
2,000 |
[a]
記載の制限を超えるクラスターはサポートされません。複数のクラスターに分割することを検討してください。
[b]
ここに記載の Pod 数は、テスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、ストレージ要件により異なります。
[c]
これは、状態の変更に対する対応として、特定の namespace にある全オブジェクトに対して反復する必要のある、システム内のコントロールループ数のことです。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。
[d]
iptables では、各サービスポートと各サービスのバックエンドに対応するエントリーが含まれます。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。
| |||
10.3. クラスターの制限に合わせた環境計画
ノードで物理リソースを過剰にサブスクライブすると、Kubernetes スケジューラーが Pod の配置時に行うリソース保証に影響を与えます。Swap メモリーを無効にするために実行できる処置について確認してください。
環境の計画時に、ノードに配置できる Pod の数を判断します。
クラスターごとの最大 Pod 数 / ノードごとの予想 Pod 数 = ノード数合計
ノードで適合する Pod 数は、アプリケーション自体により異なります。アプリケーションのメモリー、CPU、ストレージ要件を検討してください。
シナリオ例
クラスターごとに 2200 の Pod を設定する場合に、ノードごとに最大 250 の Pod があることを前提として、最低でも 9 のノードが必要になります。
2200 / 250 = 8.8
ノード数を 20 に増やす場合には、ノード配分がノードごとに 110 の Pod に変わります。
2200 / 20 = 110
10.4. アプリケーション要件に合わせた環境計画
アプリケーション環境の例を考えてみましょう。
| 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 アプリケーションや、大きいページを使用するアプリケーションの多くは、オーバーコミットに対応できません。対象のメモリーは、他のアプリケーションに使用できません。上記の例では、環境は一般的な比率として約 30 % オーバーコミットされています。
