サポートコンソール開発者トライアルの開始お問い合わせ

3.2. Hosted Control Plane のサイジングに関するガイダンス

ホステッドクラスターのワークロードやワーカーノード数などの多くの要因が、一定数のコントロールプレーンノード内に収容できるホステッドクラスターの数に影響します。このサイジングガイドを使用して、ホステッドクラスターの容量計画に役立ててください。このガイダンスでは、高可用性 Hosted Control Plane トポロジーを前提としています。負荷ベースのサイジングの例は、ベアメタルクラスターで測定されました。クラウドベースのインスタンスには、メモリーサイズなど、さまざまな制限要因が含まれる場合があります。

次のリソース使用量のサイズ測定値をオーバーライドし、メトリクスサービスの監視を無効化することもできます。

次の高可用性 Hosted Control Plane の要件を参照してください。この要件は、OpenShift Container Platform バージョン 4.12.9 以降でテストされたものです。

  • 78 Pod
  • etcd 用の 3 つの 8 GiB PV
  • 最小仮想 CPU: 約 5.5 コア
  • 最小メモリー: 約 19 GiB

関連情報

3.2.1. Pod の制限

各ノードの maxPods 設定は、コントロールプレーンノードに収容できるホステッドクラスターの数に影響します。すべてのコントロールプレーンノードの maxPods 値に注意することが重要です。高可用性の Hosted Control Plane ごとに約 75 個の Pod を計画します。

ベアメタルノードの場合、マシンに十分なリソースがある場合でも、Pod 要件を考慮すると、各ノードに約 3 つの Hosted Control Plane が使用されるため、デフォルトで maxPods 設定に 250 が指定されていることが制限要因となる可能性があります。KubeletConfig 値を設定して maxPods 値を 500 に設定すると、Hosted Control Plane の密度が増し、追加のコンピュートリソースを活用できるようになります。

関連情報

3.2.2. 要求ベースのリソース制限

クラスターがホストできる Hosted Control Plane の最大数は、Pod からの Hosted Control Plane CPU およびメモリー要求に基づいて計算されます。

可用性の高い Hosted Control Plane は、5 つの仮想 CPU と 18 GB のメモリーを要求する 78 個の Pod で構成されています。これらのベースライン数値は、クラスターワーカーノードのリソース容量と比較され、Hosted Control Plane の最大数を推定します。

3.2.3. 負荷ベースの制限

クラスターがホストできる Hosted Control Plane の最大数は、Hosted Control Plane の Kubernetes API サーバーに何らかのワークロードが配置されたときの Hosted Control Plane Pod の CPU とメモリーの使用量に基づいて計算されます。

次の方法を使用して、ワークロードの増加に伴う Hosted Control Plane のリソース使用量を測定しました。

  • KubeVirt プラットフォームを使用し、それぞれ 8 つの仮想 CPU と 32 GiB を使用する 9 つのワーカーを持つホステッドクラスター

  • 次の定義に基づいて、API コントロールプレーンのストレスに重点を置くように設定されたワークロードテストプロファイル:

    • 各 namespace にオブジェクトを作成し、合計 100 の namespace まで拡張しました。
    • オブジェクトの継続的な削除と作成により、API のストレスを増加させます。
    • ワークロードの 1 秒あたりのクエリー数 (QPS) とバースト設定を高く設定して、クライアント側のスロットリングを排除します。

負荷が 1000 QPS 増加すると、Hosted Control Plane のリソース使用量が、仮想 CPU 9 個分およびメモリー 2.5 GB 分増加します。

一般的なサイジングが目的の場合は、1000 QPS の API レートを 中程度 のホステッドクラスターの負荷、2000 QPS の API レートを 高程度 のホステッドクラスターの負荷とみなしてください。

注記

このテストでは、予想される API 負荷に基づいてコンピュートリソースの使用量を増やすために、推定係数を定めています。正確な使用率は、クラスターのワークロードのタイプとペースによって異なる場合があります。

表3.5 負荷の表
Hosted Control Plane のリソース使用量のスケーリング仮想 CPUメモリー (GiB)

負荷がないときのリソース使用量

2.9

11.1

1000 QPS でのリソース使用量

9.0

2.5

負荷が 1000 QPS 増加すると、Hosted Control Plane のリソース使用量が、仮想 CPU 9 個分およびメモリー 2.5 GB 分増加します。

一般的なサイジングが目的の場合は、1000 QPS API レートを中程度のホステッドクラスターの負荷、2000 QPS API を高程度のホステッドクラスターの負荷とみなしてください。

次の例は、ワークロードおよび API レート定義の Hosted Control Plane リソースのスケーリングを示しています。

表3.6 API レートの表
QPS (API レート)仮想 CPU の使用量メモリーの使用量 (GiB)

低負荷 (50 QPS 未満)

2.9

11.1

中負荷 (1000 QPS)

11.9

13.6

高負荷 (2000 QPS)

20.9

16.1

Hosted Control Plane のサイジングは、コントロールプレーンの負荷と、大量の API アクティビティー、etcd アクティビティー、またはその両方を引き起こすワークロードに関係します。データベースの実行など、データプレーンの負荷に重点を置くホスト型 Pod ワークロードでは、API レートが高い可能性があります。

3.2.4. サイジング計算の例

この例では、次のシナリオに対してサイジングのガイダンスを提供します。

  • hypershift.openshift.io/control-plane ノードとしてラベル付けされたベアメタルワーカー 3 つ
  • maxPods 値を 500 に設定している
  • 負荷ベースの制限に応じて、予想される API レートは中または約 1000 である
表3.7 入力の制限
制限の説明サーバー 1サーバー 2

ワーカーノード上の仮想 CPU 数

64

128

ワーカーノードのメモリー (GiB)

128

256

ワーカーあたりの最大 Pod 数

500

500

コントロールプレーンのホストに使用されるワーカーの数

3

3

最大 QPS ターゲットレート (1 秒あたりの API リクエスト)

1000

1000

表3.8 サイジング計算の例

ワーカーノードのサイズと API レートに基づいた計算値

サーバー 1

サーバー 2

計算の注記

仮想 CPU リクエストに基づくワーカーあたりの最大ホストコントロールプレーン数

12.8

25.6

Hosted Control Plane ごとにワーカー仮想 CPU/5 合計仮想 CPU 要求の数

仮想 CPU 使用率に基づくワーカーあたりの最大 Hosted Control Plane 数

5.4

10.7

仮想 CPU の数 ÷ (2.9 測定されたアイドル状態の仮想 CPU 使用率 + (QPS ターゲットレート ÷ 1000) × 9.0 1000 QPS 増加あたりの測定された仮想 CPU 使用率)

メモリーリクエストに基づくワーカーごとの最大 Hosted Control Plane

7.1

14.2

Hosted Control Plane ごとにワーカーメモリー GiB/18 GiB の合計メモリーリクエスト

メモリー使用量に基づくワーカーあたりの最大 Hosted Control Plane 数

9.4

18.8

ワーカーメモリー GiB ÷ (11.1 測定されたアイドルメモリー使用量 + (QPS ターゲットレート ÷ 1000) × 2.5 1000 QPS 増加あたりの測定されたメモリー使用量)

ノードごとの Pod の制限に基づくワーカーごとの最大 Hosted Control Plane

6.7

6.7

500 maxPod/Hosted Control Plane あたり 75 Pod

前述の最大値の中の最小値

5.4

6.7

 
 

仮想 CPU の制限要因

maxPods の制限要因

 

管理クラスター内の Hosted Control Plane の最大数

16

20

前述の各最大値の最小値 x 3 control-plane 用ワーカー

表3.9 Hosted Control Plane の容量メトリクス

名前

説明

mce_hs_addon_request_based_hcp_capacity_gauge

高可用性 Hosted Control Plane のリソース要求に基づく、クラスターがホストできる Hosted Control Plane の推定最大数。

mce_hs_addon_low_qps_based_hcp_capacity_gauge

すべての Hosted Control Plane がクラスターの Kube API サーバーに約 50 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。

mce_hs_addon_medium_qps_based_hcp_capacity_gauge

すべての Hosted Control Plane がクラスターの Kube API サーバーに約 1000 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。

mce_hs_addon_high_qps_based_hcp_capacity_gauge

すべての Hosted Control Plane がクラスターの Kube API サーバーに約 2000 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。

mce_hs_addon_average_qps_based_hcp_capacity_gauge

Hosted Control Plane の既存の平均 QPS に基づいて、クラスターがホストできる Hosted Control Plane の推定最大数。アクティブな Hosted Control Plane がない場合、QPS が低くなることが予想されます。

3.2.5. Hosted Control Plane とスタンドアロンコントロールプレーン間でのインフラストラクチャーの共有

サービスプロバイダーは、スタンドアロンの OpenShift Container Platform コントロールプレーンと Hosted Control Plane 間でインフラストラクチャーを共有することで、リソースをより効率的に使用できます。3 ノードの OpenShift Container Platform クラスターは、ホステッドクラスターの管理クラスターとして使用できます。

インフラストラクチャーの共有は、リソース効率が必要な小規模なデプロイメントなど、制約のある環境で有益です。

インフラストラクチャーを共有する前に、インフラストラクチャーに Hosted Control Plane をサポートするのに十分なリソースがあることを確認してください。OpenShift Container Platform 管理クラスターには、Hosted Control Plane 以外のものは何もデプロイできません。管理クラスターに、ホステッドクラスターの合計負荷を処理するのに十分な CPU、メモリー、ストレージ、およびネットワークリソースがあることを確認してください。詳細は、「Hosted Control Plane のサイジングに関するガイダンス」を参照してください。

ワークロードは要求が厳しいものであってはならず、1 秒あたりのクエリー数 (QPS) プロファイルの範囲内で低く抑える必要があります。妥当なリスクプロファイルを維持するために、共有するホステッドクラスターは 3 つまでとしてください。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.