3.2.4. サイジング計算の例
この例では、次のシナリオに対してサイジングのガイダンスを提供します。
-
hypershift.openshift.io/control-planeノードとしてラベル付けされたベアメタルワーカー 3 つ -
maxPods値を 500 に設定している - 負荷ベースの制限に応じて、予想される API レートは中または約 1000 である
| 制限の説明 | サーバー 1 | サーバー 2 |
|---|---|---|
| ワーカーノード上の仮想 CPU 数 | 64 | 128 |
| ワーカーノードのメモリー (GiB) | 128 | 256 |
| ワーカーあたりの最大 Pod 数 | 500 | 500 |
| コントロールプレーンのホストに使用されるワーカーの数 | 3 | 3 |
| 最大 QPS ターゲットレート (1 秒あたりの API リクエスト) | 1000 | 1000 |
| ワーカーノードのサイズと API レートに基づいた計算値 | サーバー 1 | サーバー 2 | 計算の注記 |
| 仮想 CPU リクエストに基づくワーカーあたりの最大ホストコントロールプレーン数 | 12.8 | 25.6 | ワーカーの仮想 CPU の数 ÷ Hosted Control Plane あたりの合計仮想 CPU 要求数 5 |
| 仮想 CPU 使用率に基づくワーカーあたりの最大 Hosted Control Plane 数 | 5.4 | 10.7 | 仮想 CPU の数 ÷ (アイドル状態の仮想 CPU 使用率の測定値 2.9 + (QPS ターゲットレート ÷ 1000) x QPS 増分 1000 あたりの仮想 CPU 使用率の測定値 9.0) |
| メモリーリクエストに基づくワーカーごとの最大 Hosted Control Plane | 7.1 | 14.2 | ワーカーのメモリー (GiB) ÷ Hosted Control Plane あたりの合計メモリー要求 18 GiB |
| メモリー使用量に基づくワーカーあたりの最大 Hosted Control Plane 数 | 9.4 | 18.8 | ワーカーのメモリー (GiB) ÷ (アイドル状態のメモリー使用率の測定値 11.1 + (QPS ターゲットレート ÷ 1000) x QPS 増分 1000 あたりのメモリー使用率の測定値 2.5) |
| ノードごとの Pod の制限に基づくワーカーごとの最大 Hosted Control Plane | 6.7 | 6.7 |
500 |
| 前述の最大値の中の最小値 | 5.4 | 6.7 | |
| 仮想 CPU の制限要因 |
| ||
| 管理クラスター内の Hosted Control Plane の最大数 | 16 | 20 | 前述の各最大値の最小値 x 3 control-plane 用ワーカー |
| 名前 | 説明 |
|
| 高可用性 Hosted Control Plane のリソース要求に基づく、クラスターがホストできる Hosted Control Plane の推定最大数。 |
|
| すべての Hosted Control Plane がクラスターの Kube API サーバーに約 50 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。 |
|
| すべての Hosted Control Plane がクラスターの Kube API サーバーに約 1000 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。 |
|
| すべての Hosted Control Plane がクラスターの Kube API サーバーに約 2000 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。 |
|
| Hosted Control Plane の既存の平均 QPS に基づいて、クラスターがホストできる Hosted Control Plane の推定最大数。アクティブな Hosted Control Plane がない場合、QPS が低くなることが予想されます。 |