1.2.4. クラスターのサイジング
Red Hat Advanced Cluster Management for Kubernetes クラスターは一意で、以下のガイドラインは一意のデプロイメントサイズを提供します。推奨事項は、サイズと目的で分類されています。Red Had Advanced Cluster Management は、サポートサービスのサイジングと配置に以下の 3 つの条件が適用されます。
- クラスター全体で障害の発生する可能性のあるドメインを分離するアベイラビリティーゾーン。通常のクラスターには、3 つ以上のアベイラビリティーゾーンでほぼ同等の容量のワーカーノードが必要です。
- vCPU の予約と制限をもとに、コンテナーに割り当てるワーカーノードの vCPU 容量が確立されます。vCPU は Kubernetes のコンピュートユニットと同じです。詳細は、Kubernetes の Meaning of CPU を参照してください。
- メモリーの予約と制限。コンテナーに割り当てるワーカーノードのメモリー容量を確立します。予約は CPU またはメモリーの 下限 を、制限は 上限 を決定します。
- 製品によって管理され、Kubernetes が使用する etcd クラスターに保存される永続データ。ベストプラクティス: OpenShift Container Platform では、3 つのアベイラビリティーゾーンにクラスターのマスターノードを分散させてください。
1.2.4.1. 製品環境
注記: 以下の要件は、最小要件ではありません。
| OpenShift Container Platform ノードロール | アベイラビリティーゾーン | データストア | 予約済みメモリーの合計 (下限) | 予約済み CPU の合計 (下限) |
|---|---|---|---|---|
| マスター | 3 | etcd x 3 | OpenShift Container Platform のサイジングガイドライン別 | OpenShift のサイジングガイドライン別 |
| ワーカー | 3 | redisgraph/redis x 1 | 12 GB | 6 CPU |
OpenShift Container Platform クラスターは、Red Hat Advanced Cluster Management for Kubernetes に加え、追加のサービスを実行してクラスター機能をサポートします。以下のノードサイズ (以下の記載している 3 種のノードは、3 つのアベイラビリティーゾーンに均等に分散) を推奨します。
1.2.4.1.1. シナリオ例: 2000 の単一ノードの OpenShift Container Platform クラスターの作成および管理
以下の表は、Red Hat Advanced Cluster Management を使用して 1000 個の単一ノード OpenShift (SNO) クラスター (230 以上を同時にプロビジョニング) を作成し、ハブクラスターで 1000 の SNO クラスターを管理する最小要件を示しています。
| OpenShift Container Platform ノードロール | ノード数 | 必要な永続ボリューム (PV) | 使用済みメモリー (インスタンス別) | 使用済み CPU (インスタンス別) |
|---|---|---|---|---|
| マスター | 3 |
アシスト付きインストーラー: 3 つのノードごとに 110 Gb (それぞれ 3 つのノードについて PostgreSQL - 25 Gb)、3 つのノードごとに etcd。注記: | 30 GB | 10 CPU |
| ワーカー | 3 | 可観測性: 各ノードの 25 Gb (ユーザー指定の、検索の無効化) の 25 Gbredisgraph は必要ありません。 | 44 GB | 17 CPU |
注記: 使用率の値は、複数のクラスターが同時に作成された間に収集されたピーク値です。
1.2.4.1.2. Amazon Web Services 上の OpenShift Container Platform
詳細は、OpenShift Container Platform 製品ドキュメントの Amazon Web Services の情報 を参照してください。また、マシンタイプ についても確認してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ: m5.xlarge
- vCPU: 4
- メモリー: 16 GB
- ストレージサイズ: 120 GB
1.2.4.1.3. Google Cloud Platform での OpenShift Container Platform クラスター
クォータの詳細は、Google Cloud Platform の製品ドキュメント を参照してください。また、マシンタイプ についても確認してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ: N1-standard-4 (0.95–6.5 GB)
- vCPU: 4
- メモリー: 15 GB
- ストレージサイズ: 120 GB
1.2.4.1.4. Microsoft Azure での OpenShift Container Platform クラスター
詳細は、以下の 製品ドキュメント を参照してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ: Standard_D4_v3
- vCPU: 4
- メモリー: 16 GB
- ストレージサイズ: 120 GB
1.2.4.1.5. VMware vSphere での OpenShift Container Platform クラスター
詳細は、以下の 製品ドキュメント を参照してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ:
- メモリー: 16 GB
- ストレージサイズ: 120 GB
- vCPUs: 4
- ソケットごとのコア: 2
1.2.4.1.6. IBM Z システムの OpenShift Container Platform
詳細は、OpenShift Container Platform ドキュメントの クラスターの IBM Z システムへのインストール を参照してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ:
- メモリー: 16 GB
- ストレージサイズ: 100 GB
vCPU: 10
IBM Z システムには、同時マルチスレッド (SMT) を設定する機能があり、各コアで実行できる vCPU の数を拡張します。SMT を設定している場合は、1 つの物理コア (IFL) は 2 つの論理コア (スレッド) を提供します。ハイパーバイザーは、2 つ以上の vCPU を提供できます。
1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効になっていると、数式 (コアごとのスレッド × コア数) × ソケット数 = vCPU を使用して対応する比率を計算します。
SMT の詳細は、Simultaneous multithreading を参照してください。
1.2.4.1.7. IBM Power Systems 上の OpenShift Container Platform
詳細は、OpenShift Container Platform ドキュメントの クラスターの Power システムへのインストール を参照してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ:
- メモリー: 16 GB
- ストレージサイズ: 120 GB
vCPU: 16
IBM Power システムには、同時マルチスレッド (SMT) を設定する機能があり、各コアで実行できる vCPU の数を拡張します。SMT を設定した場合、その SMT レベルでは vCPU 16 個という要件を満たす方法が決まります。以下は、最も一般的な設定です。
- SMT-8 (IBM PowerVM を実行しているシステムのデフォルト設定) で実行しているコア 2 つでは、必要とされる 16 個の vCPU を提供します。
SMT-4 で実行しているコア 4 つでは、必要とされる 16 個の vCPU を提供します。
SMT の詳細は、Simultaneous multithreading を参照してください。
1.2.4.1.8. ベアメタルアセット上の OpenShift Container Platform クラスター
詳細は、以下の 製品ドキュメント を参照してください。
Red Hat Advanced Cluster Management for Kubernetes ハブクラスターは、OpenShift Container Platform ベアメタルにインストールし、サポートできます。ハブクラスターは、スケジュール可能な 3 つのコントロールプレーンノードがあり、追加のワーカーが 0 の、コンパクトなベアメタルトポロジーで実行できます。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ:
- メモリー: 16 GB
- ストレージサイズ: 120 GB
- vCPUs: 4
