3.5. ホステッドクラスターのワークロードの分散
OpenShift Container Platform の Hosted Control Plane を初めて使用する前に、ホステッドクラスターの Pod をインフラストラクチャーノードにスケジュールできるように、ノードを適切にラベル付けする必要があります。また、ノードのラベリングは以下の理由で重要です。
-
高可用性と適切なワークロードのデプロイメントを確保するため。たとえば、
node-role.kubernetes.io/infraラベルを設定して、OpenShift Container Platform サブスクリプションに control-plane ワークロード数が割り当てられないようにできます。 - コントロールプレーンのワークロードが管理クラスター内の他のワークロードから分離されるようにするため。
ワークロードには管理クラスターを使用しないでください。ワークロードは、コントロールプレーンが実行されるノード上で実行してはなりません。
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 をインフラストラクチャーノードにスケジュールすることを要求できるようにするには、次の例に示すように HostedCluster.spec.nodeSelector を設定します。
spec:
nodeSelector:
role.kubernetes.io/infra: ""こうすることで、各ホステッドクラスターの 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
OpenShift Virtualization 上の Hosted Control Plane の場合、ホステッドクラスターの 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
hcp CLI の引数 --toleration を使用して、クラスターを作成するときに、ホステッドクラスターに toleration を設定することもできます。
CLI 引数の例
--toleration="key=kubernetes.io/custom,operator=Exists,effect=NoSchedule"
ホステッドクラスターごとにホステッドクラスター Pod の配置を細かく制御するには、カスタムの toleration を nodeSelectors とともに使用します。ホステッドクラスターのグループを同じ場所に配置し、他のホステッドクラスターから分離することができます。ホステッドクラスターをインフラノードとコントロールプレーンノードに配置することもできます。
ホステッドクラスターの toleration は、コントロールプレーンの Pod にのみ適用されます。管理クラスターで実行される他の Pod や、仮想マシンを実行する Pod などのインフラストラクチャー関連の Pod を設定するには、別のプロセスを使用する必要があります。
