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

3.5. ホステッドクラスターのワークロードの分散

OpenShift Container Platform の Hosted Control Plane を初めて使用する前に、ホステッドクラスターの Pod をインフラストラクチャーノードにスケジュールできるように、ノードを適切にラベル付けする必要があります。また、ノードのラベリングは以下の理由で重要です。

  • 高可用性と適切なワークロードのデプロイメントを確保するため。たとえば、コントロールプレーンのワークロードが OpenShift Container Platform サブスクリプションにカウントされるのを回避するために、node-role.kubernetes.io/infra ラベルを設定できます。
  • コントロールプレーンのワークロードが管理クラスター内の他のワークロードから分離されるようにするため。

  • コントロールプレーンのワークロードを、デプロイメントに応じた適切なマルチテナンシー分散レベルで設定するため。分散レベルには次のものがあります。

    • すべて共有: ホステッドクラスターのコントロールプレーンを、コントロールプレーン用に指定された任意のノードで実行できます。
    • サービングの分離を要求: 専用のノードでサービング Pod を要求します。
    • 共有なし: すべてのコントロールプレーンに専用のノードを提供します。

1 つのホステッドクラスターに専用のノードを提供する方法の詳細は、「管理クラスターノードのラベル付け」を参照してください。

重要

ワークロードには管理クラスターを使用しないでください。ワークロードは、コントロールプレーンが実行されるノード上で実行してはなりません。

3.5.1. 管理クラスターノードのラベル付け
リンクのコピー

Hosted Control Plane をデプロイするには、適切なノードのラベル付けを行う必要があります。

管理クラスターの管理者は、管理クラスターノードで次のラベルと taint を使用して、コントロールプレーンのワークロードをスケジュールします。

  • hypershift.openshift.io/control-plane: true: このラベルとテイントを使用して、Hosted Control Plane ワークロードの実行専用にノードを割り当てます。値を true に設定すると、コントロールプレーンノードが他のコンポーネント (管理クラスターのインフラストラクチャーコンポーネントや誤ってデプロイされたその他のワークロードなど) と共有されるのを回避できます。
  • hypershift.openshift.io/cluster: ${HostedControlPlane Namespace} : ノードを単一のホステッドクラスター専用にする場合は、このラベルとテイントを使用します。

コントロールプレーン Pod をホストするノードに以下のラベルを適用します。

  • node-role.kubernetes.io/infra: このラベルを使用して、サブスクリプションにコントロールプレーンワークロード数が割り当てられないようにします。

  • topology.kubernetes.io/zone: このラベルを管理クラスターノードで使用して、障害ドメイン全体に高可用性クラスターをデプロイします。ゾーンは、ゾーンが設定されているノードの場所、ラック名、またはホスト名である場合があります。たとえば、管理クラスターには、worker-1a、worker-1b、worker-2a、および worker-2b のノードがあります。worker-1a と worker-1b ノードは rack1 にあり、worker-2a ノードと worker-2b ノードは rack2 にあります。各ラックをアベイラビリティゾーンとして使用するには、次のコマンドを入力します。 

    $ oc label node/worker-1a node/worker-1b topology.kubernetes.io/zone=rack1
     
    $ oc label node/worker-2a node/worker-2b topology.kubernetes.io/zone=rack2

ホステッドクラスターの Pod には許容範囲があり、スケジューラーはアフィニティールールを使用して Pod をスケジュールします。Pod は、control-plane と Pod の cluster のテイントを許容します。スケジューラーは、hypershift.openshift.io/control-plane および hypershift.openshift.io/cluster: ${HostedControlPlane Namespace} でラベル付けされたノードへの Pod のスケジューリングを優先します。

ControllerAvailabilityPolicy オプションには、HighlyAvailable を使用します。これは、Hosted Control Plane のコマンドラインインターフェイス (hcp) がデプロイするデフォルト値です。このオプションを使用する場合は、topology.kubernetes.io/zone をトポロジーキーとして設定することで、別々の障害ドメインにまたがるホステッドクラスター内の各デプロイメントに対して Pod をスケジュールできます。別々の障害ドメインにまたがるホステッドクラスター内のデプロイメントに対する Pod のスケジュールは、高可用性コントロールプレーンでのみ可能です。

手順

ホステッドクラスターがその Pod をインフラストラクチャーノードにスケジュールすることを要求できるようにするには、次の例に示すように HostedCluster.spec.nodeSelector を設定します。 

  spec:
    nodeSelector:
      node-role.kubernetes.io/infra: ""

こうすることで、各ホステッドクラスターの Hosted Control Plane が適格なインフラストラクチャーノードワークロードとなり、基盤となる OpenShift Container Platform ノードに資格を与える必要がなくなります。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る