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
    Copy to Clipboard Toggle word wrap 
    $ oc label node/worker-2a node/worker-2b topology.kubernetes.io/zone=rack2
    Copy to Clipboard Toggle word wrap

ホステッドクラスターの 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: ""
Copy to Clipboard Toggle word wrap

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

3.5.2. 優先クラス
リンクのコピー

4 つの組み込み優先クラスは、ホステッドクラスター Pod の優先順位とプリエンプションに影響を与えます。管理クラスター内に Pod は、次の上位から下位の順序で作成できます。

  • hypershift-operator: HyperShift Operator Pod。
  • hypershift-etcd: etcd 用の Pod。
  • hypershift-api-critical: API 呼び出しとリソース許可が成功するために必要な Pod。これらの Pod には、kube-apiserver、集約 API サーバー、Web フックなどの Pod が含まれます。
  • hypershift-control-plane : API クリティカルではないものの、クラスターバージョンの Operator など、高い優先順位が必要なコントロールプレーン内の Pod。

3.5.3. カスタムの taint と toleration
リンクのコピー

デフォルトでは、ホステッドクラスターの Pod は、control-plane および cluster taint を許容します。ただし、HostedCluster.spec.tolerations を設定することで、ホステッドクラスターがホステッドクラスターごとにこれらの taint を許容できるように、ノードでカスタムの taint を使用することもできます。

重要

ホステッドクラスターの toleration を渡す機能は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

設定例

  spec:
    tolerations:
    - effect: NoSchedule
      key: kubernetes.io/custom
      operator: Exists
Copy to Clipboard Toggle word wrap

hcp CLI の引数 --toleration を使用して、クラスターを作成するときに、ホステッドクラスターに toleration を設定することもできます。

CLI 引数の例

--toleration="key=kubernetes.io/custom,operator=Exists,effect=NoSchedule"
Copy to Clipboard Toggle word wrap

ホステッドクラスターごとにホステッドクラスター Pod の配置を細かく制御するには、カスタムの toleration を nodeSelectors とともに使用します。ホステッドクラスターのグループを同じ場所に配置し、他のホステッドクラスターから分離することができます。ホステッドクラスターをインフラノードとコントロールプレーンノードに配置することもできます。

ホステッドクラスターの toleration は、コントロールプレーンの Pod にのみ適用されます。管理クラスターで実行される他の Pod や、仮想マシンを実行する Pod などのインフラストラクチャー関連の Pod を設定するには、別のプロセスを使用する必要があります。

3.5.4. コントロールプレーンの分離
リンクのコピー

Hosted Control Plane を設定して、ネットワークトラフィックやコントロールプレーン Pod を分離できます。

3.5.4.1. ネットワークポリシーの分離
リンクのコピー

各 Hosted Control Plane は、専用の Kubernetes namespace で稼働するように指定されます。デフォルトでは、Kubernetes namespace はすべてのネットワークトラフィックを拒否します。

次のネットワークトラフィックは、Kubernetes Container Network Interface (CNI) によって適用されるネットワークポリシーによって許可されます。

  • 同じ namespace (テナント内) での Ingress Pod 間通信
  • テナントのホストされた kube-apiserver Pod へのポート 6443 の Ingress
  • network.openshift.io/policy-group:monitoring ラベルを持つ管理クラスターの Kubernetes namespace からのメトリクススクレイピングは、監視用に許可されます。

3.5.4.2. コントロールプレーン Pod の分離
リンクのコピー

各 Hosted Control Plane Pod は、ネットワークポリシーに加えて、restricted セキュリティーコンテキスト制約を使用して実行されます。このポリシーは、すべてのホスト機能へのアクセスを拒否し、お客様のコントロールプレーンをホストする各 namespace に一意に割り当てられた UID と SELinux コンテキストを使用して Pod を実行することを要求します。

このポリシーにより、次の制約が確実に実行されます。

  • Pod は特権付き Pod として実行できません。
  • Pod はホストディレクトリーボリュームをマウントできません。
  • Pod は、事前に割り当てられた UID の範囲内のユーザーとして実行する必要があります。
  • Pod は、事前に割り当てられた MCS ラベルを使用して実行する必要があります。
  • Pod はホストネットワークの namespace にアクセスできません。
  • Pod はホストネットワークのポートを公開できません。
  • Pod はホストの PID namespace にアクセスできません。
  • Pod はデフォルトで Linux ケイパビリティー KILL、MKNOD、SETUID、および SETGID をドロップします。

各管理クラスターのワーカーノード上の管理コンポーネント (kubelet や crio など) は、Hosted Control Plane を支える Pod の SELinux コンテキストからアクセスできない SELinux ラベルによって保護されます。

主要なプロセスとソケットには、次の SELinux ラベルが使用されます。

  • kubelet: system_u:system_r:unconfined_service_t:s0
  • crio: system_u:system_r:container_runtime_t:s0
  • crio.sock: system_u:object_r:container_var_run_t:s0
  • <ユーザーコンテナープロセスの例>: system_u:system_r:container_t:s0:c14,c24
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat