Hosted Control Plane


OpenShift Container Platform 4.19

OpenShift Container Platform で Hosted Control Plane を使用する

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Container Platform の Hosted Control Plane を管理するための手順を説明します。Hosted Control Plane を使用すると、コントロールプレーンごとに専用の物理マシンまたは仮想マシンを用意することなく、管理クラスター上の Pod としてコントロールプレーンを作成できます。

第1章 Hosted Control Plane のリリースノート

リリースノートには、新機能、非推奨機能、変更、既知の問題に関する情報が記載されています。

1.1. OpenShift Container Platform 4.19 用の Hosted Control Plane のリリースノート

このリリースでは、OpenShift Container Platform 4.19 用の Hosted Control Plane が利用可能になりました。OpenShift Container Platform 4.19 用の Hosted Control Plane は、multicluster engine for Kubernetes Operator バージョン 2.9 をサポートしています。

1.1.1. 新機能および機能拡張

1.1.1.1. カスタム DNS 名の定義

クラスター管理者は、ホステッドクラスターのカスタム DNS 名を定義して、DNS 名の管理および使用方法の柔軟性を高めることができるようになりました。詳細は、カスタム DNS 名の定義 を参照してください。

1.1.1.2. ホステッドクラスターの AWS タグの追加または更新

クラスター管理者は、さまざまな種類のリソースに対して Amazon Web Services (AWS) タグを追加または更新できます。詳細は、ホステッドクラスターの AWS タグの追加または更新 を参照してください。

1.1.1.3. OADP を使用したホステッドクラスターの自動障害復旧

ベアメタルまたは Amazon Web Services (AWS) プラットフォームでは、OpenShift API for Data Protection (OADP) を使用して、ホステッドクラスターの障害復旧を自動化できます。詳細は、OADP を使用したホステッドクラスターの自動障害復旧 を参照してください。

1.1.1.4. ベアメタルプラットフォーム上のホステッドクラスターの障害復旧

ベアメタルプラットフォーム上のホステッドクラスターの場合、OADP を使用して、データプレーンとコントロールプレーンのワークロードのバックアップや、同じ管理クラスターまたは新しい管理クラスターへの復元などの障害復旧タスクを完了できます。詳細は、OADP を使用したホステッドクラスターの障害復旧 を参照してください。

1.1.1.5. Red Hat OpenStack Platform (RHOSP) 17.1 上の Hosted Control Plane (テクノロジープレビュー)

RHOSP 17.1 上の Hosted Control Plane がテクノロジープレビュー機能としてサポートされるようになりました。

詳細は、OpenStack での Hosted Control Plane のデプロイ を参照してください。

1.1.1.6. AWS でのノードプール容量ブロックの設定

Amazon Web Services (AWS) 上の Hosted Control Plane のノードプール容量ブロックを設定できるようになりました。詳細は、AWS でのノードプール容量ブロックの設定 を参照してください。

1.1.2. バグ修正

  • 以前は、管理 OpenShift クラスター内の IDMS または ICSP で registry.redhat.io または registry.redhat.io/redhat を参照するソースが定義されており、ミラーレジストリーに必要な OLM カタログイメージが含まれていない場合、不正なイメージプルが原因で HostedCluster リソースのプロビジョニングが停止していました。その結果、HostedCluster リソースはデプロイされず、ブロックされたままになり、ミラーレジストリーから重要なカタログイメージを取得できませんでした。

    このリリースでは、認可エラーのために必要なイメージをプルできない場合、プロビジョニングが明示的に失敗するようになりました。レジストリーのオーバーライドのロジックが改善され、OLM CatalogSource イメージの解決時に registry.redhat.io などのレジストリーのルートでのマッチングが可能になりました。レジストリーのオーバーライドによって正常なイメージが得られなかった場合に、元の ImageReference を使用するためのフォールバックメカニズムも導入されています。

    その結果、ミラーレジストリーに必要な OLM カタログイメージが不足しているシナリオでも、システムが適切な場合に元のソースからプルするように正しくフォールバックするため、HostedCluster リソースを正常にデプロイできます。(OCPBUGS-56492)

  • 以前は、コントロールプレーンコントローラーは機能セットに対して正しい CVO マニフェストを適切に選択していませんでした。その結果、機能セットの間違った CVO マニフェストがホストされたクラスターにデプロイされた可能性がありました。実際には、CVO マニフェストは機能セット間で異なることはなかったため、この問題は実際には影響を与えませんでした。このリリースでは、コントロールプレーンコントローラーが、機能セットに対して正しい CVO マニフェストを適切に選択するようになりました。その結果、機能セットの正しい CVO マニフェストがホステッドクラスターに展開されます。(OCPBUGS-44438)
  • 以前は、カスタム CA によって署名された証明書を提供する HostedCluster リソースにセキュアプロキシーを設定すると、その CA はノードの初期 Ignition 設定に含まれていませんでした。その結果、Ignition に失敗したためノードは起動しませんでした。このリリースでは、プロキシーの信頼された CA を初期 Ignition 設定に含めることで問題が修正され、ノードのブートと Ignition が成功するようになりました。(OCPBUGS-56896)
  • 以前は、管理クラスターの IDMS または ICSP リソースが、ユーザーがイメージ置き換え用のミラーまたはソースとしてルートレジストリー名のみを指定する可能性があることを考慮せずに処理されていました。その結果、ルートレジストリー名のみを使用する IDMS または ICSP エントリーが期待どおりに動作しませんでした。このリリースでは、ミラーの置き換えロジックが、ルートレジストリー名のみが指定されているケースを正しく処理するようになりました。その結果、問題が発生しなくなり、ルートレジストリーミラーの置き換えがサポートされるようになりました。(OCPBUGS-55693)
  • 以前は、OADP プラグインは間違った namespace で DataUpload オブジェクトを検索していました。その結果、バックアッププロセスは無期限に停止しました。このリリースでは、プラグインはバックアップオブジェクトのソース namespace を使用するため、この問題は発生しなくなりました。(OCPBUGS-55469)
  • 以前は、ユーザーが hc.spec.configuration.apiServer.servingCerts.namedCertificates フィールドに追加したカスタム証明書の SAN が、Kubernetes Agent Server (KAS) の hc.spec.services.servicePublishingStrategy フィールドに設定されたホスト名と競合していました。その結果、KAS 証明書は新しいペイロードを生成するための証明書のセットに追加されず、HostedCluster リソースに参加しようとした新しいノードでは証明書の検証に問題が発生しました。このリリースでは、早期に失敗してユーザーに問題について警告する検証手順が追加され、問題が発生しなくなりました。(OCPBUGS-53261)
  • 以前は、共有 VPC にホステッドクラスターを作成すると、プライベートリンクコントローラーが共有 VPC 内の VPC エンドポイントを管理するための共有 VPC ロールを引き受けられない場合がありました。このリリースでは、プライベートリンクコントローラーでのすべてのリコンシリエーションに対してクライアントが作成されるため、無効なクライアントから回復できます。その結果、ホステッドクラスターエンドポイントとホステッドクラスターが正常に作成されます。(OCPBUGS-45184)
  • 以前は、Agent プラットフォーム上の NodePool API で、ARM64 アーキテクチャーが許可されていませんでした。その結果、Agent プラットフォーム上に異種クラスターをデプロイできませんでした。このリリースでは、Agent プラットフォーム上で ARM64 ベースの NodePool リソースが API によって許可されます。(OCPBUGS-46342)
  • 以前は、HyperShift Operator は常に Kubernetes API サーバーのサブジェクト代替名 (SAN) を検証していました。このリリースでは、PKI リコンシリエーションが有効になっている場合にのみ、Operator は SAN を検証します。(OCPBUGS-56562)
  • 以前は、1 年超存在するホステッドクラスターでは、内部サービング証明書が更新されても、コントロールプレーンのワークロードは再起動されず、更新された証明書を取得できませんでした。その結果、コントロールプレーンが劣化した状態になりました。このリリースでは、証明書が更新されると、コントロールプレーンのワークロードが自動的に再起動されます。その結果、コントロールプレーンは安定した状態を維持します。(OCPBUGS-52331)
  • 以前は、OpenShift OAuth API サーバーが管理するリソース (ユーザーやグループなど) に対して validating webhook を作成しても、その validating webhook は実行されませんでした。このリリースでは、Konnectivity プロキシーサイドカーを追加することで、OpenShift OAuth API サーバーとデータプレーン間の通信が修正されました。その結果、ユーザーとグループに対する Webhook を検証するプロセスが期待どおりに機能します。(OCPBUGS-52190)
  • 以前は、HostedCluster リソースが利用できない場合、その理由が条件内の HostedControlPlane リソースから正しく伝播されませんでした。HostedCluster カスタムリソースの Available 条件の Status および Message 情報は伝播されましたが、Resource の値は伝播されませんでした。このリリースでは、理由も伝播されるようになったため、利用不可の根本原因を特定するための情報がより多く得られます。(OCPBUGS-50907)
  • 以前は、managed-trust-bundle ボリュームマウントと trusted-ca-bundle-managed config map が必須コンポーネントとして導入されていました。OpenShift API サーバーは、trusted-ca-bundle-managed config map の存在を想定していたため、独自の公開鍵基盤 (PKI) を使用した場合、この要件が原因でデプロイメントが失敗していました。この問題に対処するために、これらのコンポーネントはオプションになり、カスタム PKI を使用している場合は trusted-ca-bundle-managed config map なしでクラスターを正常にデプロイできるようになりました。(OCPBUGS-52323)
  • 以前は、IBMPowerVSImage リソースが削除されたことを確認する方法がなかったため、不要なクラスターの取得が試行されていました。その結果、IBM Power Virtual Server 上のホステッドクラスターは破棄状態のままになりました。このリリースでは、イメージが削除中でない場合にのみ、イメージに関連付けられているクラスターを取得して処理できます。(OCPBUGS-46037)
  • 以前は、セキュアプロキシーを有効にしてクラスターを作成し、証明書設定を configuration.proxy.trustCA に設定すると、クラスターのインストールは失敗していました。さらに、OpenShift OAuth API サーバーは、管理クラスタープロキシーを使用してクラウド API にアクセスできませんでした。このリリースでは、これらの問題を防ぐための修正が導入されています。(OCPBUGS-51050)
  • 以前は、NodePool コントローラーとクラスター API コントローラーの両方が、NodePool カスタムリソースに updatingConfig ステータス条件を設定していました。その結果、updatingConfig ステータスは常に変更されていました。このリリースでは、updatingConfig ステータスを更新するロジックが 2 つのコントローラー間で統合されました。その結果、updatingConfig ステータスは正しく設定されるようになりました。(OCPBUGS-45322)
  • 以前は、コンテナーイメージアーキテクチャーを検証するプロセスは、イメージメタデータプロバイダーを経由しませんでした。その結果、イメージのオーバーライドは有効にならず、切断されたデプロイメントは失敗しました。このリリースでは、イメージメタデータプロバイダーのメソッドが、マルチアーキテクチャーの検証を可能にするように変更され、その変更はイメージ検証を行うすべてのコンポーネントに伝播されます。その結果、問題は解決しました。(OCPBUGS-44655)
  • 以前は、Kubernetes API サーバーの --goaway-chance フラグは設定できませんでした。フラグのデフォルト値は 0 でした。このリリースでは、HostedCluster カスタムリソースにアノテーションを追加することで、--goaway-chance フラグの値を変更できます。(OCPBUGS-54863)
  • 以前は、Hosted Control Plane に基づく Red Hat OpenShift on IBM Cloud のインスタンスの OVN 以外のクラスターでは、Cluster Network Operator は、monitoring.coreos.com API グループのサービスモニターと Prometheus ルールにパッチを適用できませんでした。その結果、Cluster Network Operator ログに権限エラーと "could not apply" というメッセージが表示されました。このリリースでは、OVN 以外のクラスターの Cluster Network Operator にサービスモニターと Prometheus ルールの権限が追加されました。その結果、Cluster Network Operator ログに権限エラーが表示されなくなりました。(OCPBUGS-54178)
  • 以前は、Hosted Control Plane のコマンドラインインターフェイス (CLI) を使用して非接続クラスターを作成しようとすると、CLI がペイロードにアクセスできないため、作成に失敗していました。このリリースでは、リリースペイロードアーキテクチャーチェックは非接続環境ではスキップされます。これは、ホストされているレジストリーは通常、CLI が実行されているマシンからアクセスできないためです。その結果、CLI を使用して非接続クラスターを作成できるようになりました。(OCPBUGS-47715)
  • 以前は、Control Plane Operator が API エンドポイントの可用性をチェックしたときに、Operator は設定された _*PROXY 変数を考慮しませんでした。その結果、プロキシー経由以外で Egress トラフィックがブロックされると、Kubernetes API サーバーを検証するための HTTP リクエストが失敗し、Hosted Control Plane とホステッドクラスターは利用できなくなりました。このリリースでは、この問題は解決されました。(OCPBUGS-49913)
  • 以前は、Hosted Control Plane CLI (hcp) を使用してホステッドクラスターを作成すると、etcd ストレージサイズを設定できませんでした。その結果、一部の大規模なクラスターではディスクサイズが不十分になりました。このリリースでは、HostedCluster リソースにフラグを設定することで、etcd ストレージサイズを設定できます。このフラグは当初、OpenShift パフォーマンスチームが ROSA with HCP 上で、より大規模な NodePool リソースのテストを支援するために追加されました。その結果、hcp CLI を使用してホステッドクラスターを作成するときに、etcd ストレージサイズを設定できるようになりました。(OCPBUGS-52655)
  • 以前は、インプレース更新を使用するホステッドクラスターを更新しようとすると、プロキシー変数が考慮されず、更新が失敗していました。このリリースでは、インプレースアップグレードを実行する Pod がクラスタープロキシー設定を考慮します。その結果、インプレース更新を使用するホステッドクラスターでも更新が機能するようになりました。(OCPBUGS-48540)
  • 以前は、Hosted Control Plane の OpenShift API サーバーに関連付けられている liveness プローブと readiness プローブは、installer-provisioned infrastructure で使用されるプローブと一致していませんでした。このリリースでは、liveness プローブと readiness プローブが更新され、/healthz エンドポイントの代わりに /livez エンドポイントと /readyz エンドポイントが使用されるようになりました。(OCPBUGS-54819)
  • 以前は、Hosted Control Plane 上の Konnectivity エージェントには readiness チェックがありませんでした。このリリースでは、Konnectivity サーバーへの接続が切断されたときに Pod の readiness を示す readiness プローブが Konnectivity エージェントに追加されました。(OCPBUGS-49611)
  • 以前は、HyperShift Operator のスコープがホステッドクラスターとノードプールのサブセットに限定されていた場合、Operator はコントロールプレーンの namespace 内のトークンとユーザーデータシークレットを適切にクリーンアップしませんでした。その結果、シークレットは蓄積されました。このリリースでは、Operator はシークレットを適切にクリーンアップします。(OCPBUGS-54272)

1.1.3. 既知の問題

  • アノテーションと ManagedCluster リソース名が一致しない場合、multicluster engine for Kubernetes Operator コンソールにはクラスターの状態が Pending import として表示されます。このようなクラスターは、multicluster engine Operator で使用できません。アノテーションがなく、ManagedCluster 名が HostedCluster リソースの Infra-ID 値と一致しない場合も、同じ問題が発生します。
  • multicluster engine for Kubernetes Operator コンソールを使用して、既存のホステッドクラスターに新しいノードプールを追加すると、オプションのリストに同じバージョンの OpenShift Container Platform が複数回表示される場合があります。必要なバージョンの一覧で任意のインスタンスを選択できます。
  • ノードプールが 0 ワーカーにスケールダウンされても、コンソールのホストのリストには、Ready 状態のノードが表示されます。ノードの数は、次の 2 つの方法で確認できます。

    • コンソールでノードプールに移動し、ノードが 0 であることを確認します。
    • コマンドラインインターフェイスで、以下のコマンドを実行します。

      • 次のコマンドを実行して、ノードプールにあるノード数が 0 個であることを確認します。

        $ oc get nodepool -A
        Copy to Clipboard Toggle word wrap
      • 次のコマンドを実行して、クラスター内にあるノード数が 0 個であることを確認します。

        $ oc get nodes --kubeconfig
        Copy to Clipboard Toggle word wrap
      • 次のコマンドを実行して、クラスターにバインドされているエージェント数が 0 と報告されていることを確認します。

        $ oc get agents -A
        Copy to Clipboard Toggle word wrap
  • デュアルスタックネットワークを使用する環境でホステッドクラスターを作成すると、ContainerCreating 状態のままになっている Pod が発生する可能性があります。この問題は、DNS Pod が DNS 解決に必要な metrics-tls シークレットを openshift-service-ca-operator リソースが生成できないために発生します。その結果、Pod は Kubernetes API サーバーを解決できません。この問題を解決するには、デュアルスタックネットワークの DNS サーバー設定を行います。
  • ホステッドクラスターをそのマネージドクラスターと同じ namespace に作成した場合、マネージドホステッドクラスターをデタッチすると、ホステッドクラスターが含まれるマネージドクラスター namespace 内のすべてが削除されます。次の状況では、マネージドクラスターと同じ namespace にホステッドクラスターが作成される可能性があります。

    • デフォルトのホステッドクラスターのクラスター namespace を使用し、multicluster engine for Kubernetes Operator のコンソールを介して Agent プラットフォーム上にホステッドクラスターを作成した場合。
    • ホステッドクラスターの namespace をホステッドクラスターの名前と同じになるよう指定して、コマンドラインインターフェイスまたは API を介してホステッドクラスターを作成した場合。
  • コンソールまたは API を使用して、ホステッドクラスターの spec.services.servicePublishingStrategy.nodePort.address フィールドに IPv6 アドレスを指定する場合、8 ヘクステットの完全な IPv6 アドレスが必要です。たとえば、2620:52:0:1306::30 ではなく、2620:52:0:1306:0:0:0:30 を指定する必要があります。
  • バージョン 4.19.3 以前では、ベアメタル Agent プラットフォーム上にホステッドクラスターを作成し、MetalLB Operator を使用すると、ホステッドクラスター内の Cluster Network Operator が起動に失敗します。以下のエラーが発生します。

    "Error while updating operator configuration: could not apply (apps/v1, Kind=Deployment) openshift-frr-k8s/frr-k8s-webhook-server: failed to apply / update (apps/v1, Kind=Deployment) openshift-frr-k8s/frr-k8s-webhook-server: Deployment.apps \"frr-k8s-webhook-server\" is invalid: spec.template.spec.containers[0].image: Required value"
    Copy to Clipboard Toggle word wrap

    この問題を回避するには、バージョン 4.19.4 以降にアップグレードしてください。

1.1.4. 一般提供とテクノロジープレビュー機能

現在、このリリースに含まれる機能にはテクノロジープレビューのものがあります。これらの実験的機能は、実稼働環境での使用を目的としていません。これらの機能のサポート範囲の詳細は、Red Hat カスタマーポータルの テクノロジープレビュー機能のサポート範囲 を参照してください。

重要

IBM Power および IBM Z の場合、コントロールプレーンは 64 ビット x86 アーキテクチャーベースのマシンタイプで実行し、ノードプールは IBM Power または IBM Z で実行する必要があります。

Expand
表1.1 Hosted Control Plane GA および TP トラッカー
機能4.174.184.19

非ベアメタルエージェントマシンを使用した OpenShift Container Platform の Hosted Control Plane

テクノロジープレビュー

テクノロジープレビュー

テクノロジープレビュー

Amazon Web Services 上の ARM64 OpenShift Container Platform クラスター用の Hosted Control Plane

一般提供

一般提供

一般提供

IBM Power 上の OpenShift Container Platform の Hosted Control Plane

一般提供

一般提供

一般提供

IBM Z 上の OpenShift Container Platform の Hosted Control Plane

一般提供

一般提供

一般提供

RHOSP 上の OpenShift Container Platform の Hosted Control Plane

開発者プレビュー

開発者プレビュー

テクノロジープレビュー

第2章 Hosted Control Plane の概要

OpenShift Container Platform クラスターは、スタンドアロンまたは Hosted Control Plane という 2 つの異なるコントロールプレーン設定を使用してデプロイできます。スタンドアロン設定では、専用の仮想マシンまたは物理マシンを使用してコントロールプレーンをホストします。OpenShift Container Platform の Hosted Control Plane を使用すると、各コントロールプレーンに専用の仮想マシンまたは物理マシンを用意する必要なく、管理クラスター上の Pod としてコントロールプレーンを作成できます。

2.1. Hosted Control Plane の概要

Hosted Control Plane は、次のプラットフォームで サポートされているバージョンの multicluster engine for Kubernetes Operator を使用することで利用できます。

  • Agent プロバイダーを使用したベアメタル
  • 非ベアメタルエージェントマシン (テクノロジープレビュー機能)
  • OpenShift Virtualization
  • Amazon Web Services (AWS)
  • IBM Z
  • IBM Power
  • Red Hat OpenStack Platform (RHOSP) 17.1 (テクノロジープレビュー機能)

Hosted Control Plane 機能はデフォルトで有効になっています。

注記

multicluster engine Operator は Red Hat Advanced Cluster Management (RHACM) の不可欠な要素であり、RHACM ではデフォルトで有効になっています。ただし、Hosted Control Plane を使用するのに RHACM は必要ありません。

2.1.1. Hosted Control Plane のアーキテクチャー

OpenShift Container Platform は、多くの場合、クラスターがコントロールプレーンとデータプレーンで構成される結合モデルまたはスタンドアロンモデルでデプロイされます。コントロールプレーンには、API エンドポイント、ストレージエンドポイント、ワークロードスケジューラー、および状態を保証するアクチュエーターが含まれます。データプレーンには、ワークロードとアプリケーションが実行されるコンピュート、ストレージ、およびネットワークが含まれます。

スタンドアロンコントロールプレーンは、クォーラムを確保できる最小限の数で、物理または仮想のノードの専用グループによってホストされます。ネットワークスタックは共有されます。クラスターへの管理者アクセスにより、クラスターのコントロールプレーン、マシン管理 API、およびクラスターの状態に影響を与える他のコンポーネントを可視化できます。

スタンドアロンモデルは正常に機能しますが、状況によっては、コントロールプレーンとデータプレーンが分離されたアーキテクチャーが必要になります。そのような場合には、データプレーンは、専用の物理ホスティング環境がある別のネットワークドメインに配置されています。コントロールプレーンは、Kubernetes にネイティブなデプロイやステートフルセットなど、高レベルのプリミティブを使用してホストされます。コントロールプレーンは、他のワークロードと同様に扱われます。

2.1.2. Hosted Control Plane の利点

Hosted Control Plane を使用すると、真のハイブリッドクラウドアプローチへの道が開かれ、その他のさまざまなメリットも享受できます。

  • コントロールプレーンが分離され、専用のホスティングサービスクラスターでホストされるため、管理とワークロードの間のセキュリティー境界が強化されます。その結果、クラスターのクレデンシャルが他のユーザーに漏洩する可能性が低くなります。インフラストラクチャーのシークレットアカウント管理も分離されているため、クラスターインフラストラクチャーの管理者が誤ってコントロールプレーンインフラストラクチャーを削除することはありません。
  • Hosted Control Plane を使用すると、より少ないノードで多数のコントロールプレーンを実行できます。その結果、クラスターはより安価になります。
  • コントロールプレーンは OpenShift Container Platform で起動される Pod で構成されるため、コントロールプレーンはすぐに起動します。同じ原則が、モニタリング、ロギング、自動スケーリングなどのコントロールプレーンとワークロードに適用されます。
  • インフラストラクチャーの観点からは、レジストリー、HAProxy、クラスター監視、ストレージノードなどのインフラストラクチャーをテナントのクラウドプロバイダーのアカウントにプッシュして、テナントでの使用を分離できます。
  • 運用上の観点からは、マルチクラスター管理はさらに集約され、クラスターの状態と一貫性に影響を与える外部要因が少なくなります。Site Reliability Engineer は、一箇所で問題をデバッグしてクラスターのデータプレーンに移動できるため、解決までの時間 (TTR) が短縮され、生産性が向上します。

2.2. Hosted Control Plane と OpenShift Container Platform の違い

Hosted Control Plane は、OpenShift Container Platform の 1 つのフォームファクターです。ホステッドクラスターとスタンドアロンの OpenShift Container Platform クラスターは、設定と管理が異なります。OpenShift Container Platform と Hosted Control Plane の違いを理解するには、次の表を参照してください。

2.2.1. クラスターの作成とライフサイクル

Expand
OpenShift Container PlatformHosted Control Plane

openshift-install バイナリーまたは Assisted Installer を使用して、スタンドアロンの OpenShift Container Platform クラスターをインストールします。

既存の OpenShift Container Platform クラスターに、HostedClusterNodePool などの hypershift.openshift.io API リソースを使用して、ホステッドクラスターをインストールします。

2.2.2. Cluster configuration

Expand
OpenShift Container PlatformHosted Control Plane

config.openshift.io API グループを使用して、認証、API サーバー、プロキシーなど、クラスタースコープのリソースを設定します。

コントロールプレーンに影響するリソースを、HostedCluster リソースで設定します。

2.2.3. etcd 暗号化

Expand
OpenShift Container PlatformHosted Control Plane

APIServer リソースと AES-GCM または AES-CBC を使用して、etcd 暗号化を設定します。詳細は、「etcd 暗号化の有効化」を参照してください。

SecretEncryption フィールドの HostedCluster リソースと Amazon Web Services の AES-CBC または KMS を使用して、etcd 暗号化を設定します。

2.2.4. Operator とコントロールプレーン

Expand
OpenShift Container PlatformHosted Control Plane

スタンドアロンの OpenShift Container Platform クラスターには、コントロールプレーンコンポーネントごとに個別の Operator が含まれています。

ホステッドクラスターには、管理クラスターの Hosted Control Plane の namespace で実行される Control Plane Operator という名前の単一の Operator が含まれています。

etcd は、コントロールプレーンノードにマウントされたストレージを使用します。etcd のクラスター Operator が etcd を管理します。

etcd は、ストレージに永続ボリューム要求を使用し、Control Plane Operator によって管理されます。

Ingress Operator、ネットワーク関連の Operator、および Operator Lifecycle Manager (OLM) は、クラスター上で実行されます。

Ingress Operator、ネットワーク関連の Operator、および Operator Lifecycle Manager (OLM) は、管理クラスターの Hosted Control Plane の namespace で実行されます。

OAuth サーバーは、クラスター内で実行され、クラスター内のルートを通じて公開されます。

OAuth サーバーは、コントロールプレーン内で実行され、管理クラスター上のルート、ノードポート、またはロードバランサーを通じて公開されます。

2.2.5. 更新

Expand
OpenShift Container PlatformHosted Control Plane

Cluster Version Operator (CVO) が更新プロセスをオーケストレーションし、ClusterVersion リソースを監視します。管理者と OpenShift コンポーネントは、ClusterVersion リソースを通じて CVO とやり取りできます。oc adm upgrade コマンドを実行すると、ClusterVersion リソースの ClusterVersion.Spec.DesiredUpdate フィールドが変更されます。

Hosted Control Plane を更新すると、HostedCluster および NodePool リソースの .spec.release.image フィールドが変更されます。ClusterVersion リソースへの変更はすべて無視されます。

OpenShift Container Platform クラスターを更新すると、コントロールプレーンとコンピュートマシンの両方が更新されます。

ホステッドクラスターを更新すると、コントロールプレーンのみが更新されます。ノードプールの更新は個別に実行します。

2.2.6. マシンの設定と管理

Expand
OpenShift Container PlatformHosted Control Plane

MachineSets リソースが、openshift-machine-api namespace 内のマシンを管理します。

NodePool リソースが、管理クラスター上のマシンを管理します。

コントロールプレーンマシンのセットが利用可能です。

コントロールプレーンマシンのセットが存在しません。

MachineHealthCheck リソースを使用して、マシンのヘルスチェックを有効にします。

NodePool リソースの .spec.management.autoRepair フィールドを通じてマシンのヘルスチェックを有効にします。

ClusterAutoscaler および MachineAutoscaler リソースを使用して自動スケーリングを有効にします。

NodePool リソースの spec.autoScaling フィールドを通じて自動スケーリングを有効にします。

マシンとマシンセットがクラスター内で公開されます。

アップストリームの Cluster CAPI Operator からのマシン、マシンセット、およびマシンデプロイメントが、マシンを管理するために使用されます。ただし、これらはユーザーには公開されません。

クラスターを更新すると、すべてのマシンセットが自動的にアップグレードされます。

ホステッドクラスターの更新とは別にノードプールを更新します。

インプレースアップグレードだけがクラスターでサポートされています。

置換アップグレードとインプレースアップグレードの両方が、ホステッドクラスターでサポートされています。

Machine Config Operator がマシンの設定を管理します。

Hosted Control Plane には Machine Config Operator が存在しません。

MachineConfigPool セレクターから選択された MachineConfigKubeletConfig、および ContainerRuntimeConfig リソースを使用して、マシンの Ignition を設定します。

MachineConfigKubeletConfig、および ContainerRuntimeConfig リソースを、NodePool リソースの spec.config フィールドで参照される config map を通じて設定します。

Machine Config Daemon (MCD) が各ノードの設定の変更と更新を管理します。

インプレースアップグレードの場合、ノードプールコントローラーが、一度だけ実行され、設定に基づいてマシンを更新する Pod を作成します。

SR-IOV Operator などのマシン設定リソースを変更できます。

マシン設定リソースを変更することはできません。

2.2.7. ネットワーク

Expand
OpenShift Container PlatformHosted Control Plane

Kube API サーバーとノードが同じ Virtual Private Cloud (VPC) 内に存在するため、Kube API サーバーはノードと直接通信します。

Kube API サーバーは Konnectivity を介してノードと通信します。Kube API サーバーとノードは、別々の Virtual Private Cloud (VPC) 内に存在します。

ノードは内部ロードバランサーを介して Kube API サーバーと通信します。

ノードは外部ロードバランサーまたはノードポートを介して Kube API サーバーと通信します。

2.2.8. Web コンソール

Expand
OpenShift Container PlatformHosted Control Plane

Web コンソールにコントロールプレーンのステータスが表示されます。

Web コンソールにコントロールプレーンのステータスが表示されません。

Web コンソールを使用してクラスターを更新できます。

Web コンソールを使用してホステッドクラスターを更新することはできません。

Web コンソールにマシンなどのインフラストラクチャーリソースが表示されます。

Web コンソールにインフラストラクチャーリソースが表示されません。

Web コンソールを使用して、MachineConfig リソースを通じてマシンを設定できます。

Web コンソールを使用してマシンを設定することはできません。

2.3. Hosted Control Plane、multicluster engine Operator、および RHACM の関係

Hosted Control Plane は、multicluster engine for Kubernetes Operator を使用して設定できます。multicluster engine Operator のクラスターライフサイクルにより、さまざまなインフラストラクチャークラウドプロバイダー、プライベートクラウド、オンプレミスデータセンターにおける Kubernetes クラスターの作成、インポート、管理、破棄のプロセスが定義されます。

注記

multicluster engine Operator は Red Hat Advanced Cluster Management (RHACM) の不可欠な要素であり、RHACM ではデフォルトで有効になっています。ただし、Hosted Control Plane を使用するのに RHACM は必要ありません。

multicluster engine Operator は、OpenShift Container Platform および RHACM ハブクラスターにクラスター管理機能を提供するクラスターライフサイクル Operator です。multicluster engine Operator は、クラスター群の管理を強化し、クラウドとデータセンター全体の OpenShift Container Platform クラスターのライフサイクル管理を支援します。

図2.1 クラスターライフサイクルと基盤

OpenShift Container Platform の multicluster engine Operator は、スタンドアロンクラスターマネージャーとして、または RHACM ハブクラスターの一部として使用できます。

ヒント

管理クラスターはホスティングクラスターとも呼ばれます。

OpenShift Container Platform クラスターは、スタンドアロンまたは Hosted Control Plane という 2 つの異なるコントロールプレーン設定を使用してデプロイできます。スタンドアロン設定では、専用の仮想マシンまたは物理マシンを使用してコントロールプレーンをホストします。OpenShift Container Platform の Hosted Control Plane を使用すると、各コントロールプレーンに専用の仮想マシンまたは物理マシンを用意する必要なく、管理クラスター上の Pod としてコントロールプレーンを作成できます。

図2.2 RHACM と multicluster engine Operator の概要図

2.3.1. RHACM での multicluster engine Operator ホステッドクラスターの検出

ホステッドクラスターを Red Hat Advanced Cluster Management (RHACM) ハブクラスターに移行し、RHACM 管理コンポーネントを使用して管理する場合は、Red Hat Advanced Cluster Management の公式ドキュメント の手順を参照してください。

2.4. Hosted Control Plane のバージョン管理

Hosted Control Plane 機能には次のコンポーネントが含まれています。これらのコンポーネントには、個別のバージョン管理とサポートレベルが必要な場合があります。

  • 管理クラスター
  • HyperShift Operator
  • Hosted Control Plane (hcp) コマンドラインインターフェイス (CLI)
  • hypershift.openshift.io API
  • Control Plane Operator

2.4.1. 管理クラスター

実稼働環境で使用する管理クラスターでは、OperatorHub から入手できる multicluster engine for Kubernetes Operator が必要です。multicluster engine Operator には、HyperShift Operator のサポートされているビルドがバンドルされています。管理クラスターのサポートを継続するには、multicluster engine Operator が動作する OpenShift Container Platform のバージョンを使用する必要があります。一般に、multicluster engine Operator の新しいリリースは、以下の OpenShift Container Platform のバージョンで動作します。

  • OpenShift Container Platform の最新の一般提供バージョン
  • OpenShift Container Platform の最新の一般提供バージョンより 2 つ前のバージョン

管理クラスター上の HyperShift Operator を通じてインストールできる OpenShift Container Platform バージョンの完全なリストは、HyperShift Operator のバージョンによって異なります。ただし、リストには常に、管理クラスターと同じ OpenShift Container Platform バージョンと、管理クラスターよりも 2 つ前のマイナーバージョンが含まれます。たとえば、管理クラスターが 4.17 とサポートされているバージョンの multicluster engine Operator を実行している場合、HyperShift Operator は 4.17、4.16、4.15、および 4.14 ホステッドクラスターをインストールできます。

OpenShift Container Platform のメジャー、マイナー、またはパッチバージョンのリリースごとに、Hosted Control Plane の 2 つのコンポーネントがリリースされます。

  • HyperShift Operator
  • hcp コマンドラインインターフェイス (CLI)

2.4.2. HyperShift Operator

HyperShift Operator は、HostedCluster API リソースによって表されるホステッドクラスターのライフサイクルを管理します。HyperShift Operator は、OpenShift Container Platform の各リリースでリリースされます。HyperShift Operator は、hypershift namespace に supported-versions config map を作成します。この config map には、サポートされているホステッドクラスターのバージョンが含まれています。

同じ管理クラスター上で異なるバージョンのコントロールプレーンをホストできます。

supported-versions config map オブジェクトの例

    apiVersion: v1
    data:
      supported-versions: '{"versions":["4.19"]}'
    kind: ConfigMap
    metadata:
      labels:
        hypershift.openshift.io/supported-versions: "true"
      name: supported-versions
      namespace: hypershift
Copy to Clipboard Toggle word wrap

2.4.3. Hosted Control Plane CLI

hcp CLI を使用してホステッドクラスターを作成できます。CLI は multicluster engine Operator からダウンロードできます。hcp version コマンドを実行すると、CLI が kubeconfig ファイルに対してサポートする最新の OpenShift Container Platform が出力に表示されます。

2.4.4. hypershift.openshift.io API

HostedClusterNodePool などの hypershift.openshift.io API リソースを使用して、大規模な OpenShift Container Platform クラスターを作成および管理できます。HostedCluster リソースには、コントロールプレーンと共通データプレーンの設定が含まれます。HostedCluster リソースを作成すると、ノードが接続されていない、完全に機能するコントロールプレーンが作成されます。NodePool リソースは、HostedCluster リソースにアタッチされたスケーラブルなワーカーノードのセットです。

API バージョンポリシーは、通常、Kubernetes API のバージョン管理 のポリシーと一致します。

Hosted Control Plane の更新には、ホステッドクラスターとノードプールの更新が含まれます。詳細は、「Hosted Control Plane の更新」を参照してください。

2.4.5. Control Plane Operator

Control Plane Operator は、次のアーキテクチャー用の各 OpenShift Container Platform ペイロードリリースイメージの一部としてリリースされます。

  • amd64
  • arm64
  • multi-arch

2.5. Hosted Control Plane の一般的な概念とペルソナの用語集

OpenShift Container Platform の Hosted Control Plane を使用する場合は、その主要な概念と関連するペルソナを理解することが重要です。

2.5.1. 概念

データプレーン
ワークロードとアプリケーションが実行されるコンピュート、ストレージ、ネットワークを含む、クラスターの一部分。
ホステッドクラスター
コントロールプレーンと API エンドポイントが管理クラスターでホストされている OpenShift Container Platform クラスター。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。
ホステッドクラスターのインフラストラクチャー
テナントまたはエンドユーザーのクラウドアカウントに存在するネットワーク、コンピュート、およびストレージリソース。
Hosted Control Plane
管理クラスターで実行される OpenShift Container Platform コントロールプレーン。ホステッドクラスターの API エンドポイントによって公開されます。コントロールプレーンのコンポーネントには、etcd、Kubernetes API サーバー、Kubernetes コントローラーマネージャー、および VPN が含まれます。
ホスティングクラスター
管理クラスター を参照してください。
マネージドクラスター
ハブクラスターが管理するクラスター。この用語は、Red Hat Advanced Cluster Management で multicluster engine for Kubernetes Operator が管理するクラスターライフサイクル特有の用語です。マネージドクラスターは、管理クラスター とは異なります。詳細は、マネージドクラスター を参照してください。
管理クラスター
HyperShift Operator がデプロイされる OpenShift Container Platform クラスター。ホステッドクラスターのコントロールプレーンをホストします。管理クラスターは ホスティングクラスター と同義です。
管理クラスターのインフラストラクチャー
管理クラスターのネットワーク、コンピュート、およびストレージリソース。
ノードプール
ホステッドクラスターに関連付けられたコンピュートノードのセットを管理するリソース。コンピュートノードは、ホステッドクラスター内でアプリケーションとワークロードを実行します。

2.5.2. ペルソナ

クラスターインスタンス管理者
このロールを引き受けるユーザーは、スタンドアロン OpenShift Container Platform の管理者と同等です。このユーザーには、プロビジョニングされたクラスター内で cluster-admin ロールがありますが、クラスターがいつ、どのように更新または設定されるかを制御できない可能性があります。このユーザーは、クラスターに投影された設定を表示するための読み取り専用アクセス権を持っている可能性があります。
クラスターインスタンスユーザー
このロールを引き受けるユーザーは、スタンドアロン OpenShift Container Platform の開発者と同等です。このユーザーには、OperatorHub またはマシンに対するビューがありません。
クラスターサービスコンシューマー
このロールを引き受けるユーザーは、コントロールプレーンとワーカーノードを要求したり、更新を実行したり、外部化された設定を変更したりできます。通常、このユーザーはクラウド認証情報やインフラストラクチャー暗号化キーを管理したりアクセスしたりしません。クラスターサービスのコンシューマーペルソナは、ホステッドクラスターを要求し、ノードプールと対話できます。このロールを引き受けるユーザーには、論理境界内でホステッドクラスターとノードプールを作成、読み取り、更新、または削除するための RBAC があります。
クラスターサービスプロバイダー

このロールを引き受けるユーザーは通常、管理クラスター上で cluster-admin ロールを持ち、HyperShift Operator とテナントのホステッドクラスターのコントロールプレーンの可用性を監視および所有するための RBAC を持っています。クラスターサービスプロバイダーのペルソナは、次の例を含むいくつかのアクティビティーを担当します。

  • コントロールプレーンの可用性、稼働時間、安定性を確保するためのサービスレベルオブジェクトの所有
  • コントロールプレーンをホストするための管理クラスターのクラウドアカウントの設定
  • ユーザーがプロビジョニングするインフラストラクチャーの設定 (利用可能なコンピュートリソースのホスト認識を含む)

第3章 Hosted Control Plane のデプロイの準備

3.1. Hosted Control Plane の要件

Hosted Control Plane において、管理クラスター とは HyperShift Operator がデプロイされ、ホステッドクラスターのコントロールプレーンがホストされる OpenShift Container Platform クラスターです。

コントロールプレーンはホステッドクラスターに関連付けられており、単一の namespace 内の Pod として実行されます。クラスターのサービスコンシューマーがホステッドクラスターを作成すると、コントロールプレーンから独立したワーカーノードが作成されます。

Hosted Control Plane には次の要件が適用されます。

  • HyperShift Operator を実行するには、管理クラスターに少なくとも 3 つのワーカーノードが必要です。
  • ドメインネームサービス (DNS) プロトコルが期待どおりに動作できるように、Transmission Control Protocol (TCP) および User Datagram Protocol (UDP) のファイアウォールポート 53 を開く必要があります。
  • 管理クラスターとワーカーノードの両方を、オンプレミス (ベアメタルプラットフォームや OpenShift Virtualization 上など) で実行できます。さらに、管理クラスターとワーカーノードの両方を、Amazon Web Services (AWS) などのクラウドインフラストラクチャー上で実行することもできます。
  • 管理クラスターを AWS で実行し、ワーカーノードをオンプレミスで実行する、またはワーカーノードを AWS で実行し、管理クラスターをオンプレミスで実行するなど、混合インフラストラクチャーを使用する場合は、PublicAndPrivate 公開ストラテジーを使用し、サポートマトリックスのレイテンシー要件に従う必要があります。
  • Bare Metal Operator がマシンを起動するベアメタルホスト (BMH) デプロイメントでは、Hosted Control Plane が Baseboard Management Controller (BMC) にアクセスできる必要があります。Redfish の自動化を有効にするために、BMH の BMC があるネットワークに Cluster Baremetal Operator がアクセスすることをセキュリティープロファイルで禁止している場合は、BYO ISO サポートを使用できます。ただし、BYO モードでは、OpenShift Container Platform は BMH の電源オンを自動化できません。

3.1.1. Hosted Control Plane のサポートマトリックス

Multicluster engine for Kubernetes Operator には HyperShift Operator が含まれているため、Hosted Control Plane のリリースは multicluster engine Operator のリリースと一致します。詳細は、OpenShift Operator のライフサイクル を参照してください。

3.1.1.1. 管理クラスターのサポート

サポートされているスタンドアロンの OpenShift Container Platform クラスターは、すべて管理クラスターにすることができます。

注記

シングルノードの OpenShift Container Platform クラスターは、管理クラスターとしてはサポートされていません。リソースに制約がある場合は、スタンドアロンの OpenShift Container Platform コントロールプレーンと Hosted Control Plane 間でインフラストラクチャーを共有できます。詳細は、「Hosted Control Plane とスタンドアロンコントロールプレーン間でのインフラストラクチャーの共有」を参照してください。

次の表は、multicluster engine Operator のバージョンと、それらをサポートする管理クラスターのバージョンをマッピングしています。

Expand
表3.1 OpenShift Container Platform 管理クラスターでサポートされている multicluster engine Operator バージョン
管理クラスターのバージョンサポートされている multicluster engine Operator バージョン

4.14 - 4.15

2.4

4.14 - 4.16

2.5

4.14 - 4.17

2.6

4.15 - 4.17

2.7

4.16 - 4.18

2.8

4.17 - 4.19

2.9

3.1.1.2. ホステッドクラスターのサポート

ホステッドクラスターの場合、管理クラスターのバージョンとホステッドクラスターのバージョンの間に直接的な関係はありません。ホステッドクラスターのバージョンは、使用している multicluster engine Operator バージョンに含まる HyperShift Operator により異なります。

注記

管理クラスターとホステッドクラスター間の最大遅延が 200 ミリ秒であることを確認してください。この要件は、管理クラスターが AWS 上にあり、コンピュートノードがオンプレミスにある場合など、混合インフラストラクチャーのデプロイメントでは特に重要です。

次の表は、multicluster engine Operator のバージョンに関連付けられた HyperShift Operator を使用して作成できるホステッドクラスターバージョンを示しています。

注記

HyperShift Operator は次の表に示すホステッドクラスターのバージョンをサポートしていますが、multicluster engine Operator は現行バージョンから 2 バージョン前までしかサポートしていません。たとえば、現在のホステッドクラスターのバージョンが 4.19 の場合、multicluster engine Operator はバージョン 4.17 までサポートします。multicluster engine Operator がサポートするバージョンよりも前のホステッドクラスターバージョンを使用する場合は、multicluster engine Operator からホステッドクラスターをデタッチして管理対象外にするか、multicluster engine Operator の以前のバージョンを使用できます。ホステッドクラスターを multicluster engine Operator から切り離す手順については、管理からのクラスターの削除 (RHACM ドキュメント) を参照してください。multicluster engine Operator のサポートに関する詳細は、The multicluster engine for Kubernetes operator 2.9 Support Matrix (Red Hat ナレッジベース) を参照してください。

Expand
表3.2 multicluster engine Operator バージョンに関連付けられた HyperShift Operator にマッピングされたホステッドクラスターバージョン
ホステッドクラスターのバージョンHyperShift Operator in multicluster engine Operator 2.4HyperShift Operator in multicluster engine Operator 2.5HyperShift Operator in multicluster engine Operator 2.6HyperShift Operator in multicluster engine Operator 2.7HyperShift Operator in multicluster engine Operator 2.8HyperShift Operator in multicluster engine Operator 2.9

4.14

はい

はい

はい

はい

はい

はい

4.15

いいえ

はい

はい

はい

はい

はい

4.16

いいえ

いいえ

はい

はい

はい

はい

4.17

いいえ

いいえ

いいえ

はい

はい

はい

4.18

いいえ

いいえ

いいえ

いいえ

はい

はい

4.19

いいえ

いいえ

いいえ

いいえ

いいえ

はい

3.1.1.3. ホステッドクラスタープラットフォームのサポート

ホステッドクラスターは、1 つのインフラストラクチャープラットフォームのみサポートします。たとえば、異なるインフラストラクチャープラットフォーム上に複数のノードプールを作成することはできません。

次の表は、Hosted Control Plane の各プラットフォームでサポートされている OpenShift Container Platform のバージョンを示しています。

重要

IBM Power および IBM Z の場合、コントロールプレーンは 64 ビット x86 アーキテクチャーベースのマシンタイプで実行し、ノードプールは IBM Power または IBM Z で実行する必要があります。

次の表に示す管理クラスターのバージョンは、multicluster engine Operator が有効になっている OpenShift Container Platform バージョンです。

Expand
表3.3 プラットフォームに必要な OpenShift Container Platform バージョン
ホステッドクラスターのプラットフォーム管理クラスターのバージョンホステッドクラスターのバージョン

Amazon Web Services

4.16 - 4.19

4.16 - 4.19

IBM Power

4.17 - 4.19

4.17 - 4.19

IBM Z

4.17 - 4.19

4.17 - 4.19

OpenShift Virtualization

4.14 - 4.19

4.14 - 4.19

ベアメタル

4.14 - 4.19

4.14 - 4.19

非ベアメタルエージェントマシン (テクノロジープレビュー)

4.16 - 4.19

4.16 - 4.19

Red Hat OpenStack Platform (RHOSP) (テクノロジープレビュー)

4.19

4.19

3.1.1.4. マルチアーキテクチャーのサポート

次の表は、プラットフォーム別に、マルチアーキテクチャー上の Hosted Control Plane のサポート状況を示しています。

Expand
表3.4 AWS 上の Hosted Control Plane のマルチアーキテクチャーサポート
OpenShift Container Platform バージョンARM64 コントロールプレーンARM64 コンピュートノード

4.19

一般提供

一般提供

4.18

一般提供

一般提供

4.17

一般提供

一般提供

4.16

テクノロジープレビュー

一般提供

4.15

テクノロジープレビュー

一般提供

4.14

テクノロジープレビュー

一般提供

Expand
表3.5 ベアメタル上の Hosted Control Plane のマルチアーキテクチャーサポート
OpenShift Container Platform バージョンARM64 コントロールプレーンARM64 コンピュートノード

4.19

利用不可

テクノロジープレビュー

4.18

利用不可

テクノロジープレビュー

4.17

利用不可

テクノロジープレビュー

4.16

利用不可

テクノロジープレビュー

4.15

利用不可

テクノロジープレビュー

4.14

利用不可

テクノロジープレビュー

Expand
表3.6 非ベアメタルエージェントマシン上の Hosted Control Plane のマルチアーキテクチャーサポート
OpenShift Container Platform バージョンARM64 コントロールプレーンARM64 コンピュートノード

4.19

利用不可

利用不可

4.18

利用不可

利用不可

4.17

利用不可

利用不可

Expand
表3.7 IBM Power 上の Hosted Control Plane のマルチアーキテクチャーサポート
OpenShift Container Platform バージョンコントロールプレーンCompute nodes

4.19

  • 64 ビット x86: 一般提供
  • ARM64: 利用不可
  • s390x: 利用不可
  • ppc64le: 利用不可
  • 64 ビット x86: 一般提供
  • ARM64: 利用不可
  • s390x: 利用不可
  • ppc64le: 一般提供

4.18

  • 64 ビット x86: 一般提供
  • ARM64: 利用不可
  • s390x: 利用不可
  • ppc64le: 利用不可
  • 64 ビット x86: 利用不可
  • ARM64: 利用不可
  • s390x: 利用不可
  • ppc64le: 一般提供

4.17

  • 64 ビット x86: 一般提供
  • ARM64: 利用不可
  • s390x: 利用不可
  • ppc64le: 利用不可
  • 64 ビット x86: 利用不可
  • ARM64: 利用不可
  • s390x: 利用不可
  • ppc64le: 一般提供
Expand
表3.8 IBM Z 上の Hosted Control Plane のマルチアーキテクチャーサポート
OpenShift Container Platform バージョンコントロールプレーンCompute nodes

4.19

  • 64 ビット x86: 一般提供
  • ARM64: 利用不可
  • s390x: 利用不可
  • ppc64le: 利用不可
  • 64 ビット x86: 利用不可
  • ARM64: 利用不可
  • s390x: 一般提供

4.18

  • 64 ビット x86: 一般提供
  • ARM64: 利用不可
  • s390x: 利用不可
  • ppc64le: 利用不可
  • 64 ビット x86: 利用不可
  • ARM64: 利用不可
  • s390x: 一般提供
  • ppc64le: 利用不可

4.17

  • 64 ビット x86: 一般提供
  • ARM64: 利用不可
  • s390x: 利用不可
  • ppc64le: 利用不可
  • 64 ビット x86: 利用不可
  • ARM64: 利用不可
  • s390x: 一般提供
  • ppc64le: 利用不可
Expand
表3.9 OpenShift Virtualization 上の Hosted Control Plane のマルチアーキテクチャーサポート
OpenShift Container Platform バージョンARM64 コントロールプレーンARM64 コンピュートノード

4.19

利用不可

利用不可

4.18

利用不可

利用不可

4.17

利用不可

利用不可

4.16

利用不可

利用不可

4.15

利用不可

利用不可

4.14

利用不可

利用不可

3.1.1.5. multicluster engine Operator の更新

multicluster engine Operator の別バージョンに更新する場合、その multicluster engine Operator バージョンに含まれる HyperShift Operator がサポートしているバージョンのホステッドクラスターは、引き続き実行できます。次の表は、更新後の multicluster engine Operator バージョンでサポートされるホステッドクラスターバージョンを示しています。

注記

HyperShift Operator は次の表に示すホステッドクラスターのバージョンをサポートしていますが、multicluster engine Operator は現行バージョンから 2 バージョン前までしかサポートしていません。たとえば、現在のホステッドクラスターのバージョンが 4.19 の場合、multicluster engine Operator はバージョン 4.17 までサポートします。multicluster engine Operator がサポートするバージョンよりも前のホステッドクラスターバージョンを使用する場合は、multicluster engine Operator からホステッドクラスターをデタッチして管理対象外にするか、multicluster engine Operator の以前のバージョンを使用できます。ホステッドクラスターを multicluster engine Operator から切り離す手順については、管理からのクラスターの削除 (RHACM ドキュメント) を参照してください。multicluster engine Operator のサポートに関する詳細は、The multicluster engine for Kubernetes operator 2.9 Support Matrix (Red Hat ナレッジベース) を参照してください。

Expand
表3.10 更新後の multicluster engine Operator バージョンでサポートされるホステッドクラスター
更新後の multicluster engine Operator バージョンサポートされるホステッドクラスターバージョン

2.4 から 2.5 に更新

OpenShift Container Platform 4.14

2.5 から 2.6 に更新

OpenShift Container Platform 4.14 - 4.15

2.6 から 2.7 に更新

OpenShift Container Platform 4.14 - 4.16

2.7 から 2.8 に更新

OpenShift Container Platform 4.14 - 4.17

2.8 から 2.9 に更新

OpenShift Container Platform 4.14 - 4.18

たとえば、管理クラスターに OpenShift Container Platform 4.14 ホステッドクラスターがあり、multicluster engine Operator 2.4 から 2.5 に更新した場合、ホステッドクラスターは引き続き実行できます。

3.1.1.6. テクノロジープレビュー機能

次のリストは、このリリースでテクノロジープレビューステータスになっている機能を示しています。

  • 非接続環境の IBM Z の Hosted Control Plane
  • Hosted Control Plane のカスタムの taint と toleration
  • OpenShift Virtualization の Hosted Control Plane 上の NVIDIA GPU デバイス
  • Red Hat OpenStack Platform (RHOSP) 上の Hosted Control Plane

3.1.2. FIPS 対応ホステッドクラスター

Hosted Control Plane のバイナリーは、Hosted Control Plane コマンドラインインターフェイス hcp を除き、FIP に準拠しています。

FIPS 対応のホステッドクラスターをデプロイする場合は、FIPS 対応の管理クラスターを使用する必要があります。管理クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。

FIPS モードでブートされた RHEL または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーでのみ、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

管理クラスターを FIPS モードでセットアップすると、その管理クラスター上でホステッドクラスターの作成プロセスが実行されます。

3.1.3. Hosted Control Plane の CIDR 範囲

OpenShift Container Platform に Hosted Control Plane をデプロイするには、次の必須の Classless Inter-Domain Routing (CIDR) サブネット範囲を使用してください。

  • v4InternalSubnet: 100.65.0.0/16 (OVN-Kubernetes)
  • clusterNetwork: 10.132.0.0/14 (Pod ネットワーク)
  • serviceNetwork: 172.31.0.0/16

OpenShift Container Platform の CIDR 範囲の定義に関する詳細は、「CIDR 範囲の定義」を参照してください。

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

一定数のワーカーノード内に収容できる 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 負荷に基づいてコンピュートリソースの使用量を増やすために、推定係数を定めています。正確な使用率は、クラスターのワークロードのタイプとペースによって異なる場合があります。

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

Expand
表3.11 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 である
Expand
表3.12 入力の制限
制限の説明サーバー 1サーバー 2

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

64

128

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

128

256

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

500

500

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

3

3

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

1000

1000

Expand
表3.13 サイジング計算の例

ワーカーノードのサイズと 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 maxPods/Hosted Control Plane あたり 75 Pod

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

5.4

6.7

 
 

仮想 CPU の制限要因

maxPods の制限要因

 

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

16

20

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

Expand
表3.14 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 が低くなることが予想されます。

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

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

インフラストラクチャーを共有する前に、インフラストラクチャーに Hosted Control Plane をサポートするのに十分なリソースがあることを確認してください。OpenShift Container Platform 管理クラスターには、Hosted Control Plane 以外のものは何もデプロイできません。管理クラスターに、ホステッドクラスターの合計負荷を処理するのに十分な CPU、メモリー、ストレージ、およびネットワークリソースがあることを確認してください。ワークロードは要求が厳しいものであってはならず、1 秒あたりのクエリー数 (QPS) プロファイルの範囲内で低く抑える必要があります。リソースとワークロードの詳細は、「Hosted Control Plane のサイジングに関するガイダンス」を参照してください。

3.3. リソース使用率測定値のオーバーライド

リソース使用率のベースライン測定値のセットは、ホステッドクラスターごとに異なる場合があります。

3.3.1. ホステッドクラスターのリソース使用率測定値のオーバーライド

リソース使用率の測定値は、クラスターのワークロードの種類とペースに基づいてオーバーライドできます。

手順

  1. 次のコマンドを実行して、ConfigMap リソースを作成します。

    $ oc create -f <your-config-map-file.yaml>
    Copy to Clipboard Toggle word wrap

    <your-config-map-file.yaml>hcp-sizing-baseline config map を含む YAML ファイルの名前に置き換えます。

  2. local-cluster namespace に hcp-sizing-baseline config map を作成し、オーバーライドする測定値を指定します。config map は、次の YAML ファイルのようになります。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: hcp-sizing-baseline
      namespace: local-cluster
    data:
      incrementalCPUUsagePer1KQPS: "9.0"
      memoryRequestPerHCP: "18"
      minimumQPSPerHCP: "50.0"
    Copy to Clipboard Toggle word wrap
  3. 以下のコマンドを実行して hypershift-addon-agent デプロイメントを削除し、hypershift-addon-agent Pod を再起動します。

    $ oc delete deployment hypershift-addon-agent \
      -n open-cluster-management-agent-addon
    Copy to Clipboard Toggle word wrap

検証

  • hypershift-addon-agent Pod ログを監視します。次のコマンドを実行して、オーバーライドされた測定値が config map 内で更新されていることを確認します。

    $ oc logs hypershift-addon-agent -n open-cluster-management-agent-addon
    Copy to Clipboard Toggle word wrap

    ログは以下の出力のようになります。

    出力例

    2024-01-05T19:41:05.392Z	INFO	agent.agent-reconciler	agent/agent.go:793	setting cpuRequestPerHCP to 5
    2024-01-05T19:41:05.392Z	INFO	agent.agent-reconciler	agent/agent.go:802	setting memoryRequestPerHCP to 18
    2024-01-05T19:53:54.070Z	INFO	agent.agent-reconciler	agent/hcp_capacity_calculation.go:141	The worker nodes have 12.000000 vCPUs
    2024-01-05T19:53:54.070Z	INFO	agent.agent-reconciler	agent/hcp_capacity_calculation.go:142	The worker nodes have 49.173369 GB memory
    Copy to Clipboard Toggle word wrap

    オーバーライドされた測定値が hcp-sizing-baseline config map で適切に更新されない場合、hypershift-addon-agent Pod ログに次のエラーメッセージが表示されることがあります。

    エラーの例

    2024-01-05T19:53:54.052Z	ERROR	agent.agent-reconciler	agent/agent.go:788	failed to get configmap from the hub. Setting the HCP sizing baseline with default values.	{"error": "configmaps \"hcp-sizing-baseline\" not found"}
    Copy to Clipboard Toggle word wrap

3.3.2. メトリクスサービスモニタリングの無効化

hypershift-addon マネージドクラスターアドオンを有効にすると、メトリクスサービスモニタリングがデフォルトで設定され、OpenShift Container Platform モニタリングが hypershift-addon からメトリクスを収集できるようになります。

手順

次の手順を実行して、メトリクスサービスの監視を無効にできます。

  1. 次のコマンドを実行して、ハブクラスターにログインします。

    $ oc login
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、hypershift-addon-deploy-config アドオンのデプロイメント設定の仕様を編集します。

    $ oc edit addondeploymentconfig hypershift-addon-deploy-config \
      -n multicluster-engine
    Copy to Clipboard Toggle word wrap
  3. 次の例に示すように、disableMetrics=true カスタマイズ変数を仕様に追加します。

    apiVersion: addon.open-cluster-management.io/v1alpha1
    kind: AddOnDeploymentConfig
    metadata:
      name: hypershift-addon-deploy-config
      namespace: multicluster-engine
    spec:
      customizedVariables:
      - name: hcMaxNumber
        value: "80"
      - name: hcThresholdNumber
        value: "60"
      - name: disableMetrics 
    1
    
        value: "true"
    Copy to Clipboard Toggle word wrap
    1
    カスタマイズ変数 disableMetrics=true は、新規および既存の hypershift-addon マネージドクラスターアドオンのメトリクスサービス監視を無効にします。
  4. 次のコマンドを実行して、設定の仕様に変更を適用します。

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

3.4. Hosted Control Plane のコマンドラインインターフェイスのインストール

Hosted Control Plane のコマンドラインインターフェイスである hcp は、Hosted Control Plane の使用を開始するために使用できるツールです。管理や設定などの Day 2 運用には、GitOps や独自の自動化ツールを使用してください。

3.4.1. ターミナルからの Hosted Control Plane コマンドラインインターフェイスのインストール

ターミナルから、Hosted Control Plane のコマンドラインインターフェイス (CLI) である hcp をインストールできます。

前提条件

  • OpenShift Container Platform クラスターに multicluster engine for Kubernetes Operator 2.5 がインストールされている。multicluster engine Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。Red Hat Advanced Cluster Management を使用せずに、OpenShift Container Platform OperatorHub から multicluster engine Operator を Operator としてインストールすることもできます。

手順

  1. 次のコマンドを実行して、hcp バイナリーをダウンロードするための URL を取得します。

    $ oc get ConsoleCLIDownload hcp-cli-download -o json | jq -r ".spec"
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して hcp バイナリーをダウンロードします。

    $ wget <hcp_cli_download_url> 
    1
    Copy to Clipboard Toggle word wrap
    1
    hcp_cli_download_url は、前の手順で取得した URL に置き換えます。
  3. 次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。

    $ tar xvzf hcp.tar.gz
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、hcp バイナリーファイルを実行可能にします。

    $ chmod +x hcp
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、hcp バイナリーファイルをパス内のディレクトリーに移動します。

    $ sudo mv hcp /usr/local/bin/.
    Copy to Clipboard Toggle word wrap
注記

Mac コンピューターに CLI をダウンロードすると、hcp バイナリーファイルに関する警告が表示される場合があります。バイナリーファイルを実行できるようにするには、セキュリティー設定を調整する必要があります。

検証

  • 次のコマンドを実行して、使用可能なパラメーターのリストが表示されることを確認します。

    $ hcp create cluster <platform> --help 
    1
    Copy to Clipboard Toggle word wrap
    1
    hcp create cluster コマンドを使用すると、ホステッドクラスターを作成および管理できます。サポートされているプラットフォームは、awsagent、および kubevirt です。

OpenShift Container Platform Web コンソールを使用して、Hosted Control Plane のコマンドラインインターフェイス (CLI) である hcp をインストールできます。

前提条件

  • OpenShift Container Platform クラスターに multicluster engine for Kubernetes Operator 2.5 がインストールされている。multicluster engine Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。Red Hat Advanced Cluster Management を使用せずに、OpenShift Container Platform OperatorHub から multicluster engine Operator を Operator としてインストールすることもできます。

手順

  1. OpenShift Container Platform Web コンソールから、Help アイコンCommand Line Tools をクリックします。
  2. お使いのプラットフォーム用の Download hcp CLI をクリックします。
  3. 次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。

    $ tar xvzf hcp.tar.gz
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、バイナリーファイルを実行可能にします。

    $ chmod +x hcp
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。

    $ sudo mv hcp /usr/local/bin/.
    Copy to Clipboard Toggle word wrap
注記

Mac コンピューターに CLI をダウンロードすると、hcp バイナリーファイルに関する警告が表示される場合があります。バイナリーファイルを実行できるようにするには、セキュリティー設定を調整する必要があります。

検証

  • 次のコマンドを実行して、使用可能なパラメーターのリストが表示されることを確認します。

    $ hcp create cluster <platform> --help 
    1
    Copy to Clipboard Toggle word wrap
    1
    hcp create cluster コマンドを使用すると、ホステッドクラスターを作成および管理できます。サポートされているプラットフォームは、awsagent、および kubevirt です。

コンテンツゲートウェイを使用して、Hosted Control Plane のコマンドラインインターフェイス (CLI) である hcp をインストールできます。

前提条件

  • OpenShift Container Platform クラスターに multicluster engine for Kubernetes Operator 2.5 がインストールされている。multicluster engine Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。Red Hat Advanced Cluster Management を使用せずに、OpenShift Container Platform OperatorHub から multicluster engine Operator を Operator としてインストールすることもできます。

手順

  1. コンテンツゲートウェイ に移動し、hcp バイナリーをダウンロードします。
  2. 次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。

    $ tar xvzf hcp.tar.gz
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、hcp バイナリーファイルを実行可能にします。

    $ chmod +x hcp
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、hcp バイナリーファイルをパス内のディレクトリーに移動します。

    $ sudo mv hcp /usr/local/bin/.
    Copy to Clipboard Toggle word wrap
注記

Mac コンピューターに CLI をダウンロードすると、hcp バイナリーファイルに関する警告が表示される場合があります。バイナリーファイルを実行できるようにするには、セキュリティー設定を調整する必要があります。

検証

  • 次のコマンドを実行して、使用可能なパラメーターのリストが表示されることを確認します。

    $ hcp create cluster <platform> --help 
    1
    Copy to Clipboard Toggle word wrap
    1
    hcp create cluster コマンドを使用すると、ホステッドクラスターを作成および管理できます。サポートされているプラットフォームは、awsagent、および kubevirt です。

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-1aworker-1bworker-2a、および worker-2b のノードがあります。worker-1aworker-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 の引数 --tolerations を使用して、クラスターを作成するときに、ホステッドクラスターに 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 ケイパビリティー KILLMKNODSETUID、および SETGID をドロップします。

各管理クラスターのワーカーノード上の管理コンポーネント (kubeletcrio など) は、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

3.6. Hosted Control Plane 機能の有効化または無効化

Hosted Control Plane 機能と hypershift-addon マネージドクラスターアドオンは、デフォルトで有効になっています。機能を無効にする場合、または無効にした後に手動で有効にする場合は、次の手順を参照してください。

3.6.1. Hosted Control Plane 機能の手動での有効化

Hosted Control Plane を手動で有効にする必要がある場合は、次の手順を実行します。

手順

  1. 次のコマンドを実行して機能を有効にします。

    $ oc patch mce multiclusterengine --type=merge -p \
      '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}' 
    1
    Copy to Clipboard Toggle word wrap
    1
    デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。
  2. 次のコマンドを実行して、hypershift および hypershift-local-hosting 機能が MultiClusterEngine カスタムリソースで有効になっていることを確認します。

    $ oc get mce multiclusterengine -o yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。

    出力例

    apiVersion: multicluster.openshift.io/v1
    kind: MultiClusterEngine
    metadata:
      name: multiclusterengine
    spec:
      overrides:
        components:
        - name: hypershift
          enabled: true
        - name: hypershift-local-hosting
          enabled: true
    Copy to Clipboard Toggle word wrap

3.6.1.1. local-cluster の hypershift-addon マネージドクラスターアドオンを手動で有効にする

Hosted Control Plane 機能を有効にすると、hypershift-addon マネージドクラスターアドオンが自動的に有効になります。hypershift-addon マネージドクラスターアドオンを手動で有効にする必要がある場合は、次の手順を実行して hypershift-addon を使用し、HyperShift Operator を local-cluster にインストールします。

手順

  1. 次の例のようなファイルを作成して、hypershift-addon という名前の ManagedClusterAddon アドオンを作成します。

    apiVersion: addon.open-cluster-management.io/v1alpha1
    kind: ManagedClusterAddOn
    metadata:
      name: hypershift-addon
      namespace: local-cluster
    spec:
      installNamespace: open-cluster-management-agent-addon
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行してこのファイルを適用します。

    $ oc apply -f <filename>
    Copy to Clipboard Toggle word wrap

    filename は、作成したファイル名に置き換えます。

  3. 次のコマンドを実行して、hypershift-addon マネージドクラスターアドオンがインストールされていることを確認します。

    $ oc get managedclusteraddons -n local-cluster hypershift-addon
    Copy to Clipboard Toggle word wrap

    アドオンがインストールされている場合、出力は以下の例のようになります。

    NAME               AVAILABLE   DEGRADED   PROGRESSING
    hypershift-addon   True
    Copy to Clipboard Toggle word wrap

hypershift-addon マネージドクラスターアドオンがインストールされ、ホスティングクラスターを使用してホステッドクラスターを作成および管理できるようになります。

3.6.2. Hosted Control Plane 機能の無効化

HyperShift Operator をアンインストールして、Hosted Control Plane 機能を無効にすることができます。Hosted Control Plane 機能を無効にする場合は、ホステッドクラスターの管理 のトピックで説明されているように、multicluster engine Operator のホステッドクラスターとマネージドクラスターリソースを破棄する必要があります。

3.6.2.1. HyperShift Operator のアンインストール

HyperShift Operator をアンインストールし、local-cluster から hypershift-addon を無効にするには、以下の手順を実行します。

手順

  1. 以下のコマンドを実行して、ホステッドクラスターが実行されていないことを確認します。

    $ oc get hostedcluster -A
    Copy to Clipboard Toggle word wrap
    重要

    ホステッドクラスターが実行中の場合、hypershift-addon が無効になっていても、HyperShift Operator はアンインストールされません。

  2. 以下のコマンドを実行して hypershift-addon を無効にします。

    $ oc patch mce multiclusterengine --type=merge -p \
    1
    
      '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}'
    Copy to Clipboard Toggle word wrap
    1
    デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。
    注記

    hypershift-addon を無効にした後、multicluster engine Operator コンソールから local-clusterhypershift-addon を無効にすることもできます。

3.6.2.2. Hosted Control Plane 機能の無効化

Hosted Control Plane 機能を無効にするには、次の手順を実行します。

前提条件

  • HyperShift Operator をアンインストールした。詳細は、「HyperShift Operator のアンインストール」を参照してください。

手順

  1. 次のコマンドを実行して、Hosted Control Plane 機能を無効にします。

    $ oc patch mce multiclusterengine --type=merge -p \
    1
    
      '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": false}]}}}'
    Copy to Clipboard Toggle word wrap
    1
    デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。
  2. 次のコマンドを実行すると、MultiClusterEngine カスタムリソースで hypershift および hypershift-local-hosting 機能が無効になっていることを確認できます。

    $ oc get mce multiclusterengine -o yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。

    hypershifthypershift-local-hostingenabled: フラグが false に設定されている次の例を参照してください。

    apiVersion: multicluster.openshift.io/v1
    kind: MultiClusterEngine
    metadata:
      name: multiclusterengine
    spec:
      overrides:
        components:
        - name: hypershift
          enabled: false
        - name: hypershift-local-hosting
          enabled: false
    Copy to Clipboard Toggle word wrap

第4章 Hosted Control Plane のデプロイ

4.1. AWS への Hosted Control Plane のデプロイ

ホステッドクラスター は、API エンドポイントとコントロールプレーンが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。オンプレミスで Hosted Control Plane を設定するには、管理クラスターに multicluster engine for Kubernetes Operator をインストールする必要があります。hypershift-addon マネージドクラスターアドオンを使用して既存のマネージドクラスターに HyperShift Operator をデプロイすると、そのクラスターを管理クラスターとして有効にして、ホステッドクラスターの作成を開始できます。hypershift-addon マネージドクラスターアドオンは、local-cluster マネージドクラスターでデフォルトで有効になっています。

ホステッドクラスターは、multicluster engine Operator のコンソールか、Hosted Control Plane のコマンドラインインターフェイス (CLI) である hcp を使用して作成できます。ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。ただし、この multicluster engine Operator への自動インポート機能を無効にする こともできます。

4.1.1. AWS への Hosted Control Plane のデプロイの準備

Amazon Web Services (AWS) に Hosted Control Plane をデプロイする準備をする際には、次の情報を考慮してください。

  • 各ホステッドクラスターの名前がクラスター全体で一意である。multicluster engine Operator によってホステッドクラスターを管理するには、ホステッドクラスター名を既存のマネージドクラスターと同じにすることはできません。
  • ホステッドクラスター名として clusters を使用しないでください。
  • 管理クラスターとワーカーは、Hosted Control Plane の同じプラットフォーム上で実行してください。
  • ホステッドクラスターは、multicluster engine Operator のマネージドクラスターの namespace には作成できない。
4.1.1.1. 管理クラスターを設定するための前提条件

管理クラスターを設定するには、次の前提条件を満たす必要があります。

  • OpenShift Container Platform クラスターに multicluster engine for Kubernetes Operator 2.5 以降がインストールされている。multicluster engine Operator は、Red Hat Advanced Cluster Management (RHACM) をインストールすると、自動的にインストールされます。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator として RHACM なしでインストールすることもできます。
  • multicluster engine Operator のマネージド OpenShift Container Platform クラスターが少なくとも 1 つある。multicluster engine Operator バージョン 2.5 以降では、local-cluster が自動的にインポートされます。次のコマンドを実行して、ハブクラスターの状態を確認できます。

    $ oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • aws コマンドラインインターフェイス (CLI) がインストールされている。
  • Hosted Control Plane の CLI である hcp がインストールされている。

4.1.2. hcp CLI を使用して AWS 上のホステッドクラスターにアクセスする

hcp コマンドラインインターフェイス (CLI) を使用して kubeconfig ファイルを生成することで、ホステッドクラスターにアクセスできます。

手順

  1. 次のコマンドを入力して、kubeconfig ファイルを生成します。

    $ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
      --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
    Copy to Clipboard Toggle word wrap
  2. kubeconfig ファイルを保存した後、次のコマンドを入力してホステッドクラスターにアクセスできます。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

4.1.3. Amazon Web Services S3 バケットと S3 OIDC シークレットの作成

Amazon Web Services (AWS) でホステッドクラスターを作成して管理するには、S3 バケットと S3 OIDC シークレットを作成する必要があります。

手順

  1. 次のコマンドを実行して、クラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを持つ S3 バケットを作成します。

    $ aws s3api create-bucket --bucket <bucket_name> \
    1
    
      --create-bucket-configuration LocationConstraint=<region> \
    2
    
      --region <region> 
    3
    Copy to Clipboard Toggle word wrap
    1
    <bucket_name> は、作成する S3 バケットの名前に置き換えます。
    2 3
    us-east-1 リージョン以外のリージョンにバケットを作成するには、この行を追加し、<region> を使用するリージョンに置き換えます。us-east-1 リージョンにバケットを作成するには、この行を省略します。
    $ aws s3api delete-public-access-block --bucket <bucket_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <bucket_name> は、作成する S3 バケットの名前に置き換えます。
    $ echo '{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": "*",
                "Action": "s3:GetObject",
                "Resource": "arn:aws:s3:::<bucket_name>/*" 
    1
    
            }
        ]
    }' | envsubst > policy.json
    Copy to Clipboard Toggle word wrap
    1
    <bucket_name> は、作成する S3 バケットの名前に置き換えます。
    $ aws s3api put-bucket-policy --bucket <bucket_name> \
    1
    
      --policy file://policy.json
    Copy to Clipboard Toggle word wrap
    1
    <bucket_name> は、作成する S3 バケットの名前に置き換えます。
    注記

    Mac コンピューターを使用している場合は、ポリシーを機能させるためにバケット名をエクスポートする必要があります。

  2. HyperShift Operator 用に hypershift-operator-oidc-provider-s3-credentials という名前の OIDC S3 シークレットを作成します。
  3. シークレットを local-cluster namespace に保存します。
  4. 次の表を参照して、シークレットに次のフィールドが含まれていることを確認します。

    Expand
    表4.1 AWS シークレットの必須フィールド
    フィールド名説明

    bucket

    ホステッドクラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを備えた S3 バケットが含まれています。

    credentials

    バケットにアクセスできる default プロファイルの認証情報を含むファイルへの参照。デフォルトでは、HyperShift は default プロファイルのみを使用して bucket を操作します。

    region

    S3 バケットのリージョンを指定します。

  5. AWS シークレットを作成するには、次のコマンドを実行します。

    $ oc create secret generic <secret_name> \
      --from-file=credentials=<path>/.aws/credentials \
      --from-literal=bucket=<s3_bucket> \
      --from-literal=region=<region> \
      -n local-cluster
    Copy to Clipboard Toggle word wrap
    注記

    シークレットの障害復旧バックアップは自動的に有効になりません。障害復旧用に hypershift-operator-oidc-provider-s3-credentials シークレットのバックアップを有効にするラベルを追加するには、次のコマンドを実行します。

    $ oc label secret hypershift-operator-oidc-provider-s3-credentials \
      -n local-cluster cluster.open-cluster-management.io/backup=true
    Copy to Clipboard Toggle word wrap

4.1.4. ホステッドクラスター用のルーティング可能なパブリックゾーンの作成

ホステッドクラスター内のアプリケーションにアクセスするには、ルーティング可能なパブリックゾーンを設定する必要があります。パブリックゾーンが存在する場合は、この手順を省略します。省略しないと、パブリックゾーンによって既存の機能に影響が生じます。

手順

  • DNS レコードのルーティング可能なパブリックゾーンを作成するには、次のコマンドを入力します。

    $ aws route53 create-hosted-zone \
      --name <basedomain> \
    1
    
      --caller-reference $(whoami)-$(date --rfc-3339=date)
    Copy to Clipboard Toggle word wrap
    1
    <basedomain> は、ベースドメイン (例: www.example.com) に置き換えます。

4.1.5. AWS IAM ロールと STS 認証情報の作成

Amazon Web Services (AWS) でホステッドクラスターを作成する前に、AWS IAM ロールと STS 認証情報を作成する必要があります。

手順

  1. 次のコマンドを実行して、ユーザーの Amazon Resource Name (ARN) を取得します。

    $ aws sts get-caller-identity --query "Arn" --output text
    Copy to Clipboard Toggle word wrap

    出力例

    arn:aws:iam::1234567890:user/<aws_username>
    Copy to Clipboard Toggle word wrap

    この出力は、次のステップで <arn> の値として使用します。

  2. ロールの信頼関係設定を含む JSON ファイルを作成します。以下の例を参照してください。

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "AWS": "<arn>" 
    1
    
                },
                "Action": "sts:AssumeRole"
            }
        ]
    }
    Copy to Clipboard Toggle word wrap
    1
    <arn> は、前のステップでメモしたユーザーの ARN に置き換えます。
  3. 次のコマンドを実行して、Identity and Access Management (IAM) ロールを作成します。

    $ aws iam create-role \
      --role-name <name> \
    1
    
      --assume-role-policy-document file://<file_name>.json \
    2
    
      --query "Role.Arn"
    Copy to Clipboard Toggle word wrap
    1
    <name> は、ロール名に置き換えます (例: hcp-cli-role)。
    2
    <file_name> は、前のステップで作成した JSON ファイルの名前に置き換えます。

    出力例

    arn:aws:iam::820196288204:role/myrole
    Copy to Clipboard Toggle word wrap

  4. ロールの次の権限ポリシーを含む policy.json という名前の JSON ファイルを作成します。

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "EC2",
                "Effect": "Allow",
                "Action": [
                    "ec2:CreateDhcpOptions",
                    "ec2:DeleteSubnet",
                    "ec2:ReplaceRouteTableAssociation",
                    "ec2:DescribeAddresses",
                    "ec2:DescribeInstances",
                    "ec2:DeleteVpcEndpoints",
                    "ec2:CreateNatGateway",
                    "ec2:CreateVpc",
                    "ec2:DescribeDhcpOptions",
                    "ec2:AttachInternetGateway",
                    "ec2:DeleteVpcEndpointServiceConfigurations",
                    "ec2:DeleteRouteTable",
                    "ec2:AssociateRouteTable",
                    "ec2:DescribeInternetGateways",
                    "ec2:DescribeAvailabilityZones",
                    "ec2:CreateRoute",
                    "ec2:CreateInternetGateway",
                    "ec2:RevokeSecurityGroupEgress",
                    "ec2:ModifyVpcAttribute",
                    "ec2:DeleteInternetGateway",
                    "ec2:DescribeVpcEndpointConnections",
                    "ec2:RejectVpcEndpointConnections",
                    "ec2:DescribeRouteTables",
                    "ec2:ReleaseAddress",
                    "ec2:AssociateDhcpOptions",
                    "ec2:TerminateInstances",
                    "ec2:CreateTags",
                    "ec2:DeleteRoute",
                    "ec2:CreateRouteTable",
                    "ec2:DetachInternetGateway",
                    "ec2:DescribeVpcEndpointServiceConfigurations",
                    "ec2:DescribeNatGateways",
                    "ec2:DisassociateRouteTable",
                    "ec2:AllocateAddress",
                    "ec2:DescribeSecurityGroups",
                    "ec2:RevokeSecurityGroupIngress",
                    "ec2:CreateVpcEndpoint",
                    "ec2:DescribeVpcs",
                    "ec2:DeleteSecurityGroup",
                    "ec2:DeleteDhcpOptions",
                    "ec2:DeleteNatGateway",
                    "ec2:DescribeVpcEndpoints",
                    "ec2:DeleteVpc",
                    "ec2:CreateSubnet",
                    "ec2:DescribeSubnets"
                ],
                "Resource": "*"
            },
            {
                "Sid": "ELB",
                "Effect": "Allow",
                "Action": [
                    "elasticloadbalancing:DeleteLoadBalancer",
                    "elasticloadbalancing:DescribeLoadBalancers",
                    "elasticloadbalancing:DescribeTargetGroups",
                    "elasticloadbalancing:DeleteTargetGroup"
                ],
                "Resource": "*"
            },
            {
                "Sid": "IAMPassRole",
                "Effect": "Allow",
                "Action": "iam:PassRole",
                "Resource": "arn:*:iam::*:role/*-worker-role",
                "Condition": {
                    "ForAnyValue:StringEqualsIfExists": {
                        "iam:PassedToService": "ec2.amazonaws.com"
                    }
                }
            },
            {
                "Sid": "IAM",
                "Effect": "Allow",
                "Action": [
                    "iam:CreateInstanceProfile",
                    "iam:DeleteInstanceProfile",
                    "iam:GetRole",
                    "iam:UpdateAssumeRolePolicy",
                    "iam:GetInstanceProfile",
                    "iam:TagRole",
                    "iam:RemoveRoleFromInstanceProfile",
                    "iam:CreateRole",
                    "iam:DeleteRole",
                    "iam:PutRolePolicy",
                    "iam:AddRoleToInstanceProfile",
                    "iam:CreateOpenIDConnectProvider",
                    "iam:ListOpenIDConnectProviders",
                    "iam:DeleteRolePolicy",
                    "iam:UpdateRole",
                    "iam:DeleteOpenIDConnectProvider",
                    "iam:GetRolePolicy"
                ],
                "Resource": "*"
            },
            {
                "Sid": "Route53",
                "Effect": "Allow",
                "Action": [
                    "route53:ListHostedZonesByVPC",
                    "route53:CreateHostedZone",
                    "route53:ListHostedZones",
                    "route53:ChangeResourceRecordSets",
                    "route53:ListResourceRecordSets",
                    "route53:DeleteHostedZone",
                    "route53:AssociateVPCWithHostedZone",
                    "route53:ListHostedZonesByName"
                ],
                "Resource": "*"
            },
            {
                "Sid": "S3",
                "Effect": "Allow",
                "Action": [
                    "s3:ListAllMyBuckets",
                    "s3:ListBucket",
                    "s3:DeleteObject",
                    "s3:DeleteBucket"
                ],
                "Resource": "*"
            }
        ]
    }
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、policy.json ファイルをロールに割り当てます。

    $ aws iam put-role-policy \
      --role-name <role_name> \
    1
    
      --policy-name <policy_name> \
    2
    
      --policy-document file://policy.json 
    3
    Copy to Clipboard Toggle word wrap
    1
    <role_name> は、ロールの名前に置き換えます。
    2
    <policy_name> は、ポリシー名に置き換えます。
    3
    policy.json ファイルには、ロールの権限ポリシーを含めます。
  6. 次のコマンドを実行して、sts-creds.json という名前の JSON ファイル内の STS 認証情報を取得します。

    $ aws sts get-session-token --output json > sts-creds.json
    Copy to Clipboard Toggle word wrap

    sts-creds.json ファイルの例

    {
        "Credentials": {
            "AccessKeyId": "<access_key_id",
            "SecretAccessKey": "<secret_access_key>”,
            "SessionToken": "<session_token>",
            "Expiration": "<time_stamp>"
        }
    }
    Copy to Clipboard Toggle word wrap

4.1.7. AWS 上の Hosted Control Plane 用の外部 DNS を有効にする

Hosted Control Plane では、コントロールプレーンとデータプレーンが分離されています。DNS は、次の 2 つの独立した領域で設定できます。

  • ホステッドクラスター (*.apps.service-consumer-domain.com などのドメイン) 内のワークロードの Ingress。
  • サービスプロバイダーのドメイン *.service-provider-domain.com を介した API または OAuth エンドポイントなど、管理クラスター内のサービスエンドポイントの Ingress。

hostedCluster.spec.dns の入力は、ホステッドクラスター内のワークロードの Ingress を管理します。hostedCluster.spec.services.servicePublishingStrategy.route.hostname の入力は、管理クラスター内のサービスエンドポイントの Ingress を決定します。

外部 DNS は、LoadBalancer または Route の公開タイプを指定し、その公開タイプのホスト名を提供するホステッドクラスター Services の名前レコードを作成します。Private または PublicAndPrivate エンドポイントアクセスタイプを持つホステッドクラスターの場合、APIServer サービスと OAuth サービスのみがホスト名をサポートします。Private ホステッドクラスターの場合、DNS レコードが VPC 内の Virtual Private Cloud (VPC) エンドポイントのプライベート IP アドレスに解決されます。

Hosted Control Plane は、次のサービスを公開します。

  • APIServer
  • OIDC

これらのサービスは、HostedCluster 仕様の servicePublishingStrategy フィールドを使用して公開できます。デフォルトでは、servicePublishingStrategyLoadBalancer および Route タイプの場合、次のいずれかの方法でサービスを公開できます。

  • LoadBalancer タイプの Service のステータスにあるロードバランサーのホスト名を使用する方法
  • Route リソースの status.host フィールドを使用する方法

ただし、マネージドサービスのコンテキストで Hosted Control Plane をデプロイすると、これらの方法によって、基盤となる管理クラスターの Ingress サブドメインが公開され、管理クラスターのライフサイクルと障害復旧のオプションが制限される可能性があります。

DNS 間接化が LoadBalancer および Route 公開タイプに階層化されている場合、マネージドサービスオペレーターは、サービスレベルドメインを使用してすべてのパブリックホステッドクラスターサービスを公開できます。このアーキテクチャーでは、DNS 名を新しい LoadBalancer または Route に再マッピングできますが、管理クラスターの Ingress ドメインは公開されません。Hosted Control Plane は、外部 DNS を使用して間接層を実現します。

管理クラスターの hypershift namespace に HyperShift Operator と一緒に external-dns をデプロイできます。外部 DNS は、external-dns.alpha.kubernetes.io/hostname アノテーションを持つ Services または Routes を監視します。このアノテーションは、A レコードなどの Service、または CNAME レコードなどの Route を参照する DNS レコードを作成するために使用されます。

外部 DNS はクラウド環境でのみ使用できます。その他の環境では、DNS とサービスを手動で設定する必要があります。

外部 DNS の詳細は、外部 DNS を参照してください。

4.1.7.1. 前提条件

Amazon Web Services (AWS) で Hosted Control Plane の外部 DNS を設定する前に、次の前提条件を満たす必要があります。

  • 外部パブリックドメインを作成した。
  • AWS Route53 管理コンソールにアクセスできる。
  • Hosted Control Plane 用に AWS PrivateLink を有効にした。
4.1.7.2. Hosted Control Plane の外部 DNS の設定

Hosted Control Plane は、外部 DNS またはサービスレベル DNS を使用してプロビジョニングできます。

  1. HyperShift Operator 用の Amazon Web Services (AWS) 認証情報シークレットを作成し、local-cluster namespace で hypershift-operator-external-dns-credentials という名前を付けます。
  2. 次の表を参照して、シークレットに必須フィールドが含まれていることを確認してください。

    Expand
    表4.3 AWS シークレットの必須フィールド
    フィールド名説明任意または必須

    provider

    サービスレベル DNS ゾーンを管理する DNS プロバイダー。

    必須

    domain-filter

    サービスレベルドメイン。

    必須

    credentials

    すべての外部 DNS タイプをサポートする認証情報ファイル。

    AWS キーを使用する場合はオプション

    aws-access-key-id

    認証情報アクセスキー ID。

    AWS DNS サービスを使用する場合はオプション

    aws-secret-access-key

    認証情報アクセスキーのシークレット。

    AWS DNS サービスを使用する場合はオプション

  3. AWS シークレットを作成するには、次のコマンドを実行します。

    $ oc create secret generic <secret_name> \
      --from-literal=provider=aws \
      --from-literal=domain-filter=<domain_name> \
      --from-file=credentials=<path_to_aws_credentials_file> -n local-cluster
    Copy to Clipboard Toggle word wrap
    注記

    シークレットの障害復旧バックアップは自動的に有効になりません。障害復旧のためにシークレットをバックアップするには、次のコマンドを入力して hypershift-operator-external-dns-credentials を追加します。

    $ oc label secret hypershift-operator-external-dns-credentials \
      -n local-cluster \
      cluster.open-cluster-management.io/backup=""
    Copy to Clipboard Toggle word wrap
4.1.7.3. パブリック DNS ホストゾーンの作成

パブリック DNS ホストゾーンは、パブリックホステッドクラスターを作成するために、External DNS Operator によって使用されます。

外部 DNS ドメインフィルターとして使用するパブリック DNS ホストゾーンを作成できます。AWS Route 53 管理コンソールで次の手順を実行します。

手順

  1. Route 53 管理コンソールで、Create hosted zone をクリックします。
  2. Hosted zone configuration ページでドメイン名を入力し、タイプとして Public hosted zone が選択されていることを確認し、Create hosted zone をクリックします。
  3. ゾーンが作成されたら、Records タブの Value/Route traffic to 列の値をメモします。
  4. メインドメインで、DNS 要求を委任ゾーンにリダイレクトするための NS レコードを作成します。Value フィールドに、前の手順でメモした値を入力します。
  5. Create records をクリックします。
  6. 次の例のように、新しいサブゾーンにテストエントリーを作成し、dig コマンドでテストして、DNS ホストゾーンが機能していることを確認します。

    $ dig +short test.user-dest-public.aws.kerberos.com
    Copy to Clipboard Toggle word wrap

    出力例

    192.168.1.1
    Copy to Clipboard Toggle word wrap

  7. LoadBalancer および Route サービスのホスト名を設定するホステッドクラスターを作成するには、次のコマンドを入力します。

    $ hcp create cluster aws --name=<hosted_cluster_name> \
      --endpoint-access=PublicAndPrivate \
      --external-dns-domain=<public_hosted_zone> ... 
    1
    Copy to Clipboard Toggle word wrap
    1
    <public_hosted_zone> は、作成したパブリックホストゾーンに置き換えます。

    ホステッドクラスターの services ブロックの例

      platform:
        aws:
          endpointAccess: PublicAndPrivate
    ...
      services:
      - service: APIServer
        servicePublishingStrategy:
          route:
            hostname: api-example.service-provider-domain.com
          type: Route
      - service: OAuthServer
        servicePublishingStrategy:
          route:
            hostname: oauth-example.service-provider-domain.com
          type: Route
      - service: Konnectivity
        servicePublishingStrategy:
          type: Route
      - service: Ignition
        servicePublishingStrategy:
          type: Route
    Copy to Clipboard Toggle word wrap

Control Plane Operator は、ServicesRoutes リソースを作成し、external-dns.alpha.kubernetes.io/hostname のアノテーションを付けます。ServicesRoutes の場合、Control Plane Operator は、サービスエンドポイントの servicePublishingStrategy フィールドの hostname パラメーターの値を使用します。DNS レコードを作成するには、external-dns デプロイメントなどのメカニズムを使用できます。

サービスレベルの DNS 間接化をパブリックサービスにのみ設定できます。プライベートサービスは hypershift.local プライベートゾーンを使用するため、hostname を設定できません。

次の表は、サービスとエンドポイントの組み合わせに対して hostname を設定することが有効な場合を示しています。

Expand
表4.4 hostname を設定するためのサービスとエンドポイントの組み合わせ
サービスPublicPublicAndPrivatePrivate

APIServer

Y

Y

N

OAuthServer

Y

Y

N

Konnectivity

Y

N

N

Ignition

Y

N

N

4.1.7.4. AWS 上で外部 DNS を使用してホステッドクラスターを作成する

Amazon Web Services (AWS) で PublicAndPrivate または Public 公開ストラテジーを使用してホステッドクラスターを作成するには、管理クラスターで次のアーティファクトが設定されている必要があります。

  • パブリック DNS ホストゾーン
  • External DNS Operator
  • HyperShift Operator

ホステッドクラスターは、hcp コマンドラインインターフェイス (CLI) を使用してデプロイできます。

手順

  1. 管理クラスターにアクセスするには、次のコマンドを入力します。

    $ export KUBECONFIG=<path_to_management_cluster_kubeconfig>
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、External DNS Operator が実行されていることを確認します。

    $ oc get pod -n hypershift -lapp=external-dns
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                            READY   STATUS    RESTARTS   AGE
    external-dns-7c89788c69-rn8gp   1/1     Running   0          40s
    Copy to Clipboard Toggle word wrap

  3. 外部 DNS を使用してホステッドクラスターを作成するには、次のコマンドを入力します。

    $ hcp create cluster aws \
        --role-arn <arn_role> \ 
    1
    
        --instance-type <instance_type> \ 
    2
    
        --region <region> \ 
    3
    
        --auto-repair \
        --generate-ssh \
        --name <hosted_cluster_name> \ 
    4
    
        --namespace clusters \
        --base-domain <service_consumer_domain> \ 
    5
    
        --node-pool-replicas <node_replica_count> \ 
    6
    
        --pull-secret <path_to_your_pull_secret> \ 
    7
    
        --release-image quay.io/openshift-release-dev/ocp-release:<ocp_release_image> \ 
    8
    
        --external-dns-domain=<service_provider_domain> \ 
    9
    
        --endpoint-access=PublicAndPrivate 
    10
    
        --sts-creds <path_to_sts_credential_file> 
    11
    Copy to Clipboard Toggle word wrap
    1
    Amazon Resource Name (ARN) を指定します (例: arn:aws:iam::820196288204:role/myrole)。
    2
    インスタンスタイプを指定します (例: m6i.xlarge)。
    3
    AWS リージョンを指定します (例: us-east-1)。
    4
    ホステッドクラスター名を指定します (例: my-external-aws)。
    5
    サービスコンシューマーが所有するパブリックホストゾーンを指定します (例: service-consumer-domain.com)。
    6
    ノードのレプリカ数を指定します (例: 2)。
    7
    プルシークレットファイルへのパスを指定します。
    8
    使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.19.0-multi)。
    9
    サービスプロバイダーが所有するパブリックホストゾーンを指定します (例: service-provider-domain.com)。
    10
    PublicAndPrivate として設定します。外部 DNS は、Public または PublicAndPrivate 設定でのみ使用できます。
    11
    AWS STS 認証情報ファイルへのパスを指定します (例: /home/user/sts-creds/sts-creds.json)。
4.1.7.5. カスタム DNS 名の定義

クラスター管理者は、ノードのブートストラップとコントロールプレーンの通信に使用される内部エンドポイントとは異なる外部 API DNS 名を持つホステッドクラスターを作成できます。別の DNS 名を定義する理由には、次のようなものがあります。

  • 内部ルート CA にバインドされているコントロールプレーン機能を損なうことなく、ユーザー向けの TLS 証明書をパブリック CA が発行したものに置き換えるため。
  • スプリットホライズン DNS および NAT のシナリオをサポートするため。
  • スタンドアロンのコントロールプレーンと同様のエクスペリエンスを確保し、正しい kubeconfig と DNS 設定を使用して、Show Login Command などの機能を使用可能にするため。

HostedCluster オブジェクトの kubeAPIServerDNSName パラメーターにドメイン名を入力することで、初期セットアップ時またはインストール後の操作時に DNS 名を定義できます。

前提条件

  • kubeAPIServerDNSName パラメーターで設定する DNS 名が、有効な TLS 証明書の対象に含まれている。
  • 正しいアドレスに到達し、それを指し示す解決可能な DNS 名 URI がある。

手順

  • HostedCluster オブジェクトの仕様で、kubeAPIServerDNSName パラメーターとドメインのアドレスを追加し、使用する証明書を指定します (次の例を参照)。

    #...
    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names:
              - xxx.example.com
              - yyy.example.com
              servingCertificate:
                name: <my_serving_certificate>
      kubeAPIServerDNSName: <custom_address> 
    1
    Copy to Clipboard Toggle word wrap
    1
    kubeAPIServerDNSName パラメーターの値は、有効でアドレス指定可能なドメインである必要があります。

kubeAPIServerDNSName パラメーターを定義して証明書を指定すると、Control Plane Operator のコントローラーによって custom-admin-kubeconfig という名前の kubeconfig ファイルが作成されます。このファイルは HostedControlPlane namespace に保存されます。証明書はルート CA から生成され、HostedControlPlane namespace によって証明書の有効期限と更新が管理されます。

Control Plane Operator は、HostedControlPlane namespace に CustomKubeconfig という名前の新しい kubeconfig ファイルを報告します。このファイルは、kubeAPIServerDNSName パラメーターで定義された新しいサーバーを使用します。

カスタム kubeconfig ファイルへの参照情報は、HostedCluster オブジェクトの status パラメーター内に CustomKubeconfig という名前で存在しています。CustomKubeConfig パラメーターは任意であり、kubeAPIServerDNSName パラメーターが空でない場合にのみ追加できます。CustomKubeConfig パラメーターを設定すると、そのパラメーターによって、HostedCluster namespace で <hosted_cluster_name>-custom-admin-kubeconfig という名前のシークレットの生成がトリガーされます。このシークレットを使用して HostedCluster API サーバーにアクセスできます。インストール後の操作時に CustomKubeConfig パラメーターを削除すると、関連するすべてのシークレットとステータス参照が削除されます。

注記

カスタム DNS 名の定義はデータプレーンに直接影響しないため、予期されるロールアウトは発生しません。HostedControlPlane namespace は、HyperShift Operator から変更を受け取り、対応するパラメーターを削除します。

HostedCluster オブジェクトの仕様から kubeAPIServerDNSName パラメーターを削除すると、新しく生成されたすべてのシークレットと、CustomKubeconfig 参照がクラスターと status パラメーターから削除されます。

4.1.8. AWS 上でホステッドクラスターを作成する

hcp コマンドラインインターフェイス (CLI) を使用して、Amazon Web Services (AWS) 上にホステッドクラスターを作成できます。

Amazon Web Services (AWS) 上の Hosted Control Plane では、デフォルトで AMD64 ホステッドクラスターを使用します。ただし、Hosted Control Plane を ARM64 ホステッドクラスターで実行することもできます。詳細は、「ARM64 アーキテクチャーでのホステッドクラスターの実行」を参照してください。

ノードプールとホステッドクラスターの互換性のある組み合わせは、次の表を参照してください。

Expand
表4.5 ノードプールとホステッドクラスターの互換性のあるアーキテクチャー
ホステッドクラスターノードプール

AMD64

AMD64 または ARM64

ARM64

ARM64 または AMD64

前提条件

  • Hosted Control Plane の CLI である hcp を設定した。
  • local-cluster マネージドクラスターを管理クラスターとして有効にした。
  • AWS Identity and Access Management (IAM) ロールと AWS Security Token Service (STS) 認証情報を作成した。

手順

  1. AWS 上にホステッドクラスターを作成するには、次のコマンドを実行します。

    $ hcp create cluster aws \
        --name <hosted_cluster_name> \
    1
    
        --infra-id <infra_id> \
    2
    
        --base-domain <basedomain> \
    3
    
        --sts-creds <path_to_sts_credential_file> \
    4
    
        --pull-secret <path_to_pull_secret> \
    5
    
        --region <region> \
    6
    
        --generate-ssh \
        --node-pool-replicas <node_pool_replica_count> \
    7
    
        --namespace <hosted_cluster_namespace> \
    8
    
        --role-arn <role_name> \
    9
    
        --render-into <file_name>.yaml 
    10
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    インフラストラクチャー名を指定します。<hosted_cluster_name><infra_id> には同じ値を指定する必要があります。そうしないと、multicluster engine for Kubernetes Operator のコンソールに、クラスターが正しく表示されない可能性があります。
    3
    ベースドメインを指定します (例: example.com)。
    4
    AWS STS 認証情報ファイルへのパスを指定します (例: /home/user/sts-creds/sts-creds.json)。
    5
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    6
    AWS リージョン名を指定します (例: us-east-1)。
    7
    ノードプールのレプリカ数を指定します (例: 3)。
    8
    デフォルトでは、HostedClusterNodePool のすべてのカスタムリソースが clusters namespace に作成されます。--namespace <namespace> パラメーターを使用すると、特定の namespace に HostedCluster および NodePool カスタムリソースを作成できます。
    9
    Amazon Resource Name (ARN) を指定します (例: arn:aws:iam::820196288204:role/myrole)。
    10
    EC2 インスタンスを共有テナントハードウェア上で実行するか、シングルテナントハードウェア上で実行するかを指定する場合は、このフィールドを含めます。--render-into フラグを含めると、Kubernetes リソースが、このフィールドで指定した YAML ファイルにレンダリングされます。この場合、次のステップに進み、YAML ファイルを編集します。
  2. 前のコマンドに --render-into フラグを含めた場合は、指定した YAML ファイルを編集します。YAML ファイルの NodePool 仕様を編集して、EC2 インスタンスを共有ハードウェア上で実行するか、シングルテナントハードウェア上で実行するかを指定します。次に例を示します。

    サンプル YAML ファイル

    apiVersion: hypershift.openshift.io/v1beta1
    kind: NodePool
    metadata:
      name: <nodepool_name> 
    1
    
    spec:
      platform:
        aws:
          placement:
            tenancy: "default" 
    2
    Copy to Clipboard Toggle word wrap

    1
    NodePool リソースの名前を指定します。
    2
    テナンシーの有効な値 ("default""dedicated"、または "host") を指定します。ノードプールインスタンスを共有ハードウェア上で実行する場合は、"default" を使用します。各ノードプールインスタンスをシングルテナントハードウェア上で実行する場合は、"dedicated" を使用します。事前に割り当てられた専用ホスト上でノードプールインスタンスを実行する場合は、"host" を使用します。

検証

  1. ホステッドクラスターのステータスを確認し、AVAILABLE の値が True であることを確認します。以下のコマンドを実行します。

    $ oc get hostedclusters -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、ノードプールのリストを取得します。

    $ oc get nodepools --namespace <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
4.1.8.1. AWS 上のホステッドクラスターへのアクセス

リソースから kubeconfig ファイルと kubeadmin 認証情報を直接取得することで、ホステッドクラスターにアクセスできます。

ホステッドクラスターのアクセスシークレットを理解している必要があります。ホステッドクラスター namespace にはホステッドクラスターリソースが含まれており、Hosted Control Plane namespace では Hosted Control Plane が実行されます。シークレット名の形式は次のとおりです。

  • kubeconfig シークレット: <hosted-cluster-namespace>-<name>-admin-kubeconfig.たとえば、clusters-hypershift-demo-admin-kubeconfig です。
  • kubeadmin パスワードシークレット: <hosted-cluster-namespace>-<name>-kubeadmin-password。たとえば、clusters-hypershift-demo-kubeadmin-password です。

手順

  • kubeconfig シークレットには Base64 でエンコードされた kubeconfig フィールドが含まれており、これをデコードしてファイルに保存し、次のコマンドで使用できます。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    kubeadmin パスワードシークレットも Base64 でエンコードされます。これをデコードし、そのパスワードを使用して、ホステッドクラスターの API サーバーまたはコンソールにログインできます。

4.1.8.2. kubeadmin 認証情報を使用して AWS 上のホステッドクラスターにアクセスする

Amazon Web Services (AWS) にホステッドクラスターを作成した後、kubeconfig ファイル、アクセスシークレット、および kubeadmin 認証情報を取得して、ホステッドクラスターにアクセスできます。

ホステッドクラスターのリソースとアクセスシークレットは、ホステッドクラスターの namespace に格納されます。Hosted Control Plane は、Hosted Control Plane の namespace で実行されます。

シークレット名の形式は次のとおりです。

  • kubeconfig シークレット: <hosted_cluster_namespace>-<name>-admin-kubeconfig。たとえば、clusters-hypershift-demo-admin-kubeconfig です。
  • kubeadmin パスワードシークレット: <hosted_cluster_namespace>-<name>-kubeadmin-password。たとえば、clusters-hypershift-demo-kubeadmin-password です。
注記

kubeadmin パスワードシークレットは、Base64 でエンコードされています。kubeconfig シークレットには、Base64 でエンコードされた kubeconfig 設定が含まれています。Base64 でエンコードされた kubeconfig 設定をデコードし、<hosted_cluster_name>.kubeconfig ファイルに保存する必要があります。

手順

  • デコードされた kubeconfig 設定を含む <hosted_cluster_name>.kubeconfig ファイルを使用して、ホステッドクラスターにアクセスします。以下のコマンドを入力します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    API サーバーまたはホステッドクラスターのコンソールにログインするには、kubeadmin パスワードシークレットをデコードする必要があります。

4.1.8.3. hcp CLI を使用して AWS 上のホステッドクラスターにアクセスする

hcp コマンドラインインターフェイス (CLI) を使用して、ホステッドクラスターにアクセスできます。

手順

  1. 次のコマンドを入力して、kubeconfig ファイルを生成します。

    $ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
      --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
    Copy to Clipboard Toggle word wrap
  2. kubeconfig ファイルを保存したら、次のコマンドを入力してホステッドクラスターにアクセスします。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

4.1.9. ホステッドクラスターでカスタム API サーバー証明書を設定する

API サーバーのカスタム証明書を設定するには、HostedCluster 設定の spec.configuration.apiServer セクションで証明書の詳細を指定します。

カスタム証明書は、Day 1 操作または Day 2 操作の中で設定できます。ただし、サービス公開ストラテジーはホステッドクラスターの作成中に設定した後は変更できないため、設定する予定の Kubernetes API サーバーのホスト名を知っておく必要があります。

前提条件

  • 管理クラスターにカスタム証明書が含まれる Kubernetes シークレットを作成しました。シークレットには次の鍵が含まれています。

    • tls.crt: 証明書
    • tls.key: 秘密鍵
  • HostedCluster 設定にロードバランサーを使用するサービス公開ストラテジーが含まれている場合は、証明書のサブジェクト代替名 (SAN) が内部 API エンドポイント (api-int) と競合しないことを確認してください。内部 API エンドポイントは、プラットフォームによって自動的に作成および管理されます。カスタム証明書と内部 API エンドポイントの両方で同じホスト名を使用すると、ルーティングの競合が発生する可能性があります。このルールの唯一の例外は、Private または PublicAndPrivate 設定で AWS をプロバイダーとして使用する場合です。このような場合、SAN の競合はプラットフォームによって管理されます。
  • 証明書は外部 API エンドポイントに対して有効である必要があります。
  • 証明書の有効期間は、クラスターの予想されるライフサイクルと一致します。

手順

  1. 次のコマンドを入力して、カスタム証明書を使用してシークレットを作成します。

    $ oc create secret tls sample-hosted-kas-custom-cert \
      --cert=path/to/cert.crt \
      --key=path/to/key.key \
      -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  2. 次の例に示すように、カスタム証明書の詳細を使用して HostedCluster 設定を更新します。

    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names: 
    1
    
              - api-custom-cert-sample-hosted.sample-hosted.example.com
              servingCertificate: 
    2
    
                name: sample-hosted-kas-custom-cert
    Copy to Clipboard Toggle word wrap
    1
    証明書が有効な DNS の名前のリスト。
    2
    カスタム証明書が含まれるシークレットの名前。
  3. 次のコマンドを入力して、HostedCluster 設定に変更を適用します。

    $ oc apply -f <hosted_cluster_config>.yaml
    Copy to Clipboard Toggle word wrap

検証

  • API サーバー Pod をチェックして、新しい証明書がマウントされていることを確認します。
  • カスタムドメイン名を使用して API サーバーへの接続をテストします。
  • ブラウザーで、または openssl などのツールを使用して、証明書の詳細を確認します。

4.1.10. AWS 上の複数のゾーンにホステッドクラスターを作成する

hcp コマンドラインインターフェイス (CLI) を使用して、Amazon Web Services (AWS) 上の複数のゾーンにホステッドクラスターを作成できます。

前提条件

  • AWS Identity and Access Management (IAM) ロールと AWS Security Token Service (STS) 認証情報を作成した。

手順

  • 次のコマンドを実行して、AWS 上の複数のゾーンにホステッドクラスターを作成します。

    $ hcp create cluster aws \
      --name <hosted_cluster_name> \
    1
    
      --node-pool-replicas=<node_pool_replica_count> \
    2
    
      --base-domain <basedomain> \
    3
    
      --pull-secret <path_to_pull_secret> \
    4
    
      --role-arn <arn_role> \
    5
    
      --region <region> \
    6
    
      --zones <zones> \
    7
    
      --sts-creds <path_to_sts_credential_file> 
    8
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ノードプールのレプリカ数を指定します (例: 2)。
    3
    ベースドメインを指定します (例: example.com)。
    4
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    5
    Amazon Resource Name (ARN) を指定します (例: arn:aws:iam::820196288204:role/myrole)。
    6
    AWS リージョン名を指定します (例: us-east-1)。
    7
    AWS リージョン内のアベイラビリティーゾーンを指定します (例: us-east-1aus-east-1b)。
    8
    AWS STS 認証情報ファイルへのパスを指定します (例: /home/user/sts-creds/sts-creds.json)。

指定したゾーンごとに、次のインフラストラクチャーが作成されます。

  • パブリックサブネット
  • プライベートサブネット
  • NAT ゲートウェイ
  • プライベートルートテーブル

パブリックルートテーブルはパブリックサブネット間で共有されます。

ゾーンごとに 1 つの NodePool リソースが作成されます。ノードプール名の末尾にはゾーン名が付けられます。ゾーンのプライベートサブネットは spec.platform.aws.subnet.id に設定されます。

4.1.10.1. AWS STS 認証情報を指定してホステッドクラスターを作成する

hcp create cluster aws コマンドを使用してホステッドクラスターを作成する場合は、ホステッドクラスターのインフラストラクチャーリソースを作成する権限を持つ Amazon Web Services (AWS) アカウントの認証情報を指定する必要があります。

インフラストラクチャーリソースの例としては、次のものがあります。

  • Virtual Private Cloud (VPC)
  • サブネット
  • ネットワークアドレス変換 (NAT) ゲートウェイ

次のいずれかの方法で AWS 認証情報を指定できます。

  • AWS Security Token Service (STS) 認証情報
  • multicluster engine Operator からの AWS クラウドプロバイダーのシークレット

手順

  • AWS STS 認証情報を指定して AWS 上にホステッドクラスターを作成するには、次のコマンドを入力します。

    $ hcp create cluster aws \
      --name <hosted_cluster_name> \
    1
    
      --node-pool-replicas <node_pool_replica_count> \
    2
    
      --base-domain <basedomain> \
    3
    
      --pull-secret <path_to_pull_secret> \
    4
    
      --sts-creds <path_to_sts_credential_file> \
    5
    
      --region <region> \
    6
    
      --role-arn <arn_role>  
    7
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ノードプールのレプリカ数を指定します (例: 2)。
    3
    ベースドメインを指定します (例: example.com)。
    4
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    5
    AWS STS 認証情報ファイルへのパスを指定します (例: /home/user/sts-creds/sts-creds.json)。
    6
    AWS リージョン名を指定します (例: us-east-1)。
    7
    Amazon Resource Name (ARN) を指定します (例: arn:aws:iam::820196288204:role/myrole)。

4.1.11. ARM64 アーキテクチャーでのホステッドクラスターの実行

Amazon Web Services (AWS) 上の Hosted Control Plane では、デフォルトで AMD64 ホステッドクラスターを使用します。ただし、Hosted Control Plane を ARM64 ホステッドクラスターで実行することもできます。

ノードプールとホステッドクラスターの互換性のある組み合わせは、次の表を参照してください。

Expand
表4.6 ノードプールとホステッドクラスターの互換性のあるアーキテクチャー
ホステッドクラスターノードプール

AMD64

AMD64 または ARM64

ARM64

ARM64 または AMD64

4.1.11.1. ARM64 OpenShift Container Platform クラスターにホステッドクラスターを作成する

デフォルトのリリースイメージをマルチアーキテクチャーリリースイメージでオーバーライドすることで、Amazon Web Services (AWS) の ARM64 OpenShift Container Platform クラスターでホステッドクラスターを実行できます。

マルチアーキテクチャーリリースイメージを使用しない場合、ホステッドクラスターでマルチアーキテクチャーリリースイメージを使用するか、リリースイメージに基づいて NodePool カスタムリソースを更新するまで、ノードプール内のコンピュートノードが作成されず、ノードプールのリコンシリエーションが停止します。

前提条件

  • AWS にインストールされた、64 ビット ARM インフラストラクチャーの OpenShift Container Platform クラスターがある。詳細は、Create an OpenShift Container Platform Cluster: AWS (ARM) を参照してください。
  • AWS Identity and Access Management (IAM) ロールと AWS Security Token Service (STS) 認証情報を作成する。詳細は、「AWS IAM ロールと STS 認証情報の作成」を参照してください。

手順

  • 次のコマンドを入力して、ARM64 OpenShift Container Platform クラスターにホステッドクラスターを作成します。

    $ hcp create cluster aws \
      --name <hosted_cluster_name> \
    1
    
      --node-pool-replicas <node_pool_replica_count> \
    2
    
      --base-domain <basedomain> \
    3
    
      --pull-secret <path_to_pull_secret> \
    4
    
      --sts-creds <path_to_sts_credential_file> \
    5
    
      --region <region> \
    6
    
      --release-image quay.io/openshift-release-dev/ocp-release:<ocp_release_image> \
    7
    
      --role-arn <role_name> 
    8
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ノードプールのレプリカ数を指定します (例: 3)。
    3
    ベースドメインを指定します (例: example.com)。
    4
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    5
    AWS STS 認証情報ファイルへのパスを指定します (例: /home/user/sts-creds/sts-creds.json)。
    6
    AWS リージョン名を指定します (例: us-east-1)。
    7
    使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.19.0-multi)。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、「OpenShift Container Platform リリースイメージダイジェストの抽出」を参照してください。
    8
    Amazon Resource Name (ARN) を指定します (例: arn:aws:iam::820196288204:role/myrole)。
4.1.11.2. AWS ホステッドクラスターに ARM または AMD の NodePool オブジェクトを作成する

同じ Hosted Control Plane から、64 ビット ARM および AMD の NodePool オブジェクトであるアプリケーションワークロードをスケジュールできます。NodePool 仕様で arch フィールドを定義し、NodePool オブジェクトに必要なプロセッサーアーキテクチャーを設定できます。arch フィールドの有効な値は次のとおりです。

  • arm64
  • amd64

前提条件

手順

  • 次のコマンドを実行して、AWS でホステッドクラスターに ARM または AMD の NodePool オブジェクトを追加します。

    $ hcp create nodepool aws \
      --cluster-name <hosted_cluster_name> \
    1
    
      --name <node_pool_name> \
    2
    
      --node-count <node_pool_replica_count> \
    3
    
      --arch <architecture> 
    4
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ノードプール名を指定します。
    3
    ノードプールのレプリカ数を指定します (例: 3)。
    4
    アーキテクチャータイプを指定します (例: arm64amd64)。--arch フラグに値を指定しない場合は、デフォルトで amd64 値が使用されます。

4.1.12. AWS でのプライベートホステッドクラスターの作成

local-cluster をホスティングクラスターとして有効にした後、Amazon Web Services (AWS) にホステッドクラスターまたはプライベートホステッドクラスターをデプロイできます。

デフォルトでは、ホステッドクラスターはパブリック DNS と管理クラスターのデフォルトルーターを介してパブリックにアクセスできます。

AWS 上のプライベートクラスターの場合、ホステッドクラスターとの通信は、すべて AWS PrivateLink を介して行われます。

前提条件

  • AWS PrivateLink を有効にした。詳細は、「AWS PrivateLink の有効化」を参照してください。
  • AWS Identity and Access Management (IAM) ロールと AWS Security Token Service (STS) 認証情報を作成した。詳細は、「AWS IAM ロールと STS 認証情報の作成」および「Identity and Access Management (IAM) 権限」を参照してください。
  • AWS に踏み台インスタンス を設定した。

手順

  • 次のコマンドを入力して、AWS 上にプライベートホステッドクラスターを作成します。

    $ hcp create cluster aws \
      --name <hosted_cluster_name> \
    1
    
      --node-pool-replicas=<node_pool_replica_count> \
    2
    
      --base-domain <basedomain> \
    3
    
      --pull-secret <path_to_pull_secret> \
    4
    
      --sts-creds <path_to_sts_credential_file> \
    5
    
      --region <region> \
    6
    
      --endpoint-access Private \
    7
    
      --role-arn <role_name> 
    8
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ノードプールのレプリカ数を指定します (例: 3)。
    3
    ベースドメインを指定します (例: example.com)。
    4
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    5
    AWS STS 認証情報ファイルへのパスを指定します (例: /home/user/sts-creds/sts-creds.json)。
    6
    AWS リージョン名を指定します (例: us-east-1)。
    7
    クラスターがパブリックかプライベートかを定義します。
    8
    Amazon Resource Name (ARN) を指定します (例: arn:aws:iam::820196288204:role/myrole)。ARN ロールの詳細は、「Identity and Access Management (IAM) 権限」を参照してください。

    ホステッドクラスターの次の API エンドポイントは、プライベート DNS ゾーンを通じてアクセスできます。

  • api.<hosted_cluster_name>.hypershift.local
  • *.apps.<hosted_cluster_name>.hypershift.local
4.1.12.1. AWS 上のプライベート管理クラスターへのアクセス

コマンドラインインターフェイス (CLI) を使用して、プライベート管理クラスターにアクセスできます。

手順

  1. 次のコマンドを入力して、ノードのプライベート IP を確認します。

    $ aws ec2 describe-instances \
      --filter="Name=tag:kubernetes.io/cluster/<infra_id>,Values=owned" \
      | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") \
      | .PrivateIpAddress'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、ホステッドクラスターの kubeconfig ファイルを作成し、ノードにコピーします。

    $ hcp create kubeconfig > <hosted_cluster_kubeconfig>
    Copy to Clipboard Toggle word wrap
  3. 踏み台経由でノードの 1 つに SSH 接続するために、次のコマンドを入力します。

    $ ssh -o ProxyCommand="ssh ec2-user@<bastion_ip> \
      -W %h:%p" core@<node_ip>
    Copy to Clipboard Toggle word wrap
  4. SSH シェルから、次のコマンドを入力して、kubeconfig ファイルの内容をノード上のファイルにコピーします。

    $ mv <path_to_kubeconfig_file> <new_file_name>
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを入力して、kubeconfig ファイルをエクスポートします。

    $ export KUBECONFIG=<path_to_kubeconfig_file>
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを入力して、ホステッドクラスターのステータスを確認します。

    $ oc get clusteroperators clusterversion
    Copy to Clipboard Toggle word wrap

4.2. ベアメタルへの Hosted Control Plane のデプロイ

クラスターを管理クラスターとして機能するように設定することで、Hosted Control Plane をデプロイできます。管理クラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。場合によっては、管理クラスターは ホスティング クラスターとも呼ばれます。

注記

管理クラスターは、マネージド クラスターとは異なります。マネージドクラスターは、ハブクラスターが管理するクラスターです。

Hosted Control Plane 機能はデフォルトで有効になっています。

multicluster engine Operator は、マネージドのハブクラスターであるデフォルトの local-cluster と、管理クラスターとしてのハブクラスターのみをサポートしています。Red Hat Advanced Cluster Management がインストールされている場合は、マネージドハブクラスター (local-cluster) を管理クラスターとして使用できます。

ホステッドクラスター は、API エンドポイントとコントロールプレーンが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。ホステッドクラスターは、multicluster engine Operator のコンソールか、Hosted Control Plane のコマンドラインインターフェイス (hcp) を使用して作成できます。

ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、「multicluster engine Operator へのホステッドクラスターの自動インポートの無効化」を参照してください。

4.2.1. ベアメタルへの Hosted Control Plane のデプロイの準備

ベアメタルに Hosted Control Plane をデプロイする準備をする際には、次の情報を考慮してください。

  • 管理クラスターとワーカーは、Hosted Control Plane の同じプラットフォーム上で実行してください。
  • すべてのベアメタルホストは、Central Infrastructure Management が提供する Discovery Image ISO を使用して手動で起動する必要があります。ホストは手動で起動することも、Cluster-Baremetal-Operator を使用して自動化することもできます。各ホストが起動すると、エージェントプロセスが実行され、ホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。
  • Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、「推奨される etcd プラクティス」および「論理ボリュームマネージャーストレージを使用した永続ストレージ」を参照してください。
4.2.1.1. 管理クラスターを設定するための前提条件
  • OpenShift Container Platform クラスターに multicluster engine for Kubernetes Operator 2.2 以降がインストールされている必要があります。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator としてインストールできます。
  • multicluster engine Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。multicluster engine Operator バージョン 2.2 以降では、local-cluster が自動的にインポートされます。local-cluster の詳細は、Red Hat Advanced Cluster Management ドキュメントの 詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。

    $ oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • 管理クラスター上のベアメタルホストに topology.kubernetes.io/zone ラベルを追加する必要があります。各ホストの topology.kubernetes.io/zone の値が一意であることを確認します。そうしないと、すべての Hosted Control Plane Pod が 1 つのノードにスケジュールされ、単一障害点が発生します。
  • ベアメタルに Hosted Control Plane をプロビジョニングするには、Agent プラットフォームを使用できます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • Hosted Control Plane のコマンドラインインターフェイスをインストールする必要があります。
4.2.1.2. ベアメタルファイアウォール、ポート、およびサービスの要件

管理クラスター、コントロールプレーン、ホステッドクラスター間でポートの通信ができるように、ファイアウォール、ポート、およびサービスの要件を満たす必要があります。

注記

サービスはデフォルトのポートで実行されます。ただし、NodePort 公開ストラテジーを使用する場合、サービスは NodePort サービスによって割り当てられたポートで実行されます。

ファイアウォールルール、セキュリティーグループ、またはその他のアクセス制御を使用して、必要なソースだけにアクセスを制限します。必要な場合を除き、ポートを公開しないでください。実稼働環境の場合は、ロードバランサーを使用して、単一の IP アドレスによるアクセスを簡素化します。

ハブクラスターにプロキシー設定がある場合は、すべてのホステッドクラスター API エンドポイントを Proxy オブジェクトの noProxy フィールドに追加して、ハブクラスターがホステッドクラスターの API エンドポイントにアクセスできようにします。詳細は、「クラスター全体のプロキシーの設定」を参照してください。

Hosted Control Plane はベアメタル上で次のサービスを公開します。

  • APIServer

    • APIServer サービスはデフォルトでポート 6443 で実行され、コントロールプレーンコンポーネント間の通信には ingress アクセスが必要です。
    • MetalLB ロードバランシングを使用する場合は、ロードバランサーの IP アドレスに使用される IP 範囲への ingress アクセスを許可します。
  • OAuthServer

    • ルートと Ingress を使用してサービスを公開する場合、OAuthServer サービスはデフォルトでポート 443 で実行されます。
    • NodePort 公開ストラテジーを使用する場合は、OAuthServer サービスにファイアウォールルールを使用します。
  • Konnectivity

    • ルートと Ingress を使用してサービスを公開する場合、Konnectivity サービスはデフォルトでポート 443 で実行されます。
    • Konnectivity エージェントはリバーストンネルを確立し、コントロールプレーンがホステッドクラスターのネットワークにアクセスできるようにします。エージェントは egress を使用して Konnectivity サーバーに接続します。サーバーは、ポート 443 のルートまたは手動で割り当てられた NodePort を使用して公開されます。
    • クラスター API サーバーのアドレスが内部 IP アドレスの場合は、ワークロードサブネットからポート 6443 の IP アドレスへのアクセスを許可します。
    • アドレスが外部 IP アドレスの場合は、ノードからその外部 IP アドレスにポート 6443 で送信できるように許可します。
  • Ignition

    • ルートと Ingress を使用してサービスを公開する場合、Ignition サービスはデフォルトでポート 443 で実行されます。
    • NodePort 公開ストラテジーを使用する場合は、Ignition サービスにファイアウォールルールを使用します。

ベアメタルで以下のサービスは必要ありません。

  • OVNSbDb
  • OIDC
4.2.1.3. ベアメタルのインフラストラクチャー要件

Agent プラットフォームはインフラストラクチャーを作成しませんが、次のインフラストラクチャー要件があります。

  • Agent: Agent は、Discovery イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングされる準備ができているホストを表します。
  • DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

4.2.2. ベアメタルでの DNS 設定

ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<base_domain> の DNS エントリーが存在する必要があります。

DNS エントリーは、ホステッドコントロールプレーンを実行している管理クラスター内のノードの 1 つを指すレコードのように単純なものにすることができます。エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。

DNS 設定の例

api.example.krnl.es.    IN A 192.168.122.20
api.example.krnl.es.    IN A 192.168.122.21
api.example.krnl.es.    IN A 192.168.122.22
api-int.example.krnl.es.    IN A 192.168.122.20
api-int.example.krnl.es.    IN A 192.168.122.21
api-int.example.krnl.es.    IN A 192.168.122.22
`*`.apps.example.krnl.es. IN A 192.168.122.23
Copy to Clipboard Toggle word wrap

注記

前述の例の場合、*.apps.example.krnl.es. IN A 192.168.122.23 が、ホステッドクラスター内のノード、またはロードバランサー (設定されている場合) です。

IPv6 ネットワーク上の非接続環境用に DNS を設定する場合、設定は次の例のようになります。

IPv6 ネットワークの DNS 設定の例

api.example.krnl.es.    IN A 2620:52:0:1306::5
api.example.krnl.es.    IN A 2620:52:0:1306::6
api.example.krnl.es.    IN A 2620:52:0:1306::7
api-int.example.krnl.es.    IN A 2620:52:0:1306::5
api-int.example.krnl.es.    IN A 2620:52:0:1306::6
api-int.example.krnl.es.    IN A 2620:52:0:1306::7
`*`.apps.example.krnl.es. IN A 2620:52:0:1306::10
Copy to Clipboard Toggle word wrap

デュアルスタックネットワークの非接続環境で DNS を設定する場合は、IPv4 と IPv6 の両方の DNS エントリーを含めるようにしてください。

デュアルスタックネットワークの DNS 設定の例

host-record=api-int.hub-dual.dns.base.domain.name,192.168.126.10
host-record=api.hub-dual.dns.base.domain.name,192.168.126.10
address=/apps.hub-dual.dns.base.domain.name/192.168.126.11
dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,192.168.126.20
dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,192.168.126.21
dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,192.168.126.22
dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,192.168.126.25
dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,192.168.126.26

host-record=api-int.hub-dual.dns.base.domain.name,2620:52:0:1306::2
host-record=api.hub-dual.dns.base.domain.name,2620:52:0:1306::2
address=/apps.hub-dual.dns.base.domain.name/2620:52:0:1306::3
dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,[2620:52:0:1306::5]
dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,[2620:52:0:1306::6]
dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,[2620:52:0:1306::7]
dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,[2620:52:0:1306::8]
dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,[2620:52:0:1306::9]
Copy to Clipboard Toggle word wrap

4.2.2.1. カスタム DNS 名の定義

クラスター管理者は、ノードのブートストラップとコントロールプレーンの通信に使用される内部エンドポイントとは異なる外部 API DNS 名を持つホステッドクラスターを作成できます。別の DNS 名を定義する理由には、次のようなものがあります。

  • 内部ルート CA にバインドされているコントロールプレーン機能を損なうことなく、ユーザー向けの TLS 証明書をパブリック CA が発行したものに置き換えるため。
  • スプリットホライズン DNS および NAT のシナリオをサポートするため。
  • スタンドアロンのコントロールプレーンと同様のエクスペリエンスを確保し、正しい kubeconfig と DNS 設定を使用して、Show Login Command などの機能を使用可能にするため。

HostedCluster オブジェクトの kubeAPIServerDNSName パラメーターにドメイン名を入力することで、初期セットアップ時またはインストール後の操作時に DNS 名を定義できます。

前提条件

  • kubeAPIServerDNSName パラメーターで設定する DNS 名が、有効な TLS 証明書の対象に含まれている。
  • 正しいアドレスに到達し、それを指し示す解決可能な DNS 名 URI がある。

手順

  • HostedCluster オブジェクトの仕様で、kubeAPIServerDNSName パラメーターとドメインのアドレスを追加し、使用する証明書を指定します (次の例を参照)。

    #...
    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names:
              - xxx.example.com
              - yyy.example.com
              servingCertificate:
                name: <my_serving_certificate>
      kubeAPIServerDNSName: <custom_address> 
    1
    Copy to Clipboard Toggle word wrap
    1
    kubeAPIServerDNSName パラメーターの値は、有効でアドレス指定可能なドメインである必要があります。

kubeAPIServerDNSName パラメーターを定義して証明書を指定すると、Control Plane Operator のコントローラーによって custom-admin-kubeconfig という名前の kubeconfig ファイルが作成されます。このファイルは HostedControlPlane namespace に保存されます。証明書はルート CA から生成され、HostedControlPlane namespace によって証明書の有効期限と更新が管理されます。

Control Plane Operator は、HostedControlPlane namespace に CustomKubeconfig という名前の新しい kubeconfig ファイルを報告します。このファイルは、kubeAPIServerDNSName パラメーターで定義された新しいサーバーを使用します。

カスタム kubeconfig ファイルへの参照情報は、HostedCluster オブジェクトの status パラメーター内に CustomKubeconfig という名前で存在しています。CustomKubeConfig パラメーターは任意であり、kubeAPIServerDNSName パラメーターが空でない場合にのみ追加できます。CustomKubeConfig パラメーターを設定すると、そのパラメーターによって、HostedCluster namespace で <hosted_cluster_name>-custom-admin-kubeconfig という名前のシークレットの生成がトリガーされます。このシークレットを使用して HostedCluster API サーバーにアクセスできます。インストール後の操作時に CustomKubeConfig パラメーターを削除すると、関連するすべてのシークレットとステータス参照が削除されます。

注記

カスタム DNS 名の定義はデータプレーンに直接影響しないため、予期されるロールアウトは発生しません。HostedControlPlane namespace は、HyperShift Operator から変更を受け取り、対応するパラメーターを削除します。

HostedCluster オブジェクトの仕様から kubeAPIServerDNSName パラメーターを削除すると、新しく生成されたすべてのシークレットと、CustomKubeconfig 参照がクラスターと status パラメーターから削除されます。

4.2.3. InfraEnv リソースの作成

ベアメタル上にホステッドクラスターを作成するには、InfraEnv リソースが必要です。

4.2.3.1. InfraEnv リソースの作成とノードの追加

Hosted Control Plane では、コントロールプレーンコンポーネントは管理クラスター上の Pod として実行され、データプレーンは専用ノード上で実行されます。Assisted Service を使用すると、ハードウェアをハードウェアインベントリーに追加する検出 ISO を使用して、ハードウェアをブートできます。後でホステッドクラスターを作成するときに、インベントリーのハードウェアを使用してデータプレーンノードをプロビジョニングします。検出 ISO を取得するために使用されるオブジェクトは、InfraEnv リソースです。検出 ISO からベアメタルノードをブートするようにクラスターを設定する BareMetalHost オブジェクトを作成する必要があります。

手順

  1. 次のコマンドを入力して、ハードウェアインベントリーを保存する namespace を作成します。

    $ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig create \
      namespace <namespace_example>
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <directory_example>
    管理クラスターの kubeconfig ファイルが保存されるディレクトリーの名前です。
    <namespace_example>

    作成する namespace の名前 (例: hardware-inventory) です。

    出力例

    namespace/hardware-inventory created
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力して、管理クラスターのプルシークレットをコピーします。

    $ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig \
      -n openshift-config get secret pull-secret -o yaml \
      | grep -vE "uid|resourceVersion|creationTimestamp|namespace" \
      | sed "s/openshift-config/<namespace_example>/g" \
      | oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig \
      -n <namespace> apply -f -
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <directory_example>
    管理クラスターの kubeconfig ファイルが保存されるディレクトリーの名前です。
    <namespace_example>

    作成する namespace の名前 (例: hardware-inventory) です。

    出力例

    secret/pull-secret created
    Copy to Clipboard Toggle word wrap

  3. 次のコンテンツを YAML ファイルに追加して、InfraEnv リソースを作成します。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: hosted
      namespace: <namespace_example>
    spec:
      additionalNTPSources:
      - <ip_address>
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: <ssh_public_key>
    # ...
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを入力して、YAML ファイルに変更を適用します。

    $ oc apply -f <infraenv_config>.yaml
    Copy to Clipboard Toggle word wrap

    <infraenv_config> は、ファイルの名前に置き換えます。

  5. 次のコマンドを入力して、InfraEnv リソースが作成されたことを確認します。

    $ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig \
      -n <namespace_example> get infraenv hosted
    Copy to Clipboard Toggle word wrap
  6. 次の 2 つの方法のいずれかに従ってベアメタルホストを追加します。

    • Metal3 Operator を使用しない場合は、InfraEnv リソースから検出 ISO を取得し、次のステップを実行して手動でホストをブートします。

      1. 次のコマンドを入力してライブ ISO をダウンロードします。

        $ oc get infraenv -A
        Copy to Clipboard Toggle word wrap
        $ oc get infraenv <namespace_example> -o jsonpath='{.status.isoDownloadURL}' -n <namespace_example> <iso_url>
        Copy to Clipboard Toggle word wrap
      2. ISO をブートします。ノードは Assisted Service と通信し、InfraEnv リソースと同じ namespace にエージェントとして登録されます。
      3. 各エージェントに対して、インストールディスク ID とホスト名を設定し、承認してエージェントが使用可能であることを示します。次のコマンドを入力します。

        $ oc -n <hosted_control_plane_namespace> get agents
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                   CLUSTER   APPROVED   ROLE          STAGE
        86f7ac75-4fc4-4b36-8130-40fa12602218                        auto-assign
        e57a637f-745b-496e-971d-1abbf03341ba                        auto-assign
        Copy to Clipboard Toggle word wrap

        $ oc -n <hosted_control_plane_namespace> \
          patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 \
          -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' \
          --type merge
        Copy to Clipboard Toggle word wrap
        $ oc -n <hosted_control_plane_namespace> \
          patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p \
          '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' \
          --type merge
        Copy to Clipboard Toggle word wrap
        $ oc -n <hosted_control_plane_namespace> get agents
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                   CLUSTER   APPROVED   ROLE          STAGE
        86f7ac75-4fc4-4b36-8130-40fa12602218             true       auto-assign
        e57a637f-745b-496e-971d-1abbf03341ba             true       auto-assign
        Copy to Clipboard Toggle word wrap

    • Metal3 Operator を使用する場合は、次のオブジェクトを作成することで、ベアメタルホストの登録を自動化できます。

      1. YAML ファイルを作成し、そこに次のコンテンツを追加します。

        apiVersion: v1
        kind: Secret
        metadata:
          name: hosted-worker0-bmc-secret
          namespace: <namespace_example>
        data:
          password: <password>
          username: <username>
        type: Opaque
        ---
        apiVersion: v1
        kind: Secret
        metadata:
          name: hosted-worker1-bmc-secret
          namespace: <namespace_example>
        data:
          password: <password>
          username: <username>
        type: Opaque
        ---
        apiVersion: v1
        kind: Secret
        metadata:
          name: hosted-worker2-bmc-secret
          namespace: <namespace_example>
        data:
          password: <password>
          username: <username>
        type: Opaque
        ---
        apiVersion: metal3.io/v1alpha1
        kind: BareMetalHost
        metadata:
          name: hosted-worker0
          namespace: <namespace_example>
          labels:
            infraenvs.agent-install.openshift.io: hosted
          annotations:
            inspect.metal3.io: disabled
            bmac.agent-install.openshift.io/hostname: hosted-worker0
        spec:
          automatedCleaningMode: disabled
          bmc:
            disableCertificateVerification: True
            address: <bmc_address>
            credentialsName: hosted-worker0-bmc-secret
          bootMACAddress: aa:aa:aa:aa:02:01
          online: true
        ---
        apiVersion: metal3.io/v1alpha1
        kind: BareMetalHost
        metadata:
          name: hosted-worker1
          namespace: <namespace_example>
          labels:
            infraenvs.agent-install.openshift.io: hosted
          annotations:
            inspect.metal3.io: disabled
            bmac.agent-install.openshift.io/hostname: hosted-worker1
        spec:
          automatedCleaningMode: disabled
          bmc:
            disableCertificateVerification: True
            address: <bmc_address>
            credentialsName: hosted-worker1-bmc-secret
          bootMACAddress: aa:aa:aa:aa:02:02
          online: true
        ---
        apiVersion: metal3.io/v1alpha1
        kind: BareMetalHost
        metadata:
          name: hosted-worker2
          namespace: <namespace_example>
          labels:
            infraenvs.agent-install.openshift.io: hosted
          annotations:
            inspect.metal3.io: disabled
            bmac.agent-install.openshift.io/hostname: hosted-worker2
        spec:
          automatedCleaningMode: disabled
          bmc:
            disableCertificateVerification: True
            address: <bmc_address>
            credentialsName: hosted-worker2-bmc-secret
          bootMACAddress: aa:aa:aa:aa:02:03
          online: true
        ---
        apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: capi-provider-role
          namespace: <namespace_example>
        rules:
        - apiGroups:
          - agent-install.openshift.io
          resources:
          - agents
          verbs:
          - '*'
        Copy to Clipboard Toggle word wrap

        ここでは、以下のようになります。

        <namespace_example>
        namespace です。
        <password>
        シークレットのパスワードです。
        <username>
        シークレットのユーザー名です。
        <bmc_address>

        BareMetalHost オブジェクトの BMC アドレスです。

        注記

        この YAML ファイルを適用すると、次のオブジェクトが作成されます。

        • ベースボード管理コントローラー (BMC) の認証情報が含まれるシークレット
        • BareMetalHost オブジェクト
        • HyperShift Operator によるエージェントの管理が可能になるロール

        BareMetalHost オブジェクトで infraenvs.agent-install.openshift.io: hosted カスタムラベルを使用して InfraEnv リソースが参照されることに注意してください。これにより、生成された ISO を使用してノードがブートされます。

      2. 次のコマンドを入力して、YAML ファイルに変更を適用します。

        $ oc apply -f <bare_metal_host_config>.yaml
        Copy to Clipboard Toggle word wrap

        <bare_metal_host_config> は、ファイルの名前に置き換えます。

  7. 次のコマンドを入力し、BareMetalHost オブジェクトの状態が Provisioning になるまで数分間待ちます。

    $ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig -n <namespace_example> get bmh
    Copy to Clipboard Toggle word wrap

    出力例

    NAME             STATE          CONSUMER   ONLINE   ERROR   AGE
    hosted-worker0   provisioning              true             106s
    hosted-worker1   provisioning              true             106s
    hosted-worker2   provisioning              true             106s
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを入力して、ノードが起動し、エージェントとして表示されていることを確認します。このプロセスには数分かかる場合があり、コマンドを複数回入力する必要があることもあります。

    $ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig -n <namespace_example> get agent
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
    aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0201             true       auto-assign
    aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0202             true       auto-assign
    aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0203             true       auto-assign
    Copy to Clipboard Toggle word wrap

4.2.3.2. コンソールを使用して InfraEnv リソースを作成する

コンソールを使用して InfraEnv リソースを作成するには、次のステップを実行します。

手順

  1. OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。コンソールを開く手順は、「Web コンソールへのアクセス」を参照してください。
  2. コンソールヘッダーで、All Clusters が選択されていることを確認します。
  3. Infrastructure → Host inventory → Create infrastructure environment をクリックします。
  4. InfraEnv リソースを作成した後、InfraEnv ビュー内から Add hosts をクリックし、利用可能なオプションから選択してベアメタルホストを追加します。

4.2.4. ベアメタルでのホステッドクラスターの作成

コマンドラインインターフェイス (CLI)、コンソール、またはミラーレジストリーを使用して、ベアメタル上にホステッドクラスターを作成できます。

4.2.4.1. コンソールを使用したホステッドクラスターの作成

ベアメタルインフラストラクチャーには、ホステッドクラスターを作成またはインポートできます。multicluster engine Operator へのアドオンとして Assisted Installer を有効にし、Agent プラットフォームを使用してホステッドクラスターを作成すると、HyperShift Operator によって Agent Cluster API プロバイダーが Hosted Control Plane namespace にインストールされます。Agent Cluster API プロバイダーは、コントロールプレーンをホストする管理クラスターと、コンピュートノードのみで構成されるホステッドクラスターを接続します。

前提条件

  • 各ホステッドクラスターの名前がクラスター全体で一意である。ホステッドクラスター名は、既存のマネージドクラスターと同じにすることはできません。この要件を満たさないと、multicluster engine Operator がホステッドクラスターを管理できません。
  • ホステッドクラスター名として clusters という単語を使用しない。
  • multicluster engine Operator のマネージドクラスターの namespace にホステッドクラスターを作成することはできない。
  • 最適なセキュリティーと管理プラクティスを実現するために、他のホステッドクラスターとは別にホステッドクラスターを作成する。
  • クラスターにデフォルトのストレージクラスが設定されていることを確認する。そうしない場合、保留中の永続ボリューム要求 (PVC) が表示されることがあります。
  • デフォルトでは、hcp create cluster agent コマンドを使用すると、ノードポートが設定されたホステッドクラスターが作成されます。ベアメタル上のホステッドクラスターの推奨公開ストラテジーは、ロードバランサーを通じてサービスを公開することです。Web コンソールまたは Red Hat Advanced Cluster Management を使用してホステッドクラスターを作成する場合、Kubernetes API サーバー以外のサービスの公開ストラテジーを設定するには、HostedCluster カスタムリソースで servicePublishingStrategy 情報を手動で指定する必要があります。
  • インフラストラクチャー、ファイアウォール、ポート、およびサービスに関連する要件を含め、「ベアメタル上の Hosted Control Plane の要件」に記載されている要件を満たしていることを確認する。要件では、たとえば次のコマンド例に示すように、管理クラスター内のベアメタルホストに適切なゾーンラベルを追加する方法が説明されています。

    $ oc label node [compute-node-1] topology.kubernetes.io/zone=zone1
    Copy to Clipboard Toggle word wrap
    $ oc label node [compute-node-2] topology.kubernetes.io/zone=zone2
    Copy to Clipboard Toggle word wrap
    $ oc label node [compute-node-3] topology.kubernetes.io/zone=zone3
    Copy to Clipboard Toggle word wrap
  • ハードウェアインベントリーにベアメタルノードを追加したことを確認する。

手順

  1. 次のコマンドを入力して namespace を作成します。

    $ oc create ns <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

    <hosted_cluster_namespace> は、ホステッドクラスター namespace の識別子に置き換えます。namespace は HyperShift Operator によって作成されます。ベアメタルインフラストラクチャーにホステッドクラスターを作成するプロセスでは、Cluster API プロバイダー用のロールが生成されます。このロールを生成するには、namespace が事前に存在している必要があります。

  2. 次のコマンドを入力して、ホステッドクラスターの設定ファイルを作成します。

    $ hcp create cluster agent \
      --name=<hosted_cluster_name> \
    1
    
      --pull-secret=<path_to_pull_secret> \
    2
    
      --agent-namespace=<hosted_control_plane_namespace> \
    3
    
      --base-domain=<base_domain> \
    4
    
      --api-server-address=api.<hosted_cluster_name>.<base_domain> \
    5
    
      --etcd-storage-class=<etcd_storage_class> \
    6
    
      --ssh-key=<path_to_ssh_key> \
    7
    
      --namespace=<hosted_cluster_namespace> \
    8
    
      --control-plane-availability-policy=HighlyAvailable \
    9
    
      --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image>-multi \
    10
    
      --node-pool-replicas=<node_pool_replica_count> \
    11
    
      --render \
      --render-sensitive \
      --ssh-key <home_directory>/<path_to_ssh_key>/<ssh_key> > hosted-cluster-config.yaml 
    12
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: example) を指定します。
    2
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    3
    Hosted Control Plane の namespace を指定します (例: clusters-example)。oc get agent -n <hosted_control_plane_namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメイン (例: krnl.es) を指定します。
    5
    --api-server-address フラグは、ホステッドクラスター内の Kubernetes API 通信に使用される IP アドレスを定義します。--api-server-address フラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。
    6
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。
    7
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    8
    ホステッドクラスターの namespace を指定します。
    9
    Hosted Control Plane コンポーネントの可用性ポリシーを指定します。サポートされているオプションは SingleReplicaHighlyAvailable です。デフォルト値は HighlyAvailable です。
    10
    使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.19.0-multi)。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
    11
    ノードプールのレプリカ数を指定します (例: 3)。レプリカ数は 0 以上で指定する必要があります。指定したとおりの数のノードが作成されます。この値を指定しない場合、ノードプールは作成されません。
    12
    --ssh-key フラグの後に、SSH 鍵へのパス (例: user/.ssh/id_rsa) を指定します。
  3. サービス公開ストラテジーを設定します。デフォルトでは、ホステッドクラスターは NodePort サービス公開ストラテジーを使用します。これは、ノードポートが追加のインフラストラクチャーなしで常に利用可能であるためです。ただし、ロードバランサーを使用するようにサービス公開ストラテジーを設定することもできます。

    • デフォルトの NodePort ストラテジーを使用している場合は、管理クラスターノードではなく、ホステッドクラスターコンピュートノードを指すように DNS を設定します。詳細は、「ベアメタル上の DNS 設定」を参照してください。
    • 実稼働環境では、証明書の処理と自動 DNS 解決を提供する LoadBalancer ストラテジーを使用します。次の例は、ホステッドクラスターの設定ファイルで LoadBalancer サービス公開ストラテジーを変更する方法を示しています。

      # ...
      spec:
        services:
        - service: APIServer
          servicePublishingStrategy:
            type: LoadBalancer 
      1
      
        - service: Ignition
          servicePublishingStrategy:
            type: Route
        - service: Konnectivity
          servicePublishingStrategy:
            type: Route
        - service: OAuthServer
          servicePublishingStrategy:
            type: Route
        - service: OIDC
          servicePublishingStrategy:
            type: Route
        sshKey:
          name: <ssh_key>
      # ...
      Copy to Clipboard Toggle word wrap
      1
      API サーバータイプとして LoadBalancer を指定します。それ以外のすべてのサービスでは、タイプとして Route を指定します。
  4. 次のコマンドを入力して、ホステッドクラスター設定ファイルに変更を適用します。

    $ oc apply -f hosted_cluster_config.yaml
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを入力して、ホステッドクラスター、ノードプール、および Pod の作成を確認します。

    $ oc get hostedcluster \
      <hosted_cluster_namespace> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get nodepool \
      <hosted_cluster_namespace> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get pods -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  6. ホステッドクラスターの準備ができていることを確認します。Available: True というステータスはクラスターの準備完了状態であることを示しています。ノードプールのステータスには AllMachinesReady: True と表示されます。これらのステータスは、すべてのクラスター Operator の健全性を示しています。
  7. ホステッドクラスターに MetalLB をインストールします。

    1. 次のコマンドを入力して、ホステッドクラスターから kubeconfig ファイルを展開し、ホステッドクラスターアクセス用の環境変数を設定します。

      $ oc get secret \
        <hosted_cluster_namespace>-admin-kubeconfig \
        -n <hosted_cluster_namespace> \
        -o jsonpath='{.data.kubeconfig}' \
        | base64 -d > \
        kubeconfig-<hosted_cluster_namespace>.yaml
      Copy to Clipboard Toggle word wrap
      $ export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"
      Copy to Clipboard Toggle word wrap
    2. install-metallb-operator.yaml ファイルを作成して MetalLB Operator をインストールします。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: metallb-system
      ---
      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: metallb-operator
        namespace: metallb-system
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: metallb-operator
        namespace: metallb-system
      spec:
        channel: "stable"
        name: metallb-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        installPlanApproval: Automatic
      # ...
      Copy to Clipboard Toggle word wrap
    3. 以下のコマンドを入力してファイルを適用します。

      $ oc apply -f install-metallb-operator.yaml
      Copy to Clipboard Toggle word wrap
    4. deploy-metallb-ipaddresspool.yaml ファイルを作成して、MetalLB IP アドレスプールを設定します。

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        name: metallb
        namespace: metallb-system
      spec:
        autoAssign: true
        addresses:
        - 10.11.176.71-10.11.176.75
      ---
      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: l2advertisement
        namespace: metallb-system
      spec:
        ipAddressPools:
        - metallb
      # ...
      Copy to Clipboard Toggle word wrap
    5. 次のコマンドを入力して設定を適用します。

      $ oc apply -f deploy-metallb-ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
    6. 次のコマンドを入力して、Operator ステータス、IP アドレスプール、および L2Advertisement リソースを確認し、MetalLB のインストールを検証します。

      $ oc get pods -n metallb-system
      Copy to Clipboard Toggle word wrap
      $ oc get ipaddresspool -n metallb-system
      Copy to Clipboard Toggle word wrap
      $ oc get l2advertisement -n metallb-system
      Copy to Clipboard Toggle word wrap
  8. Ingress 用のロードバランサーを設定します。

    1. ingress-loadbalancer.yaml ファイルを作成します。

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          metallb.universe.tf/address-pool: metallb
        name: metallb-ingress
        namespace: openshift-ingress
      spec:
        ports:
          - name: http
            protocol: TCP
            port: 80
            targetPort: 80
          - name: https
            protocol: TCP
            port: 443
            targetPort: 443
        selector:
          ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        type: LoadBalancer
      # ...
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを入力して設定を適用します。

      $ oc apply -f ingress-loadbalancer.yaml
      Copy to Clipboard Toggle word wrap
    3. 次のコマンドを入力して、ロードバランサーサービスが期待どおりに動作することを確認します。

      $ oc get svc metallb-ingress -n openshift-ingress
      Copy to Clipboard Toggle word wrap

      出力例

      NAME              TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
      metallb-ingress   LoadBalancer   172.31.127.129   10.11.176.71   80:30961/TCP,443:32090/TCP   16h
      Copy to Clipboard Toggle word wrap

  9. ロードバランサーと連携するように DNS を設定します。

    1. *.apps.<hosted_cluster_namespace>.<base_domain> ワイルドカード DNS レコードがロードバランサーの IP アドレスをポイントするように、apps ドメインの DNS を設定します。
    2. 次のコマンドを入力して DNS 解決を確認します。

      $ nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>
      Copy to Clipboard Toggle word wrap

      出力例

      Server:         10.11.176.1
      Address:        10.11.176.1#53
      
      Name:   console-openshift-console.apps.my-hosted-cluster.sample-base-domain.com
      Address: 10.11.176.71
      Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを入力して、クラスター Operator を確認します。

    $ oc get clusteroperators
    Copy to Clipboard Toggle word wrap

    すべての Operator に AVAILABLE: TruePROGRESSING: FalseDEGRADED: False が表示されていることを確認します。

  2. 次のコマンドを入力してノードを確認します。

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    各ノードのステータスが READY であることを確認します。

  3. Web ブラウザーに次の URL を入力して、コンソールへのアクセスをテストします。

    https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>
    Copy to Clipboard Toggle word wrap
4.2.4.2. コンソールを使用してベアメタル上にホステッドクラスターを作成する

コンソールを使用してホステッドクラスターを作成するには、次の手順を実行します。

手順

  1. OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。コンソールを開く手順は、「Web コンソールへのアクセス」を参照してください。
  2. コンソールヘッダーで、All Clusters が選択されていることを確認します。
  3. Infrastructure → Clusters をクリックします。
  4. Create cluster → Host inventory → Hosted control plane をクリックします。

    Create cluster ページが表示されます。

  5. Create cluster ページでプロンプトに従い、クラスター、ノードプール、ネットワーク、および自動化に関する詳細を入力します。

    注記

    クラスターの詳細を入力する際には、次のヒントが役立つ場合があります。

    • 事前定義された値を使用してコンソールのフィールドに自動的に値を入力する場合は、ホストインベントリーの認証情報を作成できます。詳細は、「オンプレミス環境の認証情報の作成」を参照してください。
    • Cluster details ページのプルシークレットは、OpenShift Container Platform リソースへのアクセスに使用する OpenShift Container Platform プルシークレットです。ホストインベントリー認証情報を選択した場合は、プルシークレットが自動的に入力されます。
    • Node pools ページでは、namespace にノードプールのホストが含まれます。コンソールを使用してホストインベントリーを作成した場合、コンソールは専用の namespace を作成します。
    • Networking ページで、API サーバー公開ストラテジーを選択します。ホステッドクラスターの API サーバーは、既存のロードバランサーを使用するか、NodePort タイプのサービスとして公開できます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<base_domain> 設定の DNS エントリーが存在する必要があります。このエントリーとして、管理クラスター内のノードの 1 つを指すレコード、または受信トラフィックを Ingress Pod にリダイレクトするロードバランサーを指すレコードを指定できます。
  6. エントリーを確認し、Create をクリックします。

    Hosted cluster ビューが表示されます。

  7. Hosted cluster ビューでホステッドクラスターのデプロイメントを監視します。
  8. ホステッドクラスターに関する情報が表示されない場合は、All Clusters が選択されていることを確認し、クラスター名をクリックします。
  9. コントロールプレーンコンポーネントの準備が整うまで待ちます。このプロセスには数分かかる場合があります。
  10. ノードプールのステータスを表示するには、NodePool セクションまでスクロールします。ノードをインストールするプロセスには約 10 分かかります。Nodes をクリックして、ノードがホステッドクラスターに参加したかどうかを確認することもできます。

次のステップ

4.2.4.3. ミラーレジストリーを使用してベアメタル上にホステッドクラスターを作成する

ミラーレジストリーを使用して、hcp create cluster コマンドで --image-content-sources フラグを指定して、ベアメタル上にホステッドクラスターを作成できます。

手順

  1. YAML ファイルを作成して、イメージコンテンツソースポリシー (ICSP) を定義します。以下の例を参照してください。

    - mirrors:
      - brew.registry.redhat.io
      source: registry.redhat.io
    - mirrors:
      - brew.registry.redhat.io
      source: registry.stage.redhat.io
    - mirrors:
      - brew.registry.redhat.io
      source: registry-proxy.engineering.redhat.com
    Copy to Clipboard Toggle word wrap
  2. ファイルを icsp.yaml として保存します。このファイルにはミラーレジストリーが含まれます。
  3. ミラーレジストリーを使用してホステッドクラスターを作成するには、次のコマンドを実行します。

    $ hcp create cluster agent \
        --name=<hosted_cluster_name> \
    1
    
        --pull-secret=<path_to_pull_secret> \
    2
    
        --agent-namespace=<hosted_control_plane_namespace> \
    3
    
        --base-domain=<basedomain> \
    4
    
        --api-server-address=api.<hosted_cluster_name>.<basedomain> \
    5
    
        --image-content-sources icsp.yaml  \
    6
    
        --ssh-key  <path_to_ssh_key> \
    7
    
        --namespace <hosted_cluster_namespace> \
    8
    
        --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> 
    9
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    3
    Hosted Control Plane namespace を指定します (例: clusters-example)。oc get agent -n <hosted-control-plane-namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメインを指定します (例: krnl.es)。
    5
    --api-server-address フラグは、ホステッドクラスター内の Kubernetes API 通信に使用される IP アドレスを定義します。--api-server-address フラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。
    6
    ICSP およびミラーレジストリーを定義する icsp.yaml ファイルを指定します。
    7
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    8
    ホステッドクラスターの namespace を指定します。
    9
    使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.19.0-multi)。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、「OpenShift Container Platform リリースイメージダイジェストの抽出」を参照してください。

次のステップ

4.2.5. ホステッドクラスター作成の確認

デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。

手順

  1. 次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。

    $ oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig \
      --to=- > kubeconfig-<hosted-cluster-name>
    Copy to Clipboard Toggle word wrap
  2. kubeconfig を使用して、ホステッドクラスターのクラスター Operator を表示します。以下のコマンドを入力します。

    $ oc get co --kubeconfig=kubeconfig-<hosted-cluster-name>
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    console                                    4.10.26   True        False         False      2m38s
    dns                                        4.10.26   True        False         False      2m52s
    image-registry                             4.10.26   True        False         False      2m8s
    ingress                                    4.10.26   True        False         False      22m
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを入力して、ホステッドクラスター上で実行中の Pod を表示することもできます。

    $ oc get pods -A --kubeconfig=kubeconfig-<hosted-cluster-name>
    Copy to Clipboard Toggle word wrap

    出力例

    NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
    kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
    openshift-cluster-node-tuning-operator             tuned-dhw5p                                               1/1     Running            0               109s
    openshift-cluster-storage-operator                 cluster-storage-operator-5f784969f5-vwzgz                 1/1     Running            1 (113s ago)    20m
    openshift-cluster-storage-operator                 csi-snapshot-controller-6b7687b7d9-7nrfw                  1/1     Running            0               3m8s
    openshift-console                                  console-5cbf6c7969-6gk6z                                  1/1     Running            0               119s
    openshift-console                                  downloads-7bcd756565-6wj5j                                1/1     Running            0               4m3s
    openshift-dns-operator                             dns-operator-77d755cd8c-xjfbn                             2/2     Running            0               21m
    openshift-dns                                      dns-default-kfqnh                                         2/2     Running            0               113s
    Copy to Clipboard Toggle word wrap

4.2.6. ホステッドクラスターでカスタム API サーバー証明書を設定する

API サーバーのカスタム証明書を設定するには、HostedCluster 設定の spec.configuration.apiServer セクションで証明書の詳細を指定します。

カスタム証明書は、Day 1 操作または Day 2 操作の中で設定できます。ただし、サービス公開ストラテジーはホステッドクラスターの作成中に設定した後は変更できないため、設定する予定の Kubernetes API サーバーのホスト名を知っておく必要があります。

前提条件

  • 管理クラスターにカスタム証明書が含まれる Kubernetes シークレットを作成しました。シークレットには次の鍵が含まれています。

    • tls.crt: 証明書
    • tls.key: 秘密鍵
  • HostedCluster 設定にロードバランサーを使用するサービス公開ストラテジーが含まれている場合は、証明書のサブジェクト代替名 (SAN) が内部 API エンドポイント (api-int) と競合しないことを確認してください。内部 API エンドポイントは、プラットフォームによって自動的に作成および管理されます。カスタム証明書と内部 API エンドポイントの両方で同じホスト名を使用すると、ルーティングの競合が発生する可能性があります。このルールの唯一の例外は、Private または PublicAndPrivate 設定で AWS をプロバイダーとして使用する場合です。このような場合、SAN の競合はプラットフォームによって管理されます。
  • 証明書は外部 API エンドポイントに対して有効である必要があります。
  • 証明書の有効期間は、クラスターの予想されるライフサイクルと一致します。

手順

  1. 次のコマンドを入力して、カスタム証明書を使用してシークレットを作成します。

    $ oc create secret tls sample-hosted-kas-custom-cert \
      --cert=path/to/cert.crt \
      --key=path/to/key.key \
      -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  2. 次の例に示すように、カスタム証明書の詳細を使用して HostedCluster 設定を更新します。

    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names: 
    1
    
              - api-custom-cert-sample-hosted.sample-hosted.example.com
              servingCertificate: 
    2
    
                name: sample-hosted-kas-custom-cert
    Copy to Clipboard Toggle word wrap
    1
    証明書が有効な DNS の名前のリスト。
    2
    カスタム証明書が含まれるシークレットの名前。
  3. 次のコマンドを入力して、HostedCluster 設定に変更を適用します。

    $ oc apply -f <hosted_cluster_config>.yaml
    Copy to Clipboard Toggle word wrap

検証

  • API サーバー Pod をチェックして、新しい証明書がマウントされていることを確認します。
  • カスタムドメイン名を使用して API サーバーへの接続をテストします。
  • ブラウザーで、または openssl などのツールを使用して、証明書の詳細を確認します。

4.3. OpenShift Virtualization への Hosted Control Plane のデプロイ

Hosted Control Plane と OpenShift Virtualization を使用すると、KubeVirt 仮想マシンによってホストされるワーカーノードを含む OpenShift Container Platform クラスターを作成できます。OpenShift Virtualization 上の Hosted Control Plane には、次のようないくつかの利点があります。

  • Hosted Control Plane とホステッドクラスターを同じ基盤となるベアメタルインフラストラクチャーにまとめることで、リソースの使用率が向上する
  • Hosted Control Plane とホステッドクラスターを分離して強力な分離を実現する
  • ベアメタルノードのブートストラッププロセスを排除することで、クラスターのプロビジョニング時間を短縮する
  • 同じベース OpenShift Container Platform クラスターで多くのリリースを管理する

Hosted Control Plane 機能はデフォルトで有効になっています。

Hosted Control Plane のコマンドラインインターフェイス (hcp) を使用して、OpenShift Container Platform のホステッドクラスターを作成できます。ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、「multicluster engine Operator へのホステッドクラスターの自動インポートの無効化」を参照してください。

4.3.1. OpenShift Virtualization に Hosted Control Plane をデプロイするための要件

OpenShift Virtualization に Hosted Control Plane をデプロイする準備をする際には、次の情報を考慮してください。

  • 管理クラスターはベアメタル上で実行してください。
  • 各ホステッドクラスターの名前がクラスター全体で一意である。
  • ホステッドクラスター名として clusters を使用しない。
  • ホステッドクラスターは、multicluster engine Operator のマネージドクラスターの namespace には作成できない。
  • Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、「推奨される etcd プラクティス」および「論理ボリュームマネージャーストレージを使用した永続ストレージ」を参照してください。
4.3.1.1. 前提条件

OpenShift Virtualization 上に OpenShift Container Platform クラスターを作成するには、以下の前提条件を満たす必要があります。

  • KUBECONFIG 環境変数で指定された OpenShift Container Platform クラスター、バージョン 4.14 以降への管理者アクセスを持っている。
  • OpenShift Container Platform 管理クラスターで、ワイルドカード DNS ルートが有効になっている。次のコマンドを参照してください。

    $ oc patch ingresscontroller -n openshift-ingress-operator default \
      --type=json \
      -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
    Copy to Clipboard Toggle word wrap
  • OpenShift Container Platform 管理クラスターに、OpenShift Virtualization バージョン 4.14 以降がインストールされている。詳細は、「Web コンソールを使用した OpenShift Virtualization のインストール」を参照してください。
  • OpenShift Container Platform 管理クラスターはオンプレミスのベアメタルである。
  • OpenShift Container Platform 管理クラスターが、デフォルトの Pod ネットワーク Container Network Interface (CNI) として OVNKubernetes を使用するように設定されている。CNI が OVN-Kubernetes の場合にのみ、ノードのライブマイグレーションがサポートされます。
  • OpenShift Container Platform 管理クラスターにはデフォルトのストレージクラスがある。詳細は、「インストール後のストレージ設定」を参照してください。次の例は、デフォルトのストレージクラスを設定する方法を示しています。

    $ oc patch storageclass ocs-storagecluster-ceph-rbd \
      -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
    Copy to Clipboard Toggle word wrap
  • quay.io/openshift-release-dev リポジトリーの有効なプルシークレットファイルがある。詳細は、「user-provisioned infrastructure を使用して任意の x86_64 プラットフォームに OpenShift をインストールする」を参照してください。
  • Hosted Control Plane コマンドラインインターフェイスがインストール済みである。
  • ロードバランサーを設定した。詳細は、「MetalLB の設定」を参照してください。
  • ネットワークパフォーマンスを最適化するために、KubeVirt 仮想マシンをホストする OpenShift Container Platform クラスターで 9000 以上のネットワーク最大伝送単位 (MTU) を使用している。低い MTU 設定を使用すると、ネットワーク遅延とホストされる Pod のスループットに影響があります。MTU が 9000 以上の場合にのみ、ノードプールでマルチキューを有効にします。
  • multicluster engine Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターがある。local-cluster は自動的にインポートされます。local-cluster の詳細は、multicluster engine Operator ドキュメントの「高度な設定」を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。

    $ oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • OpenShift Virtualization 仮想マシンをホストする OpenShift Container Platform クラスターで、ライブマイグレーションを有効化できるように ReadWriteMany (RWX) ストレージクラスを使用している。
4.3.1.2. ファイアウォールのポートの要件

管理クラスター、コントロールプレーン、ホステッドクラスター間でポートが通信できるように、ファイアウォールとポートの要件を満たしていることを確認します。

  • kube-apiserver サービスはデフォルトでポート 6443 で実行され、コントロールプレーンコンポーネント間の通信には ingress アクセスが必要です。

    • NodePort 公開ストラテジーを使用する場合は、kube-apiserver サービスに割り当てられたノードポートが公開されていることを確認してください。
    • MetalLB ロードバランシングを使用する場合は、ロードバランサーの IP アドレスに使用される IP 範囲への ingress アクセスを許可します。
  • NodePort 公開ストラテジーを使用する場合は、ignition-server および Oauth-server 設定にファイアウォールルールを使用します。
  • konnectivity エージェントは、ホステッドクラスター上で双方向通信を可能にするリバーストンネルを確立し、ポート 6443 でクラスター API サーバーアドレスへの egress アクセスを必要とします。この egress アクセスを使用すると、エージェントは kube-apiserver サービスにアクセスできます。

    • クラスター API サーバーのアドレスが内部 IP アドレスの場合は、ワークロードサブネットからポート 6443 の IP アドレスへのアクセスを許可します。
    • アドレスが外部 IP アドレスの場合は、ノードからその外部 IP アドレスにポート 6443 で送信できるように許可します。
  • デフォルトのポート 6443 を変更する場合は、その変更を反映するようにルールを調整します。
  • クラスター内で実行されるワークロードに必要なポートがすべて開いていることを確認してください。
  • ファイアウォールルール、セキュリティーグループ、またはその他のアクセス制御を使用して、必要なソースだけにアクセスを制限します。必要な場合を除き、ポートを公開しないでください。
  • 実稼働環境の場合は、ロードバランサーを使用して、単一の IP アドレスによるアクセスを簡素化します。

4.3.2. コンピュートノードのライブマイグレーション

ホステッドクラスターの仮想マシン (仮想マシン) の管理クラスターが更新中またはメンテナンス中に、ホステッドクラスターのワークロードの中断を防止するためにホステッドクラスター仮想マシンを自動的にライブマイグレーションできます。その結果、KubeVirt プラットフォームのホステッドクラスターの可用性と操作に影響を与えることなく、管理クラスターを更新できます。

重要

仮想マシンがルートボリュームと kubevirt-csi CSI プロバイダーにマッピングされているストレージクラスの両方に ReadWriteMany (RWX) ストレージを使用していれば、KubeVirt 仮想マシンのライブマイグレーションはデフォルトで有効になります。

NodePool オブジェクトの status セクションで KubeVirtNodesLiveMigratable 条件を確認することで、ノードプール内の仮想マシンがライブマイグレーションに対応していることを確認できます。

以下は、RWX ストレージが使用されていないために仮想マシンをライブマイグレーションできない例を示しています。

仮想マシンのライブマイグレーションができない設定例

    - lastTransitionTime: "2024-10-08T15:38:19Z"
      message: |
        3 of 3 machines are not live migratable
        Machine user-np-ngst4-gw2hz: DisksNotLiveMigratable: user-np-ngst4-gw2hz is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-gw2hz-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode)
        Machine user-np-ngst4-npq7x: DisksNotLiveMigratable: user-np-ngst4-npq7x is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-npq7x-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode)
        Machine user-np-ngst4-q5nkb: DisksNotLiveMigratable: user-np-ngst4-q5nkb is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-q5nkb-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode)
      observedGeneration: 1
      reason: DisksNotLiveMigratable
      status: "False"
      type: KubeVirtNodesLiveMigratable
Copy to Clipboard Toggle word wrap

以下は、仮想マシンがライブマイグレーション要件を満たしている例を示しています。

仮想マシンのライブマイグレーションが可能な設定例

    - lastTransitionTime: "2024-10-08T15:38:19Z"
      message: "All is well"
      observedGeneration: 1
      reason: AsExpected
      status: "True"
      type: KubeVirtNodesLiveMigratable
Copy to Clipboard Toggle word wrap

通常の状況ではライブマイグレーションにより仮想マシンの中断を防止できますが、インフラストラクチャーノードの障害などのイベントが発生すると、障害が発生したノードでホストされているすべての仮想マシンが強制的に再起動される可能性があります。ライブマイグレーションを成功させるには、仮想マシンがホストされているソースノードが正しく動作している必要があります。

ノードプール内の仮想マシンのライブマイグレーションができない場合、管理クラスターのメンテナンス中にホステッドクラスターでワークロードの中断が発生する可能性があります。デフォルトでは、Hosted Control Plane コントローラーは、仮想マシンが停止される前に、ライブマイグレーションできない KubeVirt 仮想マシンでホストされているワークロードをドレインしようとします。仮想マシンが停止する前にホステッドクラスターノードをドレインすると、Pod Disruption Budget によってホステッドクラスター内のワークロードの可用性を保護できます。

4.3.3. KubeVirt プラットフォームを使用したホステッドクラスターの作成

OpenShift Container Platform 4.14 以降では、KubeVirt を使用してクラスターを作成でき、外部インフラストラクチャーを使用して作成することも可能です。

4.3.3.1. CLI を使用して KubeVirt プラットフォームでホステッドクラスターを作成する

ホステッドクラスターを作成するには、Hosted Control Plane のコマンドラインインターフェイス (CLI) hcp を使用できます。

手順

  1. 次のコマンドを入力して、KubeVirt プラットフォームでホステッドクラスターを作成します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \
    1
    
      --node-pool-replicas <node_pool_replica_count> \
    2
    
      --pull-secret <path_to_pull_secret> \
    3
    
      --memory <value_for_memory> \
    4
    
      --cores <value_for_cpu> \
    5
    
      --etcd-storage-class=<etcd_storage_class> 
    6
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: my-hosted-cluster) を指定します。
    2
    ノードプールのレプリカ数を指定します (例: 3)。レプリカ数は 0 以上で指定する必要があります。指定したとおりの数のノードが作成されます。それ以外の場合、ノードプールは作成されません。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 6Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。
    注記

    --release-image フラグを使用すると、特定の OpenShift Container Platform リリースを使用してホステッドクラスターを設定できます。

    --node-pool-replicas フラグに従って、2 つの仮想マシンワーカーレプリカを持つクラスターに対してデフォルトのノードプールが作成されます。

  2. しばらくすると、次のコマンドを入力して、ホストされているコントロールプレーン Pod が実行されていることを確認できます。

    $ oc -n clusters-<hosted-cluster-name> get pods
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                  READY   STATUS    RESTARTS   AGE
    capi-provider-5cc7b74f47-n5gkr                        1/1     Running   0          3m
    catalog-operator-5f799567b7-fd6jw                     2/2     Running   0          69s
    certified-operators-catalog-784b9899f9-mrp6p          1/1     Running   0          66s
    cluster-api-6bbc867966-l4dwl                          1/1     Running   0          66s
    .
    .
    .
    redhat-operators-catalog-9d5fd4d44-z8qqk              1/1     Running   0          66s
    Copy to Clipboard Toggle word wrap

    KubeVirt 仮想マシンによってサポートされるワーカーノードを含むホステッドクラスターは、通常、完全にプロビジョニングされるまでに 10 ~ 15 分かかります。

検証

  • ホステッドクラスターのステータスを確認するには、次のコマンドを入力して、対応する HostedCluster リソースを確認します。

    $ oc get --namespace clusters hostedclusters
    Copy to Clipboard Toggle word wrap

    完全にプロビジョニングされた HostedCluster オブジェクトを示す以下の出力例を参照してください。

    NAMESPACE   NAME                VERSION     KUBECONFIG                 PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
    clusters    my-hosted-cluster   <4.x.0>     example-admin-kubeconfig   Completed   True        False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

    <4.x.0> を、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

デフォルトでは、HyperShift Operator は、ホステッドクラスターのコントロールプレーン Pod と、同じクラスター内の KubeVirt ワーカー VM の両方をホストします。外部インフラストラクチャー機能を使用すると、ワーカーノード VM をコントロールプレーン Pod とは別のクラスターに配置できます。

  • 管理クラスター は HyperShift Operator を実行し、ホステッドクラスターのコントロールプレーン Pod をホストする OpenShift Container Platform クラスターです。
  • インフラストラクチャークラスター は、ホステッドクラスターの KubeVirt ワーカー VM を実行する OpenShift Container Platform クラスターです。
  • デフォルトでは、管理クラスターは VM をホストするインフラストラクチャークラスターとしても機能します。ただし、外部インフラストラクチャーの場合、管理クラスターとインフラストラクチャークラスターは異なります。

前提条件

  • KubeVirt ノードをホストする外部インフラストラクチャークラスター上に namespace が必要です。
  • 外部インフラストラクチャークラスター用の kubeconfig ファイルが必要です。

手順

hcp コマンドラインインターフェイスを使用して、ホステッドクラスターを作成できます。

  • KubeVirt ワーカーの仮想マシンをインフラストラクチャークラスターに配置するには、次の例に示すように、--infra-kubeconfig-file および --infra-namespace 引数を使用します。

    $ hcp create cluster kubevirt \
      --name <hosted-cluster-name> \
    1
    
      --node-pool-replicas <worker-count> \
    2
    
      --pull-secret <path-to-pull-secret> \
    3
    
      --memory <value-for-memory> \
    4
    
      --cores <value-for-cpu> \
    5
    
      --infra-namespace=<hosted-cluster-namespace>-<hosted-cluster-name> \
    6
    
      --infra-kubeconfig-file=<path-to-external-infra-kubeconfig> 
    7
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: my-hosted-cluster) を指定します。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 6Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    インフラストラクチャー namespace を指定します (例: clusters-example)。
    7
    インフラストラクチャークラスターの kubeconfig ファイルへのパスを指定します (例: /user/name/external-infra-kubeconfig)。

    このコマンドを入力すると、コントロールプレーン Pod は HyperShift Operator が実行される管理クラスターでホストされ、KubeVirt VM は別のインフラストラクチャークラスターでホストされます。

4.3.3.3. コンソールを使用したホステッドクラスターの作成

コンソールを使用して KubeVirt プラットフォームでホステッドクラスターを作成するには、次の手順を実行します。

手順

  1. OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。
  2. コンソールヘッダーで、All Clusters が選択されていることを確認します。
  3. Infrastructure > Clusters をクリックします。
  4. Create cluster > Red Hat OpenShift Virtualization > Hosted をクリックします。
  5. Create cluster ページで、プロンプトに従ってクラスターとノードプールの詳細を入力します。

    注記
    • 事前定義された値を使用してコンソールのフィールドに自動的に入力する場合は、OpenShift Virtualization の認証情報を作成します。詳細は、「オンプレミス環境の認証情報の作成」を参照してください。
    • Cluster details ページのプルシークレットは、OpenShift Container Platform リソースへのアクセスに使用する OpenShift Container Platform プルシークレットです。OpenShift Virtualization の認証情報を選択した場合、プルシークレットが自動的に入力されます。
  6. Node pools ページで、Networking options セクションを展開し、ノードプールのネットワークオプションを設定します。

    1. Additional networks フィールドに、<namespace>/<name> という形式でネットワーク名を入力します (例: my-namespace/network1)。namespace と名前は有効な DNS ラベルである必要があります。複数のネットワークがサポートされています。
    2. デフォルトでは、Attach default pod network チェックボックスがオンになっています。追加のネットワークが存在する場合にのみ、このチェックボックスをオフにすることができます。
  7. エントリーを確認し、Create をクリックします。

    Hosted cluster ビューが表示されます。

検証

  1. Hosted cluster ビューでホステッドクラスターのデプロイメントを監視します。ホステッドクラスターに関する情報が表示されない場合は、All Clusters が選択されていることを確認し、クラスター名をクリックします。
  2. コントロールプレーンコンポーネントの準備が整うまで待ちます。このプロセスには数分かかる場合があります。
  3. ノードプールのステータスを表示するには、NodePool セクションまでスクロールします。ノードをインストールするプロセスには約 10 分かかります。Nodes をクリックして、ノードがホステッドクラスターに参加したかどうかを確認することもできます。

4.3.4. OpenShift Virtualization 上の Hosted Control Plane のデフォルトの Ingress と DNS を設定する

すべての OpenShift Container Platform クラスターにはデフォルトのアプリケーション Ingress コントローラーが含まれており、これにはワイルドカード DNS レコードが関連付けられている必要があります。デフォルトでは、HyperShift KubeVirt プロバイダーを使用して作成されたホステッドクラスターは、自動的に KubeVirt 仮想マシンが実行される OpenShift Container Platform クラスターのサブドメインになります。

たとえば、OpenShift Container Platform クラスターには次のデフォルトの Ingress DNS エントリーがある可能性があります。

*.apps.mgmt-cluster.example.com
Copy to Clipboard Toggle word wrap

その結果、guest という名前が付けられ、その基礎となる OpenShift Container Platform クラスター上で実行される KubeVirt ホステッドクラスターには、次のデフォルト Ingress が設定されます。

*.apps.guest.apps.mgmt-cluster.example.com
Copy to Clipboard Toggle word wrap

手順

デフォルトの Ingress DNS が適切に機能するには、KubeVirt 仮想マシンをホストするクラスターでワイルドカード DNS ルートを許可する必要があります。

  • この動作は、以下のコマンドを入力して設定できます。

    $ oc patch ingresscontroller -n openshift-ingress-operator default \
      --type=json \
      -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
    Copy to Clipboard Toggle word wrap
注記

デフォルトのホステッドクラスターの Ingress を使用する場合、接続がポート 443 経由の HTTPS トラフィックに制限されます。ポート 80 経由のプレーン HTTP トラフィックは拒否されます。この制限は、デフォルトの Ingress の動作にのみ適用されます。

4.3.4.1. カスタム DNS 名の定義

クラスター管理者は、ノードのブートストラップとコントロールプレーンの通信に使用される内部エンドポイントとは異なる外部 API DNS 名を持つホステッドクラスターを作成できます。別の DNS 名を定義する理由には、次のようなものがあります。

  • 内部ルート CA にバインドされているコントロールプレーン機能を損なうことなく、ユーザー向けの TLS 証明書をパブリック CA が発行したものに置き換えるため。
  • スプリットホライズン DNS および NAT のシナリオをサポートするため。
  • スタンドアロンのコントロールプレーンと同様のエクスペリエンスを確保し、正しい kubeconfig と DNS 設定を使用して、Show Login Command などの機能を使用可能にするため。

HostedCluster オブジェクトの kubeAPIServerDNSName パラメーターにドメイン名を入力することで、初期セットアップ時またはインストール後の操作時に DNS 名を定義できます。

前提条件

  • kubeAPIServerDNSName パラメーターで設定する DNS 名が、有効な TLS 証明書の対象に含まれている。
  • 正しいアドレスに到達し、それを指し示す解決可能な DNS 名 URI がある。

手順

  • HostedCluster オブジェクトの仕様で、kubeAPIServerDNSName パラメーターとドメインのアドレスを追加し、使用する証明書を指定します (次の例を参照)。

    #...
    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names:
              - xxx.example.com
              - yyy.example.com
              servingCertificate:
                name: <my_serving_certificate>
      kubeAPIServerDNSName: <custom_address> 
    1
    Copy to Clipboard Toggle word wrap
    1
    kubeAPIServerDNSName パラメーターの値は、有効でアドレス指定可能なドメインである必要があります。

kubeAPIServerDNSName パラメーターを定義して証明書を指定すると、Control Plane Operator のコントローラーによって custom-admin-kubeconfig という名前の kubeconfig ファイルが作成されます。このファイルは HostedControlPlane namespace に保存されます。証明書はルート CA から生成され、HostedControlPlane namespace によって証明書の有効期限と更新が管理されます。

Control Plane Operator は、HostedControlPlane namespace に CustomKubeconfig という名前の新しい kubeconfig ファイルを報告します。このファイルは、kubeAPIServerDNSName パラメーターで定義された新しいサーバーを使用します。

カスタム kubeconfig ファイルへの参照情報は、HostedCluster オブジェクトの status パラメーター内に CustomKubeconfig という名前で存在しています。CustomKubeConfig パラメーターは任意であり、kubeAPIServerDNSName パラメーターが空でない場合にのみ追加できます。CustomKubeConfig パラメーターを設定すると、そのパラメーターによって、HostedCluster namespace で <hosted_cluster_name>-custom-admin-kubeconfig という名前のシークレットの生成がトリガーされます。このシークレットを使用して HostedCluster API サーバーにアクセスできます。インストール後の操作時に CustomKubeConfig パラメーターを削除すると、関連するすべてのシークレットとステータス参照が削除されます。

注記

カスタム DNS 名の定義はデータプレーンに直接影響しないため、予期されるロールアウトは発生しません。HostedControlPlane namespace は、HyperShift Operator から変更を受け取り、対応するパラメーターを削除します。

HostedCluster オブジェクトの仕様から kubeAPIServerDNSName パラメーターを削除すると、新しく生成されたすべてのシークレットと、CustomKubeconfig 参照がクラスターと status パラメーターから削除されます。

4.3.5. Ingress と DNS の動作のカスタマイズ

デフォルトの Ingress および DNS 動作を使用しない場合は、作成時に一意のベースドメインを使用して KubeVirt ホステッドクラスターを設定できます。このオプションでは、作成時に手動の設定手順が必要であり、クラスターの作成、ロードバランサーの作成、およびワイルドカード DNS 設定の 3 つの主要な手順が含まれます。

4.3.5.1. ベースドメインを指定するホステッドクラスターのデプロイ

ベースドメインを指定するホステッドクラスターを作成するには、次の手順を実行します。

手順

  1. 以下のコマンドを入力します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \ 
    1
    
      --node-pool-replicas <worker_count> \ 
    2
    
      --pull-secret <path_to_pull_secret> \ 
    3
    
      --memory <value_for_memory> \ 
    4
    
      --cores <value_for_cpu> \ 
    5
    
      --base-domain <basedomain> 
    6
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 6Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    ベースドメインを指定します (例: hypershift.lab)。

    その結果、ホステッドクラスターには、クラスター名とベースドメイン用に設定された Ingress ワイルドカード (例: .apps.example.hypershift.lab) が含まれます。ホステッドクラスターは Partial ステータスのままです。一意のベースドメインを持つホステッドクラスターを作成した後、必要な DNS レコードとロードバランサーを設定する必要があるためです。

検証

  1. 次のコマンドを入力して、ホステッドクラスターのステータスを表示します。

    $ oc get --namespace clusters hostedclusters
    Copy to Clipboard Toggle word wrap

    出力例

    NAME            VERSION   KUBECONFIG                       PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
    example                   example-admin-kubeconfig         Partial    True        False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力してクラスターにアクセスします。

    $ hcp create kubeconfig --name <hosted_cluster_name> \
      > <hosted_cluster_name>-kubeconfig
    Copy to Clipboard Toggle word wrap
    $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get co
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    console                                    <4.x.0>     False       False         False      30m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host
    ingress                                    <4.x.0>     True        False         True       28m     The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
    Copy to Clipboard Toggle word wrap

    <4.x.0> を、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

次のステップ

出力のエラーを修正するには、「ロードバランサーのセットアップ」および「ワイルドカード DNS の設定」の手順を完了します。

注記

ホステッドクラスターがベアメタル上にある場合は、ロードバランサーサービスを設定するために MetalLB が必要になる場合があります。詳細は、「MetalLB の設定」を参照してください。

4.3.5.2. ロードバランサーのセットアップ

Ingress トラフィックを KubeVirt 仮想マシンにルーティングし、ロードバランサー IP アドレスにワイルドカード DNS エントリーを割り当てるロードバランサーサービスを設定します。

手順

  1. ホステッドクラスターの Ingress を公開する NodePort サービスがすでに存在します。ノードポートをエクスポートし、それらのポートをターゲットとするロードバランサーサービスを作成できます。

    1. 次のコマンドを入力して、HTTP ノードポートを取得します。

      $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \
        -n openshift-ingress router-nodeport-default \
        -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'
      Copy to Clipboard Toggle word wrap

      次の手順で使用する HTTP ノードポート値をメモします。

    2. 次のコマンドを入力して、HTTPS ノードポートを取得します。

      $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \
        -n openshift-ingress router-nodeport-default \
        -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'
      Copy to Clipboard Toggle word wrap

      次の手順で使用する HTTPS ノードポート値をメモします。

  2. YAML ファイルに次の情報を入力します。

    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: <hosted_cluster_name>
      name: <hosted_cluster_name>-apps
      namespace: clusters-<hosted_cluster_name>
    spec:
      ports:
      - name: https-443
        port: 443
        protocol: TCP
        targetPort: <https_node_port> 
    1
    
      - name: http-80
        port: 80
        protocol: TCP
        targetPort: <http_node_port> 
    2
    
      selector:
        kubevirt.io: virt-launcher
      type: LoadBalancer
    Copy to Clipboard Toggle word wrap
    1
    前の手順でメモした HTTPS ノードポート値を指定します。
    2
    前の手順でメモした HTTP ノードポート値を指定します。
  3. 次のコマンドを実行してロードバランサーサービスを作成します。

    $ oc create -f <file_name>.yaml
    Copy to Clipboard Toggle word wrap
4.3.5.3. ワイルドカード DNS の設定

ロードバランサーサービスの外部 IP を参照するワイルドカード DNS レコードまたは CNAME を設定します。

手順

  1. 次のコマンドを入力して外部 IP アドレスを取得します。

    $ oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps \
      -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
    Copy to Clipboard Toggle word wrap

    出力例

    192.168.20.30
    Copy to Clipboard Toggle word wrap

  2. 外部 IP アドレスを参照するワイルドカード DNS エントリーを設定します。次の DNS エントリーの例を表示します。

    *.apps.<hosted_cluster_name\>.<base_domain\>.
    Copy to Clipboard Toggle word wrap

    DNS エントリーは、クラスターの内部と外部にルーティングできる必要があります。

    DNS 解決の例

    dig +short test.apps.example.hypershift.lab
    
    192.168.20.30
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、ホステッドクラスターのステータスが Partial から Completed に移行したことを確認します。

    $ oc get --namespace clusters hostedclusters
    Copy to Clipboard Toggle word wrap

    出力例

    NAME            VERSION   KUBECONFIG                       PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
    example         <4.x.0>     example-admin-kubeconfig         Completed   True        False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

    <4.x.0> を、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

4.3.6. MetalLB の設定

MetalLB を設定する前に、MetalLB Operator をインストールする必要があります。

手順

ホステッドクラスターで MetalLB を設定するには、次の手順を実行します。

  1. 次のサンプル YAML コンテンツを configure-metallb.yaml ファイルに保存して、MetalLB リソースを作成します。

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、YAML コンテンツを適用します。

    $ oc apply -f configure-metallb.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    metallb.metallb.io/metallb created
    Copy to Clipboard Toggle word wrap

  3. 以下のサンプル YAML コンテンツを create-ip-address-pool.yaml ファイルに保存して、IPAddressPool リソースを作成します。

    apiVersion: metallb.io/v1beta1
    kind: IPAddressPool
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      addresses:
      - 192.168.216.32-192.168.216.122 
    1
    Copy to Clipboard Toggle word wrap
    1
    ノードネットワーク内で使用可能な IP アドレスの範囲を使用してアドレスプールを作成します。IP アドレス範囲は、ネットワーク内で使用可能な IP アドレスの未使用のプールに置き換えます。
  4. 次のコマンドを入力して、YAML コンテンツを適用します。

    $ oc apply -f create-ip-address-pool.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    ipaddresspool.metallb.io/metallb created
    Copy to Clipboard Toggle word wrap

  5. 次のサンプル YAML コンテンツを l2advertisement.yaml ファイルに保存して、L2Advertisement リソースを作成します。

    apiVersion: metallb.io/v1beta1
    kind: L2Advertisement
    metadata:
      name: l2advertisement
      namespace: metallb-system
    spec:
      ipAddressPools:
       - metallb
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを入力して、YAML コンテンツを適用します。

    $ oc apply -f l2advertisement.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    l2advertisement.metallb.io/metallb created
    Copy to Clipboard Toggle word wrap

ノードプール用に追加のネットワークを設定する必要がある場合、仮想マシン (VM) 用の Guaranteed CPU へのアクセスを要求する場合、または KubeVirt 仮想マシンのスケジュールを管理する必要がある場合は、次の手順を参照してください。

4.3.7.1. ノードプールへの複数のネットワークの追加

デフォルトでは、ノードプールによって生成されたノードは、Pod ネットワークに割り当てられます。Multus および NetworkAttachmentDefinitions を使用すると、追加のネットワークをノードに割り当てることができます。

手順

  • ノードに複数のネットワークを追加するには、次のコマンドを実行して --additional-network 引数を使用します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \
    1
    
      --node-pool-replicas <worker_node_count> \
    2
    
      --pull-secret <path_to_pull_secret> \
    3
    
      --memory <memory> \
    4
    
      --cores <cpu> \
    5
    
      --additional-network name:<namespace/name> \
    6
    
      –-additional-network name:<namespace/name>
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: my-hosted-cluster) を指定します。
    2
    ワーカーノードの数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    –additional-network 引数の値を name:<namespace/name> に設定します。<namespace/name> は、NetworkAttachmentDefinitions の namespace と名前に置き換えます。
4.3.7.1.1. 追加のネットワークをデフォルトとして使用する

デフォルトの Pod ネットワークを無効にすることで、追加のネットワークをノードのデフォルトネットワークとして追加できます。

手順

  • 追加のネットワークをデフォルトとしてノードに追加するには、次のコマンドを実行します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \
    1
    
      --node-pool-replicas <worker_node_count> \
    2
    
      --pull-secret <path_to_pull_secret> \
    3
    
      --memory <memory> \
    4
    
      --cores <cpu> \
    5
    
      --attach-default-network false \
    6
    
      --additional-network name:<namespace>/<network_name> 
    7
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: my-hosted-cluster) を指定します。
    2
    ワーカーノードの数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    --attach-default-network false 引数は、デフォルトの Pod ネットワークを無効にします。
    7
    ノードに追加する追加のネットワークを指定します (例: name:my-namespace/my-network)。
4.3.7.2. Guaranteed CPU リソースの要求

デフォルトでは、KubeVirt 仮想マシンはノード上の他のワークロードと CPU を共有する場合があります。これにより、仮想マシンのパフォーマンスに影響が出る可能性があります。パフォーマンスへの影響を回避するために、仮想マシン用の Guaranteed CPU へのアクセスを要求できます。

手順

  • 保証された CPU リソースを要求するには、次のコマンドを実行して --qos-class 引数を Guaranteed に設定します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \
    1
    
      --node-pool-replicas <worker_node_count> \
    2
    
      --pull-secret <path_to_pull_secret> \
    3
    
      --memory <memory> \
    4
    
      --cores <cpu> \
    5
    
      --qos-class Guaranteed 
    6
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: my-hosted-cluster) を指定します。
    2
    ワーカーノードの数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    --qos-class Guaranteed 引数は、指定された数の CPU リソースが仮想マシンに割り当てられることを保証します。
4.3.7.3. ノードセットに KubeVirt 仮想マシンをスケジュールする

デフォルトでは、ノードプールによって作成された KubeVirt 仮想マシンは、使用可能な任意のノードにスケジュールされます。KubeVirt 仮想マシンは、仮想マシンを実行するのに十分な容量を持つ特定のノードセットにスケジュールすることもできます。

手順

  • 特定のノードセット上のノードプール内で KubeVirt 仮想マシンをスケジュールするには、次のコマンドを実行して --vm-node-selector 引数を使用します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \
    1
    
      --node-pool-replicas <worker_node_count> \
    2
    
      --pull-secret <path_to_pull_secret> \
    3
    
      --memory <memory> \
    4
    
      --cores <cpu> \
    5
    
      --vm-node-selector <label_key>=<label_value>,<label_key>=<label_value> 
    6
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: my-hosted-cluster) を指定します。
    2
    ワーカーノードの数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    --vm-node-selector フラグは、キーと値のペアを含む特定のノードセットを定義します。<label_key> はラベルのキーに置き換え、<label_value> はラベルの値に置き換えます。

4.3.8. ノードプールのスケーリング

oc scale コマンドを使用して、ノードプールを手動でスケーリングできます。

手順

  1. 以下のコマンドを実行します。

    NODEPOOL_NAME=${CLUSTER_NAME}-work
    NODEPOOL_REPLICAS=5
    
    $ oc scale nodepool/$NODEPOOL_NAME --namespace clusters \
      --replicas=$NODEPOOL_REPLICAS
    Copy to Clipboard Toggle word wrap
  2. しばらくしてから、次のコマンドを入力して、ノードプールのステータスを確認します。

    $ oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                  STATUS   ROLES    AGE     VERSION
    example-9jvnf         Ready    worker   97s     v1.27.4+18eadca
    example-n6prw         Ready    worker   116m    v1.27.4+18eadca
    example-nc6g4         Ready    worker   117m    v1.27.4+18eadca
    example-thp29         Ready    worker   4m17s   v1.27.4+18eadca
    example-twxns         Ready    worker   88s     v1.27.4+18eadca
    Copy to Clipboard Toggle word wrap

4.3.8.1. ノードプールの追加

名前、レプリカの数、およびメモリーや CPU 要件などの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。

手順

  1. ノードプールを作成するには、次の情報を入力します。この例では、ノードプールには VM に割り当てられたより多くの CPU があります。

    export NODEPOOL_NAME=${CLUSTER_NAME}-extra-cpu
    export WORKER_COUNT="2"
    export MEM="6Gi"
    export CPU="4"
    export DISK="16"
    
    $ hcp create nodepool kubevirt \
      --cluster-name $CLUSTER_NAME \
      --name $NODEPOOL_NAME \
      --node-count $WORKER_COUNT \
      --memory $MEM \
      --cores $CPU \
      --root-volume-size $DISK
    Copy to Clipboard Toggle word wrap
  2. clusters namespace 内の nodepool リソースをリスト表示して、ノードプールのステータスを確認します。

    $ oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
    example                   example         5               5               False         False        <4.x.0>
    example-extra-cpu         example         2                               False         False                  True              True             Minimum availability requires 2 replicas, current 0 available
    Copy to Clipboard Toggle word wrap

    <4.x.0> を、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

検証

  1. しばらくしてから、次のコマンドを入力してノードプールのステータスを確認できます。

    $ oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                      STATUS   ROLES    AGE     VERSION
    example-9jvnf             Ready    worker   97s     v1.27.4+18eadca
    example-n6prw             Ready    worker   116m    v1.27.4+18eadca
    example-nc6g4             Ready    worker   117m    v1.27.4+18eadca
    example-thp29             Ready    worker   4m17s   v1.27.4+18eadca
    example-twxns             Ready    worker   88s     v1.27.4+18eadca
    example-extra-cpu-zh9l5   Ready    worker   2m6s    v1.27.4+18eadca
    example-extra-cpu-zr8mj   Ready    worker   102s    v1.27.4+18eadca
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力して、ノードプールが予期したステータスになっていることを確認します。

    $ oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
    example                   example         5               5               False         False        <4.x.0>
    example-extra-cpu         example         2               2               False         False        <4.x.0>
    Copy to Clipboard Toggle word wrap

    <4.x.0> を、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

4.3.9. OpenShift Virtualization でのホステッドクラスターの作成の検証

ホステッドクラスターが正常に作成されたことを確認するには、次の手順を完了します。

手順

  1. 次のコマンドを入力して、HostedCluster リソースが completed 状態に移行したことを確認します。

    $ oc get --namespace clusters hostedclusters <hosted_cluster_name>
    Copy to Clipboard Toggle word wrap

    出力例

    NAMESPACE   NAME      VERSION   KUBECONFIG                 PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
    clusters    example   4.12.2    example-admin-kubeconfig   Completed   True        False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力して、ホステッドクラスター内のすべてのクラスターオペレーターがオンラインであることを確認します。

    $ hcp create kubeconfig --name <hosted_cluster_name> \
      > <hosted_cluster_name>-kubeconfig
    Copy to Clipboard Toggle word wrap
    $ oc get co --kubeconfig=<hosted_cluster_name>-kubeconfig
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    console                                    4.12.2   True        False         False      2m38s
    csi-snapshot-controller                    4.12.2   True        False         False      4m3s
    dns                                        4.12.2   True        False         False      2m52s
    image-registry                             4.12.2   True        False         False      2m8s
    ingress                                    4.12.2   True        False         False      22m
    kube-apiserver                             4.12.2   True        False         False      23m
    kube-controller-manager                    4.12.2   True        False         False      23m
    kube-scheduler                             4.12.2   True        False         False      23m
    kube-storage-version-migrator              4.12.2   True        False         False      4m52s
    monitoring                                 4.12.2   True        False         False      69s
    network                                    4.12.2   True        False         False      4m3s
    node-tuning                                4.12.2   True        False         False      2m22s
    openshift-apiserver                        4.12.2   True        False         False      23m
    openshift-controller-manager               4.12.2   True        False         False      23m
    openshift-samples                          4.12.2   True        False         False      2m15s
    operator-lifecycle-manager                 4.12.2   True        False         False      22m
    operator-lifecycle-manager-catalog         4.12.2   True        False         False      23m
    operator-lifecycle-manager-packageserver   4.12.2   True        False         False      23m
    service-ca                                 4.12.2   True        False         False      4m41s
    storage                                    4.12.2   True        False         False      4m43s
    Copy to Clipboard Toggle word wrap

4.3.10. ホステッドクラスターでカスタム API サーバー証明書を設定する

API サーバーのカスタム証明書を設定するには、HostedCluster 設定の spec.configuration.apiServer セクションで証明書の詳細を指定します。

カスタム証明書は、Day 1 操作または Day 2 操作の中で設定できます。ただし、サービス公開ストラテジーはホステッドクラスターの作成中に設定した後は変更できないため、設定する予定の Kubernetes API サーバーのホスト名を知っておく必要があります。

前提条件

  • 管理クラスターにカスタム証明書が含まれる Kubernetes シークレットを作成しました。シークレットには次の鍵が含まれています。

    • tls.crt: 証明書
    • tls.key: 秘密鍵
  • HostedCluster 設定にロードバランサーを使用するサービス公開ストラテジーが含まれている場合は、証明書のサブジェクト代替名 (SAN) が内部 API エンドポイント (api-int) と競合しないことを確認してください。内部 API エンドポイントは、プラットフォームによって自動的に作成および管理されます。カスタム証明書と内部 API エンドポイントの両方で同じホスト名を使用すると、ルーティングの競合が発生する可能性があります。このルールの唯一の例外は、Private または PublicAndPrivate 設定で AWS をプロバイダーとして使用する場合です。このような場合、SAN の競合はプラットフォームによって管理されます。
  • 証明書は外部 API エンドポイントに対して有効である必要があります。
  • 証明書の有効期間は、クラスターの予想されるライフサイクルと一致します。

手順

  1. 次のコマンドを入力して、カスタム証明書を使用してシークレットを作成します。

    $ oc create secret tls sample-hosted-kas-custom-cert \
      --cert=path/to/cert.crt \
      --key=path/to/key.key \
      -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  2. 次の例に示すように、カスタム証明書の詳細を使用して HostedCluster 設定を更新します。

    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names: 
    1
    
              - api-custom-cert-sample-hosted.sample-hosted.example.com
              servingCertificate: 
    2
    
                name: sample-hosted-kas-custom-cert
    Copy to Clipboard Toggle word wrap
    1
    証明書が有効な DNS の名前のリスト。
    2
    カスタム証明書が含まれるシークレットの名前。
  3. 次のコマンドを入力して、HostedCluster 設定に変更を適用します。

    $ oc apply -f <hosted_cluster_config>.yaml
    Copy to Clipboard Toggle word wrap

検証

  • API サーバー Pod をチェックして、新しい証明書がマウントされていることを確認します。
  • カスタムドメイン名を使用して API サーバーへの接続をテストします。
  • ブラウザーで、または openssl などのツールを使用して、証明書の詳細を確認します。

4.4. 非ベアメタルエージェントマシンへの Hosted Control Plane のデプロイ

クラスターをホスティングクラスターとして機能するように設定することで、Hosted Control Plane をデプロイできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。ホスティングクラスターは管理クラスターとも呼ばれます。

重要

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

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

注記

管理クラスターは、マネージド クラスターとは異なります。マネージドクラスターは、ハブクラスターが管理するクラスターです。

Hosted Control Plane 機能はデフォルトで有効になっています。

multicluster engine Operator は、デフォルトの local-cluster マネージドハブクラスターのみをサポートしています。Red Hat Advanced Cluster Management (RHACM) 2.10 では、local-cluster マネージドハブクラスターをホスティングクラスターとして使用できます。

ホステッドクラスター は、ホスティングクラスターでホストされる API エンドポイントとコントロールプレーンを含む OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。ホステッドクラスターは、multicluster engine Operator コンソールまたは hcp コマンドラインインターフェイス (CLI) を使用して作成できます。

ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、「multicluster engine Operator へのホステッドクラスターの自動インポートの無効化」を参照してください。

4.4.1. 非ベアメタルエージェントマシンへの Hosted Control Plane のデプロイの準備

ベアメタルに Hosted Control Plane をデプロイする準備をする際には、次の情報を考慮してください。

  • Agent プラットフォームを使用すると、エージェントマシンをワーカーノードとしてホステッドクラスターに追加できます。エージェントマシンは、Discovery Image でブートされ、OpenShift Container Platform ノードとしてプロビジョニングされる準備ができているホストを表します。Agent プラットフォームは、Central Infrastructure Management サービスの一部です。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • ベアメタルではないすべてのホストは、Central Infrastructure Management が提供する検出イメージ ISO を使用して手動で起動する必要があります。
  • ノードプールをスケールアップすると、レプリカごとにマシンが作成されます。Cluster API プロバイダーは、マシンごとに、承認済みで、検証に合格し、現在使用されておらず、ノードプール仕様で指定されている要件を満たしているエージェントを検索してインストールします。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
  • ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。Agent を再利用するには、Discovery イメージを使用してエージェントを再起動する必要があります。
  • Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、OpenShift Container Platform ドキュメントの「推奨される etcd プラクティス」および「論理ボリュームマネージャーストレージを使用した永続ストレージ」を参照してください。
4.4.1.1. 非ベアメタルエージェントマシンに Hosted Control Plane をデプロイするための前提条件

非ベアメタルエージェントマシンに Hosted Control Plane をデプロイする前に、次の前提条件を満たしていることを確認してください。

  • OpenShift Container Platform クラスターに multicluster engine for Kubernetes Operator 2.5 以降がインストールされている。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator としてインストールできます。
  • multicluster engine Operator のマネージド OpenShift Container Platform クラスターが少なくとも 1 つある。local-cluster 管理クラスターは自動的にインポートされます。local-cluster の詳細は、Red Hat Advanced Cluster Management ドキュメントの 詳細設定 を参照してください。次のコマンドを実行すると、管理クラスターのステータスを確認できます。

    $ oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • Central Infrastructure Management を有効にした。詳細は、Red Hat Advanced Cluster Management ドキュメントの Central Infrastructure Management サービスの有効化 を参照してください。
  • hcp コマンドラインインターフェイスをインストールした。
  • ホステッドクラスターの名前がクラスター全体で一意である。
  • 管理クラスターとワーカーを同じインフラストラクチャー上で実行している。

管理クラスター、コントロールプレーン、ホステッドクラスター間でポートが通信できるように、ファイアウォールとポートの要件を満たす必要があります。

注記

サービスはデフォルトのポートで実行されます。ただし、NodePort 公開ストラテジーを使用する場合、サービスは NodePort サービスによって割り当てられたポートで実行されます。

ファイアウォールルール、セキュリティーグループ、またはその他のアクセス制御を使用して、必要なソースだけにアクセスを制限します。必要な場合を除き、ポートを公開しないでください。実稼働環境の場合は、ロードバランサーを使用して、単一の IP アドレスによるアクセスを簡素化します。

Hosted Control Plane は、非ベアメタルエージェントマシン上で次のサービスを公開します。

  • APIServer

    • APIServer サービスはデフォルトでポート 6443 で実行され、コントロールプレーンコンポーネント間の通信には ingress アクセスが必要です。
    • MetalLB ロードバランシングを使用する場合は、ロードバランサーの IP アドレスに使用される IP 範囲への ingress アクセスを許可します。
  • OAuthServer

    • ルートと Ingress を使用してサービスを公開する場合、OAuthServer サービスはデフォルトでポート 443 で実行されます。
    • NodePort 公開ストラテジーを使用する場合は、OAuthServer サービスにファイアウォールルールを使用します。
  • Konnectivity

    • ルートと Ingress を使用してサービスを公開する場合、Konnectivity サービスはデフォルトでポート 443 で実行されます。
    • Konnectivity エージェントはリバーストンネルを確立し、コントロールプレーンがホステッドクラスターのネットワークにアクセスできるようにします。エージェントは egress を使用して Konnectivity サーバーに接続します。サーバーは、ポート 443 のルートまたは手動で割り当てられた NodePort を使用して公開されます。
    • クラスター API サーバーのアドレスが内部 IP アドレスの場合は、ワークロードサブネットからポート 6443 の IP アドレスへのアクセスを許可します。
    • アドレスが外部 IP アドレスの場合は、ノードからその外部 IP アドレスにポート 6443 で送信できるように許可します。
  • Ignition

    • ルートと Ingress を使用してサービスを公開する場合、Ignition サービスはデフォルトでポート 443 で実行されます。
    • NodePort 公開ストラテジーを使用する場合は、Ignition サービスにファイアウォールルールを使用します。

非ベアメタルエージェントマシンでは、次のサービスは必要ありません。

  • OVNSbDb
  • OIDC
4.4.1.3. 非ベアメタルエージェントマシンのインフラストラクチャー要件

Agent プラットフォームはインフラストラクチャーを作成しませんが、次のインフラストラクチャー要件があります。

  • Agent: Agent は、Discovery イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングされる準備ができているホストを表します。
  • DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

4.4.2. 非ベアメタルエージェントマシンでの DNS の設定

ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<basedomain> の DNS エントリーが存在する必要があります。

DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。

  • IPv4 ネットワークで接続環境の DNS を設定する場合は、次の DNS 設定の例を参照してください。

    api.example.krnl.es.        IN A 192.168.122.20
    api.example.krnl.es.        IN A 192.168.122.21
    api.example.krnl.es.        IN A 192.168.122.22
    api-int.example.krnl.es.    IN A 192.168.122.20
    api-int.example.krnl.es.    IN A 192.168.122.21
    api-int.example.krnl.es.    IN A 192.168.122.22
    `*`.apps.example.krnl.es.   IN A 192.168.122.23
    Copy to Clipboard Toggle word wrap
  • IPv6 ネットワークで非接続環境の DNS を設定する場合は、次の DNS 設定の例を参照してください。

    api.example.krnl.es.        IN A 2620:52:0:1306::5
    api.example.krnl.es.        IN A 2620:52:0:1306::6
    api.example.krnl.es.        IN A 2620:52:0:1306::7
    api-int.example.krnl.es.    IN A 2620:52:0:1306::5
    api-int.example.krnl.es.    IN A 2620:52:0:1306::6
    api-int.example.krnl.es.    IN A 2620:52:0:1306::7
    `*`.apps.example.krnl.es.   IN A 2620:52:0:1306::10
    Copy to Clipboard Toggle word wrap
  • デュアルスタックネットワークの非接続環境で DNS を設定する場合は、IPv4 と IPv6 の両方の DNS エントリーを含めるようにしてください。次の DNS 設定の例を参照してください。

    host-record=api-int.hub-dual.dns.base.domain.name,192.168.126.10
    host-record=api.hub-dual.dns.base.domain.name,192.168.126.10
    address=/apps.hub-dual.dns.base.domain.name/192.168.126.11
    dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,192.168.126.20
    dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,192.168.126.21
    dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,192.168.126.22
    dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,192.168.126.25
    dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,192.168.126.26
    
    host-record=api-int.hub-dual.dns.base.domain.name,2620:52:0:1306::2
    host-record=api.hub-dual.dns.base.domain.name,2620:52:0:1306::2
    address=/apps.hub-dual.dns.base.domain.name/2620:52:0:1306::3
    dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,[2620:52:0:1306::5]
    dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,[2620:52:0:1306::6]
    dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,[2620:52:0:1306::7]
    dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,[2620:52:0:1306::8]
    dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,[2620:52:0:1306::9]
    Copy to Clipboard Toggle word wrap
4.4.2.1. カスタム DNS 名の定義

クラスター管理者は、ノードのブートストラップとコントロールプレーンの通信に使用される内部エンドポイントとは異なる外部 API DNS 名を持つホステッドクラスターを作成できます。別の DNS 名を定義する理由には、次のようなものがあります。

  • 内部ルート CA にバインドされているコントロールプレーン機能を損なうことなく、ユーザー向けの TLS 証明書をパブリック CA が発行したものに置き換えるため。
  • スプリットホライズン DNS および NAT のシナリオをサポートするため。
  • スタンドアロンのコントロールプレーンと同様のエクスペリエンスを確保し、正しい kubeconfig と DNS 設定を使用して、Show Login Command などの機能を使用可能にするため。

HostedCluster オブジェクトの kubeAPIServerDNSName パラメーターにドメイン名を入力することで、初期セットアップ時またはインストール後の操作時に DNS 名を定義できます。

前提条件

  • kubeAPIServerDNSName パラメーターで設定する DNS 名が、有効な TLS 証明書の対象に含まれている。
  • 正しいアドレスに到達し、それを指し示す解決可能な DNS 名 URI がある。

手順

  • HostedCluster オブジェクトの仕様で、kubeAPIServerDNSName パラメーターとドメインのアドレスを追加し、使用する証明書を指定します (次の例を参照)。

    #...
    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names:
              - xxx.example.com
              - yyy.example.com
              servingCertificate:
                name: <my_serving_certificate>
      kubeAPIServerDNSName: <custom_address> 
    1
    Copy to Clipboard Toggle word wrap
    1
    kubeAPIServerDNSName パラメーターの値は、有効でアドレス指定可能なドメインである必要があります。

kubeAPIServerDNSName パラメーターを定義して証明書を指定すると、Control Plane Operator のコントローラーによって custom-admin-kubeconfig という名前の kubeconfig ファイルが作成されます。このファイルは HostedControlPlane namespace に保存されます。証明書はルート CA から生成され、HostedControlPlane namespace によって証明書の有効期限と更新が管理されます。

Control Plane Operator は、HostedControlPlane namespace に CustomKubeconfig という名前の新しい kubeconfig ファイルを報告します。このファイルは、kubeAPIServerDNSName パラメーターで定義された新しいサーバーを使用します。

カスタム kubeconfig ファイルへの参照情報は、HostedCluster オブジェクトの status パラメーター内に CustomKubeconfig という名前で存在しています。CustomKubeConfig パラメーターは任意であり、kubeAPIServerDNSName パラメーターが空でない場合にのみ追加できます。CustomKubeConfig パラメーターを設定すると、そのパラメーターによって、HostedCluster namespace で <hosted_cluster_name>-custom-admin-kubeconfig という名前のシークレットの生成がトリガーされます。このシークレットを使用して HostedCluster API サーバーにアクセスできます。インストール後の操作時に CustomKubeConfig パラメーターを削除すると、関連するすべてのシークレットとステータス参照が削除されます。

注記

カスタム DNS 名の定義はデータプレーンに直接影響しないため、予期されるロールアウトは発生しません。HostedControlPlane namespace は、HyperShift Operator から変更を受け取り、対応するパラメーターを削除します。

HostedCluster オブジェクトの仕様から kubeAPIServerDNSName パラメーターを削除すると、新しく生成されたすべてのシークレットと、CustomKubeconfig 参照がクラスターと status パラメーターから削除されます。

4.4.3. CLI を使用した非ベアメタルエージェントマシンでのホステッドクラスターの作成

Agent プラットフォームを使用してホステッドクラスターを作成すると、HyperShift Operator によって Agent Cluster API プロバイダーが Hosted Control Plane の namespace にインストールされます。ベアメタルでホステッドクラスターを作成するか、インポートできます。

ホステッドクラスターを作成するときは、次のガイドラインを確認してください。

  • 各ホステッドクラスターの名前がクラスター全体で一意である。multicluster engine Operator によってホステッドクラスターを管理するには、ホステッドクラスター名を既存のマネージドクラスターと同じにすることはできません。
  • ホステッドクラスター名として clusters を使用しない。
  • ホステッドクラスターは、multicluster engine Operator のマネージドクラスターの namespace には作成できない。

手順

  1. 次のコマンドを入力して、Hosted Control Plane namespace を作成します。

    $ oc create ns <hosted_cluster_namespace>-<hosted_cluster_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_namespace> を、ホステッドクラスターの namespace 名 (例: clusters) に置き換えます。<hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
  2. 次のコマンドを入力して、ホステッドクラスターを作成します。

    $ hcp create cluster agent \
      --name=<hosted_cluster_name> \
    1
    
      --pull-secret=<path_to_pull_secret> \
    2
    
      --agent-namespace=<hosted_control_plane_namespace> \
    3
    
      --base-domain=<basedomain> \
    4
    
      --api-server-address=api.<hosted_cluster_name>.<basedomain> \
    5
    
      --etcd-storage-class=<etcd_storage_class> \
    6
    
      --ssh-key  <path_to_ssh_key> \
    7
    
      --namespace <hosted_cluster_namespace> \
    8
    
      --control-plane-availability-policy HighlyAvailable \
    9
    
      --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release> \
    10
    
      --node-pool-replicas <node_pool_replica_count> 
    11
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    3
    Hosted Control Plane namespace を指定します (例: clusters-example)。oc get agent -n <hosted-control-plane-namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメインを指定します (例: krnl.es)。
    5
    --api-server-address フラグは、ホステッドクラスター内の Kubernetes API 通信に使用される IP アドレスを定義します。--api-server-address フラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。
    6
    クラスターにデフォルトのストレージクラスが設定されていることを確認する。設定されていない場合は、PVC が保留になる可能性があります。etcd ストレージクラス名を指定します (例: lvm-storageclass)。
    7
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    8
    ホステッドクラスターの namespace を指定します。
    9
    Hosted Control Plane コンポーネントの可用性ポリシーを指定します。サポートされているオプションは SingleReplicaHighlyAvailable です。デフォルト値は HighlyAvailable です。
    10
    使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.19.0-multi)。
    11
    ノードプールのレプリカ数を指定します (例: 3)。レプリカ数は 0 以上で指定する必要があります。指定したとおりの数のノードが作成されます。それ以外の場合、ノードプールは作成されません。

検証

  • しばらくしてから、次のコマンドを入力して、Hosted Control Plane の Pod が稼働中であることを確認します。

    $ oc -n <hosted_cluster_namespace>-<hosted_cluster_name> get pods
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                             READY   STATUS    RESTARTS   AGE
    catalog-operator-6cd867cc7-phb2q                 2/2     Running   0          2m50s
    control-plane-operator-f6b4c8465-4k5dh           1/1     Running   0          4m32s
    Copy to Clipboard Toggle word wrap

OpenShift Container Platform Web コンソールを使用して、非ベアメタルエージェントマシン上にホステッドクラスターを作成できます。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。
  2. コンソールのヘッダーで、All Clusters を選択します。
  3. Infrastructure → Clusters をクリックします。
  4. Create cluster Host inventory → Hosted control plane をクリックします。

    Create cluster ページが表示されます。

  5. Create cluster ページでプロンプトに従い、クラスター、ノードプール、ネットワーク、および自動化に関する詳細を入力します。

クラスターの詳細を入力する際には、次のヒントが役立つ場合があります。

  • 事前定義された値を使用してコンソールのフィールドに自動的に値を入力する場合は、ホストインベントリーの認証情報を作成できます。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
  • Cluster details ページのプルシークレットは、OpenShift Container Platform リソースへのアクセスに使用する OpenShift Container Platform プルシークレットです。ホストインベントリー認証情報を選択した場合は、プルシークレットが自動的に入力されます。
  • Node pools ページでは、namespace にノードプールのホストが含まれます。コンソールを使用してホストインベントリーを作成した場合、コンソールは専用の namespace を作成します。
  • Networking ページで、API サーバー公開ストラテジーを選択します。ホステッドクラスターの API サーバーは、既存のロードバランサーを使用するか、NodePort タイプのサービスとして公開できます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<basedomain> 設定の DNS エントリーが存在する必要があります。このエントリーとして、管理クラスター内のノードの 1 つを指すレコード、または受信トラフィックを Ingress Pod にリダイレクトするロードバランサーを指すレコードを指定できます。

    1. エントリーを確認し、Create をクリックします。

    Hosted cluster ビューが表示されます。

    1. Hosted cluster ビューでホステッドクラスターのデプロイメントを監視します。ホステッドクラスターに関する情報が表示されない場合は、All Clusters が選択されていることを確認し、クラスター名をクリックします。コントロールプレーンコンポーネントの準備が整うまで待ちます。このプロセスには数分かかる場合があります。
    2. ノードプールのステータスを表示するには、NodePool セクションまでスクロールします。ノードをインストールするプロセスには約 10 分かかります。Nodes をクリックして、ノードがホステッドクラスターに参加したかどうかを確認することもできます。

次のステップ

hcp create cluster コマンドで --image-content-sources フラグを指定することで、ミラーレジストリーを使用して、非ベアメタルエージェントマシン上にホステッドクラスターを作成できます。

手順

  1. YAML ファイルを作成して、イメージコンテンツソースポリシー (ICSP) を定義します。以下の例を参照してください。

    - mirrors:
      - brew.registry.redhat.io
      source: registry.redhat.io
    - mirrors:
      - brew.registry.redhat.io
      source: registry.stage.redhat.io
    - mirrors:
      - brew.registry.redhat.io
      source: registry-proxy.engineering.redhat.com
    Copy to Clipboard Toggle word wrap
  2. ファイルを icsp.yaml として保存します。このファイルにはミラーレジストリーが含まれます。
  3. ミラーレジストリーを使用してホステッドクラスターを作成するには、次のコマンドを実行します。

    $ hcp create cluster agent \
        --name=<hosted_cluster_name> \
    1
    
        --pull-secret=<path_to_pull_secret> \
    2
    
        --agent-namespace=<hosted_control_plane_namespace> \
    3
    
        --base-domain=<basedomain> \
    4
    
        --api-server-address=api.<hosted_cluster_name>.<basedomain> \
    5
    
        --image-content-sources icsp.yaml  \
    6
    
        --ssh-key  <path_to_ssh_key> \
    7
    
        --namespace <hosted_cluster_namespace> \
    8
    
        --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> 
    9
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    3
    Hosted Control Plane namespace を指定します (例: clusters-example)。oc get agent -n <hosted-control-plane-namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメインを指定します (例: krnl.es)。
    5
    --api-server-address フラグは、ホステッドクラスター内の Kubernetes API 通信に使用される IP アドレスを定義します。--api-server-address フラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。
    6
    ICSP およびミラーレジストリーを定義する icsp.yaml ファイルを指定します。
    7
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    8
    ホステッドクラスターの namespace を指定します。
    9
    使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.19.0-multi)。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。

次のステップ

4.4.4. 非ベアメタルエージェントマシンでのホステッドクラスターの作成を検証する

デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。

手順

  1. 次のコマンドを入力して、新しいホステッドクラスターの kubeconfig ファイルを取得します。

    $ oc extract -n <hosted_cluster_namespace> \
      secret/<hosted_cluster_name>-admin-kubeconfig --to=- \
      > kubeconfig-<hosted_cluster_name>
    Copy to Clipboard Toggle word wrap
  2. kubeconfig ファイルを使用して、ホステッドクラスターのクラスター Operator を表示します。以下のコマンドを入力します。

    $ oc get co --kubeconfig=kubeconfig-<hosted_cluster_name>
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    console                                    4.10.26   True        False         False      2m38s
    csi-snapshot-controller                    4.10.26   True        False         False      4m3s
    dns                                        4.10.26   True        False         False      2m52s
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを入力して、ホステッドクラスター上で実行中の Pod を表示します。

    $ oc get pods -A --kubeconfig=kubeconfig-<hosted_cluster_name>
    Copy to Clipboard Toggle word wrap

    出力例

    NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
    kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
    openshift-cluster-samples-operator                 cluster-samples-operator-6b5bcb9dff-kpnbc                 2/2     Running            0               20m
    openshift-monitoring                               alertmanager-main-0                                       6/6     Running            0               100s
    openshift-monitoring                               openshift-state-metrics-677b9fb74f-qqp6g                  3/3     Running            0               104s
    Copy to Clipboard Toggle word wrap

4.4.5. ホステッドクラスターでカスタム API サーバー証明書を設定する

API サーバーのカスタム証明書を設定するには、HostedCluster 設定の spec.configuration.apiServer セクションで証明書の詳細を指定します。

カスタム証明書は、Day 1 操作または Day 2 操作の中で設定できます。ただし、サービス公開ストラテジーはホステッドクラスターの作成中に設定した後は変更できないため、設定する予定の Kubernetes API サーバーのホスト名を知っておく必要があります。

前提条件

  • 管理クラスターにカスタム証明書が含まれる Kubernetes シークレットを作成しました。シークレットには次の鍵が含まれています。

    • tls.crt: 証明書
    • tls.key: 秘密鍵
  • HostedCluster 設定にロードバランサーを使用するサービス公開ストラテジーが含まれている場合は、証明書のサブジェクト代替名 (SAN) が内部 API エンドポイント (api-int) と競合しないことを確認してください。内部 API エンドポイントは、プラットフォームによって自動的に作成および管理されます。カスタム証明書と内部 API エンドポイントの両方で同じホスト名を使用すると、ルーティングの競合が発生する可能性があります。このルールの唯一の例外は、Private または PublicAndPrivate 設定で AWS をプロバイダーとして使用する場合です。このような場合、SAN の競合はプラットフォームによって管理されます。
  • 証明書は外部 API エンドポイントに対して有効である必要があります。
  • 証明書の有効期間は、クラスターの予想されるライフサイクルと一致します。

手順

  1. 次のコマンドを入力して、カスタム証明書を使用してシークレットを作成します。

    $ oc create secret tls sample-hosted-kas-custom-cert \
      --cert=path/to/cert.crt \
      --key=path/to/key.key \
      -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  2. 次の例に示すように、カスタム証明書の詳細を使用して HostedCluster 設定を更新します。

    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names: 
    1
    
              - api-custom-cert-sample-hosted.sample-hosted.example.com
              servingCertificate: 
    2
    
                name: sample-hosted-kas-custom-cert
    Copy to Clipboard Toggle word wrap
    1
    証明書が有効な DNS の名前のリスト。
    2
    カスタム証明書が含まれるシークレットの名前。
  3. 次のコマンドを入力して、HostedCluster 設定に変更を適用します。

    $ oc apply -f <hosted_cluster_config>.yaml
    Copy to Clipboard Toggle word wrap

検証

  • API サーバー Pod をチェックして、新しい証明書がマウントされていることを確認します。
  • カスタムドメイン名を使用して API サーバーへの接続をテストします。
  • ブラウザーで、または openssl などのツールを使用して、証明書の詳細を確認します。

4.5. IBM Z への Hosted Control Plane のデプロイ

クラスターを管理クラスターとして機能するように設定することで、Hosted Control Plane をデプロイできます。管理クラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。管理クラスターは ホスティング クラスターとも呼ばれます。

注記

管理 クラスターは マネージド クラスターではありません。マネージドクラスターは、ハブクラスターが管理するクラスターです。

hypershift アドオンを使用してマネージドクラスターに HyperShift Operator をデプロイすることにより、そのマネージドクラスターを管理クラスターに変換できます。その後、ホステッドクラスターの作成を開始できます。

multicluster engine Operator は、マネージドのハブクラスターであるデフォルトの local-cluster と、管理クラスターとしてのハブクラスターのみをサポートしています。

ベアメタルに Hosted Control Plane をプロビジョニングするには、Agent プラットフォームを使用できます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。詳細は、「Central Infrastructure Management サービスの有効化」を参照してください。

各 IBM Z システムホストは、Central Infrastructure Management によって提供される PXE イメージを使用して起動する必要があります。各ホストが起動すると、エージェントプロセスが実行されてホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。

Agent プラットフォームでホステッドクラスターを作成すると、HyperShift Operator は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。

4.5.1. IBM Z で Hosted Control Plane を設定するための前提条件

  • multicluster engine for Kubernetes Operator version 2.5 以降を OpenShift Container Platform クラスターにインストールする必要があります。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator としてインストールできます。
  • multicluster engine Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。multicluster engine Operator バージョン 2.5 以降では、local-cluster が自動的にインポートされます。local-cluster の詳細は、Red Hat Advanced Cluster Management ドキュメントの 詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。

    $ oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • HyperShift Operator を実行するために 3 つ以上のワーカーノードを含むホスティングクラスターがある。
  • Central Infrastructure Management サービスが有効である。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • Hosted Control Plane のコマンドラインインターフェイスをインストールする必要があります。詳細は、Hosted Control Plane のコマンドラインインターフェイスのインストール を参照してください。

4.5.2. IBM Z のインフラストラクチャー要件

Agent プラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャー用の次のリソースを必要とします。

  • Agents: Agent は Discovery イメージまたは PXE イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングする準備ができているホストを表します。
  • DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

Hosted Control Plane 機能はデフォルトで有効になっています。この機能を以前に無効にしていて手動で有効にする場合、またはこの機能を無効にする必要がある場合は、Hosted Control Plane 機能の有効化または無効化 を参照してください。

4.5.3. IBM Z での Hosted Control Plane の DNS 設定

ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<base_domain> の DNS エントリーが存在する必要があります。

DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。

エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。

次の DNS 設定の例を参照してください。

$ cat /var/named/<example.krnl.es.zone>
Copy to Clipboard Toggle word wrap

出力例

$ TTL 900
@ IN  SOA bastion.example.krnl.es.com. hostmaster.example.krnl.es.com. (
      2019062002
      1D 1H 1W 3H )
  IN NS bastion.example.krnl.es.com.
;
;
api                   IN A 1xx.2x.2xx.1xx 
1

api-int               IN A 1xx.2x.2xx.1xx
;
;
*.apps        IN A 1xx.2x.2xx.1xx
;
;EOF
Copy to Clipboard Toggle word wrap

1
このレコードは、Hosted Control Plane の受信トラフィックと送信トラフィックを処理する API ロードバランサーの IP アドレスを参照します。

IBM z/VM の場合、エージェントの IP アドレスに対応する IP アドレスを追加します。

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy
Copy to Clipboard Toggle word wrap
4.5.3.1. カスタム DNS 名の定義

クラスター管理者は、ノードのブートストラップとコントロールプレーンの通信に使用される内部エンドポイントとは異なる外部 API DNS 名を持つホステッドクラスターを作成できます。別の DNS 名を定義する理由には、次のようなものがあります。

  • 内部ルート CA にバインドされているコントロールプレーン機能を損なうことなく、ユーザー向けの TLS 証明書をパブリック CA が発行したものに置き換えるため。
  • スプリットホライズン DNS および NAT のシナリオをサポートするため。
  • スタンドアロンのコントロールプレーンと同様のエクスペリエンスを確保し、正しい kubeconfig と DNS 設定を使用して、Show Login Command などの機能を使用可能にするため。

HostedCluster オブジェクトの kubeAPIServerDNSName パラメーターにドメイン名を入力することで、初期セットアップ時またはインストール後の操作時に DNS 名を定義できます。

前提条件

  • kubeAPIServerDNSName パラメーターで設定する DNS 名が、有効な TLS 証明書の対象に含まれている。
  • 正しいアドレスに到達し、それを指し示す解決可能な DNS 名 URI がある。

手順

  • HostedCluster オブジェクトの仕様で、kubeAPIServerDNSName パラメーターとドメインのアドレスを追加し、使用する証明書を指定します (次の例を参照)。

    #...
    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names:
              - xxx.example.com
              - yyy.example.com
              servingCertificate:
                name: <my_serving_certificate>
      kubeAPIServerDNSName: <custom_address> 
    1
    Copy to Clipboard Toggle word wrap
    1
    kubeAPIServerDNSName パラメーターの値は、有効でアドレス指定可能なドメインである必要があります。

kubeAPIServerDNSName パラメーターを定義して証明書を指定すると、Control Plane Operator のコントローラーによって custom-admin-kubeconfig という名前の kubeconfig ファイルが作成されます。このファイルは HostedControlPlane namespace に保存されます。証明書はルート CA から生成され、HostedControlPlane namespace によって証明書の有効期限と更新が管理されます。

Control Plane Operator は、HostedControlPlane namespace に CustomKubeconfig という名前の新しい kubeconfig ファイルを報告します。このファイルは、kubeAPIServerDNSName パラメーターで定義された新しいサーバーを使用します。

カスタム kubeconfig ファイルへの参照情報は、HostedCluster オブジェクトの status パラメーター内に CustomKubeconfig という名前で存在しています。CustomKubeConfig パラメーターは任意であり、kubeAPIServerDNSName パラメーターが空でない場合にのみ追加できます。CustomKubeConfig パラメーターを設定すると、そのパラメーターによって、HostedCluster namespace で <hosted_cluster_name>-custom-admin-kubeconfig という名前のシークレットの生成がトリガーされます。このシークレットを使用して HostedCluster API サーバーにアクセスできます。インストール後の操作時に CustomKubeConfig パラメーターを削除すると、関連するすべてのシークレットとステータス参照が削除されます。

注記

カスタム DNS 名の定義はデータプレーンに直接影響しないため、予期されるロールアウトは発生しません。HostedControlPlane namespace は、HyperShift Operator から変更を受け取り、対応するパラメーターを削除します。

HostedCluster オブジェクトの仕様から kubeAPIServerDNSName パラメーターを削除すると、新しく生成されたすべてのシークレットと、CustomKubeconfig 参照がクラスターと status パラメーターから削除されます。

4.5.4. コンソールを使用したホステッドクラスターの作成

ベアメタルインフラストラクチャーには、ホステッドクラスターを作成またはインポートできます。multicluster engine Operator へのアドオンとして Assisted Installer を有効にし、Agent プラットフォームを使用してホステッドクラスターを作成すると、HyperShift Operator によって Agent Cluster API プロバイダーが Hosted Control Plane namespace にインストールされます。Agent Cluster API プロバイダーは、コントロールプレーンをホストする管理クラスターと、コンピュートノードのみで構成されるホステッドクラスターを接続します。

前提条件

  • 各ホステッドクラスターの名前がクラスター全体で一意である。ホステッドクラスター名は、既存のマネージドクラスターと同じにすることはできません。この要件を満たさないと、multicluster engine Operator がホステッドクラスターを管理できません。
  • ホステッドクラスター名として clusters という単語を使用しない。
  • multicluster engine Operator のマネージドクラスターの namespace にホステッドクラスターを作成することはできない。
  • 最適なセキュリティーと管理プラクティスを実現するために、他のホステッドクラスターとは別にホステッドクラスターを作成する。
  • クラスターにデフォルトのストレージクラスが設定されていることを確認する。そうしない場合、保留中の永続ボリューム要求 (PVC) が表示されることがあります。
  • デフォルトでは、hcp create cluster agent コマンドを使用すると、ノードポートが設定されたホステッドクラスターが作成されます。ベアメタル上のホステッドクラスターの推奨公開ストラテジーは、ロードバランサーを通じてサービスを公開することです。Web コンソールまたは Red Hat Advanced Cluster Management を使用してホステッドクラスターを作成する場合、Kubernetes API サーバー以外のサービスの公開ストラテジーを設定するには、HostedCluster カスタムリソースで servicePublishingStrategy 情報を手動で指定する必要があります。
  • インフラストラクチャー、ファイアウォール、ポート、およびサービスに関連する要件を含め、「ベアメタル上の Hosted Control Plane の要件」に記載されている要件を満たしていることを確認する。要件では、たとえば次のコマンド例に示すように、管理クラスター内のベアメタルホストに適切なゾーンラベルを追加する方法が説明されています。

    $ oc label node [compute-node-1] topology.kubernetes.io/zone=zone1
    Copy to Clipboard Toggle word wrap
    $ oc label node [compute-node-2] topology.kubernetes.io/zone=zone2
    Copy to Clipboard Toggle word wrap
    $ oc label node [compute-node-3] topology.kubernetes.io/zone=zone3
    Copy to Clipboard Toggle word wrap
  • ハードウェアインベントリーにベアメタルノードを追加したことを確認する。

手順

  1. 次のコマンドを入力して namespace を作成します。

    $ oc create ns <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

    <hosted_cluster_namespace> は、ホステッドクラスター namespace の識別子に置き換えます。namespace は HyperShift Operator によって作成されます。ベアメタルインフラストラクチャーにホステッドクラスターを作成するプロセスでは、Cluster API プロバイダー用のロールが生成されます。このロールを生成するには、namespace が事前に存在している必要があります。

  2. 次のコマンドを入力して、ホステッドクラスターの設定ファイルを作成します。

    $ hcp create cluster agent \
      --name=<hosted_cluster_name> \
    1
    
      --pull-secret=<path_to_pull_secret> \
    2
    
      --agent-namespace=<hosted_control_plane_namespace> \
    3
    
      --base-domain=<base_domain> \
    4
    
      --api-server-address=api.<hosted_cluster_name>.<base_domain> \
    5
    
      --etcd-storage-class=<etcd_storage_class> \
    6
    
      --ssh-key=<path_to_ssh_key> \
    7
    
      --namespace=<hosted_cluster_namespace> \
    8
    
      --control-plane-availability-policy=HighlyAvailable \
    9
    
      --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image>-multi \
    10
    
      --node-pool-replicas=<node_pool_replica_count> \
    11
    
      --render \
      --render-sensitive \
      --ssh-key <home_directory>/<path_to_ssh_key>/<ssh_key> > hosted-cluster-config.yaml 
    12
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: example) を指定します。
    2
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    3
    Hosted Control Plane の namespace を指定します (例: clusters-example)。oc get agent -n <hosted_control_plane_namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメイン (例: krnl.es) を指定します。
    5
    --api-server-address フラグは、ホステッドクラスター内の Kubernetes API 通信に使用される IP アドレスを定義します。--api-server-address フラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。
    6
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。
    7
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    8
    ホステッドクラスターの namespace を指定します。
    9
    Hosted Control Plane コンポーネントの可用性ポリシーを指定します。サポートされているオプションは SingleReplicaHighlyAvailable です。デフォルト値は HighlyAvailable です。
    10
    使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.19.0-multi)。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
    11
    ノードプールのレプリカ数を指定します (例: 3)。レプリカ数は 0 以上で指定する必要があります。指定したとおりの数のノードが作成されます。この値を指定しない場合、ノードプールは作成されません。
    12
    --ssh-key フラグの後に、SSH 鍵へのパス (例: user/.ssh/id_rsa) を指定します。
  3. サービス公開ストラテジーを設定します。デフォルトでは、ホステッドクラスターは NodePort サービス公開ストラテジーを使用します。これは、ノードポートが追加のインフラストラクチャーなしで常に利用可能であるためです。ただし、ロードバランサーを使用するようにサービス公開ストラテジーを設定することもできます。

    • デフォルトの NodePort ストラテジーを使用している場合は、管理クラスターノードではなく、ホステッドクラスターコンピュートノードを指すように DNS を設定します。詳細は、「ベアメタル上の DNS 設定」を参照してください。
    • 実稼働環境では、証明書の処理と自動 DNS 解決を提供する LoadBalancer ストラテジーを使用します。次の例は、ホステッドクラスターの設定ファイルで LoadBalancer サービス公開ストラテジーを変更する方法を示しています。

      # ...
      spec:
        services:
        - service: APIServer
          servicePublishingStrategy:
            type: LoadBalancer 
      1
      
        - service: Ignition
          servicePublishingStrategy:
            type: Route
        - service: Konnectivity
          servicePublishingStrategy:
            type: Route
        - service: OAuthServer
          servicePublishingStrategy:
            type: Route
        - service: OIDC
          servicePublishingStrategy:
            type: Route
        sshKey:
          name: <ssh_key>
      # ...
      Copy to Clipboard Toggle word wrap
      1
      API サーバータイプとして LoadBalancer を指定します。それ以外のすべてのサービスでは、タイプとして Route を指定します。
  4. 次のコマンドを入力して、ホステッドクラスター設定ファイルに変更を適用します。

    $ oc apply -f hosted_cluster_config.yaml
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを入力して、ホステッドクラスター、ノードプール、および Pod の作成を確認します。

    $ oc get hostedcluster \
      <hosted_cluster_namespace> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get nodepool \
      <hosted_cluster_namespace> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get pods -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  6. ホステッドクラスターの準備ができていることを確認します。Available: True というステータスはクラスターの準備完了状態であることを示しています。ノードプールのステータスには AllMachinesReady: True と表示されます。これらのステータスは、すべてのクラスター Operator の健全性を示しています。
  7. ホステッドクラスターに MetalLB をインストールします。

    1. 次のコマンドを入力して、ホステッドクラスターから kubeconfig ファイルを展開し、ホステッドクラスターアクセス用の環境変数を設定します。

      $ oc get secret \
        <hosted_cluster_namespace>-admin-kubeconfig \
        -n <hosted_cluster_namespace> \
        -o jsonpath='{.data.kubeconfig}' \
        | base64 -d > \
        kubeconfig-<hosted_cluster_namespace>.yaml
      Copy to Clipboard Toggle word wrap
      $ export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"
      Copy to Clipboard Toggle word wrap
    2. install-metallb-operator.yaml ファイルを作成して MetalLB Operator をインストールします。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: metallb-system
      ---
      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: metallb-operator
        namespace: metallb-system
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: metallb-operator
        namespace: metallb-system
      spec:
        channel: "stable"
        name: metallb-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        installPlanApproval: Automatic
      # ...
      Copy to Clipboard Toggle word wrap
    3. 以下のコマンドを入力してファイルを適用します。

      $ oc apply -f install-metallb-operator.yaml
      Copy to Clipboard Toggle word wrap
    4. deploy-metallb-ipaddresspool.yaml ファイルを作成して、MetalLB IP アドレスプールを設定します。

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        name: metallb
        namespace: metallb-system
      spec:
        autoAssign: true
        addresses:
        - 10.11.176.71-10.11.176.75
      ---
      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: l2advertisement
        namespace: metallb-system
      spec:
        ipAddressPools:
        - metallb
      # ...
      Copy to Clipboard Toggle word wrap
    5. 次のコマンドを入力して設定を適用します。

      $ oc apply -f deploy-metallb-ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
    6. 次のコマンドを入力して、Operator ステータス、IP アドレスプール、および L2Advertisement リソースを確認し、MetalLB のインストールを検証します。

      $ oc get pods -n metallb-system
      Copy to Clipboard Toggle word wrap
      $ oc get ipaddresspool -n metallb-system
      Copy to Clipboard Toggle word wrap
      $ oc get l2advertisement -n metallb-system
      Copy to Clipboard Toggle word wrap
  8. Ingress 用のロードバランサーを設定します。

    1. ingress-loadbalancer.yaml ファイルを作成します。

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          metallb.universe.tf/address-pool: metallb
        name: metallb-ingress
        namespace: openshift-ingress
      spec:
        ports:
          - name: http
            protocol: TCP
            port: 80
            targetPort: 80
          - name: https
            protocol: TCP
            port: 443
            targetPort: 443
        selector:
          ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        type: LoadBalancer
      # ...
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを入力して設定を適用します。

      $ oc apply -f ingress-loadbalancer.yaml
      Copy to Clipboard Toggle word wrap
    3. 次のコマンドを入力して、ロードバランサーサービスが期待どおりに動作することを確認します。

      $ oc get svc metallb-ingress -n openshift-ingress
      Copy to Clipboard Toggle word wrap

      出力例

      NAME              TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
      metallb-ingress   LoadBalancer   172.31.127.129   10.11.176.71   80:30961/TCP,443:32090/TCP   16h
      Copy to Clipboard Toggle word wrap

  9. ロードバランサーと連携するように DNS を設定します。

    1. *.apps.<hosted_cluster_namespace>.<base_domain> ワイルドカード DNS レコードがロードバランサーの IP アドレスをポイントするように、apps ドメインの DNS を設定します。
    2. 次のコマンドを入力して DNS 解決を確認します。

      $ nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>
      Copy to Clipboard Toggle word wrap

      出力例

      Server:         10.11.176.1
      Address:        10.11.176.1#53
      
      Name:   console-openshift-console.apps.my-hosted-cluster.sample-base-domain.com
      Address: 10.11.176.71
      Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを入力して、クラスター Operator を確認します。

    $ oc get clusteroperators
    Copy to Clipboard Toggle word wrap

    すべての Operator に AVAILABLE: TruePROGRESSING: FalseDEGRADED: False が表示されていることを確認します。

  2. 次のコマンドを入力してノードを確認します。

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    各ノードのステータスが READY であることを確認します。

  3. Web ブラウザーに次の URL を入力して、コンソールへのアクセスをテストします。

    https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>
    Copy to Clipboard Toggle word wrap

4.5.5. IBM Z 上の Hosted Control Plane 用の InfraEnv リソースを作成する

InfraEnv は、PXE イメージを使用して起動されるホストがエージェントとして参加できる環境です。この場合、エージェントは Hosted Control Plane と同じ namespace に作成されます。

手順

  1. 設定を含む YAML ファイルを作成します。以下の例を参照してください。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: <hosted_cluster_name>
      namespace: <hosted_control_plane_namespace>
    spec:
      cpuArchitecture: s390x
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: <ssh_public_key>
    Copy to Clipboard Toggle word wrap
  2. ファイルを infraenv-config.yaml として保存します。
  3. 次のコマンドを入力して設定を適用します。

    $ oc apply -f infraenv-config.yaml
    Copy to Clipboard Toggle word wrap
  4. initrd.imgkernel.img、または rootfs.img などの PXE イメージをダウンロードする URL を取得するには、次のコマンドを入力します。このイメージは、IBM Z マシンがエージェントとして参加できるようにします。

    $ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json
    Copy to Clipboard Toggle word wrap

4.5.6. InfraEnv リソースへの IBM Z エージェントの追加

Hosted Control Plane にコンピュートノードをアタッチするには、ノードプールのスケーリングに役立つエージェントを作成します。IBM Z 環境にエージェントを追加するには、追加の手順が必要です。これは、このセクションで詳しく説明します。

特に明記されていない限り、以下の手順は IBM Z および IBM LinuxONE 上の z/VM と RHEL KVM の両方のインストールに適用されます。

4.5.6.1. IBM Z KVM をエージェントとして追加する

KVM を使用する IBM Z の場合は、次のコマンドを実行して、InfraEnv リソースからダウンロードした PXE イメージを使用して IBM Z 環境を開始します。エージェントが作成されると、ホストは Assisted Service と通信し、管理クラスター上の InfraEnv リソースと同じ namespace に登録します。

手順

  1. 以下のコマンドを実行します。

    virt-install \
       --name "<vm_name>" \ 
    1
    
       --autostart \
       --ram=16384 \
       --cpu host \
       --vcpus=4 \
       --location "<path_to_kernel_initrd_image>,kernel=kernel.img,initrd=initrd.img" \ 
    2
    
       --disk <qcow_image_path> \ 
    3
    
       --network network:macvtap-net,mac=<mac_address> \ 
    4
    
       --graphics none \
       --noautoconsole \
       --wait=-1
       --extra-args "rd.neednet=1 nameserver=<nameserver>   coreos.live.rootfs_url=http://<http_server>/rootfs.img random.trust_cpu=on rd.luks.options=discard ignition.firstboot ignition.platform.id=metal console=tty1 console=ttyS1,115200n8 coreos.inst.persistent-kargs=console=tty1 console=ttyS1,115200n8" 
    5
    Copy to Clipboard Toggle word wrap
    1
    仮想マシンの名前を指定します。
    2
    kernel_initrd_image ファイルの場所を指定します。
    3
    ディスクイメージのパスを指定します。
    4
    Mac アドレスを指定します。
    5
    エージェントのサーバー名を指定します。
  2. ISO ブートの場合は、InfraEnv リソースから ISO をダウンロードし、次のコマンドを実行してノードを起動します。

    virt-install \
      --name "<vm_name>" \ 
    1
    
      --autostart \
      --memory=16384 \
      --cpu host \
      --vcpus=4 \
      --network network:macvtap-net,mac=<mac_address> \ 
    2
    
      --cdrom "<path_to_image.iso>" \ 
    3
    
      --disk <qcow_image_path> \
      --graphics none \
      --noautoconsole \
      --os-variant <os_version> \ 
    4
    
      --wait=-1
    Copy to Clipboard Toggle word wrap
    1
    仮想マシンの名前を指定します。
    2
    Mac アドレスを指定します。
    3
    image.iso ファイルの場所を指定します。
    4
    使用しているオペレーティングシステムのバージョンを指定します。
4.5.6.2. IBM Z LPAR をエージェントとして追加する

IBM Z または IBM LinuxONE 上の論理パーティション (LPAR) をコンピュートノードとして Hosted Control Plane に追加できます。

手順

  1. エージェントのブートパラメーターファイルを作成します。

    パラメーターファイルの例

    rd.neednet=1 cio_ignore=all,!condev \
    console=ttysclp0 \
    ignition.firstboot ignition.platform.id=metal
    coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
    1
    
    coreos.inst.persistent-kargs=console=ttysclp0
    ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
    2
    
    rd.znet=qeth,<network_adaptor_range>,layer2=1
    rd.<disk_type>=<adapter> \
    3
    
    zfcp.allow_lun_scan=0
    ai.ip_cfg_override=1 \
    4
    
    random.trust_cpu=on rd.luks.options=discard
    Copy to Clipboard Toggle word wrap

    1
    coreos.live.rootfs_url アーティファクトには、起動する kernelinitramfs に合った rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    2
    ip パラメーターには、z/VM を使用したクラスターの IBM Z および IBM LinuxONE へのインストール の説明に従って、IP アドレスを手動で割り当てます。
    3
    DASD タイプのディスクにインストールする場合は、rd.dasd を使用して、Red Hat Enterprise Linux CoreOS (RHCOS) をインストールする DASD を指定します。FCP タイプのディスクにインストールする場合は、rd.zfcp=<adapter>,<wwpn>,<lun> を使用して、RHCOS がインストールされる FCP ディスクを指定します。
    4
    Open Systems Adapter (OSA) または HiperSockets を使用する場合は、このパラメーターを指定します。
  2. InfraEnv リソースから .ins ファイルと initrd.img.addrsize ファイルをダウンロードします。

    デフォルトでは、.ins ファイルと initrd.img.addrsize ファイルの URL は、InfraEnv リソースにはありません。これらのアーティファクトを取得するには、URL を編集する必要があります。

    1. 次のコマンドを実行して、カーネル URL エンドポイントを更新し、ins-file を含めます。

      $ curl -k -L -o generic.ins "< url for ins-file >"
      Copy to Clipboard Toggle word wrap

      URL の例

      https://…/boot-artifacts/ins-file?arch=s390x&version=4.17.0
      Copy to Clipboard Toggle word wrap

    2. initrd URL エンドポイントを更新し、s390x-initrd-addrsize を含めます。

      URL の例

      https://…./s390x-initrd-addrsize?api_key=<api-key>&arch=s390x&version=4.17.0
      Copy to Clipboard Toggle word wrap

  3. initrdkernelgeneric.ins、および initrd.img.addrsize パラメーターファイルをファイルサーバーに転送します。FTP を使用してファイルを転送し、ブートする方法の詳細は、「LPAR へのインストール」を参照してください。
  4. マシンを起動します。
  5. クラスター内の他のマシンすべてに対してこの手順を繰り返します。
4.5.6.3. IBM z/VM をエージェントとして追加する

z/VM ゲストに静的 IP を使用する場合は、IP パラメーターが 2 回目の起動でも持続するように、z/VM エージェントの NMStateConfig 属性を設定する必要があります。

InfraEnv リソースからダウンロードした PXE イメージを使用して IBM Z 環境を開始するには、以下の手順を実行します。エージェントが作成されると、ホストは Assisted Service と通信し、管理クラスター上の InfraEnv リソースと同じ namespace に登録します。

手順

  1. パラメーターファイルを更新して、rootfs_urlnetwork_adaptor、および disk_type の値を追加します。

    パラメーターファイルの例

    rd.neednet=1 cio_ignore=all,!condev \
    console=ttysclp0  \
    ignition.firstboot ignition.platform.id=metal \
    coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
    1
    
    coreos.inst.persistent-kargs=console=ttysclp0
    ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
    2
    
    rd.znet=qeth,<network_adaptor_range>,layer2=1
    rd.<disk_type>=<adapter> \
    3
    
    zfcp.allow_lun_scan=0
    ai.ip_cfg_override=1 \
    4
    Copy to Clipboard Toggle word wrap

    1
    coreos.live.rootfs_url アーティファクトには、起動する kernelinitramfs に合った rootfs アーティファクトを指定します。HTTP プロトコルおよび HTTPS プロトコルのみがサポートされます。
    2
    ip パラメーターには、z/VM を使用したクラスターの IBM Z および IBM LinuxONE へのインストール の説明に従って、IP アドレスを手動で割り当てます。
    3
    DASD タイプのディスクにインストールする場合は、rd.dasd を使用して、Red Hat Enterprise Linux CoreOS (RHCOS) をインストールする DASD を指定します。FCP タイプのディスクにインストールする場合は、rd.zfcp=<adapter>,<wwpn>,<lun> を使用して、RHCOS がインストールされる FCP ディスクを指定します。
    注記

    FCP マルチパス設定の場合、1 つのディスクではなく 2 つのディスクを用意します。

    rd.zfcp=<adapter1>,<wwpn1>,<lun1> \
    rd.zfcp=<adapter2>,<wwpn2>,<lun2>
    Copy to Clipboard Toggle word wrap

    4
    Open Systems Adapter (OSA) または HiperSockets を使用する場合は、このパラメーターを指定します。
  2. 次のコマンドを実行して、initrd、カーネルイメージ、およびパラメーターファイルをゲスト VM に移動します。

    vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>
    Copy to Clipboard Toggle word wrap
    vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename
    Copy to Clipboard Toggle word wrap
    vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>
    Copy to Clipboard Toggle word wrap
  3. ゲスト VM コンソールから次のコマンドを実行します。

    cp ipl c
    Copy to Clipboard Toggle word wrap
  4. エージェントとそのプロパティーをリスト表示するには、次のコマンドを入力します。

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    出力例

    NAME    CLUSTER APPROVED    ROLE    STAGE
    50c23cda-cedc-9bbd-bcf1-9b3a5c75804d    auto-assign
    5e498cd3-542c-e54f-0c58-ed43e28b568a    auto-assign
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを実行してエージェントを承認します。

    $ oc -n <hosted_control_plane_namespace> patch agent \
      50c23cda-cedc-9bbd-bcf1-9b3a5c75804d -p \
      '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-zvm-0.hostedn.example.com"}}' \
    1
    
      --type merge
    Copy to Clipboard Toggle word wrap
    1
    必要に応じて、仕様でエージェント ID <installation_disk_id><hostname> を設定できます。
  6. 次のコマンドを実行して、エージェントが承認されていることを確認します。

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                            CLUSTER     APPROVED   ROLE          STAGE
    50c23cda-cedc-9bbd-bcf1-9b3a5c75804d             true       auto-assign
    5e498cd3-542c-e54f-0c58-ed43e28b568a             true       auto-assign
    Copy to Clipboard Toggle word wrap

4.5.7. IBM Z 上のホステッドクラスターの NodePool オブジェクトのスケーリング

NodePool オブジェクトは、ホステッドクラスターの作成時に作成されます。NodePool オブジェクトをスケーリングすることで、Hosted Control Plane にさらに多くのコンピュートノードを追加できます。

ノードプールをスケールアップすると、マシンが作成されます。Cluster API プロバイダーは、承認され、検証に合格し、現在使用されておらず、ノードプールの仕様で指定されている要件を満たすエージェントを見つけます。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。

手順

  1. 次のコマンドを実行して、NodePool オブジェクトを 2 つのノードにスケーリングします。

    $ oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
    Copy to Clipboard Toggle word wrap

    Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で移行フェーズを通過します。

    • binding
    • discovering
    • insufficient
    • installing
    • installing-in-progress
    • added-to-existing-cluster
  2. 次のコマンドを実行して、スケールされた特定のエージェントのステータスを確認します。

    $ oc -n <hosted_control_plane_namespace> get agent -o \
      jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} \
      Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    出力例

    BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
    BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、移行フェーズを表示します。

    $ oc -n <hosted_control_plane_namespace> get agent
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER           APPROVED       ROLE        STAGE
    50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   hosted-forwarder   true          auto-assign
    5e498cd3-542c-e54f-0c58-ed43e28b568a                      true          auto-assign
    da503cf1-a347-44f2-875c-4960ddb04091   hosted-forwarder   true          auto-assign
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、ホステッドクラスターにアクセスするための kubeconfig ファイルを生成します。

    $ hcp create kubeconfig \
      --namespace <clusters_namespace> \
      --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
    Copy to Clipboard Toggle word wrap
  5. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、OpenShift Container Platform ノードが表示されることを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             STATUS   ROLES    AGE      VERSION
    worker-zvm-0.hostedn.example.com Ready    worker   5m41s    v1.24.0+3882f8f
    worker-zvm-1.hostedn.example.com Ready    worker   6m3s     v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

    Cluster Operator は、ワークロードをノードに追加することによってリコンシリエーションを開始します。

  6. 次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。

    $ oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                CLUSTER  NODENAME PROVIDERID     PHASE     AGE   VERSION
    hosted-forwarder-79558597ff-5tbqp   hosted-forwarder-crqq5   worker-zvm-0.hostedn.example.com   agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   Running   41h   4.15.0
    hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0
    Copy to Clipboard Toggle word wrap

  7. 次のコマンドを実行して、クラスターのバージョンを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
    clusterversion.config.openshift.io/version   4.15.0-ec.2   True        False         40h     Cluster version is 4.15.0-ec.2
    Copy to Clipboard Toggle word wrap

  8. 以下のコマンドを実行して、クラスター Operator のステータスを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
    Copy to Clipboard Toggle word wrap

クラスターの各コンポーネントの出力には、NAMEVERSIONAVAILABLEPROGRESSINGDEGRADEDSINCE、および MESSAGE のクラスター Operator のステータスが表示されます。

出力例は、Operator の初期設定 参照してください。

4.6. IBM Power への Hosted Control Plane のデプロイ

クラスターをホスティングクラスターとして機能するように設定することで、Hosted Control Plane をデプロイできます。この設定により、多数のクラスターを管理するための効率的でスケーラブルなソリューションが実現します。ホスティングクラスターは、コントロールプレーンをホストする OpenShift Container Platform クラスターです。ホスティングクラスターは 管理 クラスターとも呼ばれます。

注記

管理 クラスターは マネージド クラスターではありません。マネージドクラスターは、ハブクラスターが管理するクラスターです。

multicluster engine Operator がホスティングクラスターとしてサポートしているのは、デフォルトの local-cluster (マネージドハブクラスター) と、ハブクラスターだけです。

ベアメタルインフラストラクチャーに Hosted Control Plane をプロビジョニングするには、Agent プラットフォームを使用できます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにコンピュートノードを追加します。詳細は、「Central Infrastructure Management サービスの有効化」を参照してください。

各 IBM Power ホストは、Central Infrastructure Management が提供する Discovery イメージを使用して起動する必要があります。各ホストが起動すると、エージェントプロセスが実行されてホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。

Agent プラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。

4.6.1. IBM Power で Hosted Control Plane を設定するための前提条件

  • OpenShift Container Platform クラスターにインストールされた multicluster engine for Kubernetes Operator 2.7 以降。multicluster engine Operator は、Red Hat Advanced Cluster Management (RHACM) をインストールすると、自動的にインストールされます。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator として RHACM なしでインストールすることもできます。
  • multicluster engine Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。multicluster engine Operator バージョン 2.7 以降では、local-cluster マネージドハブクラスターが自動的にインポートされます。local-cluster の詳細は、RHACM ドキュメントの 詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。

    $ oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • HyperShift Operator を実行するには、少なくとも 3 つのコンピュートノードを持つホスティングクラスターが必要です。
  • Central Infrastructure Management サービスが有効である。詳細は、「Central Infrastructure Management サービスの有効化」を参照してください。
  • Hosted Control Plane コマンドラインインターフェイスをインストールする必要があります。詳細は、「Hosted Control Plane のコマンドラインインターフェイスのインストール」を参照してください。

Hosted Control Plane 機能はデフォルトで有効になっています。この機能を以前に無効にしていて、手動で有効にする場合は、「Hosted Control Plane 機能の手動での有効化」を参照してください。機能を無効にする必要がある場合は、「Hosted Control Plane 機能の無効化」を参照してください。

4.6.2. IBM Power のインフラストラクチャー要件

Agent プラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャー用の次のリソースを必要とします。

  • Agents: Agent は、Discovery イメージで起動し、OpenShift Container Platform ノードとしてプロビジョニングできるホストを表します。
  • DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

4.6.3. IBM Power での Hosted Control Plane の DNS 設定

ネットワーク外のクライアントは、ホステッドクラスターの API サーバーにアクセスできます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<basedomain> エントリーの DNS エントリーが存在する必要があります。

DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のいずれかのノードを指す単純なレコードで構いません。

また、そのエントリーでデプロイ済みのロードバランサーを指定し、受信トラフィックを Ingress Pod にリダイレクトすることもできます。

次の DNS 設定の例を参照してください。

$ cat /var/named/<example.krnl.es.zone>
Copy to Clipboard Toggle word wrap

出力例

$ TTL 900
@ IN  SOA bastion.example.krnl.es.com. hostmaster.example.krnl.es.com. (
      2019062002
      1D 1H 1W 3H )
  IN NS bastion.example.krnl.es.com.
;
;
api                   IN A 1xx.2x.2xx.1xx 
1

api-int               IN A 1xx.2x.2xx.1xx
;
;
*.apps.<hosted_cluster_name>.<basedomain>           IN A 1xx.2x.2xx.1xx
;
;EOF
Copy to Clipboard Toggle word wrap

1
このレコードは、Hosted Control Plane の受信トラフィックと送信トラフィックを処理する API ロードバランサーの IP アドレスを参照します。

IBM Power の場合、エージェントの IP アドレスに対応する IP アドレスを追加します。

設定例

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy
Copy to Clipboard Toggle word wrap

4.6.3.1. カスタム DNS 名の定義

クラスター管理者は、ノードのブートストラップとコントロールプレーンの通信に使用される内部エンドポイントとは異なる外部 API DNS 名を持つホステッドクラスターを作成できます。別の DNS 名を定義する理由には、次のようなものがあります。

  • 内部ルート CA にバインドされているコントロールプレーン機能を損なうことなく、ユーザー向けの TLS 証明書をパブリック CA が発行したものに置き換えるため。
  • スプリットホライズン DNS および NAT のシナリオをサポートするため。
  • スタンドアロンのコントロールプレーンと同様のエクスペリエンスを確保し、正しい kubeconfig と DNS 設定を使用して、Show Login Command などの機能を使用可能にするため。

HostedCluster オブジェクトの kubeAPIServerDNSName パラメーターにドメイン名を入力することで、初期セットアップ時またはインストール後の操作時に DNS 名を定義できます。

前提条件

  • kubeAPIServerDNSName パラメーターで設定する DNS 名が、有効な TLS 証明書の対象に含まれている。
  • 正しいアドレスに到達し、それを指し示す解決可能な DNS 名 URI がある。

手順

  • HostedCluster オブジェクトの仕様で、kubeAPIServerDNSName パラメーターとドメインのアドレスを追加し、使用する証明書を指定します (次の例を参照)。

    #...
    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names:
              - xxx.example.com
              - yyy.example.com
              servingCertificate:
                name: <my_serving_certificate>
      kubeAPIServerDNSName: <custom_address> 
    1
    Copy to Clipboard Toggle word wrap
    1
    kubeAPIServerDNSName パラメーターの値は、有効でアドレス指定可能なドメインである必要があります。

kubeAPIServerDNSName パラメーターを定義して証明書を指定すると、Control Plane Operator のコントローラーによって custom-admin-kubeconfig という名前の kubeconfig ファイルが作成されます。このファイルは HostedControlPlane namespace に保存されます。証明書はルート CA から生成され、HostedControlPlane namespace によって証明書の有効期限と更新が管理されます。

Control Plane Operator は、HostedControlPlane namespace に CustomKubeconfig という名前の新しい kubeconfig ファイルを報告します。このファイルは、kubeAPIServerDNSName パラメーターで定義された新しいサーバーを使用します。

カスタム kubeconfig ファイルへの参照情報は、HostedCluster オブジェクトの status パラメーター内に CustomKubeconfig という名前で存在しています。CustomKubeConfig パラメーターは任意であり、kubeAPIServerDNSName パラメーターが空でない場合にのみ追加できます。CustomKubeConfig パラメーターを設定すると、そのパラメーターによって、HostedCluster namespace で <hosted_cluster_name>-custom-admin-kubeconfig という名前のシークレットの生成がトリガーされます。このシークレットを使用して HostedCluster API サーバーにアクセスできます。インストール後の操作時に CustomKubeConfig パラメーターを削除すると、関連するすべてのシークレットとステータス参照が削除されます。

注記

カスタム DNS 名の定義はデータプレーンに直接影響しないため、予期されるロールアウトは発生しません。HostedControlPlane namespace は、HyperShift Operator から変更を受け取り、対応するパラメーターを削除します。

HostedCluster オブジェクトの仕様から kubeAPIServerDNSName パラメーターを削除すると、新しく生成されたすべてのシークレットと、CustomKubeconfig 参照がクラスターと status パラメーターから削除されます。

4.6.4. コンソールを使用したホステッドクラスターの作成

ベアメタルインフラストラクチャーには、ホステッドクラスターを作成またはインポートできます。multicluster engine Operator へのアドオンとして Assisted Installer を有効にし、Agent プラットフォームを使用してホステッドクラスターを作成すると、HyperShift Operator によって Agent Cluster API プロバイダーが Hosted Control Plane namespace にインストールされます。Agent Cluster API プロバイダーは、コントロールプレーンをホストする管理クラスターと、コンピュートノードのみで構成されるホステッドクラスターを接続します。

前提条件

  • 各ホステッドクラスターの名前がクラスター全体で一意である。ホステッドクラスター名は、既存のマネージドクラスターと同じにすることはできません。この要件を満たさないと、multicluster engine Operator がホステッドクラスターを管理できません。
  • ホステッドクラスター名として clusters という単語を使用しない。
  • multicluster engine Operator のマネージドクラスターの namespace にホステッドクラスターを作成することはできない。
  • 最適なセキュリティーと管理プラクティスを実現するために、他のホステッドクラスターとは別にホステッドクラスターを作成する。
  • クラスターにデフォルトのストレージクラスが設定されていることを確認する。そうしない場合、保留中の永続ボリューム要求 (PVC) が表示されることがあります。
  • デフォルトでは、hcp create cluster agent コマンドを使用すると、ノードポートが設定されたホステッドクラスターが作成されます。ベアメタル上のホステッドクラスターの推奨公開ストラテジーは、ロードバランサーを通じてサービスを公開することです。Web コンソールまたは Red Hat Advanced Cluster Management を使用してホステッドクラスターを作成する場合、Kubernetes API サーバー以外のサービスの公開ストラテジーを設定するには、HostedCluster カスタムリソースで servicePublishingStrategy 情報を手動で指定する必要があります。
  • インフラストラクチャー、ファイアウォール、ポート、およびサービスに関連する要件を含め、「ベアメタル上の Hosted Control Plane の要件」に記載されている要件を満たしていることを確認する。要件では、たとえば次のコマンド例に示すように、管理クラスター内のベアメタルホストに適切なゾーンラベルを追加する方法が説明されています。

    $ oc label node [compute-node-1] topology.kubernetes.io/zone=zone1
    Copy to Clipboard Toggle word wrap
    $ oc label node [compute-node-2] topology.kubernetes.io/zone=zone2
    Copy to Clipboard Toggle word wrap
    $ oc label node [compute-node-3] topology.kubernetes.io/zone=zone3
    Copy to Clipboard Toggle word wrap
  • ハードウェアインベントリーにベアメタルノードを追加したことを確認する。

手順

  1. 次のコマンドを入力して namespace を作成します。

    $ oc create ns <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

    <hosted_cluster_namespace> は、ホステッドクラスター namespace の識別子に置き換えます。namespace は HyperShift Operator によって作成されます。ベアメタルインフラストラクチャーにホステッドクラスターを作成するプロセスでは、Cluster API プロバイダー用のロールが生成されます。このロールを生成するには、namespace が事前に存在している必要があります。

  2. 次のコマンドを入力して、ホステッドクラスターの設定ファイルを作成します。

    $ hcp create cluster agent \
      --name=<hosted_cluster_name> \
    1
    
      --pull-secret=<path_to_pull_secret> \
    2
    
      --agent-namespace=<hosted_control_plane_namespace> \
    3
    
      --base-domain=<base_domain> \
    4
    
      --api-server-address=api.<hosted_cluster_name>.<base_domain> \
    5
    
      --etcd-storage-class=<etcd_storage_class> \
    6
    
      --ssh-key=<path_to_ssh_key> \
    7
    
      --namespace=<hosted_cluster_namespace> \
    8
    
      --control-plane-availability-policy=HighlyAvailable \
    9
    
      --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image>-multi \
    10
    
      --node-pool-replicas=<node_pool_replica_count> \
    11
    
      --render \
      --render-sensitive \
      --ssh-key <home_directory>/<path_to_ssh_key>/<ssh_key> > hosted-cluster-config.yaml 
    12
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: example) を指定します。
    2
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    3
    Hosted Control Plane の namespace を指定します (例: clusters-example)。oc get agent -n <hosted_control_plane_namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメイン (例: krnl.es) を指定します。
    5
    --api-server-address フラグは、ホステッドクラスター内の Kubernetes API 通信に使用される IP アドレスを定義します。--api-server-address フラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。
    6
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。
    7
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    8
    ホステッドクラスターの namespace を指定します。
    9
    Hosted Control Plane コンポーネントの可用性ポリシーを指定します。サポートされているオプションは SingleReplicaHighlyAvailable です。デフォルト値は HighlyAvailable です。
    10
    使用するサポート対象の OpenShift Container Platform バージョンを指定します (例: 4.19.0-multi)。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
    11
    ノードプールのレプリカ数を指定します (例: 3)。レプリカ数は 0 以上で指定する必要があります。指定したとおりの数のノードが作成されます。この値を指定しない場合、ノードプールは作成されません。
    12
    --ssh-key フラグの後に、SSH 鍵へのパス (例: user/.ssh/id_rsa) を指定します。
  3. サービス公開ストラテジーを設定します。デフォルトでは、ホステッドクラスターは NodePort サービス公開ストラテジーを使用します。これは、ノードポートが追加のインフラストラクチャーなしで常に利用可能であるためです。ただし、ロードバランサーを使用するようにサービス公開ストラテジーを設定することもできます。

    • デフォルトの NodePort ストラテジーを使用している場合は、管理クラスターノードではなく、ホステッドクラスターコンピュートノードを指すように DNS を設定します。詳細は、「ベアメタル上の DNS 設定」を参照してください。
    • 実稼働環境では、証明書の処理と自動 DNS 解決を提供する LoadBalancer ストラテジーを使用します。次の例は、ホステッドクラスターの設定ファイルで LoadBalancer サービス公開ストラテジーを変更する方法を示しています。

      # ...
      spec:
        services:
        - service: APIServer
          servicePublishingStrategy:
            type: LoadBalancer 
      1
      
        - service: Ignition
          servicePublishingStrategy:
            type: Route
        - service: Konnectivity
          servicePublishingStrategy:
            type: Route
        - service: OAuthServer
          servicePublishingStrategy:
            type: Route
        - service: OIDC
          servicePublishingStrategy:
            type: Route
        sshKey:
          name: <ssh_key>
      # ...
      Copy to Clipboard Toggle word wrap
      1
      API サーバータイプとして LoadBalancer を指定します。それ以外のすべてのサービスでは、タイプとして Route を指定します。
  4. 次のコマンドを入力して、ホステッドクラスター設定ファイルに変更を適用します。

    $ oc apply -f hosted_cluster_config.yaml
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを入力して、ホステッドクラスター、ノードプール、および Pod の作成を確認します。

    $ oc get hostedcluster \
      <hosted_cluster_namespace> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get nodepool \
      <hosted_cluster_namespace> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get pods -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  6. ホステッドクラスターの準備ができていることを確認します。Available: True というステータスはクラスターの準備完了状態であることを示しています。ノードプールのステータスには AllMachinesReady: True と表示されます。これらのステータスは、すべてのクラスター Operator の健全性を示しています。
  7. ホステッドクラスターに MetalLB をインストールします。

    1. 次のコマンドを入力して、ホステッドクラスターから kubeconfig ファイルを展開し、ホステッドクラスターアクセス用の環境変数を設定します。

      $ oc get secret \
        <hosted_cluster_namespace>-admin-kubeconfig \
        -n <hosted_cluster_namespace> \
        -o jsonpath='{.data.kubeconfig}' \
        | base64 -d > \
        kubeconfig-<hosted_cluster_namespace>.yaml
      Copy to Clipboard Toggle word wrap
      $ export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"
      Copy to Clipboard Toggle word wrap
    2. install-metallb-operator.yaml ファイルを作成して MetalLB Operator をインストールします。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: metallb-system
      ---
      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: metallb-operator
        namespace: metallb-system
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: metallb-operator
        namespace: metallb-system
      spec:
        channel: "stable"
        name: metallb-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        installPlanApproval: Automatic
      # ...
      Copy to Clipboard Toggle word wrap
    3. 以下のコマンドを入力してファイルを適用します。

      $ oc apply -f install-metallb-operator.yaml
      Copy to Clipboard Toggle word wrap
    4. deploy-metallb-ipaddresspool.yaml ファイルを作成して、MetalLB IP アドレスプールを設定します。

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        name: metallb
        namespace: metallb-system
      spec:
        autoAssign: true
        addresses:
        - 10.11.176.71-10.11.176.75
      ---
      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: l2advertisement
        namespace: metallb-system
      spec:
        ipAddressPools:
        - metallb
      # ...
      Copy to Clipboard Toggle word wrap
    5. 次のコマンドを入力して設定を適用します。

      $ oc apply -f deploy-metallb-ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
    6. 次のコマンドを入力して、Operator ステータス、IP アドレスプール、および L2Advertisement リソースを確認し、MetalLB のインストールを検証します。

      $ oc get pods -n metallb-system
      Copy to Clipboard Toggle word wrap
      $ oc get ipaddresspool -n metallb-system
      Copy to Clipboard Toggle word wrap
      $ oc get l2advertisement -n metallb-system
      Copy to Clipboard Toggle word wrap
  8. Ingress 用のロードバランサーを設定します。

    1. ingress-loadbalancer.yaml ファイルを作成します。

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          metallb.universe.tf/address-pool: metallb
        name: metallb-ingress
        namespace: openshift-ingress
      spec:
        ports:
          - name: http
            protocol: TCP
            port: 80
            targetPort: 80
          - name: https
            protocol: TCP
            port: 443
            targetPort: 443
        selector:
          ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        type: LoadBalancer
      # ...
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを入力して設定を適用します。

      $ oc apply -f ingress-loadbalancer.yaml
      Copy to Clipboard Toggle word wrap
    3. 次のコマンドを入力して、ロードバランサーサービスが期待どおりに動作することを確認します。

      $ oc get svc metallb-ingress -n openshift-ingress
      Copy to Clipboard Toggle word wrap

      出力例

      NAME              TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
      metallb-ingress   LoadBalancer   172.31.127.129   10.11.176.71   80:30961/TCP,443:32090/TCP   16h
      Copy to Clipboard Toggle word wrap

  9. ロードバランサーと連携するように DNS を設定します。

    1. *.apps.<hosted_cluster_namespace>.<base_domain> ワイルドカード DNS レコードがロードバランサーの IP アドレスをポイントするように、apps ドメインの DNS を設定します。
    2. 次のコマンドを入力して DNS 解決を確認します。

      $ nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>
      Copy to Clipboard Toggle word wrap

      出力例

      Server:         10.11.176.1
      Address:        10.11.176.1#53
      
      Name:   console-openshift-console.apps.my-hosted-cluster.sample-base-domain.com
      Address: 10.11.176.71
      Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを入力して、クラスター Operator を確認します。

    $ oc get clusteroperators
    Copy to Clipboard Toggle word wrap

    すべての Operator に AVAILABLE: TruePROGRESSING: FalseDEGRADED: False が表示されていることを確認します。

  2. 次のコマンドを入力してノードを確認します。

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    各ノードのステータスが READY であることを確認します。

  3. Web ブラウザーに次の URL を入力して、コンソールへのアクセスをテストします。

    https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>
    Copy to Clipboard Toggle word wrap

4.6.5. エージェントホステッドクラスターでの異種ノードプールの作成について

ノードプールは、同じ構成を共有するクラスター内のノードのグループです。異種ノードプールはそれぞれ異なる構成を持ちます。そのため、さまざまなワークロードに合わせてプールを作成し、最適化することが可能です。

異種ノードプールは Agent プラットフォーム上に作成できます。このプラットフォームにより、1 つのホステッドクラスター内で、x86_64ppc64le などのさまざまなマシンタイプをクラスターで実行できるようになります。

異種ノードプールを作成するには、次の一般的な手順を完了する必要があります。

  • データベースやファイルシステムなどのコンポーネントに必要なストレージの量を Operator に通知する AgentServiceConfig カスタムリソース (CR) を作成します。この CR では、どの OpenShift Container Platform バージョンをサポートするかも定義します。
  • エージェントクラスターを作成します。
  • 異種ノードプールを作成します。
  • Hosted Control Plane の DNS を設定します。
  • 各アーキテクチャー用の InfraEnv カスタムリソース (CR) を作成します。
  • 異種クラスターにエージェントを追加します。
4.6.5.1. AgentServiceConfig カスタムリソースの作成

エージェントホステッドクラスターに異種ノードプールを作成するには、2 つの異種アーキテクチャーオペレーティングシステム (OS) イメージを使用して AgentServiceConfig CR を作成する必要があります。

手順

  • 以下のコマンドを実行します。

    $ envsubst <<"EOF" | oc apply -f -
    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
     name: agent
    spec:
      databaseStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <db_volume_name> 
    1
    
      filesystemStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <fs_volume_name> 
    2
    
      osImages:
        - openshiftVersion: <ocp_version> 
    3
    
          version: <ocp_release_version_x86> 
    4
    
          url: <iso_url_x86> 
    5
    
          rootFSUrl: <root_fs_url_x8> 
    6
    
          cpuArchitecture: <arch_x86> 
    7
    
        - openshiftVersion: <ocp_version> 
    8
    
          version: <ocp_release_version_ppc64le> 
    9
    
          url: <iso_url_ppc64le> 
    10
    
          rootFSUrl: <root_fs_url_ppc64le> 
    11
    
          cpuArchitecture: <arch_ppc64le> 
    12
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    multicluster engine for Kubernetes Operator の agentserviceconfig、データベースボリューム名を指定します。
    2
    multicluster engine Operator の agentserviceconfig、ファイルシステムボリューム名を指定します。
    3
    OpenShift Container Platform の現在のバージョンを指定します。
    4
    x86 の現在の OpenShift Container Platform リリースバージョンを指定します。
    5
    x86 の ISO の URL を指定します。
    6
    x86 のルートファイルシステムの URL を指定します。
    7
    x86 の CPU アーキテクチャーを指定します。
    8
    現在の OpenShift Container Platform バージョンを指定します。
    9
    ppc64le の OpenShift Container Platform リリースバージョンを指定します。
    10
    ppc64le の ISO の URL を指定します。
    11
    ppc64le のルートファイルシステムの URL を指定します。
    12
    ppc64le の CPU アーキテクチャーを指定します。
4.6.5.2. エージェントクラスターの作成

エージェントベースのアプローチでは、エージェントクラスターを管理およびプロビジョニングします。エージェントクラスターは、異種ノードプールを使用して、同じクラスター内で異なる種類のコンピュートノードを使用することを可能にします。

前提条件

  • ホステッドクラスターを作成するときに、異種ノードプールのサポートを有効にするために、マルチアーキテクチャーリリースイメージを使用した。最新のマルチアーキテクチャーイメージについては、マルチアーキテクチャーリリースイメージ ページを参照してください。

手順

  1. 次のコマンドを実行して、クラスターの namespace の環境変数を作成します。

    $ export CLUSTERS_NAMESPACE=<hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、マシンの Classless Inter-Domain Routing (CIDR) 表記の環境変数を作成します。

    $ export MACHINE_CIDR=192.168.122.0/24
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、Hosted Control Plane の namespace を作成します。

    $ oc create ns <hosted_control_plane_namespace>
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行してクラスターを作成します。

    $ hcp create cluster agent \
        --name=<hosted_cluster_name> \
    1
    
        --pull-secret=<pull_secret_file> \
    2
    
        --agent-namespace=<hosted_control_plane_namespace> \
    3
    
        --base-domain=<basedomain> \
    4
    
        --api-server-address=api.<hosted_cluster_name>.<basedomain> \
        --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release> 
    5
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスター名を指定します。
    2
    プルシークレットファイルのパスを指定します。
    3
    Hosted Control Plane の namespace を指定します。
    4
    ホステッドクラスターのベースドメインを指定します。
    5
    現在の OpenShift Container Platform リリースバージョンを指定します。
4.6.5.3. 異種ノードプールの作成

NodePool カスタムリソース (CR) を使用して異種ノードプールを作成し、さまざまなワークロードを特定のハードウェアに関連付けることで、コストとパフォーマンスを最適化できます。

手順

  • NodePool CR を定義するには、次の例のような YAML ファイルを作成します。

    envsubst <<"EOF" | oc apply -f -
    apiVersion:apiVersion: hypershift.openshift.io/v1beta1
    kind: NodePool
    metadata:
      name: <hosted_cluster_name>
      namespace: <clusters_namespace>
    spec:
      arch: <arch_ppc64le>
      clusterName: <hosted_cluster_name>
      management:
        autoRepair: false
        upgradeType: InPlace
      nodeDrainTimeout: 0s
      nodeVolumeDetachTimeout: 0s
      platform:
        agent:
          agentLabelSelector:
            matchLabels:
              inventory.agent-install.openshift.io/cpu-architecture: <arch_ppc64le> 
    1
    
        type: Agent
      release:
        image: quay.io/openshift-release-dev/ocp-release:<ocp_release>
      replicas: 0
    EOF
    Copy to Clipboard Toggle word wrap
    1
    セレクターブロックは、指定されたラベルに一致するエージェントを選択します。レプリカ数ゼロで ppc64le アーキテクチャーのノードプールを作成するには、ppc64le を指定します。これにより、スケーリング操作時に、セレクターブロックが ppc64le アーキテクチャーのエージェントのみを選択するようになります。
4.6.5.4. Hosted Control Plane の DNS 設定

Hosted Control Plane のドメインネームサービス (DNS) 設定の目的は、外部クライアントが Ingress コントローラーにアクセスして、トラフィックを内部コンポーネントにルーティングできるようにすることです。この設定を指定すると、トラフィックが ppc64le または x86_64 コンピュートノードのいずれかにルーティングされるようになります。

*.apps.<cluster_name> レコードを、Ingress アプリケーションをホストするいずれかのコンピュートノードに向けることができます。または、コンピュートノード群の上にロードバランサーをセットアップできる場合は、レコードをこのロードバランサーに向けます。異種ノードプールを作成するときは、コンピュートノードが相互にアクセスできることを確認するか、同じネットワーク内に保持してください。

4.6.5.5. インフラストラクチャー環境リソースの作成

異種ノードプールの場合は、各アーキテクチャー用の infraEnv カスタムリソース (CR) を作成する必要があります。この設定により、ノードのプロビジョニングプロセス中に、アーキテクチャー固有の正しいオペレーティングシステムとブートアーティファクトが確実に使用されます。たとえば、x86_64 および ppc64le アーキテクチャーのノードプールの場合は、x86_64 および ppc64le 用の InfraEnv CR を作成します。

注記

手順を開始する前に、x86_64ppc64le アーキテクチャーの両方のオペレーティングシステムイメージを AgentServiceConfig リソースに追加してください。追加したら、InfraEnv リソースを使用して最小限の ISO イメージを取得できます。

手順

  1. 次のコマンドを実行して、異種ノードプール用の x86_64 アーキテクチャーの InfraEnv リソースを作成します。

    $ envsubst <<"EOF" | oc apply -f -
    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: <hosted_cluster_name>-<arch_x86> 
    1
     
    2
    
      namespace: <hosted_control_plane_namespace> 
    3
    
    spec:
      cpuArchitecture: <arch_x86>
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: <ssh_pub_key> 
    4
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前。
    2
    x86_64 アーキテクチャー。
    3
    Hosted Control Plane の namespace。
    4
    SSH 公開鍵。
  2. 次のコマンドを実行して、異種ノードプール用の ppc64le アーキテクチャーの InfraEnv リソースを作成します。

    envsubst <<"EOF" | oc apply -f -
    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: <hosted_cluster_name>-<arch_ppc64le> 
    1
     
    2
    
      namespace: <hosted_control_plane_namespace> 
    3
    
    spec:
      cpuArchitecture: <arch_ppc64le>
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: <ssh_pub_key> 
    4
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前。
    2
    ppc64le アーキテクチャー。
    3
    Hosted Control Plane の namespace。
    4
    SSH 公開鍵。
  3. 次のコマンドを実行して、InfraEnv リソースが正常に作成されたことを確認します。

    • x86_64 InfraEnv リソースが正常に作成されたことを確認します。

      $ oc describe InfraEnv <hosted_cluster_name>-<arch_x86>
      Copy to Clipboard Toggle word wrap
    • ppc64le InfraEnv リソースが正常に作成されたことを確認します。

      $ oc describe InfraEnv <hosted_cluster_name>-<arch_ppc64le>
      Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、仮想マシンまたはベアメタルマシンのいずれかがエージェントとして参加することを可能にするライブ ISO を生成します。

    1. x86_64 用のライブ ISO を生成します。

      $ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_x86> -ojsonpath="{.status.isoDownloadURL}"
      Copy to Clipboard Toggle word wrap
    2. ppc64le 用のライブ ISO を生成します。

      $ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_ppc64le> -ojsonpath="{.status.isoDownloadURL}"
      Copy to Clipboard Toggle word wrap
4.6.5.6. 異種クラスターへのエージェントの追加

エージェントを追加するには、ライブ ISO を使用して起動するようにマシンを手動で設定します。ライブ ISO をダウンロードし、それを使用してベアメタルノードまたは仮想マシンを起動できます。ノードは起動時に assisted-service と通信し、InfraEnv リソースと同じ namespace にエージェントとして登録されます。各エージェントの作成後、必要に応じて、仕様で installation_disk_id および hostname パラメーターを設定できます。その後、エージェントを承認して、エージェントを使用する準備が完了していることを示すことができます。

手順

  1. 次のコマンドを実行してエージェントのリストを取得します。

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
    86f7ac75-4fc4-4b36-8130-40fa12602218                        auto-assign
    e57a637f-745b-496e-971d-1abbf03341ba                        auto-assign
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、1 つのエージェントにパッチを適用します。

    $ oc -n <hosted_control_plane_namespace> patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type merge
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、2 番目のエージェントにパッチを適用します。

    $ oc -n <hosted_control_plane_namespace> patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type merge
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、エージェントの承認ステータスを確認します。

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
    86f7ac75-4fc4-4b36-8130-40fa12602218             true       auto-assign
    e57a637f-745b-496e-971d-1abbf03341ba             true       auto-assign
    Copy to Clipboard Toggle word wrap

4.6.5.7. ノードプールのスケーリング

エージェントを承認したら、ノードプールをスケーリングできます。ノードプールに設定した agentLabelSelector 値により、条件に一致するエージェントだけが確実にクラスターに追加されます。これはノードプールのスケールダウンにも役立ちます。クラスターから特定のアーキテクチャーのノードを削除するには、対応するノードプールをスケールダウンします。

手順

  • 次のコマンドを実行してノードプールをスケーリングします。

    $ oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
    Copy to Clipboard Toggle word wrap
    注記

    Cluster API エージェントプロバイダーは、2 つのエージェントをランダムに選択してホステッドクラスターに割り当てます。これらのエージェントはさまざまな状態を経て、OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントの状態には、bindingdiscoveringinsufficientinstallinginstalling-in-progressadded-to-existing-cluster などがあります。

検証

  1. 次のコマンドを実行してエージェントをリスト表示します。

    $ oc -n <hosted_control_plane_namespace> get agent
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER         APPROVED   ROLE          STAGE
    4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign
    d9198891-39f4-4930-a679-65fb142b108b                   true       auto-assign
    da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、スケーリングした特定のエージェントのステータスを確認します。

    $ oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    出力例

    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
    BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
    BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
    Copy to Clipboard Toggle word wrap

  3. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを実行して、OpenShift Container Platform ノードの準備ができていることを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME           STATUS   ROLES    AGE     VERSION
    ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
    ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

  4. ノードにワークロードが追加されると、一部のクラスター Operator がリコンサイルされることがあります。次のコマンドを実行すると、ノードプールをスケールアップした後に 2 台のマシンが作成されたことが表示されます。

    $ oc -n <hosted_control_plane_namespace> get machines
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
    hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.11.5
    hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.11.5
    Copy to Clipboard Toggle word wrap

4.7. OpenStack への Hosted Control Plane のデプロイ

重要

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

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

Red Hat OpenStack Platform (RHOSP) 17.1 上で動作するホステッドクラスターを使用して Hosted Control Plane をデプロイできます。

ホステッドクラスター は、API エンドポイントとコントロールプレーンが管理クラスターでホストされている OpenShift Container Platform クラスターです。Hosted Control Plane では、コントロールプレーンは管理クラスター上の Pod として存在します。各コントロールプレーンに専用の仮想マシンまたは物理マシンを用意する必要はありません。

4.7.1. OpenStack の前提条件

Red Hat OpenStack Platform (RHOSP) 上にホステッドクラスターを作成する前に、次の要件を満たしていることを確認してください。

  • OpenShift Container Platform 管理クラスターバージョン 4.17 以降への管理アクセス権がある。このクラスターを、ベアメタル、RHOSP、またはサポートされているパブリッククラウド上で実行できる。
  • HyperShift Operator が、「Hosted Control Plane のデプロイの準備」で指定されているとおりに、管理クラスターにインストールされている。
  • 管理クラスターが、デフォルトの Pod ネットワーク CNI である OVN-Kubernetes を使用して設定されています。
  • OpenShift CLI (oc) と Hosted Control Plane CLI、hcp がインストールされている。
  • ロードバランサーバックエンド (Octavia など) が OCP 管理クラスターにインストールされている。各ホステッドクラスターに対して kube-api サービスを作成するために、ロードバランサーが必要です。

    • Ingress が Octavia ロードバランスを使用して設定されている場合は、RHOSP Octavia サービスがゲストクラスターをホストするクラウドで実行されている。
  • quay.io/openshift-release-dev リポジトリーに有効な プルシークレット ファイルが存在する。
  • 管理クラスターのデフォルトの外部ネットワークに、ゲストクラスターから到達できる。このネットワーク上に、kube-apiserver ロードバランサータイプのサービスが作成されている。
  • Ingress に事前定義された Floating IP アドレスを使用する場合は、ワイルドカードドメイン *.apps.<cluster_name>.<base_domain> に対して、このドメインを指す DNS レコードを作成した。

    • <cluster_name> は、管理クラスターの名前です。
    • <base_domain> は、クラスターのアプリケーションが存在する親 DNS ドメインです。

4.7.2. etcd ローカルストレージ用の管理クラスターの準備

Red Hat OpenStack Platform (RHOSP) 上の Hosted Control Plane (HCP) デプロイメントでは、デフォルトの Cinder ベースの Persistent Volume Claim (PVC) を使用する代わりに、TopoLVM CSI ドライバーによってプロビジョニングされるローカルの一時ストレージを使用することで、etcd のパフォーマンスを向上できます。

前提条件

  • HyperShift がインストールされた管理クラスターにアクセスできる。
  • RHOSP フレーバーとマシンセットを作成および管理できる。
  • oc および openstack CLI ツールがインストールおよび設定されている。
  • TopoLVM および論理ボリュームマネージャー (LVM) ストレージの概念に精通している。
  • 管理クラスターに LVM Storage Operator をインストールした。詳細は、OpenShift Container Platform ドキュメントの「ストレージ」セクションにある「CLI を使用した LVM Storage のインストール」を参照してください。

手順

  1. openstack CLI を使用して、追加の一時ディスクを含む Nova フレーバーを作成します。以下に例を示します。

    $ openstack flavor create \
      --id auto \
      --ram 8192 \
      --disk 0 \
      --ephemeral 100 \
      --vcpus 4 \
      --public \
      hcp-etcd-ephemeral
    Copy to Clipboard Toggle word wrap
    注記

    Nova は、そのフレーバーを使用してサーバーが作成されると、一時ディスクをインスタンスに自動的に接続し、それを vfat としてフォーマットします。

  2. 新しいフレーバーを使用するコンピュートマシンセットを作成します。詳細は、OpenShift Container Platform ドキュメントの「OpenStack でコンピュートマシンセットを作成する」を参照してください。
  3. 要件に合わせてマシンセットをスケーリングします。高可用性のためにクラスターをデプロイする場合は、Pod を適切に分散できるように、少なくとも 3 つのワーカーをデプロイする必要があります。
  4. 新しいワーカーノードにラベルを付けて、etcd 用であることを識別できるようにします。以下に例を示します。

    $ oc label node <node_name> hypershift-capable=true
    Copy to Clipboard Toggle word wrap

    このラベルは任意であり、後で更新できます。

  5. lvmcluster.yaml という名前のファイルで、etcd のローカルストレージ設定のために、次の LVMCluster カスタムリソースを作成します。

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: etcd-hcp
      namespace: openshift-storage
    spec:
      storage:
        deviceClasses:
        - name: etcd-class
          default: true
          nodeSelector:
             nodeSelectorTerms:
             - matchExpressions:
               - key: hypershift-capable
                operator: In
                values:
                - "true"
          deviceSelector:
            forceWipeDevicesAndDestroyAllData: true
            paths:
            - /dev/vdb
    Copy to Clipboard Toggle word wrap

    このリソースの例について:

    • 一時ディスクの場所は /dev/vdb です。ほとんどの場合、この場所が使用されます。実際の環境でこの場所が正しいことを確認してください。シンボリックリンクはサポートされていないことに注意してください。
    • デフォルトの Nova 一時ディスクは VFAT でフォーマットされているため、パラメーター forceWipeDevicesAndDestroyAllDataTrue 値に設定されています。
  6. 次のコマンドを実行して、LVMCluster リソースを適用します。

    oc apply -f lvmcluster.yaml
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、LVMCluster リソースを確認します。

    $ oc get lvmcluster -A
    Copy to Clipboard Toggle word wrap

    出力例

    NAMESPACE           NAME    STATUS
    openshift-storage   etcd-hcp   Ready
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを実行して、StorageClass リソースを確認します。

    $ oc get storageclass
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                    PROVISIONER               RECLAIMPOLICY   VOLUMEBINDINGMODE     ALLOWVOLUMEEXPANSION   AGE
    lvms-etcd-class         topolvm.io                Delete          WaitForFirstConsumer  true                   23m
    standard-csi (default)  cinder.csi.openstack.org  Delete          WaitForFirstConsumer  true                   56m
    Copy to Clipboard Toggle word wrap

これで、パフォーマンスの高い etcd 設定を使用してホステッドクラスターをデプロイできるようになりました。デプロイメントプロセスについては、「OpenStack 上でのホステッドクラスターの作成」で説明されています。

4.7.3. Ingress 用の Floating IP の作成

手動による介入なしでホステッドクラスターで Ingress を利用できるようにする場合は、事前に Floating IP アドレスを作成できます。

前提条件

  • Red Hat OpenStack Platform (RHOSP) クラウドにアクセスできる。
  • Ingress に事前定義された Floating IP アドレスを使用する場合は、ワイルドカードドメイン *.apps.<cluster_name>.<base_domain> に対して、このドメインを指す DNS レコードを作成した。

    • <cluster_name> は、管理クラスターの名前です。
    • <base_domain> は、クラスターのアプリケーションが存在する親 DNS ドメインです。

手順

  • 次のコマンドを実行して、Floating IP アドレスを作成します。

    $ openstack floating ip create <external_network_id>
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <external_network_id>
    外部ネットワークの ID を指定します。
注記

Floating IP アドレスを事前に作成せずに、--openstack-ingress-floating-ip フラグを使用して Floating IP アドレスを指定すると、cloud-provider-openstack コンポーネントがそれを自動的に作成しようとします。このプロセスは、特定の IP アドレスを使用した Floating IP アドレスの作成が Neutron API ポリシーで許可されている場合にのみ、正常に実行されます。

4.7.4. OpenStack への RHCOS イメージのアップロード

Hosted Control Plane および Red Hat OpenStack Platform (RHOSP) デプロイメントでノードプールをデプロイするときに使用する RHCOS イメージを指定する場合は、イメージを RHOSP クラウドにアップロードします。イメージをアップロードしない場合、OpenStack Resource Controller (ORC) は OpenShift Container Platform ミラーからイメージをダウンロードし、ホステッドクラスターが削除された後にイメージを削除します。

前提条件

  • OpenShift Container Platform ミラーから RHCOS イメージをダウンロードした。
  • RHOSP クラウドにアクセスできる。

手順

  • 次のコマンドを実行して、RHCOS イメージを RHOSP にアップロードします。

    $ openstack image create --disk-format qcow2 --file <image_file_name> rhcos
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <image_file_name>
    RHCOS イメージのファイル名を指定します。

4.7.5. OpenStack 上でのホステッドクラスターの作成

hcp CLI を使用して、Red Hat OpenStack Platform (RHOSP) 上にホステッドクラスターを作成できます。

前提条件

  • 「Hosted Control Plane のデプロイの準備」の前提条件の手順をすべて完了した。
  • 「OpenStack の前提条件」を確認した。
  • 「etcd ローカルストレージ用の管理クラスターの準備」の手順をすべて完了した。
  • 管理クラスターにアクセスできる。
  • RHOSP クラウドにアクセスできる。

手順

  • hcp create コマンドを実行してホステッドクラスターを作成します。たとえば、「etcd ローカルストレージ用の管理クラスターの準備」で詳しく説明されているパフォーマンスの高い etcd 設定を活用するクラスターの場合は、次のように入力します。

    $ hcp create cluster openstack \
      --name my-hcp-cluster \
      --openstack-node-flavor m1.xlarge \
      --base-domain example.com \
      --pull-secret /path/to/pull-secret.json \
      --release-image quay.io/openshift-release-dev/ocp-release:4.19.0-x86_64 \
      --node-pool-replicas 3 \
      --etcd-storage-class lvms-etcd-class
    Copy to Clipboard Toggle word wrap
注記

クラスターの作成時には多くのオプションが利用できます。RHOSP 固有のオプションについては、「OpenStack 上で Hosted Control Plane クラスターを作成するためのオプション」を参照してください。一般的なオプションについては、hcp のドキュメントを参照してください。

検証

  1. 次のコマンドを実行して、ホステッドクラスターの準備ができていることを確認します。

    $ oc -n clusters-<cluster_name> get pods
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <cluster_name>
    クラスターの名前を指定します。

    数分後、出力に Hosted Control Plane Pod が実行中であることが表示されます。

    出力例

    NAME                                                  READY   STATUS    RESTARTS   AGE
    capi-provider-5cc7b74f47-n5gkr                        1/1     Running   0          3m
    catalog-operator-5f799567b7-fd6jw                     2/2     Running   0          69s
    certified-operators-catalog-784b9899f9-mrp6p          1/1     Running   0          66s
    cluster-api-6bbc867966-l4dwl                          1/1     Running   0          66s
    ...
    ...
    ...
    redhat-operators-catalog-9d5fd4d44-z8qqk              1/1     Running   0
    Copy to Clipboard Toggle word wrap

  2. クラスターの etcd 設定を検証するには、次の手順を実行します。

    1. 次のコマンドを実行して、etcd 永続ボリューム要求 (PVC) を検証します。

      $ oc get pvc -A
      Copy to Clipboard Toggle word wrap
    2. Hosted Control Plane の etcd Pod 内で、次のコマンドを実行してマウントパスとデバイスを確認します。

      $ df -h /var/lib
      Copy to Clipboard Toggle word wrap
注記

クラスター API (CAPI) プロバイダーが作成する RHOSP リソースには、openshiftClusterID=<infraID> というラベルでタグ付けされます。

ホステッドクラスターの作成に使用する YAML マニフェストの HostedCluster.Spec.Platform.OpenStack.Tags フィールドに値を指定すると、このリソースに追加のタグを定義できます。ノードプールをスケールアップすると、タグがリソースに適用されます。

4.7.5.1. OpenStack 上で Hosted Control Plane クラスターを作成するためのオプション

Red Hat OpenStack Platform (RHOSP) に Hosted Control Plane クラスターをデプロイするときに、hcp CLI にいくつかのオプションを指定できます。

Expand
オプション説明必須

--openstack-ca-cert-file

OpenStack CA 証明書ファイルへのパス。指定されていない場合は、clouds.yaml のクラウドエントリーから自動的に抽出されます。

いいえ

--openstack-cloud

clouds.yaml 内のクラウドエントリーの名前。デフォルト値は openstack です。

いいえ

--openstack-credentials-file

OpenStack 認証情報ファイルへのパス。指定されていない場合は、hcp によって次のディレクトリーが検索されます。

  • 現在の作業ディレクトリー
  • $HOME/.config/openstack
  • /etc/openstack

いいえ

--openstack-dns-nameservers

サブネットの作成時に提供される DNS サーバーアドレスのリスト。

いいえ

--openstack-external-network-id

OpenStack 外部ネットワークの ID。

いいえ

--openstack-ingress-floating-ip

OpenShift Ingress の Floating IP。

いいえ

--openstack-node-additional-port

ノードに割り当てる追加ポート。有効な値は、network-idvnic-typedisable-port-securityaddress-pairs です。

いいえ

--openstack-node-availability-zone

ノードプールのアベイラビリティーゾーン。

いいえ

--openstack-node-flavor

ノードプールのフレーバー。

はい

--openstack-node-image-name

ノードプールのイメージ名。

いいえ

第5章 Hosted Control Plane の管理

5.1. AWS での Hosted Control Plane の管理

Amazon Web Services (AWS) 上の OpenShift Container Platform に Hosted Control Plane を使用する場合、セットアップに応じてインフラストラクチャーの要件が異なります。

5.1.1. AWS インフラストラクチャーと IAM 権限を管理するための前提条件

Amazon Web Services (AWS) 上の OpenShift Container Platform の Hosted Control Plane を設定するには、次のインフラストラクチャー要件を満たす必要があります。

  • ホステッドクラスターを作成する前に、Hosted Control Plane を設定した。
  • AWS Identity and Access Management (IAM) ロールと AWS Security Token Service (STS) 認証情報を作成した。
5.1.1.1. AWS のインフラストラクチャー要件

Amazon Web Services (AWS) で Hosted Control Plane を使用する場合、インフラストラクチャー要件は次のカテゴリーに当てはまります。

  • 任意の AWS アカウント内の、HyperShift Operator 用の事前に必要な管理対象外インフラストラクチャー
  • ホステッドクラスターの AWS アカウント内の事前に必要な管理対象外インフラストラクチャー
  • 管理 AWS アカウント内の Hosted Control Plane によって管理されるインフラストラクチャー
  • ホステッドクラスターの AWS アカウント内の Hosted Control Plane によって管理されるインフラストラクチャー
  • ホステッドクラスターの AWS アカウント内の Kubernetes によって管理されるインフラストラクチャー

事前に必要とは、Hosted Control Plane を適切に動作させるために AWS インフラストラクチャーが必要であることを意味します。管理対象外とは、Operator やコントローラーによってインフラストラクチャーが作成されないことを意味します。

5.1.1.2. AWS アカウント内の HyperShift Operator 用の管理対象外インフラストラクチャー

任意の Amazon Web Services (AWS) アカウントは、Hosted Control Plane サービスのプロバイダーによって異なります。

セルフマネージドの Hosted Control Plane では、クラスターサービスプロバイダーが AWS アカウントを制御します。クラスターサービスプロバイダーは、クラスターコントロールプレーンをホストし、稼働時間の責任を負う管理者です。マネージドの Hosted Control Plane では、AWS アカウントは Red Hat に属します。

HyperShift Operator 用の事前に必要な管理対象外のインフラストラクチャーでは、管理クラスター AWS アカウントに次のインフラストラクチャー要件が適用されます。

  • 1 つの S3 バケット

    • OpenID Connect (OIDC)
  • ルート 53 のホステッドゾーン

    • ホステッドクラスターのプライベートおよびパブリックエントリーをホストするドメイン
5.1.1.3. 管理 AWS アカウントの管理対象外インフラストラクチャーの要件

インフラストラクチャーが事前に必要であり、ホステッドクラスターの AWS アカウントで管理されていない場合、すべてのアクセスモードのインフラストラクチャー要件は次のとおりです。

  • 1 つの VPC
  • 1 つの DHCP オプション
  • 2 つのサブネット

    • 内部データプレーンサブネットであるプライベートサブネット
    • データプレーンからインターネットへのアクセスを可能にするパブリックサブネット
  • 1 つのインターネットゲートウェイ
  • 1 つの Elastic IP
  • 1 つの NAT ゲートウェイ
  • 1 つのセキュリティーグループ (ワーカーノード)
  • 2 つのルートテーブル (1 つはプライベート、もう 1 つはパブリック)
  • 2 つの Route 53 のホステッドゾーン
  • 次の項目に対する十分なクォータ:

    • パブリックホステッドクラスター用の 1 つの Ingress サービスロードバランサー
    • プライベートホステッドクラスター用の 1 つのプライベートリンクエンドポイント
注記

プライベートリンクネットワークが機能するには、ホステッドクラスターの AWS アカウントのエンドポイントゾーンが、管理クラスターの AWS アカウントのサービスエンドポイントによって解決されるインスタンスのゾーンと同じである必要があります。AWS では、ゾーン名は us-east-2b などのエイリアスであり、必ずしも異なるアカウントの同じゾーンにマップされるわけではありません。そのため、プライベートリンクが機能するには、管理クラスターのリージョンのすべてのゾーンにサブネットまたはワーカーが必要です。

5.1.1.4. 管理 AWS アカウントのインフラストラクチャーの要件

インフラストラクチャーが管理 AWS アカウントの Hosted Control Plane によって管理されている場合、インフラストラクチャーの要件は、クラスターがパブリック、プライベート、またはその組み合わせであるかによって異なります。

パブリッククラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • ネットワークロードバランサー: ロードバランサー Kube API サーバー

    • Kubernetes がセキュリティーグループを作成する
  • ボリューム

    • etcd 用 (高可用性に応じて 1 つまたは 3 つ)
    • OVN-Kube 用

プライベートクラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • ネットワークロードバランサー: ロードバランサーのプライベートルーター
  • エンドポイントサービス (プライベートリンク)

パブリッククラスターとプライベートクラスターを持つアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • ネットワークロードバランサー: ロードバランサーのパブリックルーター
  • ネットワークロードバランサー: ロードバランサーのプライベートルーター
  • エンドポイントサービス (プライベートリンク)
  • ボリューム

    • etcd 用 (高可用性に応じて 1 つまたは 3 つ)
    • OVN-Kube 用
5.1.1.5. ホステッドクラスターの AWS アカウントのインフラストラクチャー要件

インフラストラクチャーがホステッドクラスターの Amazon Web Services (AWS) アカウントの Hosted Control Plane によって管理されている場合、インフラストラクチャーの要件は、クラスターがパブリック、プライベート、またはその組み合わせであるかによって異なります。

パブリッククラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • ノードプールには、RoleRolePolicy が定義された EC2 インスタンスが必要です。

プライベートクラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • アベイラビリティーゾーンごとに 1 つのプライベートリンクエンドポイント
  • ノードプールの EC2 インスタンス

パブリッククラスターとプライベートクラスターを持つアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • アベイラビリティーゾーンごとに 1 つのプライベートリンクエンドポイント
  • ノードプールの EC2 インスタンス

ホステッドクラスターの Amazon Web Services (AWS) アカウント内のインフラストラクチャーを Kubernetes によって管理する場合、インフラストラクチャーの要件は次のとおりです。

  • デフォルトの Ingress 用のネットワークロードバランサー
  • レジストリー用の S3 バケット

5.1.2. Identity and Access Management (IAM) 権限

Hosted Control Plane のコンテキストでは、コンシューマーが Amazon Resource Name (ARN) ロールを作成する役割を果たします。コンシューマー は、権限ファイルを生成するための自動プロセスです。コンシューマーは CLI または OpenShift Cluster Manager である場合があります。Hosted Control Plane では、最小権限コンポーネントの原則を遵守するための詳細な設定が可能です。そのため、すべてのコンポーネントが独自のロールを使用して Amazon Web Services (AWS) オブジェクトを操作または作成します。ロールは、製品が正常に機能するために必要なものに制限されます。

ホステッドクラスターは ARN ロールを入力として受け取り、コンシューマーは各コンポーネントの AWS 権限設定を作成します。その結果、コンポーネントは STS および事前設定された OIDC IDP を通じて認証できるようになります。

次のロールは、コントロールプレーン上で実行され、データプレーン上で動作する、Hosted Control Plane の一部のコンポーネントによって消費されます。

  • controlPlaneOperatorARN
  • imageRegistryARN
  • ingressARN
  • kubeCloudControllerARN
  • nodePoolManagementARN
  • storageARN
  • networkARN

次の例は、ホステッドクラスターからの IAM ロールへの参照を示しています。

...
endpointAccess: Public
  region: us-east-2
  resourceTags:
  - key: kubernetes.io/cluster/example-cluster-bz4j5
    value: owned
rolesRef:
    controlPlaneOperatorARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-control-plane-operator
    imageRegistryARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-openshift-image-registry
    ingressARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-openshift-ingress
    kubeCloudControllerARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-cloud-controller
    networkARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-cloud-network-config-controller
    nodePoolManagementARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-node-pool
    storageARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-aws-ebs-csi-driver-controller
type: AWS
...
Copy to Clipboard Toggle word wrap

Hosted Control Plane が使用するロールを次の例に示します。

  • ingressARN

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "elasticloadbalancing:DescribeLoadBalancers",
                    "tag:GetResources",
                    "route53:ListHostedZones"
                ],
                "Resource": "\*"
            },
            {
                "Effect": "Allow",
                "Action": [
                    "route53:ChangeResourceRecordSets"
                ],
                "Resource": [
                    "arn:aws:route53:::PUBLIC_ZONE_ID",
                    "arn:aws:route53:::PRIVATE_ZONE_ID"
                ]
            }
        ]
    }
    Copy to Clipboard Toggle word wrap
  • imageRegistryARN

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:CreateBucket",
                    "s3:DeleteBucket",
                    "s3:PutBucketTagging",
                    "s3:GetBucketTagging",
                    "s3:PutBucketPublicAccessBlock",
                    "s3:GetBucketPublicAccessBlock",
                    "s3:PutEncryptionConfiguration",
                    "s3:GetEncryptionConfiguration",
                    "s3:PutLifecycleConfiguration",
                    "s3:GetLifecycleConfiguration",
                    "s3:GetBucketLocation",
                    "s3:ListBucket",
                    "s3:GetObject",
                    "s3:PutObject",
                    "s3:DeleteObject",
                    "s3:ListBucketMultipartUploads",
                    "s3:AbortMultipartUpload",
                    "s3:ListMultipartUploadParts"
                ],
                "Resource": "\*"
            }
        ]
    }
    Copy to Clipboard Toggle word wrap
  • storageARN

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:AttachVolume",
                    "ec2:CreateSnapshot",
                    "ec2:CreateTags",
                    "ec2:CreateVolume",
                    "ec2:DeleteSnapshot",
                    "ec2:DeleteTags",
                    "ec2:DeleteVolume",
                    "ec2:DescribeInstances",
                    "ec2:DescribeSnapshots",
                    "ec2:DescribeTags",
                    "ec2:DescribeVolumes",
                    "ec2:DescribeVolumesModifications",
                    "ec2:DetachVolume",
                    "ec2:ModifyVolume"
                ],
                "Resource": "\*"
            }
        ]
    }
    Copy to Clipboard Toggle word wrap
  • networkARN

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:DescribeInstances",
                    "ec2:DescribeInstanceStatus",
                    "ec2:DescribeInstanceTypes",
                    "ec2:UnassignPrivateIpAddresses",
                    "ec2:AssignPrivateIpAddresses",
                    "ec2:UnassignIpv6Addresses",
                    "ec2:AssignIpv6Addresses",
                    "ec2:DescribeSubnets",
                    "ec2:DescribeNetworkInterfaces"
                ],
                "Resource": "\*"
            }
        ]
    }
    Copy to Clipboard Toggle word wrap
  • kubeCloudControllerARN

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": [
                    "ec2:DescribeInstances",
                    "ec2:DescribeImages",
                    "ec2:DescribeRegions",
                    "ec2:DescribeRouteTables",
                    "ec2:DescribeSecurityGroups",
                    "ec2:DescribeSubnets",
                    "ec2:DescribeVolumes",
                    "ec2:CreateSecurityGroup",
                    "ec2:CreateTags",
                    "ec2:CreateVolume",
                    "ec2:ModifyInstanceAttribute",
                    "ec2:ModifyVolume",
                    "ec2:AttachVolume",
                    "ec2:AuthorizeSecurityGroupIngress",
                    "ec2:CreateRoute",
                    "ec2:DeleteRoute",
                    "ec2:DeleteSecurityGroup",
                    "ec2:DeleteVolume",
                    "ec2:DetachVolume",
                    "ec2:RevokeSecurityGroupIngress",
                    "ec2:DescribeVpcs",
                    "elasticloadbalancing:AddTags",
                    "elasticloadbalancing:AttachLoadBalancerToSubnets",
                    "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
                    "elasticloadbalancing:CreateLoadBalancer",
                    "elasticloadbalancing:CreateLoadBalancerPolicy",
                    "elasticloadbalancing:CreateLoadBalancerListeners",
                    "elasticloadbalancing:ConfigureHealthCheck",
                    "elasticloadbalancing:DeleteLoadBalancer",
                    "elasticloadbalancing:DeleteLoadBalancerListeners",
                    "elasticloadbalancing:DescribeLoadBalancers",
                    "elasticloadbalancing:DescribeLoadBalancerAttributes",
                    "elasticloadbalancing:DetachLoadBalancerFromSubnets",
                    "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
                    "elasticloadbalancing:ModifyLoadBalancerAttributes",
                    "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
                    "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
                    "elasticloadbalancing:AddTags",
                    "elasticloadbalancing:CreateListener",
                    "elasticloadbalancing:CreateTargetGroup",
                    "elasticloadbalancing:DeleteListener",
                    "elasticloadbalancing:DeleteTargetGroup",
                    "elasticloadbalancing:DescribeListeners",
                    "elasticloadbalancing:DescribeLoadBalancerPolicies",
                    "elasticloadbalancing:DescribeTargetGroups",
                    "elasticloadbalancing:DescribeTargetHealth",
                    "elasticloadbalancing:ModifyListener",
                    "elasticloadbalancing:ModifyTargetGroup",
                    "elasticloadbalancing:RegisterTargets",
                    "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
                    "iam:CreateServiceLinkedRole",
                    "kms:DescribeKey"
                ],
                "Resource": [
                    "\*"
                ],
                "Effect": "Allow"
            }
        ]
    }
    Copy to Clipboard Toggle word wrap
  • nodePoolManagementARN

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": [
                    "ec2:AllocateAddress",
                    "ec2:AssociateRouteTable",
                    "ec2:AttachInternetGateway",
                    "ec2:AuthorizeSecurityGroupIngress",
                    "ec2:CreateInternetGateway",
                    "ec2:CreateNatGateway",
                    "ec2:CreateRoute",
                    "ec2:CreateRouteTable",
                    "ec2:CreateSecurityGroup",
                    "ec2:CreateSubnet",
                    "ec2:CreateTags",
                    "ec2:DeleteInternetGateway",
                    "ec2:DeleteNatGateway",
                    "ec2:DeleteRouteTable",
                    "ec2:DeleteSecurityGroup",
                    "ec2:DeleteSubnet",
                    "ec2:DeleteTags",
                    "ec2:DescribeAccountAttributes",
                    "ec2:DescribeAddresses",
                    "ec2:DescribeAvailabilityZones",
                    "ec2:DescribeImages",
                    "ec2:DescribeInstances",
                    "ec2:DescribeInternetGateways",
                    "ec2:DescribeNatGateways",
                    "ec2:DescribeNetworkInterfaces",
                    "ec2:DescribeNetworkInterfaceAttribute",
                    "ec2:DescribeRouteTables",
                    "ec2:DescribeSecurityGroups",
                    "ec2:DescribeSubnets",
                    "ec2:DescribeVpcs",
                    "ec2:DescribeVpcAttribute",
                    "ec2:DescribeVolumes",
                    "ec2:DetachInternetGateway",
                    "ec2:DisassociateRouteTable",
                    "ec2:DisassociateAddress",
                    "ec2:ModifyInstanceAttribute",
                    "ec2:ModifyNetworkInterfaceAttribute",
                    "ec2:ModifySubnetAttribute",
                    "ec2:ReleaseAddress",
                    "ec2:RevokeSecurityGroupIngress",
                    "ec2:RunInstances",
                    "ec2:TerminateInstances",
                    "tag:GetResources",
                    "ec2:CreateLaunchTemplate",
                    "ec2:CreateLaunchTemplateVersion",
                    "ec2:DescribeLaunchTemplates",
                    "ec2:DescribeLaunchTemplateVersions",
                    "ec2:DeleteLaunchTemplate",
                    "ec2:DeleteLaunchTemplateVersions"
                ],
                "Resource": [
                    "\*"
                ],
                "Effect": "Allow"
            },
            {
                "Condition": {
                    "StringLike": {
                        "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com"
                    }
                },
                "Action": [
                    "iam:CreateServiceLinkedRole"
                ],
                "Resource": [
                    "arn:*:iam::*:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing"
                ],
                "Effect": "Allow"
            },
            {
                "Action": [
                    "iam:PassRole"
                ],
                "Resource": [
                    "arn:*:iam::*:role/*-worker-role"
                ],
                "Effect": "Allow"
            }
        ]
    }
    Copy to Clipboard Toggle word wrap
  • controlPlaneOperatorARN

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:CreateVpcEndpoint",
                    "ec2:DescribeVpcEndpoints",
                    "ec2:ModifyVpcEndpoint",
                    "ec2:DeleteVpcEndpoints",
                    "ec2:CreateTags",
                    "route53:ListHostedZones"
                ],
                "Resource": "\*"
            },
            {
                "Effect": "Allow",
                "Action": [
                    "route53:ChangeResourceRecordSets",
                    "route53:ListResourceRecordSets"
                ],
                "Resource": "arn:aws:route53:::%s"
            }
        ]
    }
    Copy to Clipboard Toggle word wrap

5.1.3. AWS インフラストラクチャーと IAM リソースを個別に作成する

デフォルトでは、hcp create cluster aws コマンドは、クラウドインフラストラクチャーをホステッドクラスターとともに作成し、それを適用します。hcp create cluster aws コマンドを使用してクラスターの作成だけを実行したり、クラスターを生成して適用する前に変更したりできるように、クラウドインフラストラクチャー部分を個別に作成することもできます。

クラウドインフラストラクチャー部分を個別に作成するには、Amazon Web Services (AWS) インフラストラクチャーの作成、AWS Identity and Access (IAM) リソースの作成、およびクラスターの作成を行う必要があります。

5.1.3.1. AWS インフラストラクチャーを個別に作成する

Amazon Web Services (AWS) インフラストラクチャーを作成するには、クラスター用の Virtual Private Cloud (VPC) やその他のリソースを作成する必要があります。AWS コンソールまたはインフラストラクチャー自動化およびプロビジョニングツールを使用できます。AWS コンソールの使用手順は、AWS ドキュメントの Create a VPC plus other VPC resources を参照してください。

VPC には、プライベートサブネットとパブリックサブネット、およびネットワークアドレス変換 (NAT) ゲートウェイやインターネットゲートウェイなどの外部アクセス用のリソースが含まれている必要があります。VPC に加えて、クラスターの Ingress 用のプライベートホストゾーンが必要です。PrivateLink (Private または PublicAndPrivate アクセスモード) を使用するクラスターを作成する場合は、PrivateLink 用の追加のホストゾーンが必要です。

次の設定例を使用して、ホステッドクラスター用の AWS インフラストラクチャーを作成します。

---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters
spec: {}
status: {}
---
apiVersion: v1
data:
  .dockerconfigjson: xxxxxxxxxxx
kind: Secret
metadata:
  creationTimestamp: null
  labels:
    hypershift.openshift.io/safe-to-delete-with-cluster: "true"
  name: <pull_secret_name> 
1

  namespace: clusters
---
apiVersion: v1
data:
  key: xxxxxxxxxxxxxxxxx
kind: Secret
metadata:
  creationTimestamp: null
  labels:
    hypershift.openshift.io/safe-to-delete-with-cluster: "true"
  name: <etcd_encryption_key_name> 
2

  namespace: clusters
type: Opaque
---
apiVersion: v1
data:
  id_rsa: xxxxxxxxx
  id_rsa.pub: xxxxxxxxx
kind: Secret
metadata:
  creationTimestamp: null
  labels:
    hypershift.openshift.io/safe-to-delete-with-cluster: "true"
  name: <ssh-key-name> 
3

  namespace: clusters
---
apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  creationTimestamp: null
  name: <hosted_cluster_name> 
4

  namespace: clusters
spec:
  autoscaling: {}
  configuration: {}
  controllerAvailabilityPolicy: SingleReplica
  dns:
    baseDomain: <dns_domain> 
5

    privateZoneID: xxxxxxxx
    publicZoneID: xxxxxxxx
  etcd:
    managed:
      storage:
        persistentVolume:
          size: 8Gi
          storageClassName: gp3-csi
        type: PersistentVolume
    managementType: Managed
  fips: false
  infraID: <infra_id> 
6

  issuerURL: <issuer_url> 
7

  networking:
    clusterNetwork:
    - cidr: 10.132.0.0/14
    machineNetwork:
    - cidr: 10.0.0.0/16
    networkType: OVNKubernetes
    serviceNetwork:
    - cidr: 172.31.0.0/16
  olmCatalogPlacement: management
  platform:
    aws:
      cloudProviderConfig:
        subnet:
          id: <subnet_xxx> 
8

        vpc: <vpc_xxx> 
9

        zone: us-west-1b
      endpointAccess: Public
      multiArch: false
      region: us-west-1
      rolesRef:
        controlPlaneOperatorARN: arn:aws:iam::820196288204:role/<infra_id>-control-plane-operator
        imageRegistryARN: arn:aws:iam::820196288204:role/<infra_id>-openshift-image-registry
        ingressARN: arn:aws:iam::820196288204:role/<infra_id>-openshift-ingress
        kubeCloudControllerARN: arn:aws:iam::820196288204:role/<infra_id>-cloud-controller
        networkARN: arn:aws:iam::820196288204:role/<infra_id>-cloud-network-config-controller
        nodePoolManagementARN: arn:aws:iam::820196288204:role/<infra_id>-node-pool
        storageARN: arn:aws:iam::820196288204:role/<infra_id>-aws-ebs-csi-driver-controller
    type: AWS
  pullSecret:
    name: <pull_secret_name>
  release:
    image: quay.io/openshift-release-dev/ocp-release:4.16-x86_64
  secretEncryption:
    aescbc:
      activeKey:
        name: <etcd_encryption_key_name>
    type: aescbc
  services:
  - service: APIServer
    servicePublishingStrategy:
      type: LoadBalancer
  - service: OAuthServer
    servicePublishingStrategy:
      type: Route
  - service: Konnectivity
    servicePublishingStrategy:
      type: Route
  - service: Ignition
    servicePublishingStrategy:
      type: Route
  - service: OVNSbDb
    servicePublishingStrategy:
      type: Route
  sshKey:
    name: <ssh_key_name>
status:
  controlPlaneEndpoint:
    host: ""
    port: 0
---
apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  creationTimestamp: null
  name: <node_pool_name> 
10

  namespace: clusters
spec:
  arch: amd64
  clusterName: <hosted_cluster_name>
  management:
    autoRepair: true
    upgradeType: Replace
  nodeDrainTimeout: 0s
  platform:
    aws:
      instanceProfile: <instance_profile_name> 
11

      instanceType: m6i.xlarge
      rootVolume:
        size: 120
        type: gp3
      subnet:
        id: <subnet_xxx>
    type: AWS
  release:
    image: quay.io/openshift-release-dev/ocp-release:4.16-x86_64
  replicas: 2
status:
  replicas: 0
Copy to Clipboard Toggle word wrap
1
<pull_secret_name> は、プルシークレットの名前に置き換えます。
2
<etcd_encryption_key_name> は、etcd 暗号鍵の名前に置き換えます。
3
<ssh_key_name> は、SSH 鍵の名前に置き換えます。
4
<hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
5
<dns_domain> は、example.com などのベース DNS ドメインに置き換えます。
6
<infra_id> は、ホステッドクラスターに関連付けられている IAM リソースを特定する値に置き換えます。
7
<issuer_url> は、末尾の値が infra_id である発行者 URL に置き換えます。たとえば、https://example-hosted-us-west-1.s3.us-west-1.amazonaws.com/example-hosted-infra-id です。
8
<subnet_xxx> は、サブネット ID に置き換えます。プライベートサブネットとパブリックサブネットの両方にタグを付ける必要があります。パブリックサブネットの場合は、kubernetes.io/role/elb=1 を使用します。プライベートサブネットの場合は、kubernetes.io/role/internal-elb=1 を使用します。
9
<vpc_xxx> は、VPC ID に置き換えます。
10
<node_pool_name> は、NodePool リソースの名前に置き換えます。
11
<instance_profile_name> は、AWS インスタンスの名前に置き換えます。
5.1.3.2. AWS IAM リソースの作成

Amazon Web Services (AWS) では、次の IAM リソースを作成する必要があります。

5.1.3.3. ホステッドクラスターを個別に作成する

Amazon Web Services (AWS) にホステッドクラスターを個別に作成できます。

ホステッドクラスターを個別に作成するには、次のコマンドを入力します。

$ hcp create cluster aws \
    --infra-id <infra_id> \
1

    --name <hosted_cluster_name> \
2

    --sts-creds <path_to_sts_credential_file> \
3

    --pull-secret <path_to_pull_secret> \
4

    --generate-ssh \
5

    --node-pool-replicas 3
    --role-arn <role_name> 
6
Copy to Clipboard Toggle word wrap
1
<infra_id>create infra aws コマンドで指定したのと同じ ID に置き換えます。この値は、ホステッドクラスターに関連付けられている IAM リソースを識別します。
2
<hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
3
<path_to_sts_credential_file> は、create infra aws コマンドで指定した名前と同じ名前に置き換えます。
4
<path_to_pull_secret> を有効な OpenShift Container Platform プルシークレットを含むファイルの名前に置き換えます。
5
--generate-ssh フラグはオプションですが、ワーカーに SSH 接続する必要がある場合に含めるとよいでしょう。SSH キーが生成され、ホステッドクラスターと同じ名 namespace にシークレットとして保存されます。
6
<role_name> は、Amazon Resource Name (ARN) に置き換えます (例: arn:aws:iam::820196288204:role/myrole)。Amazon Resource Name (ARN) を指定します (例: arn:aws:iam::820196288204:role/myrole)。ARN ロールの詳細は、「Identity and Access Management (IAM) 権限」を参照してください。

コマンドに --render フラグを追加して、クラスターに適用する前にリソースを編集できるファイルに出力をリダイレクトすることもできます。

コマンドを実行すると、次のリソースがクラスターに適用されます。

  • namespace
  • プルシークレットを含むシークレット
  • HostedCluster
  • NodePool
  • コントロールプレーンコンポーネントの 3 つの AWS STS シークレット
  • --generate-ssh フラグを指定した場合は、1 つの SSH キーシークレット。

シングルアーキテクチャーの 64 ビット AMD ホステッドクラスターを、Amazon Web Services (AWS) 上のマルチアーキテクチャーのホステッドクラスターに移行すると、クラスター上でワークロードを実行するコストを削減できます。たとえば、64 ビット ARM に移行しながら、既存のワークロードを 64 ビット AMD で実行し、このワークロードを中央の Kubernetes クラスターから管理できます。

シングルアーキテクチャーのホステッドクラスターで管理できるのは、特定の CPU アーキテクチャーのノードプールだけです。一方、マルチアーキテクチャーのホステッドクラスターでは、CPU アーキテクチャーが異なる複数のノードプールを管理できます。AWS 上のマルチアーキテクチャーのホステッドクラスターでは、64 ビット AMD ノードプールと 64 ビット ARM ノードプールの両方を管理できます。

前提条件

  • multicluster engine for Kubernetes Operator を使用して、Red Hat Advanced Cluster Management (RHACM) に AWS 用の OpenShift Container Platform 管理クラスターをインストールした。
  • OpenShift Container Platform リリースペイロードの 64 ビット AMD バリアントを使用する既存のシングルアーキテクチャーのホステッドクラスターがある。
  • OpenShift Container Platform リリースペイロードの同じ 64 ビット AMD バリアントを使用し、既存のホステッドクラスターによって管理されるノードプールがある。
  • 次のコマンドラインツールがインストールされている。

    • oc
    • kubectl
    • hcp
    • skopeo

手順

  1. 次のコマンドを実行して、シングルアーキテクチャーホステッドクラスターの既存の OpenShift Container Platform リリースイメージを確認します。

    $ oc get hostedcluster/<hosted_cluster_name> \
    1
    
      -o jsonpath='{.spec.release.image}'
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。

    出力例

    quay.io/openshift-release-dev/ocp-release:<4.y.z>-x86_64 
    1
    Copy to Clipboard Toggle word wrap

    1
    <4.y.z> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。
  2. OpenShift Container Platform リリースイメージで、タグの代わりにダイジェストを使用する場合は、リリースイメージのマルチアーキテクチャータグバージョンを見つけます。

    1. 次のコマンドを実行して、OpenShift Container Platform バージョンの OCP_VERSION 環境変数を設定します。

      $ OCP_VERSION=$(oc image info quay.io/openshift-release-dev/ocp-release@sha256:ac78ebf77f95ab8ff52847ecd22592b545415e1ff6c7ff7f66bf81f158ae4f5e \
        -o jsonpath='{.config.config.Labels["io.openshift.release"]}')
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、リリースイメージのマルチアーキテクチャータグバージョンの MULTI_ARCH_TAG 環境変数を設定します。

      $ MULTI_ARCH_TAG=$(skopeo inspect docker://quay.io/openshift-release-dev/ocp-release@sha256:ac78ebf77f95ab8ff52847ecd22592b545415e1ff6c7ff7f66bf81f158ae4f5e \
        | jq -r '.RepoTags' | sed 's/"//g' | sed 's/,//g' \
        | grep -w "$OCP_VERSION-multi$" | xargs)
      Copy to Clipboard Toggle word wrap
    3. 次のコマンドを実行して、マルチアーキテクチャーリリースイメージ名の IMAGE 環境変数を設定します。

      $ IMAGE=quay.io/openshift-release-dev/ocp-release:$MULTI_ARCH_TAG
      Copy to Clipboard Toggle word wrap
    4. マルチアーキテクチャーイメージダイジェストのリストを表示するには、次のコマンドを実行します。

      $ oc image info $IMAGE
      Copy to Clipboard Toggle word wrap

      出力例

      OS            DIGEST
      linux/amd64   sha256:b4c7a91802c09a5a748fe19ddd99a8ffab52d8a31db3a081a956a87f22a22ff8
      linux/ppc64le sha256:66fda2ff6bd7704f1ba72be8bfe3e399c323de92262f594f8e482d110ec37388
      linux/s390x   sha256:b1c1072dc639aaa2b50ec99b530012e3ceac19ddc28adcbcdc9643f2dfd14f34
      linux/arm64   sha256:7b046404572ac96202d82b6cb029b421dddd40e88c73bbf35f602ffc13017f21
      Copy to Clipboard Toggle word wrap

  3. ホステッドクラスターをシングルアーキテクチャーからマルチアーキテクチャーに移行します。

    1. ホステッドクラスターと同じ OpenShift Container Platform バージョンを必ず使用して、ホステッドクラスターのマルチアーキテクチャー OpenShift Container Platform リリースイメージを設定します。以下のコマンドを実行します。

      $ oc patch -n clusters hostedclusters/<hosted_cluster_name> -p \
        '{"spec":{"release":{"image":"quay.io/openshift-release-dev/ocp-release:<4.x.y>-multi"}}}' \
      1
      
        --type=merge
      Copy to Clipboard Toggle word wrap
      1
      <4.y.z> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。
    2. 次のコマンドを実行して、ホステッドクラスターにマルチアーキテクチャーイメージが設定されていることを確認します。

      $ oc get hostedcluster/<hosted_cluster_name> \
        -o jsonpath='{.spec.release.image}'
      Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、HostedControlPlane リソースのステータスが Progressing であることを確認します。

    $ oc get hostedcontrolplane -n <hosted_control_plane_namespace> -oyaml
    Copy to Clipboard Toggle word wrap

    出力例

    #...
      - lastTransitionTime: "2024-07-28T13:07:18Z"
        message: HostedCluster is deploying, upgrading, or reconfiguring
        observedGeneration: 5
        reason: Progressing
        status: "True"
        type: Progressing
    #...
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを実行して、HostedCluster リソースのステータスが Progressing であることを確認します。

    $ oc get hostedcluster <hosted_cluster_name> \
      -n <hosted_cluster_namespace> -oyaml
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、ノードプールが HostedControlPlane リソース内のマルチアーキテクチャーリリースイメージを使用していることを確認します。

    $ oc get hostedcontrolplane -n clusters-example -oyaml
    Copy to Clipboard Toggle word wrap

    出力例

    #...
    version:
        availableUpdates: null
        desired:
          image: quay.io/openshift-release-dev/ocp-release:<4.x.y>-multi 
    1
    
          url: https://access.redhat.com/errata/RHBA-2024:4855
          version: 4.16.5
        history:
        - completionTime: "2024-07-28T13:10:58Z"
          image: quay.io/openshift-release-dev/ocp-release:<4.x.y>-multi
          startedTime: "2024-07-28T13:10:27Z"
          state: Completed
          verified: false
          version: <4.x.y>
    Copy to Clipboard Toggle word wrap

    1
    <4.y.z> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。
    注記

    マルチアーキテクチャー OpenShift Container Platform リリースイメージは、HostedClusterHostedControlPlane リソース、および Hosted Control Plane の Pod で更新されます。ただし、既存のノードプールは、マルチアーキテクチャーイメージに自動的に移行されません。リリースイメージの移行は、ホステッドクラスターとノードプール間で分離されているためです。新しいマルチアーキテクチャーホステッドクラスターに新しいノードプールを作成する必要があります。

次のステップ

  • マルチアーキテクチャーホステッドクラスターでのノードプールを作成する

5.1.5. マルチアーキテクチャーホステッドクラスターでのノードプールを作成する

ホステッドクラスターをシングルアーキテクチャーからマルチアーキテクチャーに移行したら、64 ビット AMD および 64 ビット ARM アーキテクチャーベースのコンピュートマシン上にノードプールを作成します。

手順

  1. 次のコマンドを入力して、64 ビット ARM アーキテクチャーベースのノードプールを作成します。

    $ hcp create nodepool aws \
      --cluster-name <hosted_cluster_name> \
    1
    
      --name <nodepool_name> \
    2
    
      --node-count=<node_count> \
    3
    
      --arch arm64
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    <nodepool_name> は、ノードプール名に置き換えます。
    3
    <node_count> は、ノード数の整数 (例: 2) に置き換えます。
  2. 次のコマンドを入力して、64 ビット AMD アーキテクチャーベースのノードプールを作成します。

    $ hcp create nodepool aws \
      --cluster-name <hosted_cluster_name> \
    1
    
      --name <nodepool_name> \
    2
    
      --node-count=<node_count> \
    3
    
      --arch amd64
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    <nodepool_name> は、ノードプール名に置き換えます。
    3
    <node_count> は、ノード数の整数 (例: 2) に置き換えます。

検証

  • 次のコマンドを入力して、ノードプールがマルチアーキテクチャーリリースイメージを使用していることを確認します。

    $ oc get nodepool/<nodepool_name> -oyaml
    Copy to Clipboard Toggle word wrap

    64 ビット AMD ノードプールの出力例

    #...
    spec:
      arch: amd64
    #...
      release:
        image: quay.io/openshift-release-dev/ocp-release:<4.x.y>-multi 
    1
    Copy to Clipboard Toggle word wrap

    1
    <4.y.z> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

    64 ビット ARM ノードプールの出力例

    #...
    spec:
      arch: arm64
    #...
      release:
        image: quay.io/openshift-release-dev/ocp-release:<4.x.y>-multi
    Copy to Clipboard Toggle word wrap

5.1.6. ホステッドクラスターの AWS タグの追加または更新

クラスターインスタンス管理者は、ホステッドクラスターを再作成しなくても、Amazon Web Services (AWS) タグを追加または更新できます。タグ は、管理と自動化のために AWS リソースにアタッチされるキーと値のペアです。

タグは次の目的で使用できます。

  • アクセス制御の管理。
  • チャージバックまたはショーバックの追跡。
  • クラウド IAM の条件付き権限の管理。
  • タグに基づいたリソースの集約。たとえば、タグをクエリーして、リソースの使用量と請求コストを計算できます。

EFS アクセスポイント、ロードバランサーリソース、Amazon EBS ボリューム、IAM ユーザー、AWS S3 など、さまざまな種類のリソースのタグを追加または更新できます。

重要

ネットワークロードバランサーでは、タグを追加または更新することはできません。AWS ロードバランサーは、HostedCluster リソース内のタグをリコンサイルします。タグを追加または更新しようとすると、ロードバランサーによってタグが上書きされます。

さらに、Hosted Control Plane によって直接作成されたデフォルトのセキュリティーグループリソースではタグを更新できません。

前提条件

  • AWS 上のホステッドクラスターに対するクラスター管理者権限が必要です。

手順

  1. EFS アクセスポイントのタグを追加または更新する場合は、手順 1 と 2 を完了します。他の種類のリソースのタグを追加または更新する場合は、手順 2 のみを完了します。

    1. aws-efs-csi-driver-operator サービスアカウントで、次の例に示すように 2 つのアノテーションを追加します。これらのアノテーションは、クラスター上で実行される AWS EKS Pod Identity Webhook が、EFS Operator が使用される Pod に AWS ロールを正しく割り当てるために必要です。

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: <service_account_name>
        namespace: <project_name>
        annotations:
          eks.amazonaws.com/role-arn:<role_arn>
          eks.amazonaws.com/audience:sts.amazonaws.com
      Copy to Clipboard Toggle word wrap
    2. Operator Pod を削除するか、aws-efs-csi-driver-operator デプロイメントの再起動をロールアウトします。
  2. HostedCluster リソースで、次の例に示すように、resourceTags フィールドに情報を入力します。

    HostedCluster リソースの例

    apiVersion: hypershift.openshift.io/v1beta1
    kind: HostedCluster
    metadata:
      #...
    spec:
      autoscaling: {}
      clusterID: <cluster_id>
      configuration: {}
      controllerAvailabilityPolicy: SingleReplica
      dns:
        #...
      etcd:
        #...
      fips: false
      infraID: <infra_id>
      infrastructureAvailabilityPolicy: SingleReplica
      issuerURL: https://<issuer_url>.s3.<region>.amazonaws.com
      networking:
        #...
      olmCatalogPlacement: management
      platform:
        aws:
          #...
          resourceTags:
          - key: kubernetes.io/cluster/<tag> 
    1
    
            value: owned
          rolesRef:
            #...
        type: AWS
    Copy to Clipboard Toggle word wrap

1
リソースに追加するタグを指定します。

5.1.7. AWS でのノードプール容量ブロックの設定

ホステッドクラスターを作成した後、Amazon Web Services (AWS) でグラフィックスプロセッシングユニット (GPU) 予約用のノードプール容量ブロックを設定できます。

手順

  1. 次のコマンドを実行して、AWS で GPU 予約を作成します。

    重要

    GPU 予約のゾーンは、ホステッドクラスターゾーンと一致する必要があります。

    $ aws ec2 describe-capacity-block-offerings \
          --instance-type "p4d.24xlarge"\ 
    1
    
          --instance-count  "1" \ 
    2
    
          --start-date-range "$(date -u +"%Y-%m-%dT%H:%M:%SZ")"  \ 
    3
    
          --end-date-range "$(date -u -d "2 day" +"%Y-%m-%dT%H:%M:%SZ")" \ 
    4
    
          --capacity-duration-hours 24 \ 
    5
    
          --output json
    Copy to Clipboard Toggle word wrap
    1
    AWS インスタンスのタイプを定義します (例: p4d.24xlarge)。
    2
    インスタンスの購入数量を定義します (例: 1)。有効な値は 1 から 64 までの整数です。
    3
    開始日の範囲を定義します (例: 2025-07-21T10:14:39Z)。
    4
    終了日の範囲を定義します (例: 2025-07-22T10:16:36Z)
    5
    容量ブロックの期間を時間単位で定義します (例: 24)。
  2. 次のコマンドを実行して、最小料金の容量ブロックを購入します。

    $ aws ec2 purchase-capacity-block \
          --capacity-block-offering-id "${MIN_FEE_ID}" \ 
    1
    
          --instance-platform "Linux/UNIX"\ 
    2
    
          --tag-specifications 'ResourceType=capacity-reservation,Tags=[{Key=usage-cluster-type,Value=hypershift-hosted}]' \ 
    3
    
          --output json   > "${CR_OUTPUT_FILE}"
    Copy to Clipboard Toggle word wrap
    1
    容量ブロックオファリングの ID を定義します。
    2
    インスタンスのプラットフォームを定義します。
    3
    インスタンスのタグを定義します。
  3. 次のコマンドを実行して、容量予約 ID を設定する環境変数を作成します。

    $ CB_RESERVATION_ID=$(jq -r '.CapacityReservation.CapacityReservationId' "${CR_OUTPUT_FILE}")
    Copy to Clipboard Toggle word wrap

    GPU の予約が利用可能になるまで数分待ちます。

  4. 次のコマンドを実行して、GPU 予約を使用するノードプールを追加します。

    $ hcp create nodepool aws \
      --cluster-name <hosted_cluster_name> \ 
    1
    
      --name <node_pool_name> \ 
    2
    
      --node-count 1 \ 
    3
    
      --instance-type p4d.24xlarge \ 
    4
    
      --arch amd64 \ 
    5
    
      --release-image <release_image> \ 
    6
    
      --render > /tmp/np.yaml
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    <node_pool_name> は、ノードプールの名前に置き換えます。
    3
    ノードプールの数を定義します (例: 1)。
    4
    インスタンスタイプを定義します (例: p4d.24xlarge)。
    5
    アーキテクチャータイプを定義します (例: amd64)。
    6
    <release_image> は、使用するリリースイメージに置き換えます。
  5. 次の設定例を使用して、NodePool リソースに capacityReservation 設定を追加します。

    # ...
    spec:
      arch: amd64
      clusterName: cb-np-hcp
      management:
        autoRepair: false
        upgradeType: Replace
      platform:
        aws:
          instanceProfile: cb-np-hcp-dqppw-worker
          instanceType: p4d.24xlarge
          rootVolume:
            size: 120
            type: gp3
          subnet:
            id: subnet-00000
          placement:
            capacityReservation:
              id: ${CB_RESERVATION_ID}
              marketType: CapacityBlocks
        type: AWS
    # ...
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、ノードプールの設定を適用します。

    $ oc apply -f /tmp/np.yaml
    Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを実行して、新しいノードプールが正常に作成されたことを確認します。

    $ oc get np -n clusters
    Copy to Clipboard Toggle word wrap

    出力例

    NAMESPACE   NAME    CLUSTER     DESIRED NODES   CURRENT  NODES   AUTOSCALING     AUTOREPAIR   VERSION                               UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
    clusters    cb-np   cb-np-hcp   1               1                False           False        4.20.0-0.nightly-2025-06-05-224220    False             False
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、ホステッドクラスターに新しいコンピュートノードが作成されたことを確認します。

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                           STATUS   ROLES    AGE    VERSION
    ip-10-0-132-74.ec2.internal    Ready    worker   17m    v1.32.5
    ip-10-0-134-183.ec2.internal   Ready    worker   4h5m   v1.32.5
    Copy to Clipboard Toggle word wrap

5.1.7.1. ノードプールの容量ブロックを設定した後にホステッドクラスターを破棄する

ノードプールの容量ブロックを設定した後、必要に応じてホステッドクラスターを破棄し、HyperShift Operator をアンインストールできます。

手順

  1. ホステッドクラスターを破棄するには、次のサンプルコマンドを実行します。

    $ hcp destroy cluster aws \
      --name cb-np-hcp \
      --aws-creds $HOME/.aws/credentials \
      --namespace clusters \
      --region us-east-2
    Copy to Clipboard Toggle word wrap
  2. HyperShift Operator をアンインストールするには、次のコマンドを実行します。

    $ hcp install render --format=yaml | oc delete -f -
    Copy to Clipboard Toggle word wrap

5.2. ベアメタルでの Hosted Control Plane の管理

Hosted Control Plane をベアメタルにデプロイした後、次のタスクを完了してホステッドクラスターを管理できます。

5.2.1. ホステッドクラスターへのアクセス

ホステッドクラスターにアクセスするには、kubeconfig ファイルと kubeadmin 認証情報をリソースから直接取得するか、hcp コマンドラインインターフェイスを使用して kubeconfig ファイルを生成します。

前提条件

リソースから kubeconfig ファイルと認証情報を直接取得し、ホステッドクラスターにアクセスするには、ホステッドクラスターのアクセスシークレットを理解している必要があります。ホステッドクラスター (ホスティング) のリソースとアクセスシークレットは、ホステッドクラスターの namespace に格納されます。Hosted Control Plane は、Hosted Control Plane の namespace で実行されます。

シークレット名の形式は次のとおりです。

  • kubeconfig シークレット: <hosted_cluster_namespace>-<name>-admin-kubeconfig.たとえば、clusters-hypershift-demo-admin-kubeconfig です。
  • kubeadmin パスワードシークレット: <hosted_cluster_namespace>-<name>-kubeadmin-password。たとえば、clusters-hypershift-demo-kubeadmin-password です。

kubeconfig シークレットには Base64 でエンコードされた kubeconfig フィールドが含まれており、これをデコードしてファイルに保存し、次のコマンドで使用できます。

$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
Copy to Clipboard Toggle word wrap

kubeadmin パスワードシークレットも Base64 でエンコードされます。これをデコードし、そのパスワードを使用して、ホステッドクラスターの API サーバーまたはコンソールにログインできます。

手順

  • hcp CLI を使用してホステッドクラスターにアクセスして kubeconfig ファイルを生成するには、次の手順を実行します。

    1. 次のコマンドを入力して、kubeconfig ファイルを生成します。

      $ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
        --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
      Copy to Clipboard Toggle word wrap
    2. kubeconfig ファイルを保存した後、次のコマンド例を入力して、ホステッドクラスターにアクセスできます。

      $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
      Copy to Clipboard Toggle word wrap

5.2.2. ホステッドクラスターの NodePool オブジェクトのスケーリング

ホステッドクラスターにノードを追加することで、NodePool オブジェクトをスケールアップできます。ノードプールをスケーリングする際には、次の情報を考慮してください。

  • ノードプールによってレプリカをスケーリングすると、マシンが作成されます。クラスター API プロバイダーは、すべてのマシンに対して、ノードプール仕様で指定された要件を満たすエージェントを見つけてインストールします。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
  • ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。Agent を再利用するには、Discovery イメージを使用してエージェントを再起動する必要があります。

手順

  1. NodePool オブジェクトを 2 つのノードにスケーリングします。

    $ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2
    Copy to Clipboard Toggle word wrap

    Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で状態を通過します。

    • binding
    • discovering
    • insufficient
    • installing
    • installing-in-progress
    • added-to-existing-cluster
  2. 以下のコマンドを入力します。

    $ oc -n <hosted_control_plane_namespace> get agent
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER         APPROVED   ROLE          STAGE
    4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign
    d9198891-39f4-4930-a679-65fb142b108b                   true       auto-assign
    da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign
    Copy to Clipboard Toggle word wrap

  3. 以下のコマンドを入力します。

    $ oc -n <hosted_control_plane_namespace> get agent \
      -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    出力例

    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
    BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
    BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
    Copy to Clipboard Toggle word wrap

  4. 次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。

    $ oc extract -n <hosted_cluster_namespace> \
      secret/<hosted_cluster_name>-admin-kubeconfig --to=- \
      > kubeconfig-<hosted_cluster_name>
    Copy to Clipboard Toggle word wrap
  5. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、ホステッドクラスターの OpenShift Container Platform ノードが表示されることを確認します。

    $ oc --kubeconfig kubeconfig-<hosted_cluster_name> get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME           STATUS   ROLES    AGE     VERSION
    ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
    ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

    Cluster Operator は、ワークロードをノードに追加することによってリコンシリエーションを開始します。

  6. 次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。

    $ oc -n <hosted_control_plane_namespace> get machines
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
    hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.x.z
    hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.x.z
    Copy to Clipboard Toggle word wrap

    clusterversion のリコンサイルプロセスは、最終的に、Ingress および Console のクラスター Operator だけが不足しているという段階に到達します。

  7. 以下のコマンドを入力します。

    $ oc --kubeconfig kubeconfig-<hosted_cluster_name> get clusterversion,co
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.x.z: the cluster operator console has not yet successfully rolled out
    
    NAME                                                                             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    clusteroperator.config.openshift.io/console                                      4.12z     False       False         False      11m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused
    clusteroperator.config.openshift.io/csi-snapshot-controller                      4.12z     True        False         False      10m
    clusteroperator.config.openshift.io/dns                                          4.12z     True        False         False      9m16s
    Copy to Clipboard Toggle word wrap

5.2.2.1. ノードプールの追加

名前、レプリカの数、およびエージェントラベルセレクターなどの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。

注記

サポートされるエージェント namespace は、ホステッドクラスターごとに 1 つだけです。そのため、ホステッドクラスターにノードプールを追加する場合、そのノードプールを、単一の InfraEnv リソースから、または同じエージェント namespace にある InfraEnv リソースから取得する必要があります。

手順

  1. ノードプールを作成するには、次の情報を入力します。

    $ hcp create nodepool agent \
      --cluster-name <hosted_cluster_name> \
    1
    
      --name <nodepool_name> \
    2
    
      --node-count <worker_node_count> \
    3
    
      --agentLabelSelector size=medium 
    4
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    <nodepool_name> は、ノードプールの名前に置き換えます (例: <hosted_cluster_name>-extra-cpu)。
    3
    <worker_node_count> は、ワーカーノード数 (例: 2) に置き換えます。
    4
    --agentLabelSelector フラグは任意です。ノードプールは、size=medium ラベルを持つエージェントを使用します。
  2. clusters namespace 内の nodepool リソースをリスト表示して、ノードプールのステータスを確認します。

    $ oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。

    $ oc extract -n <hosted_control_plane_namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm
    Copy to Clipboard Toggle word wrap

    出力例

    hostedcluster-secrets/kubeconfig
    Copy to Clipboard Toggle word wrap

  4. しばらくしてから、次のコマンドを入力してノードプールのステータスを確認できます。

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを入力して、使用可能なノードプールの数が予想されるノードプールの数と一致することを確認します。

    $ oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap
5.2.2.2. ホステッドクラスターのノード自動スケーリングの有効化

ホステッドクラスターにさらに容量が必要で、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいワーカーノードをインストールできます。

手順

  1. 自動スケーリングを有効にするには、次のコマンドを入力します。

    $ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \
      --type=json \
      -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
    Copy to Clipboard Toggle word wrap
    注記

    この例では、ノードの最小数は 2、最大数は 5 です。追加できるノードの最大数は、プラットフォームによって制限される場合があります。たとえば、Agent プラットフォームを使用する場合、ノードの最大数は使用可能なエージェントの数によって制限されます。

  2. 新しいノードを必要とするワークロードを作成します。

    1. 次の例を使用して、ワークロード設定を含む YAML ファイルを作成します。

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        creationTimestamp: null
        labels:
          app: reversewords
        name: reversewords
        namespace: default
      spec:
        replicas: 40
        selector:
          matchLabels:
            app: reversewords
        strategy: {}
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: reversewords
          spec:
            containers:
            - image: quay.io/mavazque/reversewords:latest
              name: reversewords
              resources:
                requests:
                  memory: 2Gi
      status: {}
      Copy to Clipboard Toggle word wrap
    2. ファイルを workload-config.yaml として保存します。
    3. 以下のコマンドを入力して、YAML を適用します。

      $ oc apply -f workload-config.yaml
      Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。

    $ oc extract -n <hosted_cluster_namespace> \
      secret/<hosted_cluster_name>-admin-kubeconfig \
      --to=./hostedcluster-secrets --confirm
    Copy to Clipboard Toggle word wrap

    出力例

    hostedcluster-secrets/kubeconfig
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを入力して、新しいノードが Ready ステータスであるかどうかを確認できます。

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
    Copy to Clipboard Toggle word wrap
  5. ノードを削除するには、次のコマンドを入力してワークロードを削除します。

    $ oc --kubeconfig ./hostedcluster-secrets -n <namespace> \
      delete deployment <deployment_name>
    Copy to Clipboard Toggle word wrap
  6. 数分間待ちます。その間に、容量の追加が必要にならないようにします。Agent プラットフォームでエージェントが使用停止され、再利用できるようになります。次のコマンドを入力すると、ノードが削除されたことを確認できます。

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
    Copy to Clipboard Toggle word wrap
    注記

    IBM Z® エージェントの場合、プロセッサーリソース/システムマネージャー (PR/SM) モードで OSA ネットワークデバイスを使用している場合、自動スケーリングはサポートされません。新しいエージェントはスケールダウンプロセス中に結合されるため、古いエージェントを手動で削除し、ノードプールをスケールアップする必要があります。

5.2.2.3. ホステッドクラスターのノードの自動スケーリングを無効にする

ノードの自動スケーリングを無効にするには、次の手順を実行します。

手順

  • ホステッドクラスターのノードの自動スケーリングを無効にするには、次のコマンドを入力します。

    $ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \
      --type=json \
      -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify_value_to_scale_replicas>]'
    Copy to Clipboard Toggle word wrap

    このコマンドは、YAML ファイルから "spec.autoScaling" を削除し、"spec.replicas" を追加し、"spec.replicas" を指定の整数値に設定します。

5.2.3. ベアメタル上のホステッドクラスターでの Ingress の処理

すべての OpenShift Container Platform クラスターには、通常、外部 DNS レコードが関連付けられているデフォルトのアプリケーション Ingress コントローラーがあります。たとえば、ベースドメイン krnl.esexample という名前のホステッドクラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es がルーティング可能であると予想することができます。

手順

*.apps ドメインのロードバランサーとワイルドカード DNS レコードを設定するには、ゲストクラスターで次のアクションを実行します。

  1. MetalLB Operator の設定を含む YAML ファイルを作成して MetalLB をデプロイします。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: metallb
      labels:
        openshift.io/cluster-monitoring: "true"
      annotations:
        workload.openshift.io/allowed: management
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: metallb-operator-operatorgroup
      namespace: metallb
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: metallb-operator
      namespace: metallb
    spec:
      channel: "stable"
      name: metallb-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap
  2. ファイルを metallb-operator-config.yaml として保存します。
  3. 以下のコマンドを入力して設定を適用します。

    $ oc apply -f metallb-operator-config.yaml
    Copy to Clipboard Toggle word wrap
  4. Operator の実行後、MetalLB インスタンスを作成します。

    1. MetalLB インスタンスの設定を含む YAML ファイルを作成します。

      apiVersion: metallb.io/v1beta1
      kind: MetalLB
      metadata:
        name: metallb
        namespace: metallb
      Copy to Clipboard Toggle word wrap
    2. ファイルを metallb-instance-config.yaml として保存します。
    3. 次のコマンドを入力して、MetalLB インスタンスを作成します。

      $ oc apply -f metallb-instance-config.yaml
      Copy to Clipboard Toggle word wrap
  5. 単一の IP アドレスを含む IPAddressPool リソースを作成します。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。

    1. 以下の例のような内容で、ipaddresspool.yaml などのファイルを作成します。

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        namespace: metallb
        name: <ip_address_pool_name> 
      1
      
      spec:
        addresses:
          - <ingress_ip>-<ingress_ip> 
      2
      
        autoAssign: false
      Copy to Clipboard Toggle word wrap
      1
      IPAddressPool リソース名を指定します。
      2
      環境の IP アドレスを指定します。たとえば、192.168.122.23 です。
    2. 次のコマンドを入力して、IP アドレスプールの設定を適用します。

      $ oc apply -f ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
  6. L2 アドバタイズメントを作成します。

    1. 以下の例のような内容で、l2advertisement.yaml などのファイルを作成します。

      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: <l2_advertisement_name> 
      1
      
        namespace: metallb
      spec:
        ipAddressPools:
         - <ip_address_pool_name> 
      2
      Copy to Clipboard Toggle word wrap
      1
      L2Advertisement リソース名を指定します。
      2
      IPAddressPool リソース名を指定します。
    2. 次のコマンドを入力して設定を適用します。

      $ oc apply -f l2advertisement.yaml
      Copy to Clipboard Toggle word wrap
  7. LoadBalancer タイプのサービスを作成すると、MetalLB はサービスに外部 IP アドレスを追加します。

    1. metallb-loadbalancer-service.yaml という名前の YAML ファイルを作成して、Ingress トラフィックを Ingress デプロイメントにルーティングする新しいロードバランサーサービスを設定します。

      kind: Service
      apiVersion: v1
      metadata:
        annotations:
         metallb.io/address-pool: ingress-public-ip
        name: metallb-ingress
        namespace: openshift-ingress
      spec:
        ports:
          - name: http
            protocol: TCP
            port: 80
            targetPort: 80
          - name: https
            protocol: TCP
            port: 443
            targetPort: 443
        selector:
          ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        type: LoadBalancer
      Copy to Clipboard Toggle word wrap
    2. metallb-loadbalancer-service.yaml ファイルを保存します。
    3. YAML 設定を適用するには、次のコマンドを入力します。

      $ oc apply -f metallb-loadbalancer-service.yaml
      Copy to Clipboard Toggle word wrap
    4. 次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。

      $ curl -kI https://console-openshift-console.apps.example.krnl.es
      Copy to Clipboard Toggle word wrap

      出力例

      HTTP/1.1 200 OK
      Copy to Clipboard Toggle word wrap

    5. clusterversionclusteroperator の値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。

      $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
      clusterversion.config.openshift.io/version   4.x.y      True        False        3m32s   Cluster version is 4.x.y
      
      NAME                                                                             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
      clusteroperator.config.openshift.io/console                                      4.x.y     True        False         False      3m50s
      clusteroperator.config.openshift.io/ingress                                      4.x.y     True        False         False      53m
      Copy to Clipboard Toggle word wrap

      <4.x.y> は、使用するサポート対象の OpenShift Container Platform バージョン (例: 4.19.0-multi) に置き換えます。

5.2.4. ベアメタル上でマシンのヘルスチェックを有効にする

ベアメタル上でマシンのヘルスチェックを有効にして、異常なマネージドクラスターノードを自動的に修復および置き換えることができます。マネージドクラスターにインストールする準備ができている追加のエージェントマシンが必要です。

マシンのヘルスチェックを有効にする前に、次の制限を考慮してください。

  • MachineHealthCheck オブジェクトを変更することはできません。
  • マシンヘルスチェックでは、少なくとも 2 つのノードが 8 分以上 False または Unknown ステータスのままである場合にのみ、ノードが置き換えられます。

マネージドクラスターノードのマシンヘルスチェックを有効にすると、ホステッドクラスターに MachineHealthCheck オブジェクトが作成されます。

手順

ホステッドクラスターでマシンのヘルスチェックを有効にするには、NodePool リソースを変更します。以下の手順を実行します。

  1. NodePool リソースの spec.nodeDrainTimeout 値が 0s より大きいことを確認します。<hosted_cluster_namespace> をホステッドクラスター namespace の名前に置き換え、<nodepool_name> をノードプール名に置き換えます。以下のコマンドを実行します。

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep nodeDrainTimeout
    Copy to Clipboard Toggle word wrap

    出力例

    nodeDrainTimeout: 30s
    Copy to Clipboard Toggle word wrap

  2. spec.nodeDrainTimeout 値が 0s より大きくない場合は、次のコマンドを実行して値を変更します。

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec":{"nodeDrainTimeout": "30m"}}' --type=merge
    Copy to Clipboard Toggle word wrap
  3. NodePool リソースで spec.management.autoRepair フィールドを true に設定して、マシンのヘルスチェックを有効にします。以下のコマンドを実行します。

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":true}}}' --type=merge
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、NodePool リソースが autoRepair: true 値で更新されていることを確認します。

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair
    Copy to Clipboard Toggle word wrap

5.2.5. ベアメタル上でマシンのヘルスチェックを無効にする

マネージドクラスターノードのマシンのヘルスチェックを無効にするには、NodePool リソースを変更します。

手順

  1. NodePool リソースで spec.management.autoRepair フィールドを false に設定して、マシンのヘルスチェックを無効にします。以下のコマンドを実行します。

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":false}}}' --type=merge
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、NodePool リソースが autoRepair: false 値で更新されていることを確認します。

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair
    Copy to Clipboard Toggle word wrap

5.3. OpenShift Virtualization での Hosted Control Plane の管理

OpenShift Virtualization にホステッドクラスターをデプロイした後、次の手順を実行してクラスターを管理できます。

5.3.1. ホステッドクラスターへのアクセス

ホステッドクラスターにアクセスするには、kubeconfig ファイルと kubeadmin 認証情報をリソースから直接取得するか、hcp コマンドラインインターフェイスを使用して kubeconfig ファイルを生成します。

前提条件

リソースから kubeconfig ファイルと認証情報を直接取得し、ホステッドクラスターにアクセスするには、ホステッドクラスターのアクセスシークレットを理解している必要があります。ホステッドクラスター (ホスティング) のリソースとアクセスシークレットは、ホステッドクラスターの namespace に格納されます。Hosted Control Plane は、Hosted Control Plane の namespace で実行されます。

シークレット名の形式は次のとおりです。

  • kubeconfig シークレット: <hosted_cluster_namespace>-<name>-admin-kubeconfig (clusters-hypershift-demo-admin-kubeconfig)
  • kubeadmin パスワードシークレット: <hosted_cluster_namespace>-<name>-kubeadmin-password (clusters-hypershift-demo-kubeadmin-password)

kubeconfig シークレットには Base64 でエンコードされた kubeconfig フィールドが含まれており、これをデコードしてファイルに保存し、次のコマンドで使用できます。

$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
Copy to Clipboard Toggle word wrap

kubeadmin パスワードシークレットも Base64 でエンコードされます。これをデコードし、そのパスワードを使用して、ホステッドクラスターの API サーバーまたはコンソールにログインできます。

手順

  • hcp CLI を使用してホステッドクラスターにアクセスして kubeconfig ファイルを生成するには、次の手順を実行します。

    1. 次のコマンドを入力して、kubeconfig ファイルを生成します。

      $ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
        --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
      Copy to Clipboard Toggle word wrap
    2. kubeconfig ファイルを保存した後、次のコマンド例を入力して、ホステッドクラスターにアクセスできます。

      $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
      Copy to Clipboard Toggle word wrap

5.3.2. ホステッドクラスターのノード自動スケーリングの有効化

ホステッドクラスターにさらに容量が必要で、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいワーカーノードをインストールできます。

手順

  1. 自動スケーリングを有効にするには、次のコマンドを入力します。

    $ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \
      --type=json \
      -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
    Copy to Clipboard Toggle word wrap
    注記

    この例では、ノードの最小数は 2、最大数は 5 です。追加できるノードの最大数は、プラットフォームによって制限される場合があります。たとえば、Agent プラットフォームを使用する場合、ノードの最大数は使用可能なエージェントの数によって制限されます。

  2. 新しいノードを必要とするワークロードを作成します。

    1. 次の例を使用して、ワークロード設定を含む YAML ファイルを作成します。

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        creationTimestamp: null
        labels:
          app: reversewords
        name: reversewords
        namespace: default
      spec:
        replicas: 40
        selector:
          matchLabels:
            app: reversewords
        strategy: {}
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: reversewords
          spec:
            containers:
            - image: quay.io/mavazque/reversewords:latest
              name: reversewords
              resources:
                requests:
                  memory: 2Gi
      status: {}
      Copy to Clipboard Toggle word wrap
    2. ファイルを workload-config.yaml として保存します。
    3. 以下のコマンドを入力して、YAML を適用します。

      $ oc apply -f workload-config.yaml
      Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。

    $ oc extract -n <hosted_cluster_namespace> \
      secret/<hosted_cluster_name>-admin-kubeconfig \
      --to=./hostedcluster-secrets --confirm
    Copy to Clipboard Toggle word wrap

    出力例

    hostedcluster-secrets/kubeconfig
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを入力して、新しいノードが Ready ステータスであるかどうかを確認できます。

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
    Copy to Clipboard Toggle word wrap
  5. ノードを削除するには、次のコマンドを入力してワークロードを削除します。

    $ oc --kubeconfig ./hostedcluster-secrets -n <namespace> \
      delete deployment <deployment_name>
    Copy to Clipboard Toggle word wrap
  6. 数分間待ちます。その間に、容量の追加が必要にならないようにします。Agent プラットフォームでエージェントが使用停止され、再利用できるようになります。次のコマンドを入力すると、ノードが削除されたことを確認できます。

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
    Copy to Clipboard Toggle word wrap
    注記

    IBM Z® エージェントの場合、プロセッサーリソース/システムマネージャー (PR/SM) モードで OSA ネットワークデバイスを使用している場合、自動スケーリングはサポートされません。新しいエージェントはスケールダウンプロセス中に結合されるため、古いエージェントを手動で削除し、ノードプールをスケールアップする必要があります。

5.3.3. OpenShift Virtualization での Hosted Control Plane のストレージの設定

詳細なストレージ設定を指定しなかった場合、KubeVirt 仮想マシン (VM) イメージ、KubeVirt Container Storage Interface (CSI) マッピング、および etcd ボリュームにデフォルトのストレージクラスが使用されます。

次の表に、ホステッドクラスターで永続ストレージをサポートするためにインフラストラクチャーが提供する必要がある機能を示します。

Expand
表5.1 ホステッドクラスターの永続ストレージモード
インフラストラクチャーの CSI プロバイダーホステッドクラスターの CSI プロバイダーホステッドクラスターの機能

任意の RWX Block CSI プロバイダー

kubevirt-csi

  • 基本的な RWO Block および File
  • 基本的な RWX Block および Snapshot
  • CSI ボリュームのクローン作成

任意の RWX Block CSI プロバイダー

Red Hat OpenShift Data Foundation

Red Hat OpenShift Data Foundation の機能セット。外部モードではフットプリントが小さく、スタンドアロンの Red Hat Ceph Storage を使用します。内部モードはフットプリントが大きくなりますが、自己完結型であり、RWX File などの拡張機能を必要とするユースケースに適しています。

注記

OpenShift Virtualization はホステッドクラスター上のストレージを処理するため、要件がブロックストレージに限定されているお客様に特に役立ちます。

5.3.3.1. KubeVirt CSI ストレージクラスのマッピング

KubeVirt CSI は、ReadWriteMany (RWX) アクセスが可能なインフラストラクチャーストレージクラスのマッピングをサポートします。クラスターの作成時に、インフラストラクチャーのストレージクラスをホストされるストレージクラスにマッピングできます。

手順

  • インフラストラクチャーのストレージクラスをホストされるストレージクラスにマッピングするには、次のコマンドを実行して --infra-storage-class-mapping 引数を使用します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \ 
    1
    
      --node-pool-replicas <worker_node_count> \ 
    2
    
      --pull-secret <path_to_pull_secret> \ 
    3
    
      --memory <memory> \ 
    4
    
      --cores <cpu> \ 
    5
    
      --infra-storage-class-mapping=<infrastructure_storage_class>/<hosted_storage_class> \ 
    6
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    <infrastructure_storage_class> をインフラストラクチャーストレージクラス名に置き換え、<hosted_storage_class> をホステッドクラスターストレージクラス名に置き換えます。hcp create cluster コマンド内で --infra-storage-class-mapping 引数を複数回使用できます。

ホステッドクラスターを作成すると、インフラストラクチャーのストレージクラスがホステッドクラスター内に表示されます。これらのストレージクラスのいずれかを使用するホステッドクラスター内に永続ボリューム要求 PVC を作成すると、KubeVirt CSI はクラスターの作成時に設定したインフラストラクチャーストレージクラスマッピングを使用してそのボリュームをプロビジョニングします。

注記

KubeVirt CSI は、RWX アクセスが可能なインフラストラクチャーストレージクラスのマッピングのみをサポートします。

次の表に、ボリュームモードとアクセスモードの機能が KubeVirt CSI ストレージクラスにどのようにマッピングされるかを示します。

Expand
表5.2 KubeVirt CSI ストレージクラスとアクセスモードおよびボリュームモードのマッピング
インフラストラクチャーの CSI 機能ホステッドクラスターの CSI 機能仮想マシンのライブ移行のサポート注記

RWX: Block または Filesystem

ReadWriteOnce (RWO) Block または Filesystem RWX Block のみ

サポート対象

Filesystem ボリュームモードでは、ホストされた Block モードのパフォーマンスが低下するため、Block モードを使用してください。RWX Block ボリュームモードは、ホステッドクラスターが OpenShift Container Platform 4.16 以降の場合にのみサポートされます。

RWO Block ストレージ

RWO Block ストレージまたは Filesystem

サポート対象外

ライブマイグレーションのサポートが不足しているため、KubeVirt 仮想マシンをホストする基盤となるインフラストラクチャークラスターを更新する機能が影響を受けます。

RWO FileSystem

RWO Block または Filesystem

サポート対象外

ライブマイグレーションのサポートが不足しているため、KubeVirt 仮想マシンをホストする基盤となるインフラストラクチャークラスターを更新する機能が影響を受けます。インフラストラクチャー Filesystem ボリュームモードを使用すると、ホストされた Block モードのパフォーマンスが低下します。

5.3.3.2. 単一の KubeVirt CSI ボリュームスナップショットクラスのマッピング

KubeVirt CSI を使用して、インフラストラクチャーのボリュームスナップショットクラスをホステッドクラスターに公開できます。

手順

  • ボリュームスナップショットクラスをホステッドクラスターにマッピングするには、ホステッドクラスターを作成するときに --infra-volumesnapshot-class-mapping 引数を使用します。以下のコマンドを実行します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \ 
    1
    
      --node-pool-replicas <worker_node_count> \ 
    2
    
      --pull-secret <path_to_pull_secret> \ 
    3
    
      --memory <memory> \ 
    4
    
      --cores <cpu> \ 
    5
    
      --infra-storage-class-mapping=<infrastructure_storage_class>/<hosted_storage_class> \ 
    6
    
      --infra-volumesnapshot-class-mapping=<infrastructure_volume_snapshot_class>/<hosted_volume_snapshot_class> 
    7
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    <infrastructure_storage_class> は、インフラストラクチャークラスターに存在するストレージクラスに置き換えます。<hosted_storage_class> は、ホステッドクラスターに存在するストレージクラスに置き換えます。
    7
    <infrastructure_volume_snapshot_class> は、インフラストラクチャークラスターに存在するボリュームスナップショットクラスに置き換えます。<hosted_volume_snapshot_class> は、ホステッドクラスターに存在するボリュームスナップショットクラスに置き換えます。
    注記

    --infra-storage-class-mapping および --infra-volumesnapshot-class-mapping 引数を使用しない場合、デフォルトのストレージクラスとボリュームスナップショットクラスを使用してホステッドクラスターが作成されます。したがって、インフラストラクチャークラスターでデフォルトのストレージクラスとボリュームスナップショットクラスを設定する必要があります。

5.3.3.3. 複数の KubeVirt CSI ボリュームスナップショットクラスのマッピング

複数のボリュームスナップショットクラスを特定のグループに割り当てることで、それらをホステッドクラスターにマッピングできます。インフラストラクチャーのストレージクラスとボリュームスナップショットクラスは、同じグループに属している場合にのみ相互に互換性があります。

手順

  • 複数のボリュームスナップショットクラスをホステッドクラスターにマッピングするには、ホステッドクラスターを作成するときに group オプションを使用します。以下のコマンドを実行します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \ 
    1
    
      --node-pool-replicas <worker_node_count> \ 
    2
    
      --pull-secret <path_to_pull_secret> \ 
    3
    
      --memory <memory> \ 
    4
    
      --cores <cpu> \ 
    5
    
      --infra-storage-class-mapping=<infrastructure_storage_class>/<hosted_storage_class>,group=<group_name> \ 
    6
    
      --infra-storage-class-mapping=<infrastructure_storage_class>/<hosted_storage_class>,group=<group_name> \
      --infra-storage-class-mapping=<infrastructure_storage_class>/<hosted_storage_class>,group=<group_name> \
      --infra-volumesnapshot-class-mapping=<infrastructure_volume_snapshot_class>/<hosted_volume_snapshot_class>,group=<group_name> \ 
    7
    
      --infra-volumesnapshot-class-mapping=<infrastructure_volume_snapshot_class>/<hosted_volume_snapshot_class>,group=<group_name>
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    <infrastructure_storage_class> は、インフラストラクチャークラスターに存在するストレージクラスに置き換えます。<hosted_storage_class> は、ホステッドクラスターに存在するストレージクラスに置き換えます。<group_name> は、グループ名に置き換えます。たとえば、infra-storage-class-mygroup/hosted-storage-class-mygroup,group=mygroup および infra-storage-class-mymap/hosted-storage-class-mymap,group=mymap です。
    7
    <infrastructure_volume_snapshot_class> は、インフラストラクチャークラスターに存在するボリュームスナップショットクラスに置き換えます。<hosted_volume_snapshot_class> は、ホステッドクラスターに存在するボリュームスナップショットクラスに置き換えます。たとえば、infra-vol-snap-mygroup/hosted-vol-snap-mygroup,group=mygroup および infra-vol-snap-mymap/hosted-vol-snap-mymap,group=mymap です。
5.3.3.4. KubeVirt 仮想マシンのルートボリュームの設定

クラスターの作成時に、--root-volume-storage-class 引数を使用して、KubeVirt 仮想マシンルートボリュームをホストするために使用するストレージクラスを設定できます。

手順

  • KubeVirt 仮想マシンのカスタムのストレージクラスとボリュームサイズを設定するには、次のコマンドを実行します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \ 
    1
    
      --node-pool-replicas <worker_node_count> \ 
    2
    
      --pull-secret <path_to_pull_secret> \ 
    3
    
      --memory <memory> \ 
    4
    
      --cores <cpu> \ 
    5
    
      --root-volume-storage-class <root_volume_storage_class> \ 
    6
    
      --root-volume-size <volume_size> 
    7
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    KubeVirt 仮想マシンルートボリュームをホストするストレージクラスの名前を指定します (例: ocs-storagecluster-ceph-rbd)。
    7
    ボリュームサイズを指定します (例: 64)。

    これにより、PVC 上でホストされる仮想マシンを使用してホステッドクラスターが作成されます。

5.3.3.5. KubeVirt 仮想マシンイメージキャッシュの有効化

KubeVirt 仮想マシンイメージキャッシュを使用すると、クラスターの起動時間とストレージ使用量の両方を最適化できます。KubeVirt 仮想マシンイメージキャッシュは、スマートクローニングと ReadWriteMany アクセスモードが可能なストレージクラスの使用をサポートします。スマートクローン作成の詳細は、smart-cloning を使用したデータボリュームのクローン作成 を参照してください。

イメージのキャッシュは次のように機能します。

  1. VM イメージは、ホステッドクラスターに関連付けられた PVC にインポートされます。
  2. その PVC の一意のクローンは、クラスターにワーカーノードとして追加されるすべての KubeVirt VM に対して作成されます。

イメージキャッシュを使用すると、イメージのインポートが 1 つだけ必要になるため、VM の起動時間が短縮されます。ストレージクラスがコピーオンライトクローン作成をサポートしている場合、クラスター全体のストレージ使用量をさらに削減できます。

手順

  • イメージキャッシュを有効にするには、クラスターの作成時に、次のコマンドを実行して --root-volume-cache-strategy=PVC 引数を使用します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \ 
    1
    
      --node-pool-replicas <worker_node_count> \ 
    2
    
      --pull-secret <path_to_pull_secret> \ 
    3
    
      --memory <memory> \ 
    4
    
      --cores <cpu> \ 
    5
    
      --root-volume-cache-strategy=PVC 
    6
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    イメージキャッシュのストラテジー (例: PVC) を指定します。
5.3.3.6. KubeVirt CSI ストレージのセキュリティーと分離

KubeVirt Container Storage Interface (CSI) は、基盤となるインフラストラクチャークラスターのストレージ機能をホステッドクラスターに拡張します。CSI ドライバーは、インフラストラクチャーストレージクラスとホステッドクラスターへの分離されたセキュアなアクセスを実現するために、次のセキュリティー制約を使用します。

  • ホステッドクラスターのストレージは、他のホステッドクラスターから分離されます。
  • ホステッドクラスター内のワーカーノードは、インフラストラクチャークラスターに直接 API によってアクセスできません。ホステッドクラスターは、制御された KubeVirt CSI インターフェイスを通じてのみ、インフラストラクチャークラスター上にストレージをプロビジョニングできます。
  • ホステッドクラスターは、KubeVirt CSI クラスターコントローラーにアクセスできません。そのため、ホステッドクラスターは、ホステッドクラスターに関連付けられていないインフラストラクチャークラスター上の任意のストレージボリュームにアクセスできません。KubeVirt CSI クラスターコントローラーは、Hosted Control Plane namespace の Pod で実行されます。
  • KubeVirt CSI クラスターコントローラーのロールベースアクセス制御 (RBAC) により、永続ボリューム要求 (PVC) アクセスが Hosted Control Plane namespace だけに制限されます。したがって、KubeVirt CSI コンポーネントは他の namespace からストレージにアクセスできません。
5.3.3.7. etcd ストレージの設定

クラスターの作成時に、--etcd-storage-class 引数を使用して、etcd データをホストするために使用されるストレージクラスを設定できます。

手順

  • etcd のストレージクラスを設定するには、次のコマンドを実行します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \ 
    1
    
      --node-pool-replicas <worker_node_count> \ 
    2
    
      --pull-secret <path_to_pull_secret> \ 
    3
    
      --memory <memory> \ 
    4
    
      --cores <cpu> \ 
    5
    
      --etcd-storage-class=<etcd_storage_class_name> 
    6
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。--etcd-storage-class 引数を指定しない場合は、デフォルトのストレージクラスが使用されます。

5.3.4. hcp CLI を使用して NVIDIA GPU デバイスをアタッチする

OpenShift Virtualization 上のホステッドクラスターの hcp コマンドラインインターフェイス (CLI) を使用して、1 つ以上の NVIDIA グラフィックスプロセッシングユニット (GPU) デバイスをノードプールにアタッチできます。

重要

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

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

前提条件

  • GPU デバイスが存在するノード上のリソースとして NVIDIA GPU デバイスを公開した。詳細は、NVIDIA GPU Operator with OpenShift Virtualization を参照してください。
  • ノードプールに割り当てるために、NVIDIA GPU デバイスをノード上の 拡張リソース として公開した。

手順

  • 次のコマンドを実行すると、クラスターの作成中に GPU デバイスをノードプールにアタッチできます。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \
    1
    
      --node-pool-replicas <worker_node_count> \
    2
    
      --pull-secret <path_to_pull_secret> \
    3
    
      --memory <memory> \
    4
    
      --cores <cpu> \
    5
    
      --host-device-name="<gpu_device_name>,count:<value>" 
    6
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 3)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 16Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    GPU デバイス名と数を指定します (例: --host-device-name="nvidia-a100,count:2")。--host-device-name 引数は、インフラストラクチャーノードからの GPU デバイスの名前と、ノードプール内の各仮想マシンにアタッチする GPU デバイスの数を表すオプション数を取得します。デフォルトは 1 です。たとえば、2 つの GPU デバイスを 3 つのノードプールレプリカにアタッチすると、ノードプール内の 3 つの仮想マシンすべてが 2 つの GPU デバイスにアタッチされます。
    ヒント

    --host-device-name 引数を複数回使用して、タイプの異なる複数デバイスをアタッチできます。

5.3.5. NodePool リソースを使用して NVIDIA GPU デバイスをアタッチする

NodePool リソースの nodepool.spec.platform.kubevirt.hostDevices フィールドを設定することで、1 つ以上の NVIDIA グラフィックスプロセッシングユニット (GPU) デバイスをノードプールにアタッチできます。

重要

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

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

手順

  • 1 つ以上の GPU デバイスをノードプールにアタッチします。

    • 1 つの GPU デバイスをアタッチするには、次の設定例を使用して NodePool リソースを設定します。

      apiVersion: hypershift.openshift.io/v1beta1
      kind: NodePool
      metadata:
        name: <hosted_cluster_name> 
      1
      
        namespace: <hosted_cluster_namespace> 
      2
      
      spec:
        arch: amd64
        clusterName: <hosted_cluster_name>
        management:
          autoRepair: false
          upgradeType: Replace
        nodeDrainTimeout: 0s
        nodeVolumeDetachTimeout: 0s
        platform:
          kubevirt:
            attachDefaultNetwork: true
            compute:
              cores: <cpu> 
      3
      
              memory: <memory> 
      4
      
            hostDevices: 
      5
      
            - count: <count> 
      6
      
              deviceName: <gpu_device_name> 
      7
      
            networkInterfaceMultiqueue: Enable
            rootVolume:
              persistent:
                size: 32Gi
              type: Persistent
          type: KubeVirt
        replicas: <worker_node_count> 
      8
      Copy to Clipboard Toggle word wrap
      1
      ホステッドクラスターの名前を指定します (例: example)。
      2
      ホステッドクラスターの namespace の名前を指定します (例: clusters)。
      3
      CPU の値を指定します (例: 2)。
      4
      メモリーの値を指定します (例: 16Gi)。
      5
      hostDevices フィールドは、ノードプールにアタッチできる各種 GPU デバイスのリストを定義します。
      6
      ノードプール内の各仮想マシンにアタッチする GPU デバイスの数を指定します。たとえば、2 つの GPU デバイスを 3 つのノードプールレプリカにアタッチすると、ノードプール内の 3 つの仮想マシンすべてが 2 つの GPU デバイスにアタッチされます。デフォルトは 1 です。
      7
      GPU デバイス名を指定します (例: nvidia-a100)。
      8
      ワーカー数を指定します (例: 3)。
    • 複数の GPU デバイスをアタッチするには、次の設定例を使用して NodePool リソースを設定します。

      apiVersion: hypershift.openshift.io/v1beta1
      kind: NodePool
      metadata:
        name: <hosted_cluster_name>
        namespace: <hosted_cluster_namespace>
      spec:
        arch: amd64
        clusterName: <hosted_cluster_name>
        management:
          autoRepair: false
          upgradeType: Replace
        nodeDrainTimeout: 0s
        nodeVolumeDetachTimeout: 0s
        platform:
          kubevirt:
            attachDefaultNetwork: true
            compute:
              cores: <cpu>
              memory: <memory>
            hostDevices:
            - count: <count>
              deviceName: <gpu_device_name>
            - count: <count>
              deviceName: <gpu_device_name>
            - count: <count>
              deviceName: <gpu_device_name>
            - count: <count>
              deviceName: <gpu_device_name>
            networkInterfaceMultiqueue: Enable
            rootVolume:
              persistent:
                size: 32Gi
              type: Persistent
          type: KubeVirt
        replicas: <worker_node_count>
      Copy to Clipboard Toggle word wrap

5.3.6. KubeVirt 仮想マシンの削除

GPU パススルーを使用する場合など、KubeVirt 仮想マシン (VM) をライブマイグレーションできない場合は、ホステッドクラスターの NodePool リソースと同時に仮想マシンを退避させる必要があります。そうしないと、ワークロードの drain (Pod の退避) が実行されることなく、コンピュートノードがシャットダウンされる可能性があります。これは、OpenShift Virtualization Operator をアップグレードするときにも発生する可能性があります。同期された再起動を実現するために、hyperconverged リソースに evictionStrategy パラメーターを設定すると、ワークロードの drain が完了した仮想マシンだけを再起動させることができます。

手順

  1. hyperconverged リソースと evictionStrategy パラメーターに許可される値の詳細を確認するには、次のコマンドを入力します。

    $ oc explain hyperconverged.spec.evictionStrategy
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、hyperconverged リソースにパッチを適用します。

    $ oc -n openshift-cnv patch hyperconverged kubevirt-hyperconverged \
      --type=merge \
      -p '{"spec": {"evictionStrategy": "External"}}'
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、ワークロード更新ストラテジーとワークロード更新方法にパッチを適用します。

    $ oc -n openshift-cnv patch hyperconverged kubevirt-hyperconverged \
      --type=merge \
      -p '{"spec": {"workloadUpdateStrategy": {"workloadUpdateMethods": ["LiveMigrate","Evict"]}}}'
    Copy to Clipboard Toggle word wrap

    このパッチを適用すると、可能な場合は仮想マシンをライブマイグレーションし、ライブマイグレーションできない仮想マシンだけを退避させることを指定できます。

検証

  • 次のコマンドを入力して、パッチコマンドが正しく適用されたかどうかを確認します。

    $ oc -n openshift-cnv get hyperconverged kubevirt-hyperconverged -ojsonpath='{.spec.evictionStrategy}'
    Copy to Clipboard Toggle word wrap

    出力例

    External
    Copy to Clipboard Toggle word wrap

5.3.7. topologySpreadConstraint を使用したノードプールの仮想マシンの分散

デフォルトでは、ノードプールによって作成された KubeVirt 仮想マシン (VM) は、仮想マシンを実行する容量を持つ利用可能なノードにスケジュールされます。デフォルトでは、topologySpreadConstraint 制約は複数のノードで仮想マシンをスケジュールするように設定されています。

状況によっては、ノードプールの仮想マシンが同じノード上で実行される場合があります。その場合、可用性の問題が発生する可能性があります。仮想マシンが 1 つのノードに割り当てられるのを回避するには、Descheduler を使用して、topologySpreadConstraint 制約を継続的に適用し、仮想マシンを複数のノードに分散します。

前提条件

  • Kube Descheduler Operator をインストールした。詳細は、「Descheduler のインストール」を参照してください。

手順

  • 次のコマンドを入力して KubeDescheduler カスタムリソース (CR) を開きます。SoftTopologyAndDuplicates および DevKubeVirtRelieveAndMigrate プロファイルを使用するように KubeDescheduler CR を変更して、topologySpreadConstraint 制約の設定を維持します。

    KubeDescheduler CR という名前の cluster は、openshift-kube-descheduler-operator namespace で実行されます。

    $ oc edit kubedescheduler cluster -n openshift-kube-descheduler-operator
    Copy to Clipboard Toggle word wrap

    KubeDescheduler の設定例

    apiVersion: operator.openshift.io/v1
    kind: KubeDescheduler
    metadata:
      name: cluster
      namespace: openshift-kube-descheduler-operator
    spec:
      mode: Automatic
      managementState: Managed
      deschedulingIntervalSeconds: 30 
    1
    
      profiles:
      - SoftTopologyAndDuplicates   
    2
    
      - DevKubeVirtRelieveAndMigrate          
    3
    
      profileCustomizations:
        devDeviationThresholds: AsymmetricLow
        devActualUtilizationProfile: PrometheusCPUCombined
    # ...
    Copy to Clipboard Toggle word wrap

    1
    Descheduler の実行サイクル間の秒数を設定します。
    2
    このプロファイルは、ソフトトポロジー制約 (whenUnsatisfiable: ScheduleAnyway) に従う Pod を退避させます。
    3
    このプロファイルは、ノード間でリソース使用量のバランスを取り、RemovePodsHavingTooManyRestartsLowNodeUtilization などのストラテジーを有効にします。

5.4. 非ベアメタルエージェントマシンでの Hosted Control Plane の管理

非ベアメタルエージェントマシンに Hosted Control Plane をデプロイした後、次のタスクを完了してホステッドクラスターを管理できます。

5.4.1. ホステッドクラスターへのアクセス

ホステッドクラスターにアクセスするには、kubeconfig ファイルと kubeadmin 認証情報をリソースから直接取得するか、hcp コマンドラインインターフェイスを使用して kubeconfig ファイルを生成します。

前提条件

リソースから kubeconfig ファイルと認証情報を直接取得し、ホステッドクラスターにアクセスするには、ホステッドクラスターのアクセスシークレットを理解している必要があります。ホステッドクラスター (ホスティング) のリソースとアクセスシークレットは、ホステッドクラスターの namespace に格納されます。Hosted Control Plane は、Hosted Control Plane の namespace で実行されます。

シークレット名の形式は次のとおりです。

  • kubeconfig シークレット: <hosted_cluster_namespace>-<name>-admin-kubeconfig.たとえば、clusters-hypershift-demo-admin-kubeconfig です。
  • kubeadmin パスワードシークレット: <hosted_cluster_namespace>-<name>-kubeadmin-password。たとえば、clusters-hypershift-demo-kubeadmin-password です。

kubeconfig シークレットには Base64 でエンコードされた kubeconfig フィールドが含まれており、これをデコードしてファイルに保存し、次のコマンドで使用できます。

$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
Copy to Clipboard Toggle word wrap

kubeadmin パスワードシークレットも Base64 でエンコードされます。これをデコードし、そのパスワードを使用して、ホステッドクラスターの API サーバーまたはコンソールにログインできます。

手順

  • hcp CLI を使用してホステッドクラスターにアクセスして kubeconfig ファイルを生成するには、次の手順を実行します。

    1. 次のコマンドを入力して、kubeconfig ファイルを生成します。

      $ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
        --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
      Copy to Clipboard Toggle word wrap
    2. kubeconfig ファイルを保存した後、次のコマンド例を入力して、ホステッドクラスターにアクセスできます。

      $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
      Copy to Clipboard Toggle word wrap

5.4.2. ホステッドクラスターの NodePool オブジェクトのスケーリング

ホステッドクラスターにノードを追加することで、NodePool オブジェクトをスケールアップできます。ノードプールをスケーリングする際には、次の情報を考慮してください。

  • ノードプールによってレプリカをスケーリングすると、マシンが作成されます。クラスター API プロバイダーは、すべてのマシンに対して、ノードプール仕様で指定された要件を満たすエージェントを見つけてインストールします。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
  • ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。Agent を再利用するには、Discovery イメージを使用してエージェントを再起動する必要があります。

手順

  1. NodePool オブジェクトを 2 つのノードにスケーリングします。

    $ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2
    Copy to Clipboard Toggle word wrap

    Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で状態を通過します。

    • binding
    • discovering
    • insufficient
    • installing
    • installing-in-progress
    • added-to-existing-cluster
  2. 以下のコマンドを入力します。

    $ oc -n <hosted_control_plane_namespace> get agent
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER         APPROVED   ROLE          STAGE
    4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign
    d9198891-39f4-4930-a679-65fb142b108b                   true       auto-assign
    da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign
    Copy to Clipboard Toggle word wrap

  3. 以下のコマンドを入力します。

    $ oc -n <hosted_control_plane_namespace> get agent \
      -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    出力例

    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
    BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
    BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
    Copy to Clipboard Toggle word wrap

  4. 次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。

    $ oc extract -n <hosted_cluster_namespace> \
      secret/<hosted_cluster_name>-admin-kubeconfig --to=- \
      > kubeconfig-<hosted_cluster_name>
    Copy to Clipboard Toggle word wrap
  5. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、ホステッドクラスターの OpenShift Container Platform ノードが表示されることを確認します。

    $ oc --kubeconfig kubeconfig-<hosted_cluster_name> get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME           STATUS   ROLES    AGE     VERSION
    ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
    ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

    Cluster Operator は、ワークロードをノードに追加することによってリコンシリエーションを開始します。

  6. 次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。

    $ oc -n <hosted_control_plane_namespace> get machines
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
    hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.x.z
    hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.x.z
    Copy to Clipboard Toggle word wrap

    clusterversion のリコンサイルプロセスは、最終的に、Ingress および Console のクラスター Operator だけが不足しているという段階に到達します。

  7. 以下のコマンドを入力します。

    $ oc --kubeconfig kubeconfig-<hosted_cluster_name> get clusterversion,co
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.x.z: the cluster operator console has not yet successfully rolled out
    
    NAME                                                                             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    clusteroperator.config.openshift.io/console                                      4.12z     False       False         False      11m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused
    clusteroperator.config.openshift.io/csi-snapshot-controller                      4.12z     True        False         False      10m
    clusteroperator.config.openshift.io/dns                                          4.12z     True        False         False      9m16s
    Copy to Clipboard Toggle word wrap

5.4.2.1. ノードプールの追加

名前、レプリカの数、およびエージェントラベルセレクターなどの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。

注記

サポートされるエージェント namespace は、ホステッドクラスターごとに 1 つだけです。そのため、ホステッドクラスターにノードプールを追加する場合、そのノードプールを、単一の InfraEnv リソースから、または同じエージェント namespace にある InfraEnv リソースから取得する必要があります。

手順

  1. ノードプールを作成するには、次の情報を入力します。

    $ hcp create nodepool agent \
      --cluster-name <hosted_cluster_name> \
    1
    
      --name <nodepool_name> \
    2
    
      --node-count <worker_node_count> \
    3
    
      --agentLabelSelector size=medium 
    4
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    <nodepool_name> は、ノードプールの名前に置き換えます (例: <hosted_cluster_name>-extra-cpu)。
    3
    <worker_node_count> は、ワーカーノード数 (例: 2) に置き換えます。
    4
    --agentLabelSelector フラグは任意です。ノードプールは、size=medium ラベルを持つエージェントを使用します。
  2. clusters namespace 内の nodepool リソースをリスト表示して、ノードプールのステータスを確認します。

    $ oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。

    $ oc extract -n <hosted_control_plane_namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm
    Copy to Clipboard Toggle word wrap

    出力例

    hostedcluster-secrets/kubeconfig
    Copy to Clipboard Toggle word wrap

  4. しばらくしてから、次のコマンドを入力してノードプールのステータスを確認できます。

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを入力して、使用可能なノードプールの数が予想されるノードプールの数と一致することを確認します。

    $ oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap
5.4.2.2. ホステッドクラスターのノード自動スケーリングの有効化

ホステッドクラスターにさらに容量が必要で、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいワーカーノードをインストールできます。

手順

  1. 自動スケーリングを有効にするには、次のコマンドを入力します。

    $ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \
      --type=json \
      -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
    Copy to Clipboard Toggle word wrap
    注記

    この例では、ノードの最小数は 2、最大数は 5 です。追加できるノードの最大数は、プラットフォームによって制限される場合があります。たとえば、Agent プラットフォームを使用する場合、ノードの最大数は使用可能なエージェントの数によって制限されます。

  2. 新しいノードを必要とするワークロードを作成します。

    1. 次の例を使用して、ワークロード設定を含む YAML ファイルを作成します。

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        creationTimestamp: null
        labels:
          app: reversewords
        name: reversewords
        namespace: default
      spec:
        replicas: 40
        selector:
          matchLabels:
            app: reversewords
        strategy: {}
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: reversewords
          spec:
            containers:
            - image: quay.io/mavazque/reversewords:latest
              name: reversewords
              resources:
                requests:
                  memory: 2Gi
      status: {}
      Copy to Clipboard Toggle word wrap
    2. ファイルを workload-config.yaml として保存します。
    3. 以下のコマンドを入力して、YAML を適用します。

      $ oc apply -f workload-config.yaml
      Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。

    $ oc extract -n <hosted_cluster_namespace> \
      secret/<hosted_cluster_name>-admin-kubeconfig \
      --to=./hostedcluster-secrets --confirm
    Copy to Clipboard Toggle word wrap

    出力例

    hostedcluster-secrets/kubeconfig
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを入力して、新しいノードが Ready ステータスであるかどうかを確認できます。

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
    Copy to Clipboard Toggle word wrap
  5. ノードを削除するには、次のコマンドを入力してワークロードを削除します。

    $ oc --kubeconfig ./hostedcluster-secrets -n <namespace> \
      delete deployment <deployment_name>
    Copy to Clipboard Toggle word wrap
  6. 数分間待ちます。その間に、容量の追加が必要にならないようにします。Agent プラットフォームでエージェントが使用停止され、再利用できるようになります。次のコマンドを入力すると、ノードが削除されたことを確認できます。

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
    Copy to Clipboard Toggle word wrap
    注記

    IBM Z® エージェントの場合、プロセッサーリソース/システムマネージャー (PR/SM) モードで OSA ネットワークデバイスを使用している場合、自動スケーリングはサポートされません。新しいエージェントはスケールダウンプロセス中に結合されるため、古いエージェントを手動で削除し、ノードプールをスケールアップする必要があります。

5.4.2.3. ホステッドクラスターのノードの自動スケーリングを無効にする

ノードの自動スケーリングを無効にするには、次の手順を実行します。

手順

  • ホステッドクラスターのノードの自動スケーリングを無効にするには、次のコマンドを入力します。

    $ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \
      --type=json \
      -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify_value_to_scale_replicas>]'
    Copy to Clipboard Toggle word wrap

    このコマンドは、YAML ファイルから "spec.autoScaling" を削除し、"spec.replicas" を追加し、"spec.replicas" を指定の整数値に設定します。

5.4.3. 非ベアメタルエージェントマシン上のホステッドクラスターでの Ingress の処理

すべての OpenShift Container Platform クラスターには、通常、外部 DNS レコードが関連付けられているデフォルトのアプリケーション Ingress コントローラーがあります。たとえば、ベースドメイン krnl.esexample という名前のホステッドクラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es がルーティング可能であると予想することができます。

手順

*.apps ドメインのロードバランサーとワイルドカード DNS レコードを設定するには、ゲストクラスターで次のアクションを実行します。

  1. MetalLB Operator の設定を含む YAML ファイルを作成して MetalLB をデプロイします。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: metallb
      labels:
        openshift.io/cluster-monitoring: "true"
      annotations:
        workload.openshift.io/allowed: management
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: metallb-operator-operatorgroup
      namespace: metallb
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: metallb-operator
      namespace: metallb
    spec:
      channel: "stable"
      name: metallb-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap
  2. ファイルを metallb-operator-config.yaml として保存します。
  3. 以下のコマンドを入力して設定を適用します。

    $ oc apply -f metallb-operator-config.yaml
    Copy to Clipboard Toggle word wrap
  4. Operator の実行後、MetalLB インスタンスを作成します。

    1. MetalLB インスタンスの設定を含む YAML ファイルを作成します。

      apiVersion: metallb.io/v1beta1
      kind: MetalLB
      metadata:
        name: metallb
        namespace: metallb
      Copy to Clipboard Toggle word wrap
    2. ファイルを metallb-instance-config.yaml として保存します。
    3. 次のコマンドを入力して、MetalLB インスタンスを作成します。

      $ oc apply -f metallb-instance-config.yaml
      Copy to Clipboard Toggle word wrap
  5. 単一の IP アドレスを含む IPAddressPool リソースを作成します。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。

    1. 以下の例のような内容で、ipaddresspool.yaml などのファイルを作成します。

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        namespace: metallb
        name: <ip_address_pool_name> 
      1
      
      spec:
        addresses:
          - <ingress_ip>-<ingress_ip> 
      2
      
        autoAssign: false
      Copy to Clipboard Toggle word wrap
      1
      IPAddressPool リソース名を指定します。
      2
      環境の IP アドレスを指定します。たとえば、192.168.122.23 です。
    2. 次のコマンドを入力して、IP アドレスプールの設定を適用します。

      $ oc apply -f ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
  6. L2 アドバタイズメントを作成します。

    1. 以下の例のような内容で、l2advertisement.yaml などのファイルを作成します。

      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: <l2_advertisement_name> 
      1
      
        namespace: metallb
      spec:
        ipAddressPools:
         - <ip_address_pool_name> 
      2
      Copy to Clipboard Toggle word wrap
      1
      L2Advertisement リソース名を指定します。
      2
      IPAddressPool リソース名を指定します。
    2. 次のコマンドを入力して設定を適用します。

      $ oc apply -f l2advertisement.yaml
      Copy to Clipboard Toggle word wrap
  7. LoadBalancer タイプのサービスを作成すると、MetalLB はサービスに外部 IP アドレスを追加します。

    1. metallb-loadbalancer-service.yaml という名前の YAML ファイルを作成して、Ingress トラフィックを Ingress デプロイメントにルーティングする新しいロードバランサーサービスを設定します。

      kind: Service
      apiVersion: v1
      metadata:
        annotations:
         metallb.io/address-pool: ingress-public-ip
        name: metallb-ingress
        namespace: openshift-ingress
      spec:
        ports:
          - name: http
            protocol: TCP
            port: 80
            targetPort: 80
          - name: https
            protocol: TCP
            port: 443
            targetPort: 443
        selector:
          ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        type: LoadBalancer
      Copy to Clipboard Toggle word wrap
    2. metallb-loadbalancer-service.yaml ファイルを保存します。
    3. YAML 設定を適用するには、次のコマンドを入力します。

      $ oc apply -f metallb-loadbalancer-service.yaml
      Copy to Clipboard Toggle word wrap
    4. 次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。

      $ curl -kI https://console-openshift-console.apps.example.krnl.es
      Copy to Clipboard Toggle word wrap

      出力例

      HTTP/1.1 200 OK
      Copy to Clipboard Toggle word wrap

    5. clusterversionclusteroperator の値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。

      $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
      clusterversion.config.openshift.io/version   4.x.y      True        False        3m32s   Cluster version is 4.x.y
      
      NAME                                                                             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
      clusteroperator.config.openshift.io/console                                      4.x.y     True        False         False      3m50s
      clusteroperator.config.openshift.io/ingress                                      4.x.y     True        False         False      53m
      Copy to Clipboard Toggle word wrap

      <4.x.y> は、使用するサポート対象の OpenShift Container Platform バージョン (例: 4.19.0-multi) に置き換えます。

5.4.4. 非ベアメタルエージェントマシンでマシンのヘルスチェックを有効にする

ベアメタル上でマシンのヘルスチェックを有効にして、異常なマネージドクラスターノードを自動的に修復および置き換えることができます。マネージドクラスターにインストールする準備ができている追加のエージェントマシンが必要です。

マシンのヘルスチェックを有効にする前に、次の制限を考慮してください。

  • MachineHealthCheck オブジェクトを変更することはできません。
  • マシンヘルスチェックでは、少なくとも 2 つのノードが 8 分以上 False または Unknown ステータスのままである場合にのみ、ノードが置き換えられます。

マネージドクラスターノードのマシンヘルスチェックを有効にすると、ホステッドクラスターに MachineHealthCheck オブジェクトが作成されます。

手順

ホステッドクラスターでマシンのヘルスチェックを有効にするには、NodePool リソースを変更します。以下の手順を実行します。

  1. NodePool リソースの spec.nodeDrainTimeout 値が 0s より大きいことを確認します。<hosted_cluster_namespace> をホステッドクラスター namespace の名前に置き換え、<nodepool_name> をノードプール名に置き換えます。以下のコマンドを実行します。

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep nodeDrainTimeout
    Copy to Clipboard Toggle word wrap

    出力例

    nodeDrainTimeout: 30s
    Copy to Clipboard Toggle word wrap

  2. spec.nodeDrainTimeout 値が 0s より大きくない場合は、次のコマンドを実行して値を変更します。

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec":{"nodeDrainTimeout": "30m"}}' --type=merge
    Copy to Clipboard Toggle word wrap
  3. NodePool リソースで spec.management.autoRepair フィールドを true に設定して、マシンのヘルスチェックを有効にします。以下のコマンドを実行します。

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":true}}}' --type=merge
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、NodePool リソースが autoRepair: true 値で更新されていることを確認します。

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair
    Copy to Clipboard Toggle word wrap

5.4.5. 非ベアメタルエージェントマシンでマシンヘルスチェックを無効にする

マネージドクラスターノードのマシンのヘルスチェックを無効にするには、NodePool リソースを変更します。

手順

  1. NodePool リソースで spec.management.autoRepair フィールドを false に設定して、マシンのヘルスチェックを無効にします。以下のコマンドを実行します。

    $ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":false}}}' --type=merge
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、NodePool リソースが autoRepair: false 値で更新されていることを確認します。

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair
    Copy to Clipboard Toggle word wrap

5.5. IBM Power での Hosted Control Plane の管理

IBM Power に Hosted Control Plane をデプロイした後、次のタスクを完了してホステッドクラスターを管理できます。

5.5.1. IBM Power 上の Hosted Control Plane 用の InfraEnv リソースを作成する

InfraEnv は、ライブ ISO を開始しているホストがエージェントとして参加できる環境です。この場合、エージェントは Hosted Control Plane と同じ namespace に作成されます。

IBM Power コンピュートノード用の 64 ビット x86 ベアメタル上に、Hosted Control Plane 用の InfraEnv リソースを作成できます。

手順

  1. InfraEnv リソースを設定するための YAML ファイルを作成します。以下の例を参照してください。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: <hosted_cluster_name> \
    1
    
      namespace: <hosted_control_plane_namespace> \
    2
    
    spec:
      cpuArchitecture: ppc64le
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: <path_to_ssh_public_key> 
    3
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    <hosted_control_plane_namespace> は、Hosted Control Plane の namespace の名前 (例: clusters-hosted) に置き換えます。
    3
    <path_to_ssh_public_key> は、SSH 公開鍵へのパスに置き換えます。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
  2. ファイルを infraenv-config.yaml として保存します。
  3. 次のコマンドを入力して設定を適用します。

    $ oc apply -f infraenv-config.yaml
    Copy to Clipboard Toggle word wrap
  4. URL を取得してライブ ISO をダウンロードし、IBM Power マシンがエージェントとして参加できるようにするには、以下のコマンドを入力します。

    $ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> \
      -o json
    Copy to Clipboard Toggle word wrap

5.5.2. InfraEnv リソースへの IBM Power エージェントの追加

エージェントを追加するには、ライブ ISO で開始するようにマシンを手動で設定できます。

手順

  1. ライブ ISO をダウンロードし、それを使用してベアメタルまたは仮想マシン (VM) ホストを起動します。ライブ ISO の URL は、InfraEnv リソースの status.isoDownloadURL フィールドにあります。起動時に、ホストは Assisted Service と通信し、InfraEnv リソースと同じ namespace にエージェントとして登録します。
  2. エージェントとそのプロパティーの一部を一覧表示するには、次のコマンドを入力します。

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
    86f7ac75-4fc4-4b36-8130-40fa12602218                        auto-assign
    e57a637f-745b-496e-971d-1abbf03341ba                        auto-assign
    Copy to Clipboard Toggle word wrap

  3. 各エージェントが作成された後、必要に応じてエージェントの installation_disk_idhostname を設定できます。

    1. エージェントの installation_disk_id フィールドを設定するには、次のコマンドを入力します。

      $ oc -n <hosted_control_plane_namespace> patch agent <agent_name> -p '{"spec":{"installation_disk_id":"<installation_disk_id>","approved":true}}' --type merge
      Copy to Clipboard Toggle word wrap
    2. エージェントの hostname フィールドを設定するには、次のコマンドを入力します。

      $ oc -n <hosted_control_plane_namespace> patch agent <agent_name> -p '{"spec":{"hostname":"<hostname>","approved":true}}' --type merge
      Copy to Clipboard Toggle word wrap

検証

  • エージェントの使用が承認されていることを確認するには、次のコマンドを入力します。

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
    86f7ac75-4fc4-4b36-8130-40fa12602218             true       auto-assign
    e57a637f-745b-496e-971d-1abbf03341ba             true       auto-assign
    Copy to Clipboard Toggle word wrap

5.5.3. IBM Power 上のホステッドクラスターの NodePool オブジェクトのスケーリング

NodePool オブジェクトは、ホステッドクラスターの作成時に作成されます。NodePool オブジェクトをスケーリングすることで、Hosted Control Plane にさらに多くのコンピュートノードを追加できます。

手順

  1. 次のコマンドを実行して、NodePool オブジェクトを 2 つのノードにスケーリングします。

    $ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2
    Copy to Clipboard Toggle word wrap

    Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で移行フェーズを通過します。

    • binding
    • discovering
    • insufficient
    • installing
    • installing-in-progress
    • added-to-existing-cluster
  2. 次のコマンドを実行して、スケールされた特定のエージェントのステータスを確認します。

    $ oc -n <hosted_control_plane_namespace> get agent \
      -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    出力例

    BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
    BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、移行フェーズを表示します。

    $ oc -n <hosted_control_plane_namespace> get agent
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                   CLUSTER            APPROVED       ROLE          STAGE
    50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   hosted-forwarder   true           auto-assign
    5e498cd3-542c-e54f-0c58-ed43e28b568a                      true           auto-assign
    da503cf1-a347-44f2-875c-4960ddb04091   hosted-forwarder   true           auto-assign
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、ホステッドクラスターにアクセスするための kubeconfig ファイルを生成します。

    $ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
      --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
    Copy to Clipboard Toggle word wrap
  5. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、OpenShift Container Platform ノードが表示されることを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             STATUS   ROLES    AGE      VERSION
    worker-zvm-0.hostedn.example.com Ready    worker   5m41s    v1.24.0+3882f8f
    worker-zvm-1.hostedn.example.com Ready    worker   6m3s     v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

  6. 次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。

    $ oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                CLUSTER                  NODENAME                           PROVIDERID                                     PHASE     AGE   VERSION
    hosted-forwarder-79558597ff-5tbqp   hosted-forwarder-crqq5   worker-zvm-0.hostedn.example.com   agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   Running   41h   4.15.0
    hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0
    Copy to Clipboard Toggle word wrap

  7. 次のコマンドを実行して、クラスターのバージョンを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
    clusterversion.config.openshift.io/version   4.15.0        True        False         40h     Cluster version is 4.15.0
    Copy to Clipboard Toggle word wrap

  8. 次のコマンドを実行して、クラスター Operator のステータスを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
    Copy to Clipboard Toggle word wrap

    クラスターの各コンポーネントについて、出力に次のクラスター Operator ステータスが表示されます。

    • NAME
    • VERSION
    • AVAILABLE
    • PROGRESSING
    • DEGRADED
    • SINCE
    • MESSAGE

5.6. OpenStack 上の Hosted Control Plane の管理

Red Hat OpenStack Platform (RHOSP) エージェントマシンに Hosted Control Plane をデプロイした後、次のタスクを実行してホステッドクラスターを管理できます。

5.6.1. ホステッドクラスターへのアクセス

oc CLI を使用してリソースから kubeconfig シークレットを直接抽出することにより、Red Hat OpenStack Platform (RHOSP) 上のホステッドクラスターにアクセスできます。

ホステッドクラスター (ホスティング) のリソースとアクセスシークレットは、ホステッドクラスターの namespace に格納されます。Hosted Control Plane は、Hosted Control Plane の namespace で実行されます。

シークレット名の形式は次のとおりです。

  • kubeconfig シークレット: <hosted_cluster_namespace>-<name>-admin-kubeconfig.たとえば、clusters-hypershift-demo-admin-kubeconfig です。
  • kubeadmin パスワードシークレット: <hosted_cluster_namespace>-<name>-kubeadmin-password。たとえば、clusters-hypershift-demo-kubeadmin-password です。

kubeconfig シークレットには、Base64 でエンコードされた kubeconfig フィールドが含まれています。kubeadmin パスワードシークレットも Base64 でエンコードされています。これを抽出し、そのパスワードを使用して API サーバーまたはホステッドクラスターのコンソールにログインできます。

前提条件

  • oc CLI がインストールされている。

手順

  1. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。

    $ oc extract -n <hosted_cluster_namespace> \
      secret/<hosted_cluster_name>-admin-kubeconfig \
      --to=./hostedcluster-secrets --confirm
    Copy to Clipboard Toggle word wrap

    出力例

    hostedcluster-secrets/kubeconfig
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力して、ホステッドクラスターのノードのリストを表示し、アクセスを検証します。

    $ oc --kubeconfig ./hostedcluster-secrets/kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

5.6.2. ホステッドクラスターのノード自動スケーリングの有効化

Red Hat OpenStack Platform (RHOSP) 上のホステッドクラスターでさらに容量が必要になり、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいワーカーノードをインストールできます。

手順

  1. 自動スケーリングを有効にするには、次のコマンドを入力します。

    $ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \
      --type=json \
      -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
    Copy to Clipboard Toggle word wrap
  2. 新しいノードを必要とするワークロードを作成します。

    1. 次の例を使用して、ワークロード設定を含む YAML ファイルを作成します。

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: reversewords
        name: reversewords
        namespace: default
      spec:
        replicas: 40
        selector:
          matchLabels:
            app: reversewords
        template:
          metadata:
            labels:
              app: reversewords
          spec:
            containers:
            - image: quay.io/mavazque/reversewords:latest
              name: reversewords
              resources:
                requests:
                  memory: 2Gi
      Copy to Clipboard Toggle word wrap
    2. ファイルを workload-config.yaml という名前で保存します。
    3. 以下のコマンドを入力して、YAML を適用します。

      $ oc apply -f workload-config.yaml
      Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。

    $ oc extract -n <hosted_cluster_namespace> \
      secret/<hosted_cluster_name>-admin-kubeconfig \
      --to=./hostedcluster-secrets --confirm
    Copy to Clipboard Toggle word wrap

    出力例

    hostedcluster-secrets/kubeconfig
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを入力して、新しいノードが Ready ステータスであるかどうかを確認できます。

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
    Copy to Clipboard Toggle word wrap
  5. ノードを削除するには、次のコマンドを入力してワークロードを削除します。

    $ oc --kubeconfig ./hostedcluster-secrets -n <namespace> \
      delete deployment <deployment_name>
    Copy to Clipboard Toggle word wrap
  6. 数分間待ちます。その間に、容量の追加が必要にならないようにします。次のコマンドを入力すると、ノードが削除されたことを確認できます。

    $ oc --kubeconfig ./hostedcluster-secrets get nodes
    Copy to Clipboard Toggle word wrap

5.6.3. アベイラビリティーゾーンのノードプールの設定

複数の Red Hat OpenStack Platform (RHOSP) Nova アベイラビリティーゾーンにノードプールを分散させると、ホステッドクラスターの高可用性を向上できます。

注記

アベイラビリティーゾーンは必ずしも障害ドメインに対応するわけではなく、本質的に高可用性の利点を提供するものではありません。

前提条件

  • ホステッドクラスターを作成した。
  • 管理クラスターにアクセスできる。
  • hcp および oc CLI がインストールされている。

手順

  1. ニーズに合わせて適切な環境変数を設定します。たとえば、az1 アベイラビリティーゾーンに 2 台の追加マシンを作成する場合は、次のように入力します。

    $ export NODEPOOL_NAME="${CLUSTER_NAME}-az1" \
      && export WORKER_COUNT="2" \
      && export FLAVOR="m1.xlarge" \
      && export AZ="az1"
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、環境変数を使用してノードプールを作成します。

    $ hcp create nodepool openstack \
      --cluster-name <cluster_name> \
      --name $NODEPOOL_NAME \
      --replicas $WORKER_COUNT \
      --openstack-node-flavor $FLAVOR \
      --openstack-node-availability-zone $AZ
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <cluster_name>
    ホステッドクラスターの名前を指定します。
  3. 次のコマンドを実行して、クラスターの namespace 内の nodepool リソースをリスト表示し、ノードプールのステータスを確認します。

    $ oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
    example                   example         5               5               False         False        4.17.0
    example-az1               example         2                               False         False                  True              True             Minimum availability requires 2 replicas, current 0 available
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、ホステッドクラスターでノードが起動するのを確認します。

    $ oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                      STATUS   ROLES    AGE     VERSION
    ...
    example-extra-az-zh9l5    Ready    worker   2m6s    v1.27.4+18eadca
    example-extra-az-zr8mj    Ready    worker   102s    v1.27.4+18eadca
    ...
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを実行して、ノードプールが作成されたことを確認します。

    $ oc get nodepools --namespace clusters
    Copy to Clipboard Toggle word wrap

    出力例

    NAME              CLUSTER         DESIRED   CURRENT   AVAILABLE   PROGRESSING   MESSAGE
    <node_pool_name>  <cluster_name>  2         2         2           False         All replicas are available
    Copy to Clipboard Toggle word wrap

5.6.4. ノードプールの追加ポートの設定

SR-IOV や複数のネットワークなどの高度なネットワーク環境をサポートするために、ノードプールに追加ポートを設定できます。

5.6.4.1. ノードプールの追加ポートの使用例

ノードプールに追加ポートを設定する一般的な理由は次のとおりです。

SR-IOV (Single Root I/O Virtualization)
1 つの物理ネットワークデバイスを、複数の Virtual Function (VF) として見せかけることを可能にします。追加のポートをノードプールに割り当てることで、ワークロードで SR-IOV インターフェイスを使用して、低レイテンシーで高パフォーマンスのネットワークを実現できます。
DPDK (Data Plane Development Kit)
カーネルを迂回して、ユーザー空間で高速なパケット処理を提供します。追加ポートが割り当てられたノードプールは、DPDK を使用してネットワークパフォーマンスを向上させるワークロード用に、インターフェイスを公開できます。
NFS 上の Manila RWX ボリューム
NFS 上の ReadWriteMany (RWX) ボリュームをサポートし、複数のノードが共有ストレージにアクセスできるようにします。ノードプールに追加ポートを割り当てると、ワークロードが Manila によって使用される NFS ネットワークに到達できるようになります。
Multus CNI
Pod が複数のネットワークインターフェイスに接続できるようにします。追加ポートが割り当てられたノードプールは、デュアルスタック接続やトラフィック分離など、セカンダリーネットワークインターフェイスを必要とするユースケースに対応します。
5.6.4.2. ノードプールの追加ポートのオプション

--openstack-node-additional-port フラグを使用して、OpenStack 上のホステッドクラスター内のノードに追加ポートを割り当てることができます。このフラグは、パラメーターのコンマ区切りリストを受け取ります。パラメーターを複数回使用すると、複数の追加ポートをノードに割り当てることができます。

パラメーターは以下のとおりです。

Expand
パラメーター説明必須デフォルト

network-id

ノードに割り当てるネットワークの ID。

はい

該当なし

vnic-type

ポートに使用する VNIC タイプ。指定されていない場合、Neutron によってデフォルトのタイプ normal が使用されます。

いいえ

該当なし

disable-port-security

ポートのポートセキュリティーを無効にするかどうか。指定されていない場合、ネットワークレベルでポートセキュリティーが明示的に無効にされていない限り、Neutron によってセキュリティーが有効化されます。

いいえ

該当なし

address-pairs

ポートに割り当てる IP アドレスペアのリスト。形式は ip_address=mac_address です。ハイフン (-) で区切って複数のペアを指定できます。mac_address の部分は任意です。

いいえ

該当なし

5.6.4.3. ノードプールの追加ポートの作成

Red Hat OpenStack Platform (RHOSP) 上で動作するホステッドクラスター用のノードプールに追加ポートを設定できます。

前提条件

  • ホステッドクラスターを作成した。
  • 管理クラスターにアクセスできる。
  • hcp CLI がインストールされている。
  • 追加のネットワークが RHOSP に作成されている。
  • ホステッドクラスターによって使用されるプロジェクトが、追加のネットワークにアクセスできる。
  • 「ノードプールの追加ポートのオプション」に記載されているオプションを確認した。

手順

  • hcp create nodepool openstack コマンドに --openstack-node-additional-port オプションを付けて実行し、追加ポートが割り当てられたホステッドクラスターを作成します。以下に例を示します。

    $ hcp create nodepool openstack \
      --cluster-name <cluster_name> \
      --name <nodepool_name> \
      --replicas <replica_count> \
      --openstack-node-flavor <flavor> \
      --openstack-node-additional-port "network-id=<sriov_net_id>,vnic-type=direct,disable-port-security=true" \
      --openstack-node-additional-port "network-id=<lb_net_id>,address-pairs:192.168.0.1-192.168.0.2"
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <cluster_name>
    ホステッドクラスターの名前を指定します。
    <nodepool_name>
    ノードプールの名前を指定します。
    <replica_count>
    必要なレプリカの数を指定します。
    <flavor>
    使用する RHOSP フレーバーを指定します。
    <sriov_net_id>
    SR-IOV ネットワーク ID を指定します。
    <lb_net_id>
    ロードバランサーのネットワーク ID を指定します。

5.6.5. ノードプールの追加ポートの設定

クラウドネイティブネットワーク機能 (CNF) などの高パフォーマンスワークロード向けに、RHOSP 上のホステッドクラスターノードのパフォーマンスをチューニングできます。パフォーマンスチューニングには、RHOSP リソースの設定、パフォーマンスプロファイルの作成、チューニング済みの NodePool リソースのデプロイ、SR-IOV デバイスサポートの有効化が含まれます。

CNF はクラウドネイティブ環境で動作するように設計されています。CNF は、ルーティング、ファイアウォール、負荷分散などのネットワークサービスを提供できます。CNF を実行するために、高性能なコンピューティングおよびネットワークデバイスを使用してノードプールを設定できます。

5.6.5.1. ホステッドクラスターノードのパフォーマンスチューニング

パフォーマンスプロファイルを作成し、チューニング済みの NodePool リソースをデプロイして、Red Hat OpenStack Platform (RHOSP) Hosted Control Plane で高パフォーマンスワークロードを実行します。

前提条件

  • 専用の CPU、メモリー、ホストアグリゲートに関する情報など、ワークロードを実行するのに必要なリソースを含む RHOSP フレーバーがある。
  • SR-IOV または DPDK 対応 NIC に割り当てられた RHOSP ネットワークがある。ホステッドクラスターによって使用されるプロジェクトでネットワークが利用可能である必要があります。

手順

  1. perfprofile.yaml という名前のファイルに、要件を満たすパフォーマンスプロファイルを作成します。以下に例を示します。

    config map のパフォーマンスプロファイルの例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: perfprof-1
      namespace: clusters
    data:
      tuning: |
        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cnf-performanceprofile
          namespace: "${HYPERSHIFT_NAMESPACE}"
        data:
          tuning: |
            apiVersion: performance.openshift.io/v2
            kind: PerformanceProfile
            metadata:
              name: cnf-performanceprofile
            spec:
              additionalKernelArgs:
                - nmi_watchdog=0
                - audit=0
                - mce=off
                - processor.max_cstate=1
                - idle=poll
                - intel_idle.max_cstate=0
                - amd_iommu=on
              cpu:
                isolated: "${CPU_ISOLATED}"
                reserved: "${CPU_RESERVED}"
              hugepages:
                defaultHugepagesSize: "1G"
                pages:
                  - count: ${HUGEPAGES}
                    node: 0
                    size: 1G
              nodeSelector:
                node-role.kubernetes.io/worker: ''
              realTimeKernel:
                enabled: false
              globallyDisableIrqLoadBalancing: true
    Copy to Clipboard Toggle word wrap

    重要

    HyperShift Operator の namespace、分離された CPU と予約済み CPU、および huge page 数の環境変数がまだ設定されていない場合は、パフォーマンスプロファイルを適用する前に環境変数を作成してください。

  2. 次のコマンドを実行して、パフォーマンスプロファイル設定を適用します。

    $ oc apply -f perfprof.yaml
    Copy to Clipboard Toggle word wrap
  3. クラスターの名前に CLUSTER_NAME 環境変数がまだ設定されていない場合は、これを定義します。
  4. 次のコマンドを実行して、ノードプール名の環境変数を設定します。

    $ export NODEPOOL_NAME=$CLUSTER_NAME-cnf
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、フレーバーの環境変数を設定します。

    $ export FLAVOR="m1.xlarge.nfv"
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、パフォーマンスプロファイルを使用するノードプールを作成します。

    $ hcp create nodepool openstack \
      --cluster-name $CLUSTER_NAME \
      --name $NODEPOOL_NAME \
      --node-count 0 \
      --openstack-node-flavor $FLAVOR
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、PerformanceProfile リソースを参照するようにノードプールにパッチを適用します。

    $ oc patch nodepool -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \
      -p '{"spec":{"tuningConfig":[{"name":"cnf-performanceprofile"}]}}' --type=merge
    Copy to Clipboard Toggle word wrap
  8. 次のコマンドを実行してノードプールをスケーリングします。

    $ oc scale nodepool/$CLUSTER_NAME --namespace ${HYPERSHIFT_NAMESPACE} --replicas=1
    Copy to Clipboard Toggle word wrap
  9. ノードの準備が完了するまで待ちます。

    1. 次のコマンドを実行して、ノードの準備が完了するまで待ちます。

      $ oc wait --for=condition=UpdatingConfig=True nodepool \
        -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \
        --timeout=5m
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、設定の更新が完了するまで待ちます。

      $ oc wait --for=condition=UpdatingConfig=False nodepool \
        -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \
        --timeout=30m
      Copy to Clipboard Toggle word wrap
    3. 次のコマンドを実行して、すべてのノードが正常になるまで待ちます。

      $ oc wait --for=condition=AllNodesHealthy nodepool \
        -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \
        --timeout=5m
      Copy to Clipboard Toggle word wrap
注記

ノードに SSH 接続するか、oc debug コマンドを使用すると、パフォーマンス設定を確認できます。

5.6.5.2. ホステッドクラスターでの SR-IOV Network Operator の有効化

SR-IOV Network Operator を有効にして、NodePool リソースによってデプロイされたノード上の SR-IOV 対応デバイスを管理できます。この Operator はホステッドクラスターで実行され、ラベル付きのワーカーノードを必要とします。

手順

  1. 次のコマンドを実行して、ホステッドクラスター用の kubeconfig ファイルを生成します。

    $ hcp create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、kubeconfig リソースの環境変数を作成します。

    $ export KUBECONFIG=$CLUSTER_NAME-kubeconfig
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、各ワーカーノードに SR-IOV 機能を示すラベルを付けます。

    $ oc label node <worker_node_name> feature.node.kubernetes.io/network-sriov.capable=true
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <worker_node_name>
    ホステッドクラスター内のワーカーノードの名前を指定します。
  4. 「SR-IOV Network Operator のインストール」の手順に従って、ホステッドクラスターに SR-IOV Network Operator をインストールします。
  5. インストール後、スタンドアロンクラスターと同じプロセスを使用して、ホステッドクラスターで SR-IOV ワークロードを設定します。

第6章 非接続環境での Hosted Control Plane のデプロイ

6.1. 非接続環境の Hosted Control Plane の概要

Hosted Control Plane のコンテキストでは、非接続環境は、インターネットに接続されておらず、Hosted Control Plane をベースとして使用する OpenShift Container Platform デプロイメントです。Hosted Control Plane は、ベアメタルまたは OpenShift Virtualization 上の非接続環境にデプロイできます。

非接続環境の Hosted Control Plane は、スタンドアロンの OpenShift Container Platform とは異なる動作をします。

  • コントロールプレーンは、管理クラスター内にあります。コントロールプレーンは、Control Plane Operator によって Hosted Control Plane の Pod が実行および管理される場所です。
  • データプレーンは、ホステッドクラスターのワーカー内にあります。データプレーンは、HostedClusterConfig Operator によって管理されるワークロードやその他の Pod が実行される場所です。

Pod は、実行される場所に応じて、管理クラスターで作成された ImageDigestMirrorSet (IDMS) または ImageContentSourcePolicy (ICSP) か、ホステッドクラスターのマニフェストの spec フィールドに設定されている ImageContentSource の影響を受けます。spec フィールドは、ホステッドクラスター上の IDMS オブジェクトに変換されます。

Hosted Control Plane は、IPv4、IPv6、デュアルスタックネットワーク上の非接続環境にデプロイできます。IPv4 は、非接続環境に Hosted Control Plane をデプロイするための最もシンプルなネットワーク設定の 1 つです。IPv4 範囲では、IPv6 またはデュアルスタック設定よりも必要な外部コンポーネントが少なくなります。非接続環境の OpenShift Virtualization 上の Hosted Control Plane の場合は、IPv4 またはデュアルスタックネットワークのいずれかを使用してください。

6.2. 非接続環境で OpenShift Virtualization に Hosted Control Plane をデプロイする

Hosted Control Plane を非接続環境でデプロイする場合、使用するプラットフォームに応じて手順の一部が異なります。以下の手順は、OpenShift Virtualization へのデプロイに固有のものです。

6.2.1. 前提条件

  • 管理クラスターとして機能する、非接続の OpenShift Container Platform 環境がある。
  • イメージをミラーリングするための内部レジストリーがある。詳細は、非接続インストールミラーリングについて を参照してください。

6.2.2. 非接続環境で Hosted Control Plane のイメージミラーリングを設定する

イメージミラーリングは、registry.redhat.comquay.io などの外部レジストリーからイメージを取得し、プライベートレジストリーに保存するプロセスです。

次の手順では、ImageSetConfiguration オブジェクトを使用するバイナリーである、oc-mirror ツールが使用されます。このファイルで、以下の情報を指定できます。

  • ミラーリングする OpenShift Container Platform バージョン。バージョンは quay.io にあります。
  • ミラーリングする追加の Operator。パッケージは個別に選択します。
  • リポジトリーに追加する追加のイメージ。

前提条件

  • ミラーリングプロセスを開始する前に、レジストリーサーバーが実行されていることを確認する。

手順

イメージのミラーリングを設定するには、以下の手順を実行します。

  1. ${HOME}/.docker/config.json ファイルが、ミラーリング元のレジストリーとイメージのプッシュ先のプライベートレジストリーで更新されていることを確認します。
  2. 次の例を使用して、ミラーリングに使用する ImageSetConfiguration オブジェクトを作成します。環境に合わせて必要に応じて値を置き換えます。

    apiVersion: mirror.openshift.io/v2alpha1
    kind: ImageSetConfiguration
    mirror:
      platform:
        channels:
        - name: candidate-4.19
          minVersion: <4.x.y-build>  
    1
    
          maxVersion: <4.x.y-build> 
    2
    
          type: ocp
        kubeVirtContainer: true 
    3
    
        graph: true
      operators:
      - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.19
        packages:
        - name: lvms-operator
        - name: local-storage-operator
        - name: odf-csi-addons-operator
        - name: odf-operator
        - name: mcg-operator
        - name: ocs-operator
        - name: metallb-operator
        - name: kubevirt-hyperconverged 
    4
    Copy to Clipboard Toggle word wrap
    1 2
    <4.x.y-build> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。
    3
    KubeVirt プロバイダーの Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージのコンテナーディスクイメージもミラーリングする場合は、このオプションのフラグを true に設定します。このフラグは oc-mirror v2 でのみ使用できます。
    4
    KubeVirt プロバイダーを使用するデプロイメントの場合は、この行を含めます。
  3. 次のコマンドを入力して、ミラーリングプロセスを開始します。

    $ oc-mirror --v2 --config imagesetconfig.yaml \
      --workspace file://mirror-file docker://<registry>
    Copy to Clipboard Toggle word wrap

    ミラーリングプロセスが完了すると、mirror-file という名前の新しいフォルダーが作成されます。このフォルダーには、ImageDigestMirrorSet (IDMS)、ImageTagMirrorSet (ITMS)、およびホステッドクラスターに適用するカタログソースが含まれます。

  4. imagesetconfig.yaml ファイルを次のように設定して、OpenShift Container Platform のナイトリーバージョンまたは CI バージョンをミラーリングします。

    apiVersion: mirror.openshift.io/v2alpha1
    kind: ImageSetConfiguration
    mirror:
      platform:
        graph: true
        release: registry.ci.openshift.org/ocp/release:<4.x.y-build> 
    1
    
        kubeVirtContainer: true 
    2
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    <4.x.y-build> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。
    2
    KubeVirt プロバイダーの Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージのコンテナーディスクイメージもミラーリングする場合は、このオプションのフラグを true に設定します。このフラグは oc-mirror v2 でのみ使用できます。
  5. 部分的な非接続環境の場合は、次のコマンドを入力して、イメージセット設定からレジストリーにイメージをミラーリングします。

    $ oc mirror -c imagesetconfig.yaml \
      --workspace file://<file_path> docker://<mirror_registry_url> --v2
    Copy to Clipboard Toggle word wrap

    詳細は、「部分的な非接続環境でのイメージセットのミラーリング」を参照してください。

  6. 完全な非接続環境の場合は、次の手順を実行します。

    1. 次のコマンドを入力して、指定したイメージセット設定からディスクにイメージをミラーリングします。

      $ oc mirror -c imagesetconfig.yaml file://<file_path> --v2
      Copy to Clipboard Toggle word wrap

      詳細は、「完全な非接続環境でのイメージセットのミラーリング」を参照してください。

    2. 次のコマンドを入力して、ディスク上のイメージセットファイルを処理し、その内容をターゲットミラーレジストリーにミラーリングします。

      $ oc mirror -c imagesetconfig.yaml \
        --from file://<file_path> docker://<mirror_registry_url> --v2
      Copy to Clipboard Toggle word wrap
  7. 非接続ネットワークへのインストール の手順に従って、最新の multicluster engine Operator イメージをミラーリングします。

6.2.3. 管理クラスターでのオブジェクトの適用

ミラーリングプロセスが完了したら、管理クラスターに 2 つのオブジェクトを適用する必要があります。

  • ImageContentSourcePolicy (ICSP) または ImageDigestMirrorSet (IDMS)
  • カタログソース

oc-mirror ツールを使用すると、出力アーティファクトは oc-mirror-workspace/results-XXXXXX/ という名前のフォルダーに保存されます。

ICSP または IDMS は、ノードを再起動せずに、各ノードの kubelet を再起動する MachineConfig の変更を開始します。ノードが READY としてマークされたら、新しく生成されたカタログソースを適用する必要があります。

カタログソースは、カタログイメージのダウンロードや処理を行い、そのイメージに含まれるすべての PackageManifests を取得するなど、openshift-marketplace Operator でアクションを開始します。

手順

  1. 新しいソースを確認するには、新しい CatalogSource をソースとして使用して次のコマンドを実行します。

    $ oc get packagemanifest
    Copy to Clipboard Toggle word wrap
  2. アーティファクトを適用するには、次の手順を実行します。

    1. 次のコマンドを入力して、ICSP または IDMS アーティファクトを作成します。

      $ oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
      Copy to Clipboard Toggle word wrap
    2. ノードの準備が完了するまで待ってから、次のコマンドを入力します。

      $ oc apply -f catalogSource-XXXXXXXX-index.yaml
      Copy to Clipboard Toggle word wrap
  3. OLM カタログをミラーリングし、ホステッドクラスターがミラーを参照するように設定します。

    OLMCatalogPlacement の management (デフォルト) モードを使用する場合、OLM カタログに使用されるイメージストリームが、管理クラスター上の ICSP からのオーバーライド情報で自動的に修正されません。

    1. OLM カタログが元の名前とタグを使用して内部レジストリーに適切にミラーリングされている場合は、hypershift.openshift.io/olm-catalogs-is-registry-overrides アノテーションを HostedCluster リソースに追加します。形式は "sr1=dr1,sr2=dr2" です。ソースレジストリーの文字列がキーで、宛先レジストリーが値です。
    2. OLM カタログのイメージストリームメカニズムを回避するには、HostedCluster リソースで次の 4 つのアノテーションを使用して、OLM Operator カタログに使用する 4 つのイメージのアドレスを直接指定します。

      • hypershift.openshift.io/certified-operators-catalog-image
      • hypershift.openshift.io/community-operators-catalog-image
      • hypershift.openshift.io/redhat-marketplace-catalog-image
      • hypershift.openshift.io/redhat-operators-catalog-image

この場合、イメージストリームは作成されないため、Operator の更新を取得するために内部ミラーを更新するときに、アノテーションの値を更新する必要があります。

次のステップ

Hosted Control Plane の非接続インストールのために multicluster engine Operator をデプロイする の手順を実行して、multicluster engine Operator をデプロイします。

6.2.4. Hosted Control Plane の非接続インストールのために multicluster engine Operator をデプロイする

multicluster engine for Kubernetes Operator は、複数のプロバイダーでクラスターをデプロイする場合に重要な役割を果たします。multicluster engine Operator がインストールされていない場合は、次のドキュメントを参照して、インストールの前提条件と手順を確認してください。

6.2.5. Hosted Control Plane の非接続インストールのために TLS 証明書を設定する

非接続デプロイメントで適切な機能を確保するには、管理クラスターとホステッドクラスターのワーカーノードでレジストリー CA 証明書を設定する必要があります。

6.2.5.1. 管理クラスターにレジストリー CA を追加する

管理クラスターにレジストリー CA を追加するには、次の手順を実行します。

手順

  1. 次の例のような config map を作成します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <config_map_name> 
    1
    
      namespace: <config_map_namespace> 
    2
    
    data: 
    3
    
      <registry_name>..<port>: | 
    4
    
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
      <registry_name>..<port>: |
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
      <registry_name>..<port>: |
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap
    1
    config map の名前を指定します。
    2
    config map の namespace を指定します。
    3
    data フィールドには、レジストリー名とレジストリー証明書の内容を指定します。<port> は、レジストリーサーバーが実行されているポート (例: 5000) に置き換えます。
    4
    config map 内のデータは、| - などの他の方法ではなく、必ず | だけを使用して定義します。他の方法を使用すると、Pod が証明書を読み取るときに問題が発生する可能性があります。
  2. クラスター全体のオブジェクト image.config.openshift.io にパッチを適用して、次の仕様を含めます。

    spec:
      additionalTrustedCA:
        - name: registry-config
    Copy to Clipboard Toggle word wrap

    このパッチの結果、コントロールプレーンノードがプライベートレジストリーからイメージを取得できるようになります。また、HyperShift Operator がホステッドクラスターのデプロイメント用の OpenShift Container Platform ペイロードを抽出できるようになります。

    オブジェクトにパッチを適用するプロセスが完了するまでに数分かかる場合があります。

6.2.5.2. ホステッドクラスターのワーカーノードにレジストリー CA を追加する

ホステッドクラスターのデータプレーンワーカーがプライベートレジストリーからイメージを取得できるようにするために、ワーカーノードにレジストリー CA を追加する必要があります。

手順

  1. hc.spec.additionalTrustBundle ファイルに次の仕様を追加します。

    spec:
      additionalTrustBundle:
        - name: user-ca-bundle 
    1
    Copy to Clipboard Toggle word wrap
    1
    user-ca-bundle エントリーは、次の手順で作成する config map です。
  2. HostedCluster オブジェクトの作成先と同じ namespace で、user-ca-bundle config map を作成します。config map は次の例のようになります。

    apiVersion: v1
    data:
      ca-bundle.crt: |
        // Registry1 CA
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    
        // Registry2 CA
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    
        // Registry3 CA
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    
    kind: ConfigMap
    metadata:
      name: user-ca-bundle
      namespace: <hosted_cluster_namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    HostedCluster オブジェクトの作成先の namespace を指定します。

6.2.6. OpenShift Virtualization でのホステッドクラスターの作成

ホステッドクラスターは、コントロールプレーンと API エンドポイントが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。

6.2.6.1. OpenShift Virtualization に Hosted Control Plane をデプロイするための要件

OpenShift Virtualization に Hosted Control Plane をデプロイする準備をする際には、次の情報を考慮してください。

  • 管理クラスターはベアメタル上で実行してください。
  • 各ホステッドクラスターの名前がクラスター全体で一意である。
  • ホステッドクラスター名として clusters を使用しない。
  • ホステッドクラスターは、multicluster engine Operator のマネージドクラスターの namespace には作成できない。
  • Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、「推奨される etcd プラクティス」および「論理ボリュームマネージャーストレージを使用した永続ストレージ」を参照してください。
6.2.6.2. CLI を使用して KubeVirt プラットフォームでホステッドクラスターを作成する

ホステッドクラスターを作成するには、Hosted Control Plane のコマンドラインインターフェイス (CLI) hcp を使用できます。

手順

  1. 次のコマンドを入力して、KubeVirt プラットフォームでホステッドクラスターを作成します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \
    1
    
      --node-pool-replicas <node_pool_replica_count> \
    2
    
      --pull-secret <path_to_pull_secret> \
    3
    
      --memory <value_for_memory> \
    4
    
      --cores <value_for_cpu> \
    5
    
      --etcd-storage-class=<etcd_storage_class> 
    6
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前 (例: my-hosted-cluster) を指定します。
    2
    ノードプールのレプリカ数を指定します (例: 3)。レプリカ数は 0 以上で指定する必要があります。指定したとおりの数のノードが作成されます。それ以外の場合、ノードプールは作成されません。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 6Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。
    注記

    --release-image フラグを使用すると、特定の OpenShift Container Platform リリースを使用してホステッドクラスターを設定できます。

    --node-pool-replicas フラグに従って、2 つの仮想マシンワーカーレプリカを持つクラスターに対してデフォルトのノードプールが作成されます。

  2. しばらくすると、次のコマンドを入力して、ホストされているコントロールプレーン Pod が実行されていることを確認できます。

    $ oc -n clusters-<hosted-cluster-name> get pods
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                  READY   STATUS    RESTARTS   AGE
    capi-provider-5cc7b74f47-n5gkr                        1/1     Running   0          3m
    catalog-operator-5f799567b7-fd6jw                     2/2     Running   0          69s
    certified-operators-catalog-784b9899f9-mrp6p          1/1     Running   0          66s
    cluster-api-6bbc867966-l4dwl                          1/1     Running   0          66s
    .
    .
    .
    redhat-operators-catalog-9d5fd4d44-z8qqk              1/1     Running   0          66s
    Copy to Clipboard Toggle word wrap

    KubeVirt 仮想マシンによってサポートされるワーカーノードを含むホステッドクラスターは、通常、完全にプロビジョニングされるまでに 10 ~ 15 分かかります。

検証

  • ホステッドクラスターのステータスを確認するには、次のコマンドを入力して、対応する HostedCluster リソースを確認します。

    $ oc get --namespace clusters hostedclusters
    Copy to Clipboard Toggle word wrap

    完全にプロビジョニングされた HostedCluster オブジェクトを示す以下の出力例を参照してください。

    NAMESPACE   NAME                VERSION     KUBECONFIG                 PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
    clusters    my-hosted-cluster   <4.x.0>     example-admin-kubeconfig   Completed   True        False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

    <4.x.0> を、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

6.2.6.3. OpenShift Virtualization 上の Hosted Control Plane のデフォルトの Ingress と DNS を設定する

すべての OpenShift Container Platform クラスターにはデフォルトのアプリケーション Ingress コントローラーが含まれており、これにはワイルドカード DNS レコードが関連付けられている必要があります。デフォルトでは、HyperShift KubeVirt プロバイダーを使用して作成されたホステッドクラスターは、自動的に KubeVirt 仮想マシンが実行される OpenShift Container Platform クラスターのサブドメインになります。

たとえば、OpenShift Container Platform クラスターには次のデフォルトの Ingress DNS エントリーがある可能性があります。

*.apps.mgmt-cluster.example.com
Copy to Clipboard Toggle word wrap

その結果、guest という名前が付けられ、その基礎となる OpenShift Container Platform クラスター上で実行される KubeVirt ホステッドクラスターには、次のデフォルト Ingress が設定されます。

*.apps.guest.apps.mgmt-cluster.example.com
Copy to Clipboard Toggle word wrap

手順

デフォルトの Ingress DNS が適切に機能するには、KubeVirt 仮想マシンをホストするクラスターでワイルドカード DNS ルートを許可する必要があります。

  • この動作は、以下のコマンドを入力して設定できます。

    $ oc patch ingresscontroller -n openshift-ingress-operator default \
      --type=json \
      -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
    Copy to Clipboard Toggle word wrap
注記

デフォルトのホステッドクラスターの Ingress を使用する場合、接続がポート 443 経由の HTTPS トラフィックに制限されます。ポート 80 経由のプレーン HTTP トラフィックは拒否されます。この制限は、デフォルトの Ingress の動作にのみ適用されます。

6.2.6.4. Ingress と DNS の動作のカスタマイズ

デフォルトの Ingress および DNS 動作を使用しない場合は、作成時に一意のベースドメインを使用して KubeVirt ホステッドクラスターを設定できます。このオプションでは、作成時に手動の設定手順が必要であり、クラスターの作成、ロードバランサーの作成、およびワイルドカード DNS 設定の 3 つの主要な手順が含まれます。

6.2.6.4.1. ベースドメインを指定するホステッドクラスターのデプロイ

ベースドメインを指定するホステッドクラスターを作成するには、次の手順を実行します。

手順

  1. 以下のコマンドを入力します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \ 
    1
    
      --node-pool-replicas <worker_count> \ 
    2
    
      --pull-secret <path_to_pull_secret> \ 
    3
    
      --memory <value_for_memory> \ 
    4
    
      --cores <value_for_cpu> \ 
    5
    
      --base-domain <basedomain> 
    6
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 6Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    ベースドメインを指定します (例: hypershift.lab)。

    その結果、ホステッドクラスターには、クラスター名とベースドメイン用に設定された Ingress ワイルドカード (例: .apps.example.hypershift.lab) が含まれます。ホステッドクラスターは Partial ステータスのままです。一意のベースドメインを持つホステッドクラスターを作成した後、必要な DNS レコードとロードバランサーを設定する必要があるためです。

検証

  1. 次のコマンドを入力して、ホステッドクラスターのステータスを表示します。

    $ oc get --namespace clusters hostedclusters
    Copy to Clipboard Toggle word wrap

    出力例

    NAME            VERSION   KUBECONFIG                       PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
    example                   example-admin-kubeconfig         Partial    True        False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを入力してクラスターにアクセスします。

    $ hcp create kubeconfig --name <hosted_cluster_name> \
      > <hosted_cluster_name>-kubeconfig
    Copy to Clipboard Toggle word wrap
    $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get co
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    console                                    <4.x.0>     False       False         False      30m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host
    ingress                                    <4.x.0>     True        False         True       28m     The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
    Copy to Clipboard Toggle word wrap

    <4.x.0> を、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

次のステップ

出力のエラーを修正するには、「ロードバランサーのセットアップ」および「ワイルドカード DNS の設定」の手順を完了します。

注記

ホステッドクラスターがベアメタル上にある場合は、ロードバランサーサービスを設定するために MetalLB が必要になる場合があります。詳細は、「MetalLB の設定」を参照してください。

6.2.6.4.2. ロードバランサーのセットアップ

Ingress トラフィックを KubeVirt 仮想マシンにルーティングし、ロードバランサー IP アドレスにワイルドカード DNS エントリーを割り当てるロードバランサーサービスを設定します。

手順

  1. ホステッドクラスターの Ingress を公開する NodePort サービスがすでに存在します。ノードポートをエクスポートし、それらのポートをターゲットとするロードバランサーサービスを作成できます。

    1. 次のコマンドを入力して、HTTP ノードポートを取得します。

      $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \
        -n openshift-ingress router-nodeport-default \
        -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'
      Copy to Clipboard Toggle word wrap

      次の手順で使用する HTTP ノードポート値をメモします。

    2. 次のコマンドを入力して、HTTPS ノードポートを取得します。

      $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \
        -n openshift-ingress router-nodeport-default \
        -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'
      Copy to Clipboard Toggle word wrap

      次の手順で使用する HTTPS ノードポート値をメモします。

  2. YAML ファイルに次の情報を入力します。

    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: <hosted_cluster_name>
      name: <hosted_cluster_name>-apps
      namespace: clusters-<hosted_cluster_name>
    spec:
      ports:
      - name: https-443
        port: 443
        protocol: TCP
        targetPort: <https_node_port> 
    1
    
      - name: http-80
        port: 80
        protocol: TCP
        targetPort: <http_node_port> 
    2
    
      selector:
        kubevirt.io: virt-launcher
      type: LoadBalancer
    Copy to Clipboard Toggle word wrap
    1
    前の手順でメモした HTTPS ノードポート値を指定します。
    2
    前の手順でメモした HTTP ノードポート値を指定します。
  3. 次のコマンドを実行してロードバランサーサービスを作成します。

    $ oc create -f <file_name>.yaml
    Copy to Clipboard Toggle word wrap
6.2.6.4.3. ワイルドカード DNS の設定

ロードバランサーサービスの外部 IP を参照するワイルドカード DNS レコードまたは CNAME を設定します。

手順

  1. 次のコマンドを入力して外部 IP アドレスを取得します。

    $ oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps \
      -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
    Copy to Clipboard Toggle word wrap

    出力例

    192.168.20.30
    Copy to Clipboard Toggle word wrap

  2. 外部 IP アドレスを参照するワイルドカード DNS エントリーを設定します。次の DNS エントリーの例を表示します。

    *.apps.<hosted_cluster_name\>.<base_domain\>.
    Copy to Clipboard Toggle word wrap

    DNS エントリーは、クラスターの内部と外部にルーティングできる必要があります。

    DNS 解決の例

    dig +short test.apps.example.hypershift.lab
    
    192.168.20.30
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、ホステッドクラスターのステータスが Partial から Completed に移行したことを確認します。

    $ oc get --namespace clusters hostedclusters
    Copy to Clipboard Toggle word wrap

    出力例

    NAME            VERSION   KUBECONFIG                       PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
    example         <4.x.0>     example-admin-kubeconfig         Completed   True        False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

    <4.x.0> を、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

6.2.7. デプロイの完了

ホステッドクラスターのデプロイは、コントロールプレーンの観点とデータプレーンの観点から監視できます。

6.2.7.1. コントロールプレーンの監視

デプロイの進行中に、次のアーティファクトに関する情報を収集してコントロールプレーンを監視できます。

  • HyperShift Operator
  • HostedControlPlane Pod
  • ベアメタルホスト
  • エージェント
  • InfraEnv リソース
  • HostedCluster および NodePool リソース

手順

  • コントロールプレーンを監視するには、次のコマンドを入力します。

    $ export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
    Copy to Clipboard Toggle word wrap
    $ watch "oc get pod -n hypershift;echo;echo;\
      oc get pod -n clusters-hosted-ipv4;echo;echo;\
      oc get bmh -A;echo;echo;\
      oc get agent -A;echo;echo;\
      oc get infraenv -A;echo;echo;\
      oc get hostedcluster -A;echo;echo;\
      oc get nodepool -A;echo;echo;"
    Copy to Clipboard Toggle word wrap
6.2.7.2. データプレーンの監視

デプロイの進行中に、次のアーティファクトに関する情報を収集してデータプレーンを監視できます。

  • クラスターのバージョン
  • ノード (特にノードがクラスターに参加したかどうかについて)
  • クラスター Operator

手順

  • 次のコマンドを入力します。

    $ oc get secret -n clusters-hosted-ipv4 admin-kubeconfig \
      -o jsonpath='{.data.kubeconfig}' | base64 -d > /root/hc_admin_kubeconfig.yaml
    Copy to Clipboard Toggle word wrap
    $ export KUBECONFIG=/root/hc_admin_kubeconfig.yaml
    Copy to Clipboard Toggle word wrap
    $ watch "oc get clusterversion,nodes,co"
    Copy to Clipboard Toggle word wrap

6.3. 非接続環境でベアメタルに Hosted Control Plane をデプロイする

Hosted Control Plane をベアメタルにプロビジョニングする場合は、Agent プラットフォームを使用します。Agent プラットフォームと multicluster engine for Kubernetes Operator が連携して、非接続デプロイメントを可能にします。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。Central Infrastructure Management の概要は、Central Infrastructure Management サービスの有効化 を参照してください。

6.3.1. ベアメタル向けの非接続環境のアーキテクチャー

以下の図は、非接続環境のアーキテクチャーの例を示しています。

Disconnected architecture diagram

  1. TLS サポートを備えたレジストリー証明書のデプロイメント、Web サーバー、DNS などのインフラストラクチャーサービスを設定して、非接続デプロイメントが確実に機能するようにします。
  2. openshift-config namespace に config map を作成します。この例では、config map の名前は registry-config になります。config map の内容はレジストリー CA 証明書です。config map の data フィールドには、次のキー/値が含まれている必要があります。

    • キー: <registry_dns_domain_name>..<port> (例: registry.hypershiftdomain.lab..5000:)ポートを指定するときは、レジストリー DNS ドメイン名の後に .. を配置するようにしてください。
    • 値: 証明書の内容

      config map の作成の詳細は、Hosted Control Plane の非接続インストールのために TLS 証明書を設定する を参照してください。

  3. images.config.openshift.io カスタムリソース (CR) 仕様を変更し、値が name: registry-configadditionalTrustedCA という名前の新規フィールドを追加します。
  4. 2 つのデータフィールドを含む config map を作成します。1 つのフィールドには RAW 形式の registries.conf ファイルが、もう 1 つのフィールドにはレジストリー CA が含まれ、ca-bundle.crt という名前が付けられます。config map は multicluster-engine namespace に属し、config map の名前は他のオブジェクトで参照されます。config map の例は、以下の設定例を参照してください。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: custom-registries
      namespace: multicluster-engine
      labels:
        app: assisted-service
    data:
      ca-bundle.crt: |
        -----BEGIN CERTIFICATE-----
        # ...
        -----END CERTIFICATE-----
      registries.conf: |
        unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
    
        [[registry]]
        prefix = ""
        location = "registry.redhat.io/openshift4"
        mirror-by-digest-only = true
    
        [[registry.mirror]]
          location = "registry.ocp-edge-cluster-0.qe.lab.redhat.com:5000/openshift4"
    
        [[registry]]
        prefix = ""
        location = "registry.redhat.io/rhacm2"
        mirror-by-digest-only = true
    # ...
    # ...
    Copy to Clipboard Toggle word wrap
  5. multicluster engine Operator の namespace で、Agent と hypershift-addon アドオンの両方を有効にする multiclusterengine CR を作成します。multicluster engine Operator の namespace には、非接続デプロイメントでの動作を変更するための config map が含まれている必要があります。namespace には、multicluster-engineassisted-service、および hypershift-addon-manager Pod も含まれます。
  6. ホステッドクラスターのデプロイに必要な次のオブジェクトを作成します。

    • シークレット: シークレットには、プルシークレット、SSH キー、etcd 暗号化キーが含まれます。
    • config map: config map には、プライベートレジストリーの CA 証明書が含まれています。
    • HostedCluster: HostedCluster リソースは、ユーザーが作成しようとしているクラスターの設定を定義します。
    • NodePool: NodePool リソースは、データプレーンに使用するマシンを参照するノードプールを識別します。
  7. ホステッドクラスターオブジェクトを作成した後、HyperShift Operator は、コントロールプレーン Pod に対応するために HostedControlPlane namespace を確立します。この namespace は、エージェント、ベアメタルホスト (BMH)、InfraEnv リソースなどのコンポーネントもホストします。その後、InfraEnv リソースを作成し、ISO の作成後に、Baseboard Management Controller (BMC) の認証情報を含む BMH とそのシークレットを作成します。
  8. openshift-machine-api namespace の Metal3 Operator は、新しい BMH を検査します。その後、Metal3 Operator は、multicluster engine Operator の namespace の AgentServiceConfig CR を通じて指定された設定済みの LiveISO および RootFS の値を使用して、BMC に接続して BMC を起動しようとします。
  9. HostedCluster リソースのワーカーノードが起動された後、エージェントコンテナーが起動されます。このエージェントは、デプロイメントを完了するためのアクションを調整する Assisted Service との接続を確立します。最初に、NodePool リソースを HostedCluster リソースのワーカーノードの数にスケーリングする必要があります。Assisted Service は残りのタスクを管理します。
  10. この時点で、デプロイメントプロセスが完了するまで待ちます。

6.3.2. 非接続環境でベアメタルに Hosted Control Plane をデプロイするための要件

オフライン環境で Hosted Control Plane を設定するには、次の前提条件を満たす必要があります。

  • CPU: 提供される CPU の数によって、同時に実行できるホステッドクラスターの数が決まります。通常、3 つのノードの場合、各ノードに 16 個の CPU を使用します。最小限の開発では、3 つのノードの場合、各ノードに 12 個の CPU を使用できます。
  • メモリー: RAM の容量は、ホストできるホステッドクラスターの数に影響します。各ノードに 48 GB の RAM を使用します。最小限の開発であれば、18 GB の RAM で十分です。
  • ストレージ: multicluster engine Operator には SSD ストレージを使用します。

    • 管理クラスター: 250 GB。
    • レジストリー: 必要なストレージは、ホストされているリリース、Operator、イメージの数によって異なります。許容可能な数値は 500 GB ですが、ホステッドクラスターをホストするディスクから分離することが望ましいです。
    • Web サーバー: 必要なストレージは、ホストされる ISO とイメージの数によって異なります。許容可能な数値は 500 GB です。
  • 実稼働環境: 実稼働環境の場合、管理クラスター、レジストリー、および Web サーバーを異なるディスク上に分離します。この例は、実稼働環境で可能な設定を示しています。

    • レジストリー: 2 TB
    • 管理クラスター: 500 GB
    • Web サーバー: 2 TB

6.3.3. リリースイメージダイジェストの抽出

タグ付けされたイメージを使用して、OpenShift Container Platform リリースイメージダイジェストを抽出できます。

手順

  • 次のコマンドを実行して、イメージダイジェストを取得します。

    $ oc adm release info <tagged_openshift_release_image> | grep "Pull From"
    Copy to Clipboard Toggle word wrap

    <tagged_openshift_release_image> を、サポートされている OpenShift Container Platform バージョンのタグ付きイメージに置き換えます (例: quay.io/openshift-release-dev/ocp-release:4.14.0-x8_64)。

    出力例

    Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfe
    Copy to Clipboard Toggle word wrap

6.3.4. ベアメタルでの DNS 設定

ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<base_domain> の DNS エントリーが存在する必要があります。

DNS エントリーは、ホステッドコントロールプレーンを実行している管理クラスター内のノードの 1 つを指すレコードのように単純なものにすることができます。エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。

DNS 設定の例

api.example.krnl.es.    IN A 192.168.122.20
api.example.krnl.es.    IN A 192.168.122.21
api.example.krnl.es.    IN A 192.168.122.22
api-int.example.krnl.es.    IN A 192.168.122.20
api-int.example.krnl.es.    IN A 192.168.122.21
api-int.example.krnl.es.    IN A 192.168.122.22
`*`.apps.example.krnl.es. IN A 192.168.122.23
Copy to Clipboard Toggle word wrap

注記

前述の例の場合、*.apps.example.krnl.es. IN A 192.168.122.23 が、ホステッドクラスター内のノード、またはロードバランサー (設定されている場合) です。

IPv6 ネットワーク上の非接続環境用に DNS を設定する場合、設定は次の例のようになります。

IPv6 ネットワークの DNS 設定の例

api.example.krnl.es.    IN A 2620:52:0:1306::5
api.example.krnl.es.    IN A 2620:52:0:1306::6
api.example.krnl.es.    IN A 2620:52:0:1306::7
api-int.example.krnl.es.    IN A 2620:52:0:1306::5
api-int.example.krnl.es.    IN A 2620:52:0:1306::6
api-int.example.krnl.es.    IN A 2620:52:0:1306::7
`*`.apps.example.krnl.es. IN A 2620:52:0:1306::10
Copy to Clipboard Toggle word wrap

デュアルスタックネットワークの非接続環境で DNS を設定する場合は、IPv4 と IPv6 の両方の DNS エントリーを含めるようにしてください。

デュアルスタックネットワークの DNS 設定の例

host-record=api-int.hub-dual.dns.base.domain.name,192.168.126.10
host-record=api.hub-dual.dns.base.domain.name,192.168.126.10
address=/apps.hub-dual.dns.base.domain.name/192.168.126.11
dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,192.168.126.20
dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,192.168.126.21
dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,192.168.126.22
dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,192.168.126.25
dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,192.168.126.26

host-record=api-int.hub-dual.dns.base.domain.name,2620:52:0:1306::2
host-record=api.hub-dual.dns.base.domain.name,2620:52:0:1306::2
address=/apps.hub-dual.dns.base.domain.name/2620:52:0:1306::3
dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,[2620:52:0:1306::5]
dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,[2620:52:0:1306::6]
dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,[2620:52:0:1306::7]
dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,[2620:52:0:1306::8]
dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,[2620:52:0:1306::9]
Copy to Clipboard Toggle word wrap

6.3.5. 非接続環境で Hosted Control Plane のレジストリーをデプロイする

開発環境の場合は、Podman コンテナーを使用して、小規模なセルフホスト型レジストリーをデプロイします。実稼働環境では、Red Hat Quay、Nexus、Artifactory などのエンタープライズホスト型レジストリーをデプロイします。

手順

Podman を使用して小規模なレジストリーをデプロイするには、以下の手順を実行します。

  1. 特権ユーザーとして ${HOME} ディレクトリーにアクセスし、次のスクリプトを作成します。

    #!/usr/bin/env bash
    
    set -euo pipefail
    
    PRIMARY_NIC=$(ls -1 /sys/class/net | grep -v podman | head -1)
    export PATH=/root/bin:$PATH
    export PULL_SECRET="/root/baremetal/hub/openshift_pull.json" 
    1
    
    
    if [[ ! -f $PULL_SECRET ]];then
      echo "Pull Secret not found, exiting..."
      exit 1
    fi
    
    dnf -y install podman httpd httpd-tools jq skopeo libseccomp-devel
    export IP=$(ip -o addr show $PRIMARY_NIC | head -1 | awk '{print $4}' | cut -d'/' -f1)
    REGISTRY_NAME=registry.$(hostname --long)
    REGISTRY_USER=dummy
    REGISTRY_PASSWORD=dummy
    KEY=$(echo -n $REGISTRY_USER:$REGISTRY_PASSWORD | base64)
    echo "{\"auths\": {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\", \"email\": \"sample-email@domain.ltd\"}}}" > /root/disconnected_pull.json
    mv ${PULL_SECRET} /root/openshift_pull.json.old
    jq ".auths += {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\",\"email\": \"sample-email@domain.ltd\"}}" < /root/openshift_pull.json.old > $PULL_SECRET
    mkdir -p /opt/registry/{auth,certs,data,conf}
    cat <<EOF > /opt/registry/conf/config.yml
    version: 0.1
    log:
      fields:
        service: registry
    storage:
      cache:
        blobdescriptor: inmemory
      filesystem:
        rootdirectory: /var/lib/registry
      delete:
        enabled: true
    http:
      addr: :5000
      headers:
        X-Content-Type-Options: [nosniff]
    health:
      storagedriver:
        enabled: true
        interval: 10s
        threshold: 3
    compatibility:
      schema1:
        enabled: true
    EOF
    openssl req -newkey rsa:4096 -nodes -sha256 -keyout /opt/registry/certs/domain.key -x509 -days 3650 -out /opt/registry/certs/domain.crt -subj "/C=US/ST=Madrid/L=San Bernardo/O=Karmalabs/OU=Guitar/CN=$REGISTRY_NAME" -addext "subjectAltName=DNS:$REGISTRY_NAME"
    cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/
    update-ca-trust extract
    htpasswd -bBc /opt/registry/auth/htpasswd $REGISTRY_USER $REGISTRY_PASSWORD
    podman create --name registry --net host --security-opt label=disable --replace -v /opt/registry/data:/var/lib/registry:z -v /opt/registry/auth:/auth:z -v /opt/registry/conf/config.yml:/etc/docker/registry/config.yml -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v /opt/registry/certs:/certs:z -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key docker.io/library/registry:latest
    [ "$?" == "0" ] || !!
    systemctl enable --now registry
    Copy to Clipboard Toggle word wrap
    1
    PULL_SECRET の場所は、設定に適した場所に置き換えます。
  2. スクリプトファイル registry.sh という名前を指定して保存します。スクリプトを実行すると、以下の情報がプルされます。

    • ハイパーバイザーのホスト名に基づくレジストリー名
    • 必要な認証情報およびユーザーアクセスの詳細
  3. 次のように実行フラグを追加して、パーミッションを調整します。

    $ chmod u+x ${HOME}/registry.sh
    Copy to Clipboard Toggle word wrap
  4. パラメーターを指定せずにスクリプトを実行するには、以下のコマンドを入力します。

    $ ${HOME}/registry.sh
    Copy to Clipboard Toggle word wrap

    このスクリプトはサーバーを起動します。このスクリプトは、管理目的で systemd サービスを使用します。

  5. スクリプトを管理する必要がある場合は、以下のコマンドを使用できます。

    $ systemctl status
    Copy to Clipboard Toggle word wrap
    $ systemctl start
    Copy to Clipboard Toggle word wrap
    $ systemctl stop
    Copy to Clipboard Toggle word wrap

レジストリーのルートフォルダーは /opt/registry ディレクトリー内にあり、次のサブディレクトリーが含まれています。

  • certs には TLS 証明書が含まれます。
  • auth には認証情報が含まれます。
  • data にはレジストリーイメージが含まれます。
  • conf にはレジストリー設定が含まれています。

6.3.6. 非接続環境で Hosted Control Plane の管理クラスターをデプロイする

OpenShift Container Platform の管理クラスターをセットアップするには、multicluster engine for Kubernetes Operator がインストールされていることを確認する必要があります。multicluster engine Operator は、複数のプロバイダーでクラスターをデプロイする場合に重要な役割を果たします。

前提条件

  • 管理クラスターとターゲットのベアメタルホスト (BMH) の Baseboard Management Controller (BMC) の間に双方向の接続がある。または、エージェントプロバイダーを通じて、自分自身でブートする方式を取ることもできます。
  • ホステッドクラスターが、管理クラスターのホスト名および *.apps ホスト名の API ホスト名を解決して到達できる。管理クラスターの API ホスト名と *.apps ホスト名の例を次に示します。

    • api.management-cluster.internal.domain.com
    • console-openshift-console.apps.management-cluster.internal.domain.com
  • 管理クラスターが、ホステッドクラスターの API ホスト名および *.apps ホスト名を解決して到達できる。ホステッドクラスターの API ホスト名と *.apps ホスト名の例を次に示します。

    • api.sno-hosted-cluster-1.internal.domain.com
    • console-openshift-console.apps.sno-hosted-cluster-1.internal.domain.com

手順

  1. OpenShift Container Platform クラスターに multicluster engine Operator 2.4 以降をインストールします。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator としてインストールできます。HyperShift Operator は multicluster engine Operator に含まれています。multicluster engine Operator のインストールの詳細は、Red Hat Advanced Cluster Management ドキュメントの「multicluster engine Operator のインストールとアップグレード」を参照してください。
  2. HyperShift Operator がインストールされていることを確認します。HyperShift Operator は multicluster engine Operator とともに自動的に追加されます。手動でインストールする必要がある場合は、「local-cluster の hypershift-addon マネージドクラスターアドオンを手動で有効にする」の手順に従ってください。

次のステップ

次に、Web サーバーを設定します。

6.3.7. 非接続環境で Hosted Control Plane の Web サーバーを設定する

ホステッドクラスターとしてデプロイする OpenShift Container Platform リリースに関連付けられた Red Hat Enterprise Linux CoreOS (RHCOS) イメージをホストするには、追加の Web サーバーを設定する必要があります。

手順

Web サーバーを設定するには、以下の手順を実行します。

  1. 以下のコマンドを入力して、使用する OpenShift Container Platform リリースから openshift-install バイナリーを展開します。

    $ oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install \
      "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
    Copy to Clipboard Toggle word wrap
  2. 次のスクリプトを実行します。このスクリプトは、/opt/srv ディレクトリーにフォルダーを作成します。このフォルダーには、ワーカーノードをプロビジョニングするための RHCOS イメージが含まれています。

    #!/bin/bash
    
    WEBSRV_FOLDER=/opt/srv
    ROOTFS_IMG_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.pxe.rootfs.location')" 
    1
    
    LIVE_ISO_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location')" 
    2
    
    
    mkdir -p ${WEBSRV_FOLDER}/images
    curl -Lk ${ROOTFS_IMG_URL} -o ${WEBSRV_FOLDER}/images/${ROOTFS_IMG_URL##*/}
    curl -Lk ${LIVE_ISO_URL} -o ${WEBSRV_FOLDER}/images/${LIVE_ISO_URL##*/}
    chmod -R 755 ${WEBSRV_FOLDER}/*
    
    ## Run Webserver
    podman ps --noheading | grep -q websrv-ai
    if [[ $? == 0 ]];then
        echo "Launching Registry pod..."
        /usr/bin/podman run --name websrv-ai --net host -v /opt/srv:/usr/local/apache2/htdocs:z quay.io/alosadag/httpd:p8080
    fi
    Copy to Clipboard Toggle word wrap
    1
    ROOTFS_IMG_URL 値は OpenShift CI Release ページにあります。
    2
    LIVE_ISO_URL 値は、OpenShift CI リリースページで確認できます。

ダウンロードが完了すると、コンテナーが実行され、Web サーバー上でイメージをホストします。このコンテナーは公式 HTTPd イメージのバリエーションを使用しているので、IPv6 ネットワークでの動作も可能になります。

6.3.8. 非接続環境で Hosted Control Plane のイメージミラーリングを設定する

イメージミラーリングは、registry.redhat.comquay.io などの外部レジストリーからイメージを取得し、プライベートレジストリーに保存するプロセスです。

次の手順では、ImageSetConfiguration オブジェクトを使用するバイナリーである、oc-mirror ツールが使用されます。このファイルで、以下の情報を指定できます。

  • ミラーリングする OpenShift Container Platform バージョン。バージョンは quay.io にあります。
  • ミラーリングする追加の Operator。パッケージは個別に選択します。
  • リポジトリーに追加する追加のイメージ。

前提条件

  • ミラーリングプロセスを開始する前に、レジストリーサーバーが実行されていることを確認する。

手順

イメージのミラーリングを設定するには、以下の手順を実行します。

  1. ${HOME}/.docker/config.json ファイルが、ミラーリング元のレジストリーとイメージのプッシュ先のプライベートレジストリーで更新されていることを確認します。
  2. 次の例を使用して、ミラーリングに使用する ImageSetConfiguration オブジェクトを作成します。環境に合わせて必要に応じて値を置き換えます。

    apiVersion: mirror.openshift.io/v2alpha1
    kind: ImageSetConfiguration
    mirror:
      platform:
        channels:
        - name: candidate-4.19
          minVersion: <4.x.y-build>  
    1
    
          maxVersion: <4.x.y-build> 
    2
    
          type: ocp
        kubeVirtContainer: true 
    3
    
        graph: true
      operators:
      - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.19
        packages:
        - name: lvms-operator
        - name: local-storage-operator
        - name: odf-csi-addons-operator
        - name: odf-operator
        - name: mcg-operator
        - name: ocs-operator
        - name: metallb-operator
        - name: kubevirt-hyperconverged 
    4
    Copy to Clipboard Toggle word wrap
    1 2
    <4.x.y-build> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。
    3
    KubeVirt プロバイダーの Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージのコンテナーディスクイメージもミラーリングする場合は、このオプションのフラグを true に設定します。このフラグは oc-mirror v2 でのみ使用できます。
    4
    KubeVirt プロバイダーを使用するデプロイメントの場合は、この行を含めます。
  3. 次のコマンドを入力して、ミラーリングプロセスを開始します。

    $ oc-mirror --v2 --config imagesetconfig.yaml \
      --workspace file://mirror-file docker://<registry>
    Copy to Clipboard Toggle word wrap

    ミラーリングプロセスが完了すると、mirror-file という名前の新しいフォルダーが作成されます。このフォルダーには、ImageDigestMirrorSet (IDMS)、ImageTagMirrorSet (ITMS)、およびホステッドクラスターに適用するカタログソースが含まれます。

  4. imagesetconfig.yaml ファイルを次のように設定して、OpenShift Container Platform のナイトリーバージョンまたは CI バージョンをミラーリングします。

    apiVersion: mirror.openshift.io/v2alpha1
    kind: ImageSetConfiguration
    mirror:
      platform:
        graph: true
        release: registry.ci.openshift.org/ocp/release:<4.x.y-build> 
    1
    
        kubeVirtContainer: true 
    2
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    <4.x.y-build> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。
    2
    KubeVirt プロバイダーの Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージのコンテナーディスクイメージもミラーリングする場合は、このオプションのフラグを true に設定します。このフラグは oc-mirror v2 でのみ使用できます。
  5. 部分的な非接続環境の場合は、次のコマンドを入力して、イメージセット設定からレジストリーにイメージをミラーリングします。

    $ oc mirror -c imagesetconfig.yaml \
      --workspace file://<file_path> docker://<mirror_registry_url> --v2
    Copy to Clipboard Toggle word wrap

    詳細は、「部分的な非接続環境でのイメージセットのミラーリング」を参照してください。

  6. 完全な非接続環境の場合は、次の手順を実行します。

    1. 次のコマンドを入力して、指定したイメージセット設定からディスクにイメージをミラーリングします。

      $ oc mirror -c imagesetconfig.yaml file://<file_path> --v2
      Copy to Clipboard Toggle word wrap

      詳細は、「完全な非接続環境でのイメージセットのミラーリング」を参照してください。

    2. 次のコマンドを入力して、ディスク上のイメージセットファイルを処理し、その内容をターゲットミラーレジストリーにミラーリングします。

      $ oc mirror -c imagesetconfig.yaml \
        --from file://<file_path> docker://<mirror_registry_url> --v2
      Copy to Clipboard Toggle word wrap
  7. 非接続ネットワークへのインストール の手順に従って、最新の multicluster engine Operator イメージをミラーリングします。

6.3.9. 管理クラスターでのオブジェクトの適用

ミラーリングプロセスが完了したら、管理クラスターに 2 つのオブジェクトを適用する必要があります。

  • ImageContentSourcePolicy (ICSP) または ImageDigestMirrorSet (IDMS)
  • カタログソース

oc-mirror ツールを使用すると、出力アーティファクトは oc-mirror-workspace/results-XXXXXX/ という名前のフォルダーに保存されます。

ICSP または IDMS は、ノードを再起動せずに、各ノードの kubelet を再起動する MachineConfig の変更を開始します。ノードが READY としてマークされたら、新しく生成されたカタログソースを適用する必要があります。

カタログソースは、カタログイメージのダウンロードや処理を行い、そのイメージに含まれるすべての PackageManifests を取得するなど、openshift-marketplace Operator でアクションを開始します。

手順

  1. 新しいソースを確認するには、新しい CatalogSource をソースとして使用して次のコマンドを実行します。

    $ oc get packagemanifest
    Copy to Clipboard Toggle word wrap
  2. アーティファクトを適用するには、次の手順を実行します。

    1. 次のコマンドを入力して、ICSP または IDMS アーティファクトを作成します。

      $ oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
      Copy to Clipboard Toggle word wrap
    2. ノードの準備が完了するまで待ってから、次のコマンドを入力します。

      $ oc apply -f catalogSource-XXXXXXXX-index.yaml
      Copy to Clipboard Toggle word wrap
  3. OLM カタログをミラーリングし、ホステッドクラスターがミラーを参照するように設定します。

    OLMCatalogPlacement の management (デフォルト) モードを使用する場合、OLM カタログに使用されるイメージストリームが、管理クラスター上の ICSP からのオーバーライド情報で自動的に修正されません。

    1. OLM カタログが元の名前とタグを使用して内部レジストリーに適切にミラーリングされている場合は、hypershift.openshift.io/olm-catalogs-is-registry-overrides アノテーションを HostedCluster リソースに追加します。形式は "sr1=dr1,sr2=dr2" です。ソースレジストリーの文字列がキーで、宛先レジストリーが値です。
    2. OLM カタログのイメージストリームメカニズムを回避するには、HostedCluster リソースで次の 4 つのアノテーションを使用して、OLM Operator カタログに使用する 4 つのイメージのアドレスを直接指定します。

      • hypershift.openshift.io/certified-operators-catalog-image
      • hypershift.openshift.io/community-operators-catalog-image
      • hypershift.openshift.io/redhat-marketplace-catalog-image
      • hypershift.openshift.io/redhat-operators-catalog-image

この場合、イメージストリームは作成されないため、Operator の更新を取得するために内部ミラーを更新するときに、アノテーションの値を更新する必要があります。

次のステップ

Hosted Control Plane の非接続インストールのために multicluster engine Operator をデプロイする の手順を実行して、multicluster engine Operator をデプロイします。

6.3.10. AgentServiceConfig リソースのデプロイ

AgentServiceConfig カスタムリソースは、multicluster engine Operator の一部である Assisted Service アドオンの重要なコンポーネントです。このリソースはベアメタルクラスターをデプロイします。アドオンが有効な場合に、AgentServiceConfig リソースをデプロイしてアドオンを設定します。

AgentServiceConfig リソースの設定に加えて、multicluster engine Operator が非接続環境で適切に機能するように、追加の config map を含める必要があります。

手順

  1. 次の config map を追加してカスタムレジストリーを設定します。これには、デプロイメントをカスタマイズするための非接続環境の情報が含まれています。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: custom-registries
      namespace: multicluster-engine
      labels:
        app: assisted-service
    data:
      ca-bundle.crt: |
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
      registries.conf: |
        unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
    
        [[registry]]
        prefix = ""
        location = "registry.redhat.io/openshift4"
        mirror-by-digest-only = true
    
        [[registry.mirror]]
          location = "registry.dns.base.domain.name:5000/openshift4" 
    1
    
    
        [[registry]]
        prefix = ""
        location = "registry.redhat.io/rhacm2"
        mirror-by-digest-only = true
        # ...
        # ...
    Copy to Clipboard Toggle word wrap
    1
    dns.base.domain.name は DNS ベースドメイン名に置き換えます。

    オブジェクトには、以下の 2 つのフィールドが含まれます。

    • カスタム CA: このフィールドには、デプロイメントのさまざまなプロセスに読み込まれる認証局 (CA) が含まれます。
    • レジストリー: Registries.conf フィールドには、元のソースレジストリーではなくミラーレジストリーから使用する必要があるイメージと namespace に関する情報が含まれています。
  2. 次の例に示すように、AssistedServiceConfig オブジェクトを追加して、Assisted Service を設定します。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
      annotations:
        unsupported.agent-install.openshift.io/assisted-service-configmap: assisted-service-config 
    1
    
      name: agent
      namespace: multicluster-engine
    spec:
      mirrorRegistryRef:
        name: custom-registries 
    2
    
      databaseStorage:
        storageClassName: lvms-vg1
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi
      filesystemStorage:
        storageClassName: lvms-vg1
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
      osImages: 
    3
    
      - cpuArchitecture: x86_64 
    4
    
        openshiftVersion: "4.14"
        rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live-rootfs.x86_64.img 
    5
    
        url: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live.x86_64.iso
        version: 414.92.202308281054-0
      - cpuArchitecture: x86_64
       openshiftVersion: "4.15"
       rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-415.92.202403270524-0-live-rootfs.x86_64.img
       url: http://registry.dns.base.domain.name:8080/images/rhcos-415.92.202403270524-0-live.x86_64.iso
       version: 415.92.202403270524-0
    Copy to Clipboard Toggle word wrap
    1
    metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"] アノテーションは、Operator が動作をカスタマイズするために使用する config map 名を参照します。
    2
    spec.mirrorRegistryRef.name アノテーションは、Assisted Service Operator が使用する非接続のレジストリー情報を含む config map を指します。この config map は、デプロイメントプロセス中にこれらのリソースを追加します。
    3
    spec.osImages フィールドには、この Operator がデプロイできるさまざまなバージョンが含まれています。このフィールドは必須です。この例では、RootFS ファイルと LiveISO ファイルがすでにダウンロードされていることを前提としています。
    4
    デプロイする OpenShift Container Platform リリースごとに cpuArchitecture サブセクションを追加します。この例では、4.14 および 4.15 の cpuArchitecture サブセクションが含まれています。
    5
    rootFSUrl フィールドと url フィールドの dns.base.domain.name は、DNS ベースドメイン名に置き換えてください。
  3. すべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに適用し、これらのオブジェクトをデプロイします。起動するには、以下のコマンドを実行します。

    $ oc apply -f agentServiceConfig.yaml
    Copy to Clipboard Toggle word wrap

    このコマンドは 2 つの Pod をトリガーします。

    出力例

    assisted-image-service-0                               1/1     Running   2             11d 
    1
    
    assisted-service-668b49548-9m7xw                       2/2     Running   5             11d 
    2
    Copy to Clipboard Toggle word wrap

    1
    assisted-image-service Pod は、デプロイするクラスターごとにカスタマイズされた、Red Hat Enterprise Linux CoreOS (RHCOS) 起動イメージテンプレートを作成します。
    2
    assisted-service は Operator を参照します。

次のステップ

TLS 証明書を設定します。

6.3.11. Hosted Control Plane の非接続インストールのために TLS 証明書を設定する

非接続デプロイメントで適切な機能を確保するには、管理クラスターとホステッドクラスターのワーカーノードでレジストリー CA 証明書を設定する必要があります。

6.3.11.1. 管理クラスターにレジストリー CA を追加する

管理クラスターにレジストリー CA を追加するには、次の手順を実行します。

手順

  1. 次の例のような config map を作成します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <config_map_name> 
    1
    
      namespace: <config_map_namespace> 
    2
    
    data: 
    3
    
      <registry_name>..<port>: | 
    4
    
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
      <registry_name>..<port>: |
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
      <registry_name>..<port>: |
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap
    1
    config map の名前を指定します。
    2
    config map の namespace を指定します。
    3
    data フィールドには、レジストリー名とレジストリー証明書の内容を指定します。<port> は、レジストリーサーバーが実行されているポート (例: 5000) に置き換えます。
    4
    config map 内のデータは、| - などの他の方法ではなく、必ず | だけを使用して定義します。他の方法を使用すると、Pod が証明書を読み取るときに問題が発生する可能性があります。
  2. クラスター全体のオブジェクト image.config.openshift.io にパッチを適用して、次の仕様を含めます。

    spec:
      additionalTrustedCA:
        - name: registry-config
    Copy to Clipboard Toggle word wrap

    このパッチの結果、コントロールプレーンノードがプライベートレジストリーからイメージを取得できるようになります。また、HyperShift Operator がホステッドクラスターのデプロイメント用の OpenShift Container Platform ペイロードを抽出できるようになります。

    オブジェクトにパッチを適用するプロセスが完了するまでに数分かかる場合があります。

6.3.11.2. ホステッドクラスターのワーカーノードにレジストリー CA を追加する

ホステッドクラスターのデータプレーンワーカーがプライベートレジストリーからイメージを取得できるようにするために、ワーカーノードにレジストリー CA を追加する必要があります。

手順

  1. hc.spec.additionalTrustBundle ファイルに次の仕様を追加します。

    spec:
      additionalTrustBundle:
        - name: user-ca-bundle 
    1
    Copy to Clipboard Toggle word wrap
    1
    user-ca-bundle エントリーは、次の手順で作成する config map です。
  2. HostedCluster オブジェクトの作成先と同じ namespace で、user-ca-bundle config map を作成します。config map は次の例のようになります。

    apiVersion: v1
    data:
      ca-bundle.crt: |
        // Registry1 CA
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    
        // Registry2 CA
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    
        // Registry3 CA
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    
    kind: ConfigMap
    metadata:
      name: user-ca-bundle
      namespace: <hosted_cluster_namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    HostedCluster オブジェクトの作成先の namespace を指定します。

6.3.12. ベアメタルでのホステッドクラスターの作成

ホステッドクラスターは、コントロールプレーンと API エンドポイントが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。

6.3.12.1. ホステッドクラスターオブジェクトのデプロイ

通常は、HyperShift Operator が HostedControlPlane namespace を作成します。しかし、この場合は、HyperShift Operator が HostedCluster オブジェクトのリコンサイルを開始する前に、すべてのオブジェクトを含めておく必要があります。その後、Operator がリコンシリエーションプロセスを開始すると、所定の場所にあるすべてのオブジェクトを見つけることができます。

手順

  1. namespace に関する次の情報を含めて、YAML ファイルを作成します。

    ---
    apiVersion: v1
    kind: Namespace
    metadata:
      creationTimestamp: null
      name: <hosted_cluster_namespace>-<hosted_cluster_name> 
    1
    
    spec: {}
    status: {}
    ---
    apiVersion: v1
    kind: Namespace
    metadata:
      creationTimestamp: null
      name: <hosted_cluster_namespace> 
    2
    
    spec: {}
    status: {}
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
    2
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
  2. config map とシークレットに関する次の情報を含む YAML ファイルを作成し、HostedCluster デプロイメントに追加します。

    ---
    apiVersion: v1
    data:
      ca-bundle.crt: |
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    kind: ConfigMap
    metadata:
      name: user-ca-bundle
      namespace: <hosted_cluster_namespace> 
    1
    
    ---
    apiVersion: v1
    data:
      .dockerconfigjson: xxxxxxxxx
    kind: Secret
    metadata:
      creationTimestamp: null
      name: <hosted_cluster_name>-pull-secret 
    2
    
      namespace: <hosted_cluster_namespace> 
    3
    
    ---
    apiVersion: v1
    kind: Secret
    metadata:
      name: sshkey-cluster-<hosted_cluster_name> 
    4
    
      namespace: <hosted_cluster_namespace> 
    5
    
    stringData:
      id_rsa.pub: ssh-rsa xxxxxxxxx
    ---
    apiVersion: v1
    data:
      key: nTPtVBEt03owkrKhIdmSW8jrWRxU57KO/fnZa8oaG0Y=
    kind: Secret
    metadata:
      creationTimestamp: null
      name: <hosted_cluster_name>-etcd-encryption-key 
    6
    
      namespace: <hosted_cluster_namespace> 
    7
    
    type: Opaque
    Copy to Clipboard Toggle word wrap
    1 3 5 7
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    2 4 6
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
  3. RBAC ロールを含む YAML ファイルを作成し、Assisted Service エージェントが Hosted Control Plane と同じ HostedControlPlane namespace に配置し、引き続きクラスター API で管理されるようにします。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      creationTimestamp: null
      name: capi-provider-role
      namespace: <hosted_cluster_namespace>-<hosted_cluster_name> 
    1
     
    2
    
    rules:
    - apiGroups:
      - agent-install.openshift.io
      resources:
      - agents
      verbs:
      - '*'
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    2
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
  4. HostedCluster オブジェクトに関する情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。

    apiVersion: hypershift.openshift.io/v1beta1
    kind: HostedCluster
    metadata:
      name: <hosted_cluster_name> 
    1
    
      namespace: <hosted_cluster_namespace> 
    2
    
    spec:
      additionalTrustBundle:
        name: "user-ca-bundle"
      olmCatalogPlacement: guest
      imageContentSources: 
    3
    
      - source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
        mirrors:
        - registry.<dns.base.domain.name>:5000/openshift/release 
    4
    
      - source: quay.io/openshift-release-dev/ocp-release
        mirrors:
        - registry.<dns.base.domain.name>:5000/openshift/release-images 
    5
    
      - mirrors:
      ...
      ...
      autoscaling: {}
      controllerAvailabilityPolicy: SingleReplica
      dns:
        baseDomain: <dns.base.domain.name> 
    6
    
      etcd:
        managed:
          storage:
            persistentVolume:
              size: 8Gi
            restoreSnapshotURL: null
            type: PersistentVolume
        managementType: Managed
      fips: false
      networking:
        clusterNetwork:
        - cidr: 10.132.0.0/14
        - cidr: fd01::/48
        networkType: OVNKubernetes
        serviceNetwork:
        - cidr: 172.31.0.0/16
        - cidr: fd02::/112
      platform:
        agent:
          agentNamespace: <hosted_cluster_namespace>-<hosted_cluster_name> 
    7
     
    8
    
        type: Agent
      pullSecret:
        name: <hosted_cluster_name>-pull-secret 
    9
    
      release:
        image: registry.<dns.base.domain.name>:5000/openshift/release-images:<4.x.y>-x86_64 
    10
     
    11
    
      secretEncryption:
        aescbc:
          activeKey:
            name: <hosted_cluster_name>-etcd-encryption-key 
    12
    
        type: aescbc
      services:
      - service: APIServer
        servicePublishingStrategy:
          type: LoadBalancer
      - service: OAuthServer
        servicePublishingStrategy:
          type: Route
      - service: OIDC
        servicePublishingStrategy:
          type: Route
      - service: Konnectivity
        servicePublishingStrategy:
          type: Route
      - service: Ignition
        servicePublishingStrategy:
          type: Route
      sshKey:
        name: sshkey-cluster-<hosted_cluster_name> 
    13
    
    status:
      controlPlaneEndpoint:
        host: ""
        port: 0
    Copy to Clipboard Toggle word wrap
    1 7 9 12 13
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
    2 8
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    3
    imageContentSources セクションには、ホステッドクラスター内のユーザーワークロードのミラー参照が含まれます。
    4 5 6 10
    <dns.base.domain.name> は、DNS ベースドメイン名に置き換えます。
    11
    <4.x.y> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。
  5. YAML ファイルで定義したすべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに対して適用して作成します。起動するには、以下のコマンドを実行します。

    $ oc apply -f 01-4.14-hosted_cluster-nodeport.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                  READY   STATUS    RESTARTS   AGE
    capi-provider-5b57dbd6d5-pxlqc                        1/1     Running   0          3m57s
    catalog-operator-9694884dd-m7zzv                      2/2     Running   0          93s
    cluster-api-f98b9467c-9hfrq                           1/1     Running   0          3m57s
    cluster-autoscaler-d7f95dd5-d8m5d                     1/1     Running   0          93s
    cluster-image-registry-operator-5ff5944b4b-648ht      1/2     Running   0          93s
    cluster-network-operator-77b896ddc-wpkq8              1/1     Running   0          94s
    cluster-node-tuning-operator-84956cd484-4hfgf         1/1     Running   0          94s
    cluster-policy-controller-5fd8595d97-rhbwf            1/1     Running   0          95s
    cluster-storage-operator-54dcf584b5-xrnts             1/1     Running   0          93s
    cluster-version-operator-9c554b999-l22s7              1/1     Running   0          95s
    control-plane-operator-6fdc9c569-t7hr4                1/1     Running   0          3m57s
    csi-snapshot-controller-785c6dc77c-8ljmr              1/1     Running   0          77s
    csi-snapshot-controller-operator-7c6674bc5b-d9dtp     1/1     Running   0          93s
    csi-snapshot-webhook-5b8584875f-2492j                 1/1     Running   0          77s
    dns-operator-6874b577f-9tc6b                          1/1     Running   0          94s
    etcd-0                                                3/3     Running   0          3m39s
    hosted-cluster-config-operator-f5cf5c464-4nmbh        1/1     Running   0          93s
    ignition-server-6b689748fc-zdqzk                      1/1     Running   0          95s
    ignition-server-proxy-54d4bb9b9b-6zkg7                1/1     Running   0          95s
    ingress-operator-6548dc758b-f9gtg                     1/2     Running   0          94s
    konnectivity-agent-7767cdc6f5-tw782                   1/1     Running   0          95s
    kube-apiserver-7b5799b6c8-9f5bp                       4/4     Running   0          3m7s
    kube-controller-manager-5465bc4dd6-zpdlk              1/1     Running   0          44s
    kube-scheduler-5dd5f78b94-bbbck                       1/1     Running   0          2m36s
    machine-approver-846c69f56-jxvfr                      1/1     Running   0          92s
    oauth-openshift-79c7bf44bf-j975g                      2/2     Running   0          62s
    olm-operator-767f9584c-4lcl2                          2/2     Running   0          93s
    openshift-apiserver-5d469778c6-pl8tj                  3/3     Running   0          2m36s
    openshift-controller-manager-6475fdff58-hl4f7         1/1     Running   0          95s
    openshift-oauth-apiserver-dbbc5cc5f-98574             2/2     Running   0          95s
    openshift-route-controller-manager-5f6997b48f-s9vdc   1/1     Running   0          95s
    packageserver-67c87d4d4f-kl7qh                        2/2     Running   0          93s
    Copy to Clipboard Toggle word wrap

    ホステッドクラスターが利用可能な場合、出力は次の例のようになります。

    出力例

    NAMESPACE   NAME         VERSION   KUBECONFIG                PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
    clusters    hosted-dual            hosted-admin-kubeconfig   Partial    True          False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

6.3.12.2. ホステッドクラスターの NodePool オブジェクトの作成

NodePool は、ホステッドクラスターに関連付けられたスケーラブルなワーカーノードのセットです。NodePool マシンアーキテクチャーは特定のプール内で一貫性を保ち、コントロールプレーンのマシンアーキテクチャーから独立しています。

手順

  1. NodePool オブジェクトに関する次の情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。

    apiVersion: hypershift.openshift.io/v1beta1
    kind: NodePool
    metadata:
      creationTimestamp: null
      name: <hosted_cluster_name> \
    1
    
      namespace: <hosted_cluster_namespace> \
    2
    
    spec:
      arch: amd64
      clusterName: <hosted_cluster_name>
      management:
        autoRepair: false \
    3
    
        upgradeType: InPlace \
    4
    
      nodeDrainTimeout: 0s
      platform:
        type: Agent
      release:
        image: registry.<dns.base.domain.name>:5000/openshift/release-images:4.x.y-x86_64 \
    5
    
      replicas: 2 
    6
    
    status:
      replicas: 2
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
    2
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    3
    ノードが削除された場合、ノードは再作成されないため、autoRepair フィールドは false に設定されます。
    4
    upgradeTypeInPlace に設定されます。これは、アップグレード中に同じベアメタルノードが再利用されることを示します。
    5
    この NodePool に含まれるすべてのノードは、OpenShift Container Platform バージョン 4.x.y-x86_64 に基づいています。<dns.base.domain.name> の値は、DNS ベースドメイン名に置き換えます。4.x.y の値は、使用するサポート対象の OpenShift Container Platform のバージョンに置き換えます。
    6
    replicas の値を 2 に設定すると、ホステッドクラスターに 2 つのノードプールレプリカを作成できます。
  2. 次のコマンドを入力して、NodePool オブジェクトを作成します。

    $ oc apply -f 02-nodepool.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    NAMESPACE   NAME          CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
    clusters    hosted-dual   hosted    0                               False         False        4.x.y-x86_64
    Copy to Clipboard Toggle word wrap

6.3.12.3. ホステッドクラスターの InfraEnv リソースの作成

InfraEnv リソースは、pullSecretRefsshAuthorizedKey などの重要な詳細を含む Assisted Service オブジェクトです。これらの詳細は、ホステッドクラスター用にカスタマイズされた Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージを作成するために使用されます。

複数の InfraEnv リソースをホストすることができます。各リソースは特定のタイプのホストを採用できます。たとえば、大きな RAM 容量を持つホスト間でサーバーファームを分割することができます。

手順

  1. InfraEnv リソースに関する次の情報を含めて YAML ファイルを作成し、必要に応じて値を置き換えます。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: <hosted_cluster_name>
      namespace: <hosted-cluster-namespace>-<hosted_cluster_name> 
    1
     
    2
    
    spec:
      pullSecretRef: 
    3
    
        name: pull-secret
      sshAuthorizedKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDk7ICaUE+/k4zTpxLk4+xFdHi4ZuDi5qjeF52afsNkw0w/glILHhwpL5gnp5WkRuL8GwJuZ1VqLC9EKrdmegn4MrmUlq7WTsP0VFOZFBfq2XRUxo1wrRdor2z0Bbh93ytR+ZsDbbLlGngXaMa0Vbt+z74FqlcajbHTZ6zBmTpBVq5RHtDPgKITdpE1fongp7+ZXQNBlkaavaqv8bnyrP4BWahLP4iO9/xJF9lQYboYwEEDzmnKLMW1VtCE6nJzEgWCufACTbxpNS7GvKtoHT/OVzw8ArEXhZXQUS1UY8zKsX2iXwmyhw5Sj6YboA8WICs4z+TrFP89LmxXY0j6536TQFyRz1iB4WWvCbH5n6W+ABV2e8ssJB1AmEy8QYNwpJQJNpSxzoKBjI73XxvPYYC/IjPFMySwZqrSZCkJYqQ023ySkaQxWZT7in4KeMu7eS2tC+Kn4deJ7KwwUycx8n6RHMeD8Qg9flTHCv3gmab8JKZJqN3hW1D378JuvmIX4V0= 
    4
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
    2
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    3
    pullSecretRef は、プルシークレットが使用される InfraEnv と同じ namespace 内の config map を参照します。
    4
    sshAuthorizedKey は、ブートイメージに配置される SSH 公開鍵を表します。SSH 鍵を使用すると、core ユーザーとしてワーカーノードにアクセスできます。
  2. 次のコマンドを入力して、InfraEnv リソースを作成します。

    $ oc apply -f 03-infraenv.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    NAMESPACE              NAME     ISO CREATED AT
    clusters-hosted-dual   hosted   2023-09-11T15:14:10Z
    Copy to Clipboard Toggle word wrap

6.3.12.4. ホステッドクラスターのベアメタルホスト作成

ベアメタルホスト は、物理的な詳細と論理詳細を含む openshift-machine-api オブジェクトで、Metal3 Operator によって識別できるようになっています。これらの詳細は、agents と呼ばれる他の Assisted Service オブジェクトに関連付けられています。

前提条件

  • ベアメタルホストと宛先ノードを作成する前に、宛先マシンを準備しておく必要があります。
  • クラスターで使用するために、ベアメタルインフラストラクチャーに Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンをインストールした。

手順

ベアメタルホストを作成するには、以下の手順を実行します。

  1. 次の情報を含む YAML ファイルを作成します。ベアメタルホストに関して入力する詳細情報については、「BMO を使用して、ユーザーがプロビジョニングしたクラスターで新しいホストをプロビジョニングする」を参照してください。

    ベアメタルホストの認証情報を保持するシークレットが 1 つ以上あるため、ワーカーノードごとに少なくとも 2 つのオブジェクトを作成する必要があります。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <hosted_cluster_name>-worker0-bmc-secret 
    1
    
      namespace: <hosted_cluster_namespace>-<hosted_cluster_name> 
    2
    
    data:
      password: YWRtaW4= 
    3
    
      username: YWRtaW4= 
    4
    
    type: Opaque
    # ...
    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: <hosted_cluster_name>-worker0
      namespace: <hosted_cluster_namespace>-<hosted_cluster_name> 
    5
    
      labels:
        infraenvs.agent-install.openshift.io: <hosted_cluster_name> 
    6
    
      annotations:
        inspect.metal3.io: disabled
        bmac.agent-install.openshift.io/hostname: <hosted_cluster_name>-worker0 
    7
    
    spec:
      automatedCleaningMode: disabled 
    8
    
      bmc:
        disableCertificateVerification: true 
    9
    
        address: redfish-virtualmedia://[192.168.126.1]:9000/redfish/v1/Systems/local/<hosted_cluster_name>-worker0 
    10
    
        credentialsName: <hosted_cluster_name>-worker0-bmc-secret 
    11
    
      bootMACAddress: aa:aa:aa:aa:02:11 
    12
    
      online: true 
    13
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
    2 5
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。<hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    3
    Baseboard Management Controller (BMC) のパスワードを Base64 形式で指定します。
    4
    BMC のユーザー名を Base64 形式で指定します。
    6
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。infraenvs.agent-install.openshift.io フィールドは、Assisted Installer と BareMetalHost オブジェクト間のリンクとして機能します。
    7
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。bmac.agent-install.openshift.io/hostname フィールドは、デプロイ時に採用されるノード名を表します。
    8
    automatedCleaningMode フィールドは、Metal3 Operator によってノードが消去されるのを防ぎます。
    9
    disableCertificateVerification フィールドを true に設定して、クライアントからの証明書検証を回避します。
    10
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。address フィールドは、ワーカーノードの BMC アドレスを示します。
    11
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。credentialsName フィールドは、ユーザーとパスワードの認証情報が保存されるシークレットを指します。
    12
    bootMACAddress フィールドは、ノードの起動元のインターフェイス MAC アドレスを示します。
    13
    online フィールドは、BareMetalHost オブジェクトが作成された後のノードの状態を定義します。
  2. 次のコマンドを入力して、BareMetalHost オブジェクトをデプロイします。

    $ oc apply -f 04-bmh.yaml
    Copy to Clipboard Toggle word wrap

    プロセス中に、次の出力が確認できます。

    • この出力は、プロセスがノードに到達しようとしていることを示しています。

      出力例

      NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
      clusters-hosted   hosted-worker0   registering              true             2s
      clusters-hosted   hosted-worker1   registering              true             2s
      clusters-hosted   hosted-worker2   registering              true             2s
      Copy to Clipboard Toggle word wrap

    • この出力は、ノードが起動していることを示しています。

      出力例

      NAMESPACE         NAME             STATE          CONSUMER   ONLINE   ERROR   AGE
      clusters-hosted   hosted-worker0   provisioning              true             16s
      clusters-hosted   hosted-worker1   provisioning              true             16s
      clusters-hosted   hosted-worker2   provisioning              true             16s
      Copy to Clipboard Toggle word wrap

    • この出力は、ノードが正常に起動したことを示しています。

      出力例

      NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
      clusters-hosted   hosted-worker0   provisioned              true             67s
      clusters-hosted   hosted-worker1   provisioned              true             67s
      clusters-hosted   hosted-worker2   provisioned              true             67s
      Copy to Clipboard Toggle word wrap

  3. ノードが起動したら、次の例に示すように、namespace のエージェントに注目してください。

    出力例

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
    clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411             true       auto-assign
    clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412             true       auto-assign
    clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413             true       auto-assign
    Copy to Clipboard Toggle word wrap

    エージェントは、インストールに使用できるノードを表します。ホステッドクラスターにノードを割り当てるには、ノードプールをスケールアップします。

6.3.12.5. ノードプールのスケールアップ

ベアメタルホストを作成すると、そのステータスが Registering ProvisioningProvisioned に変わります。ノードは、エージェントの LiveISO と、agent という名前のデフォルトの Pod で始まります。このエージェントは、Assisted Service Operator から OpenShift Container Platform ペイロードをインストールする指示を受け取ります。

手順

  1. ノードプールをスケールアップするには、次のコマンドを入力します。

    $ oc -n <hosted_cluster_namespace> scale nodepool <hosted_cluster_name> \
      --replicas 3
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    • <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前です。
    • <hosted_cluster_name> は、ホステッドクラスターの名前です。
  2. スケーリングプロセスが完了すると、エージェントがホステッドクラスターに割り当てられていることがわかります。

    出力例

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
    clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411   hosted    true       auto-assign
    clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412   hosted    true       auto-assign
    clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413   hosted    true       auto-assign
    Copy to Clipboard Toggle word wrap

  3. また、ノードプールレプリカが設定されていることにも注意してください。

    出力例

    NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION       UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
    clusters    hosted   hosted    3                               False         False        <4.x.y>-x86_64                                     Minimum availability requires 3 replicas, current 0 available
    Copy to Clipboard Toggle word wrap

    <4.x.y> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

  4. ノードがクラスターに参加するまで待ちます。プロセス中に、エージェントはステージとステータスに関する最新情報を提供します。

6.4. 非接続環境で IBM Z に Hosted Control Plane をデプロイする

非接続環境の Hosted Control Plane デプロイメントは、スタンドアロンの OpenShift Container Platform とは異なる動作をします。

Hosted Control Plane には、次の 2 つの異なる環境が関係します。

  • コントロールプレーン: 管理クラスターに配置されます。Hosted Control Plane の Pod が Control Plane Operator によって実行および管理される場所です。
  • データプレーン: ホステッドクラスターのワーカーに配置されます。ワークロードと他のいくつかの Pod が実行され、Hosted Cluster Config Operator によって管理される場所です。

データプレーンの ImageContentSourcePolicy (ICSP) カスタムリソースは、ホステッドクラスターのマニフェストの ImageContentSources API を通じて管理されます。

コントロールプレーンの ICSP オブジェクトは、管理クラスターで管理されます。このオブジェクトは、HyperShift Operator によって解析され、registry-overrides エントリーとして Control Plane Operator と共有されます。このエントリーは、Hosted Control Plane の namespace 内の利用可能なデプロイメントのいずれかに引数として挿入されます。

Hosted Control Plane 内の非接続レジストリーを操作するには、まず管理クラスターに適切な ICSP を作成する必要があります。その後、非接続ワークロードをデータプレーンにデプロイするために、ホステッドクラスターのマニフェストの ImageContentSources フィールドに必要なエントリーを追加する必要があります。

6.4.1. 非接続環境で IBM Z に Hosted Control Plane をデプロイするための前提条件

  • ミラーレジストリー。詳細は、「mirror registry for Red Hat OpenShift を使用したミラーレジストリーの作成」を参照してください。
  • 非接続インストールのミラーイメージ。詳細は、「oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング」参照してください。

6.4.2. 管理クラスターに認証情報とレジストリー認証局を追加する

管理クラスターからミラーレジストリーイメージをプルするには、まずミラーレジストリーの認証情報と認証局を管理クラスターに追加する必要があります。以下の手順を使用してください。

手順

  1. 次のコマンドを実行して、ミラーレジストリーの証明書を含む ConfigMap を作成します。

    $ oc apply -f registry-config.yaml
    Copy to Clipboard Toggle word wrap

    registry-config.yaml ファイルの例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: registry-config
      namespace: openshift-config
    data:
      <mirror_registry>: |
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap

  2. image.config.openshift.io クラスター全体のオブジェクトにパッチを適用して、次のエントリーを追加します。

    spec:
      additionalTrustedCA:
        - name: registry-config
    Copy to Clipboard Toggle word wrap
  3. 管理クラスターのプルシークレットを更新して、ミラーレジストリーの認証情報を追加します。

    1. 次のコマンドを実行して、クラスターからプルシークレットを JSON 形式で取得します。

      $ oc get secret/pull-secret -n openshift-config -o json \
        | jq -r '.data.".dockerconfigjson"' \
        | base64 -d > authfile
      Copy to Clipboard Toggle word wrap
    2. 取得したシークレットの JSON ファイルを編集して、認証局の認証情報を含むセクションを追加します。

        "auths": {
          "<mirror_registry>": { 
      1
      
            "auth": "<credentials>", 
      2
      
            "email": "you@example.com"
          }
        },
      Copy to Clipboard Toggle word wrap
      1
      ミラーレジストリーの名前を指定します。
      2
      ミラーレジストリーの認証情報を指定して、イメージを取得できるようにします。
    3. 次のコマンドを実行して、クラスター上のプルシークレットを更新します。

      $ oc set data secret/pull-secret -n openshift-config \
        --from-file=.dockerconfigjson=authfile
      Copy to Clipboard Toggle word wrap

6.4.3. AgentServiceConfig リソースのレジストリー認証局をミラーレジストリーで更新する

イメージのミラーレジストリーを使用する場合、イメージをセキュアにプルできるように、エージェントがレジストリーの証明書を信頼する必要があります。ConfigMap を作成することにより、ミラーレジストリーの認証局を AgentServiceConfig カスタムリソースに追加できます。

前提条件

  • multicluster engine for Kubernetes Operator をインストールした。

手順

  1. multicluster engine Operator をインストールしたのと同じ namespace で、ミラーレジストリーの詳細を含む ConfigMap リソースを作成します。この ConfigMap リソースにより、ホステッドクラスターのワーカーに、ミラーレジストリーからイメージを取得する権限が付与されます。

    ConfigMap ファイルの例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: mirror-config
      namespace: multicluster-engine
      labels:
        app: assisted-service
    data:
      ca-bundle.crt: |
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
      registries.conf: |
    
        [[registry]]
          location = "registry.stage.redhat.io"
          insecure = false
          blocked = false
          mirror-by-digest-only = true
          prefix = ""
    
          [[registry.mirror]]
            location = "<mirror_registry>"
            insecure = false
    
        [[registry]]
          location = "registry.redhat.io/multicluster-engine"
          insecure = false
          blocked = false
          mirror-by-digest-only = true
          prefix = ""
    
          [[registry.mirror]]
            location = "<mirror_registry>/multicluster-engine" 
    1
    
            insecure = false
    Copy to Clipboard Toggle word wrap

    1
    <mirror_registry> はミラーレジストリーの名前です。
  2. AgentServiceConfig リソースにパッチを適用して、作成した ConfigMap リソースを含めます。AgentServiceConfig リソースが存在しない場合は、次の内容を埋め込んだ AgentServiceConfig リソースを作成します。

    spec:
      mirrorRegistryRef:
        name: mirror-config
    Copy to Clipboard Toggle word wrap

6.4.4. ホステッドクラスターにレジストリー認証局を追加する

非接続環境で IBM Z に Hosted Control Plane をデプロイする場合は、additional-trust-bundle リソースと image-content-sources リソースを含めます。これらのリソースにより、ホステッドクラスターがデータプレーンのワーカーに認証局を注入して、イメージをレジストリーからプルできるようになります。

  1. image-content-sources の情報を含む icsp.yaml ファイルを作成します。

    image-content-sources の情報は、oc-mirror を使用してイメージをミラーリングした後に生成される ImageContentSourcePolicy の YAML ファイルで入手できます。

    ImageContentSourcePolicy ファイルの例

    # cat icsp.yaml
    - mirrors:
      - <mirror_registry>/openshift/release
      source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    - mirrors:
      - <mirror_registry>/openshift/release-images
      source: quay.io/openshift-release-dev/ocp-release
    Copy to Clipboard Toggle word wrap

  2. ホステッドクラスターを作成し、additional-trust-bundle 証明書を指定して、コンピュートノードを証明書で更新します。次に例を示します。

    $ hcp create cluster agent \
        --name=<hosted_cluster_name> \ 
    1
    
        --pull-secret=<path_to_pull_secret> \ 
    2
    
        --agent-namespace=<hosted_control_plane_namespace> \ 
    3
    
        --base-domain=<basedomain> \ 
    4
    
        --api-server-address=api.<hosted_cluster_name>.<basedomain> \
        --etcd-storage-class=<etcd_storage_class> \ 
    5
    
        --ssh-key  <path_to_ssh_public_key> \ 
    6
    
        --namespace <hosted_cluster_namespace> \ 
    7
    
        --control-plane-availability-policy SingleReplica \
        --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> \ 
    8
    
        --additional-trust-bundle <path for cert> \ 
    9
    
        --image-content-sources icsp.yaml
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    プルシークレットへのパスを置き換えます (例: /user/name/pullsecret)。
    3
    <hosted_control_plane_namespace> は、Hosted Control Plane の namespace の名前 (例: clusters-hosted) に置き換えます。
    4
    名前をベースドメインに置き換えます (例: example.com)。
    5
    etcd ストレージクラス名を置き換えます (例: lvm-storageclass)。
    6
    SSH 公開鍵へのパスを置き換えます。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    7 8
    使用するサポート対象の OpenShift Container Platform バージョン (例: 4.19.0-multi) に置き換えます。
    9
    ミラーレジストリーの認証局へのパスを置き換えます。

6.5. オフライン環境でのユーザーワークロードの監視

hypershift-addon マネージドクラスターアドオンは、HyperShift Operator の --enable-uwm-telemetry-remote-write オプションを有効にします。このオプションを有効にすると、ユーザーワークロードの監視が有効になり、コントロールプレーンからテレメトリーメトリクスをリモートで書き込むことができるようになります。

6.5.1. ユーザーワークロード監視の問題の解決

インターネットに接続されていない OpenShift Container Platform クラスターに multicluster engine Operator をインストールした場合、次のコマンドを入力して HyperShift Operator のユーザーワークロードの監視機能を実行しようとすると、エラーが発生して機能が失敗します。

$ oc get events -n hypershift
Copy to Clipboard Toggle word wrap

エラーの例

LAST SEEN   TYPE      REASON           OBJECT                MESSAGE
4m46s       Warning   ReconcileError   deployment/operator   Failed to ensure UWM telemetry remote write: cannot get telemeter client secret: Secret "telemeter-client" not found
Copy to Clipboard Toggle word wrap

エラーを解決するには、local-cluster namespace に config map を作成して、ユーザーワークロード監視オプションを無効にする必要があります。アドオンを有効にする前または後に config map を作成できます。アドオンエージェントは、HyperShift Operator を再設定します。

手順

  1. 次の config map を作成します。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: hypershift-operator-install-flags
      namespace: local-cluster
    data:
      installFlagsToAdd: ""
      installFlagsToRemove: "--enable-uwm-telemetry-remote-write"
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して config map を適用します。

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

6.5.2. Hosted Control Plane 機能のステータス確認

Hosted Control Plane 機能がデフォルトで有効になりました。

手順

  1. この機能が無効になっており、有効にする場合は、次のコマンドを入力します。<multiclusterengine> は、multicluster engine Operator インスタンスの名前に置き換えます。

    $ oc patch mce <multiclusterengine> --type=merge -p \
      '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'
    Copy to Clipboard Toggle word wrap

    この機能を有効にすると、hypershift-addon マネージドクラスターアドオンが local-cluster マネージドクラスターにインストールされ、アドオンエージェントによって HyperShift Operator が multicluster engine Operator ハブクラスターにインストールされます。

  2. 次のコマンドを入力して、hypershift-addon マネージドクラスターアドオンがインストールされていることを確認します。

    $ oc get managedclusteraddons -n local-cluster hypershift-addon
    Copy to Clipboard Toggle word wrap

    出力例

    NAME               AVAILABLE   DEGRADED   PROGRESSING
    hypershift-addon   True        False
    Copy to Clipboard Toggle word wrap

  3. このプロセス時のタイムアウトを回避するには、以下のコマンドを入力します。

    $ oc wait --for=condition=Degraded=True managedclusteraddons/hypershift-addon \
      -n local-cluster --timeout=5m
    Copy to Clipboard Toggle word wrap
    $ oc wait --for=condition=Available=True managedclusteraddons/hypershift-addon \
      -n local-cluster --timeout=5m
    Copy to Clipboard Toggle word wrap

    プロセスが完了すると、hypershift-addon マネージドクラスターアドオンと HyperShift Operator がインストールされ、local-cluster マネージドクラスターがホステッドクラスターをホストおよび管理できるようになります。

デフォルトでは、hypershift-addon マネージドクラスターアドオンに対してノード配置設定は指定されていません。インフラストラクチャーノード上でアドオンを実行することを検討してください。そうすることで、サブスクリプション数に対する請求コストの発生や、個別のメンテナンスおよび管理タスクの発生を防ぐことができます。

手順

  1. ハブクラスターにログインします。
  2. 次のコマンドを入力して、hypershift-addon-deploy-config アドオンデプロイメント設定仕様を開いて編集します。

    $ oc edit addondeploymentconfig hypershift-addon-deploy-config \
      -n multicluster-engine
    Copy to Clipboard Toggle word wrap
  3. 以下の例のように、nodePlacement フィールドを仕様に追加します。

    apiVersion: addon.open-cluster-management.io/v1alpha1
    kind: AddOnDeploymentConfig
    metadata:
      name: hypershift-addon-deploy-config
      namespace: multicluster-engine
    spec:
      nodePlacement:
        nodeSelector:
          node-role.kubernetes.io/infra: ""
        tolerations:
        - effect: NoSchedule
          key: node-role.kubernetes.io/infra
          operator: Exists
    Copy to Clipboard Toggle word wrap
  4. 変更を保存します。hypershift-addon マネージドクラスターアドオンは、新規および既存のマネージドクラスターのインフラストラクチャーノードにデプロイされます。

第7章 Hosted Control Plane の証明書の設定

Hosted Control Plane の場合、証明書の設定手順はスタンドアロンの OpenShift Container Platform の場合とは異なります。

7.1. ホステッドクラスターでカスタム API サーバー証明書を設定する

API サーバーのカスタム証明書を設定するには、HostedCluster 設定の spec.configuration.apiServer セクションで証明書の詳細を指定します。

カスタム証明書は、Day 1 操作または Day 2 操作の中で設定できます。ただし、サービス公開ストラテジーはホステッドクラスターの作成中に設定した後は変更できないため、設定する予定の Kubernetes API サーバーのホスト名を知っておく必要があります。

前提条件

  • 管理クラスターにカスタム証明書が含まれる Kubernetes シークレットを作成しました。シークレットには次の鍵が含まれています。

    • tls.crt: 証明書
    • tls.key: 秘密鍵
  • HostedCluster 設定にロードバランサーを使用するサービス公開ストラテジーが含まれている場合は、証明書のサブジェクト代替名 (SAN) が内部 API エンドポイント (api-int) と競合しないことを確認してください。内部 API エンドポイントは、プラットフォームによって自動的に作成および管理されます。カスタム証明書と内部 API エンドポイントの両方で同じホスト名を使用すると、ルーティングの競合が発生する可能性があります。このルールの唯一の例外は、Private または PublicAndPrivate 設定で AWS をプロバイダーとして使用する場合です。このような場合、SAN の競合はプラットフォームによって管理されます。
  • 証明書は外部 API エンドポイントに対して有効である必要があります。
  • 証明書の有効期間は、クラスターの予想されるライフサイクルと一致します。

手順

  1. 次のコマンドを入力して、カスタム証明書を使用してシークレットを作成します。

    $ oc create secret tls sample-hosted-kas-custom-cert \
      --cert=path/to/cert.crt \
      --key=path/to/key.key \
      -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  2. 次の例に示すように、カスタム証明書の詳細を使用して HostedCluster 設定を更新します。

    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names: 
    1
    
              - api-custom-cert-sample-hosted.sample-hosted.example.com
              servingCertificate: 
    2
    
                name: sample-hosted-kas-custom-cert
    Copy to Clipboard Toggle word wrap
    1
    証明書が有効な DNS の名前のリスト。
    2
    カスタム証明書が含まれるシークレットの名前。
  3. 次のコマンドを入力して、HostedCluster 設定に変更を適用します。

    $ oc apply -f <hosted_cluster_config>.yaml
    Copy to Clipboard Toggle word wrap

検証

  • API サーバー Pod をチェックして、新しい証明書がマウントされていることを確認します。
  • カスタムドメイン名を使用して API サーバーへの接続をテストします。
  • ブラウザーで、または openssl などのツールを使用して、証明書の詳細を確認します。

7.2. ホステッドクラスター用の Kubernetes API サーバーの設定

ホステッドクラスター用に Kubernetes API サーバーをカスタマイズする場合は、次の手順を実行します。

前提条件

  • 実行中のホステッドクラスターがある。
  • HostedCluster リソースを変更するためのアクセス権がある。
  • Kubernetes API サーバーに使用するカスタム DNS ドメインがある。

    • カスタム DNS ドメインは適切に設定され、解決可能である。
    • DNS ドメインには有効な TLS 証明書が設定されている。
    • ドメインへのネットワークアクセスが環境内で適切に設定されている。
    • カスタム DNS ドメインは、ホステッドクラスター全体において一意である。
  • カスタム証明書を設定した。詳細は「、ホステッドクラスターでのカスタム API サーバー証明書の設定」を参照してください。

手順

  1. プロバイダープラットフォームで、kubeAPIServerDNSName URL が Kubernetes API サーバーが公開されている IP アドレスを指すように DNS レコードを設定します。DNS レコードは適切に設定され、クラスターから解決可能である必要があります。

    DNS レコードの設定に使用するコマンドの例

    $ dig + short kubeAPIServerDNSName
    Copy to Clipboard Toggle word wrap

  2. HostedCluster 仕様で、次の例に示すように kubeAPIServerDNSName フィールドを変更します。

    apiVersion: hypershift.openshift.io/v1beta1
    kind: HostedCluster
    metadata:
      name: <hosted_cluster_name>
      namespace: <hosted_cluster_namespace>
    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names: 
    1
    
              - api-custom-cert-sample-hosted.sample-hosted.example.com
              servingCertificate: 
    2
    
                name: sample-hosted-kas-custom-cert
      kubeAPIServerDNSName: api-custom-cert-sample-hosted.sample-hosted.example.com 
    3
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    証明書が有効な DNS の名前のリスト。このフィールドにリストされる名前は、spec.servicePublishingStrategy.*hostname フィールドに指定された名前と同じにすることはできません。
    2
    カスタム証明書が含まれるシークレットの名前。
    3
    このフィールドは、API サーバーのエンドポイントとして使用される URI を受け入れます。
  3. 次のコマンドを入力して設定を適用します。

    $ oc -f <hosted_cluster_spec>.yaml
    Copy to Clipboard Toggle word wrap

    設定が適用されると、HyperShift Operator はカスタム DNS ドメインを指す新しい kubeconfig シークレットを生成します。

  4. CLI またはコンソールを使用して kubeconfig シークレットを取得します。

    1. CLI を使用してシークレットを取得するには、次のコマンドを入力します。

      $ kubectl get secret <hosted_cluster_name>-custom-admin-kubeconfig \
        -n <cluster_namespace> \
        -o jsonpath='{.data.kubeconfig}' | base64 -d
      Copy to Clipboard Toggle word wrap
    2. コンソールを使用してシークレットを取得するには、ホステッドクラスターに移動し、Download Kubeconfig をクリックします。

      注記

      コンソールで show login command オプションを使用して、新しい kubeconfig シークレットを使用することはできません。

カスタム DNS を使用してホステッドクラスターにアクセスするときに問題が発生した場合は、次のステップを実行します。

手順

  1. DNS レコードが適切に設定され、解決されていることを確認します。
  2. 次のコマンドを入力して、カスタムドメインの TLS 証明書が有効であること、およびドメインの SAN が正しいことを確認します。

    $ oc get secret \
      -n clusters <serving_certificate_name> \
      -o jsonpath='{.data.tls\.crt}' | base64 \
      -d |openssl x509 -text -noout -
    Copy to Clipboard Toggle word wrap
  3. カスタムドメインへのネットワーク接続が機能していることを確認します。
  4. 次の例に示すように、HostedCluster リソースで、ステータスに正しいカスタム kubeconfig 情報が表示されていることを確認します。

    HostedCluster ステータスの例

    status:
      customKubeconfig:
        name: sample-hosted-custom-admin-kubeconfig
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを入力して、HostedControlPlane namespace の kube-apiserver ログを確認します。

    $ oc logs -n <hosted_control_plane_namespace> \
      -l app=kube-apiserver -f -c kube-apiserver
    Copy to Clipboard Toggle word wrap

第8章 Hosted Control Plane の更新

Hosted Control Plane の更新には、ホステッドクラスターとノードプールの更新が含まれます。更新プロセス中にクラスターが完全に動作し続けるためには、コントロールプレーンとノードの更新を完了する際に、Kubernetes バージョンスキューポリシー の要件を満たす必要があります。

8.1. Hosted Control Plane をアップグレードするための要件

multicluster engine for Kubernetes Operator は、1 つ以上の OpenShift Container Platform クラスターを管理できます。OpenShift Container Platform でホステッドクラスターを作成した後、ホステッドクラスターをマネージドクラスターとして multicluster engine Operator にインポートする必要があります。その後、OpenShift Container Platform クラスターを管理クラスターとして使用できます。

Hosted Control Plane の更新を開始する前に、次の要件を考慮してください。

  • OpenShift Virtualization をプロバイダーとして使用する場合は、OpenShift Container Platform クラスターにベアメタルプラットフォームを使用する必要があります。
  • ホステッドクラスターのクラウドプラットフォームとして、ベアメタルまたは OpenShift Virtualization を使用する必要があります。ホステッドクラスターのプラットフォームタイプは、HostedCluster カスタムリソース (CR) の spec.Platform.type 仕様で確認できます。
重要

Hosted Control Plane は次の順序で更新する必要があります。

  1. OpenShift Container Platform クラスターを最新バージョンにアップグレードします。詳細は、「Web コンソールを使用してクラスターを更新」または「CLI を使用したクラスターの更新」を参照してください。
  2. multicluster engine Operator を最新バージョンにアップグレードします。詳細は、「インストールされている Operator の更新」を参照してください。
  3. ホステッドクラスターとノードプールを以前の OpenShift Container Platform バージョンから最新バージョンにアップグレードします。詳細は、「ホステッドクラスターのコントロールプレーンの更新」および「ホステッドクラスターのノードプールの更新」を参照してください。

8.2. ホステッドクラスターのチャネルの設定

利用可能な更新は、HostedCluster カスタムリソース (CR) の HostedCluster.Status フィールドで確認できます。

利用可能な更新は、ホステッドクラスターの Cluster Version Operator (CVO) からは取得されません。利用可能な更新のリストは、HostedCluster カスタムリソース (CR) の次のフィールドに含まれている利用可能な更新とは異なる場合があります。

  • status.version.availableUpdates
  • status.version.conditionalUpdates

初期の HostedCluster CR には、status.version.availableUpdates フィールドと status.version.conditionalUpdates フィールドに情報が含まれていません。spec.channel フィールドを OpenShift Container Platform の stable リリースバージョンに設定すると、HyperShift Operator が HostedCluster CR をリコンサイルし、利用可能な更新と条件付き更新で status.version フィールドを更新します。

チャネル設定を含む HostedCluster CR の次の例を参照してください。

spec:
  autoscaling: {}
  channel: stable-4.y 
1

  clusterID: d6d42268-7dff-4d37-92cf-691bd2d42f41
  configuration: {}
  controllerAvailabilityPolicy: SingleReplica
  dns:
    baseDomain: dev11.red-chesterfield.com
    privateZoneID: Z0180092I0DQRKL55LN0
    publicZoneID: Z00206462VG6ZP0H2QLWK
Copy to Clipboard Toggle word wrap
1
<4.y> は、spec.release で指定した OpenShift Container Platform リリースバージョンに置き換えます。たとえば、spec.releaseocp-release:4.16.4-multi に設定する場合は、spec.channelstable-4.16 に設定する必要があります。

HostedCluster CR でチャネルを設定した後、status.version.availableUpdates フィールドと status.version.conditionalUpdates フィールドの出力を表示するには、次のコマンドを実行します。

$ oc get -n <hosted_cluster_namespace> hostedcluster <hosted_cluster_name> -o yaml
Copy to Clipboard Toggle word wrap

出力例

version:
  availableUpdates:
  - channels:
    - candidate-4.16
    - candidate-4.17
    - eus-4.16
    - fast-4.16
    - stable-4.16
    image: quay.io/openshift-release-dev/ocp-release@sha256:b7517d13514c6308ae16c5fd8108133754eb922cd37403ed27c846c129e67a9a
    url: https://access.redhat.com/errata/RHBA-2024:6401
    version: 4.16.11
  - channels:
    - candidate-4.16
    - candidate-4.17
    - eus-4.16
    - fast-4.16
    - stable-4.16
    image: quay.io/openshift-release-dev/ocp-release@sha256:d08e7c8374142c239a07d7b27d1170eae2b0d9f00ccf074c3f13228a1761c162
    url: https://access.redhat.com/errata/RHSA-2024:6004
    version: 4.16.10
  - channels:
    - candidate-4.16
    - candidate-4.17
    - eus-4.16
    - fast-4.16
    - stable-4.16
    image: quay.io/openshift-release-dev/ocp-release@sha256:6a80ac72a60635a313ae511f0959cc267a21a89c7654f1c15ee16657aafa41a0
    url: https://access.redhat.com/errata/RHBA-2024:5757
    version: 4.16.9
  - channels:
    - candidate-4.16
    - candidate-4.17
    - eus-4.16
    - fast-4.16
    - stable-4.16
    image: quay.io/openshift-release-dev/ocp-release@sha256:ea624ae7d91d3f15094e9e15037244679678bdc89e5a29834b2ddb7e1d9b57e6
    url: https://access.redhat.com/errata/RHSA-2024:5422
    version: 4.16.8
  - channels:
    - candidate-4.16
    - candidate-4.17
    - eus-4.16
    - fast-4.16
    - stable-4.16
    image: quay.io/openshift-release-dev/ocp-release@sha256:e4102eb226130117a0775a83769fe8edb029f0a17b6cbca98a682e3f1225d6b7
    url: https://access.redhat.com/errata/RHSA-2024:4965
    version: 4.16.6
  - channels:
    - candidate-4.16
    - candidate-4.17
    - eus-4.16
    - fast-4.16
    - stable-4.16
    image: quay.io/openshift-release-dev/ocp-release@sha256:f828eda3eaac179e9463ec7b1ed6baeba2cd5bd3f1dd56655796c86260db819b
    url: https://access.redhat.com/errata/RHBA-2024:4855
    version: 4.16.5
  conditionalUpdates:
  - conditions:
    - lastTransitionTime: "2024-09-23T22:33:38Z"
      message: |-
        Could not evaluate exposure to update risk SRIOVFailedToConfigureVF (creating PromQL round-tripper: unable to load specified CA cert /etc/tls/service-ca/service-ca.crt: open /etc/tls/service-ca/service-ca.crt: no such file or directory)
          SRIOVFailedToConfigureVF description: OCP Versions 4.14.34, 4.15.25, 4.16.7 and ALL subsequent versions include kernel datastructure changes which are not compatible with older versions of the SR-IOV operator. Please update SR-IOV operator to versions dated 20240826 or newer before updating OCP.
          SRIOVFailedToConfigureVF URL: https://issues.redhat.com/browse/NHE-1171
      reason: EvaluationFailed
      status: Unknown
      type: Recommended
    release:
      channels:
      - candidate-4.16
      - candidate-4.17
      - eus-4.16
      - fast-4.16
      - stable-4.16
      image: quay.io/openshift-release-dev/ocp-release@sha256:fb321a3f50596b43704dbbed2e51fdefd7a7fd488ee99655d03784d0cd02283f
      url: https://access.redhat.com/errata/RHSA-2024:5107
      version: 4.16.7
    risks:
    - matchingRules:
      - promql:
          promql: |
            group(csv_succeeded{_id="d6d42268-7dff-4d37-92cf-691bd2d42f41", name=~"sriov-network-operator[.].*"})
            or
            0 * group(csv_count{_id="d6d42268-7dff-4d37-92cf-691bd2d42f41"})
        type: PromQL
      message: OCP Versions 4.14.34, 4.15.25, 4.16.7 and ALL subsequent versions
        include kernel datastructure changes which are not compatible with older
        versions of the SR-IOV operator. Please update SR-IOV operator to versions
        dated 20240826 or newer before updating OCP.
      name: SRIOVFailedToConfigureVF
      url: https://issues.redhat.com/browse/NHE-1171
Copy to Clipboard Toggle word wrap

8.3. ホステッドクラスターの OpenShift Container Platform バージョンの更新

Hosted Control Plane は、コントロールプレーンとデータプレーン間の更新の分離を可能にします。

クラスターサービスプロバイダーやクラスター管理者は、コントロールプレーンとデータを個別に管理できます。

コントロールプレーンは HostedCluster カスタムリソース (CR) を変更することで更新でき、ノードは NodePool CR を変更することで更新できます。HostedCluster CR と NodePool CR では、どちらも .release フィールドで OpenShift Container Platform リリースイメージを指定します。

更新プロセス中にホステッドクラスターを完全に機能させ続けるには、コントロールプレーンとノードの更新が Kubernetes バージョンスキューポリシー に準拠している必要があります。

8.3.1. multicluster engine Operator ハブ管理クラスター

multicluster engine for Kubernetes Operator には、管理クラスターのサポート対象状態を維持するために、特定の OpenShift Container Platform バージョンが必要です。multicluster engine Operator は、OpenShift Container Platform Web コンソールの OperatorHub からインストールできます。

multicluster engine Operator のバージョンは、次のサポートマトリックスを参照してください。

multicluster engine Operator は、次の OpenShift Container Platform バージョンをサポートしています。

  • 最新の未リリースバージョン
  • 最新リリースバージョン
  • 最新リリースバージョンの 2 つ前のバージョン

Red Hat Advanced Cluster Management (RHACM) の一部として multicluster engine Operator バージョンを入手することもできます。

8.3.2. ホステッドクラスターでサポートされる OpenShift Container Platform のバージョン

ホステッドクラスターをデプロイする場合、管理クラスターの OpenShift Container Platform バージョンは、ホステッドクラスターの OpenShift Container Platform バージョンに影響しません。

HyperShift Operator は、hypershift namespace に supported-versions ConfigMap を作成します。supported-versions ConfigMap には、デプロイ可能なサポートされている OpenShift Container Platform バージョンの範囲が記述されています。

supported-versions ConfigMap の次の例を参照してください。

apiVersion: v1
data:
    server-version: 2f6cfe21a0861dea3130f3bed0d3ae5553b8c28b
    supported-versions: '{"versions":["4.17","4.16","4.15","4.14"]}'
kind: ConfigMap
metadata:
    creationTimestamp: "2024-06-20T07:12:31Z"
    labels:
        hypershift.openshift.io/supported-versions: "true"
    name: supported-versions
    namespace: hypershift
    resourceVersion: "927029"
    uid: f6336f91-33d3-472d-b747-94abae725f70
Copy to Clipboard Toggle word wrap
重要

ホステッドクラスターを作成するには、サポートバージョン範囲内の OpenShift Container Platform バージョンを使用する必要があります。ただし、multicluster engine Operator が管理できるのは、n+1 から n-2 までの OpenShift Container Platform バージョンのみです。ここで n は現在のマイナーバージョンを定義します。multicluster engine Operator サポートマトリックスをチェックすると、multicluster engine Operator によって管理されるホステッドクラスターが、サポートされている OpenShift Container Platform の範囲内であることを確認できます。

上位バージョンのホステッドクラスターを OpenShift Container Platform にデプロイするには、multicluster engine Operator を新しいマイナーバージョンリリースに更新して、新しいバージョンの Hypershift Operator をデプロイする必要があります。multicluster engine Operator を新しいパッチ (z-stream) にアップグレードしても、HyperShift Operator は次のバージョンに更新されません。

hcp version コマンドの次の出力例を参照してください。管理クラスターの OpenShift Container Platform 4.16 でサポートされている OpenShift Container Platform バージョンを示しています。

Client Version: openshift/hypershift: fe67b47fb60e483fe60e4755a02b3be393256343. Latest supported OCP: 4.17.0
Server Version: 05864f61f24a8517731664f8091cedcfc5f9b60d
Server Supports OCP Versions: 4.17, 4.16, 4.15, 4.14
Copy to Clipboard Toggle word wrap

8.4. ホステッドクラスターの更新

spec.release.image 値は、コントロールプレーンのバージョンを決定します。HostedCluster オブジェクトは、意図した spec.release.image 値を HostedControlPlane.spec.releaseImage 値に送信し、適切な Control Plane Operator のバージョンを実行します。

Hosted Control Plane は、新しいバージョンの Cluster Version Operator (CVO) により、新しいバージョンのコントロールプレーンコンポーネントと OpenShift Container Platform コンポーネントのロールアウトを管理します。

重要

Hosted Control Plane では、NodeHealthCheck リソースが CVO のステータスを検出できません。クラスター管理者は、クラスターの更新などの重要な操作を実行する前に、新しい修復アクションがクラスターの更新に干渉するのを防ぐために、NodeHealthCheck によってトリガーされた修復を手動で一時停止する必要があります。

修復を一時停止するには、NodeHealthCheck リソースの pauseRequests フィールドの値として、文字列の配列 (例: pause-test-cluster) を入力します。詳細は、Node Health Check Operator について を参照してください。

クラスターの更新が完了したら、修復を編集または削除できます。ComputeNodeHealthCheck ページに移動し、ノードヘルスチェックをクリックして、Actions をクリックすると、ドロップダウンリストが表示されます。

8.5. ノードプールの更新

ノードプールを使用すると、spec.release および spec.config の値を公開することで、ノードで実行されているソフトウェアを設定できます。次の方法でノードプールのローリング更新を開始できます。

  • spec.release または spec.config の値を変更します。
  • AWS インスタンスタイプなどのプラットフォーム固有のフィールドを変更します。結果は、新しいタイプの新規インスタンスのセットになります。
  • クラスター設定を変更します (変更がノードに伝播される場合)。

ノードプールは、replace 更新とインプレース更新をサポートします。nodepool.spec.release 値は、特定のノードプールのバージョンを決定します。NodePool オブジェクトは、.spec.management.upgradeType 値に従って、置換またはインプレースローリング更新を完了します。

ノードプールを作成した後は、更新タイプは変更できません。更新タイプを変更する場合は、ノードプールを作成し、他のノードプールを削除する必要があります。

8.5.1. ノードプールの replace 更新

置き換え 更新では、以前のバージョンから古いインスタンスが削除され、新しいバージョンでインスタンスが作成されます。この更新タイプは、このレベルの不変性がコスト効率に優れているクラウド環境で効果的です。

replace 更新では、ノードが完全に再プロビジョニングされるため、手動による変更は一切保持されません。

8.5.2. ノードプールのインプレース更新

インプレース 更新では、インスタンスのオペレーティングシステムが直接更新されます。このタイプは、ベアメタルなど、インフラストラクチャーの制約が高い環境に適しています。

インプレース更新では手動による変更を保存できますが、kubelet 証明書など、クラスターが直接管理するファイルシステムまたはオペレーティングシステムの設定に手動で変更を加えると、エラーが報告されます。

8.6. ホステッドクラスターのノードプールの更新

ホステッドクラスターのノードプールを更新することで、OpenShift Container Platform のバージョンを更新できます。ノードプールのバージョンが Hosted Control Plane のバージョンを超えることはできません。

NodePool カスタムリソース (CR) の .spec.release フィールドは、ノードプールのバージョンを示します。

手順

  • 次のコマンドを入力して、ノードプールの spec.release.image 値を変更します。

    $ oc patch nodepool <node_pool_name> -n <hosted_cluster_namespace> \
    1
    
      --type=merge \
      -p '{"spec":{"nodeDrainTimeout":"60s","release":{"image":"<openshift_release_image>"}}}' 
    2
    Copy to Clipboard Toggle word wrap
    1
    <node_pool_name><hosted_cluster_namespace> を、それぞれノードプール名とホステッドクラスターの namespace に置き換えます。
    2
    <openshift_release_image> 変数は、アップグレードする新しい OpenShift Container Platform リリースイメージを指定します (例: quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64)。<4.y.z> をサポートされている OpenShift Container Platform バージョンに置き換えます。

検証

  • 新しいバージョンがロールアウトされたことを確認するには、次のコマンドを実行して、ノードプールの .status.conditions 値を確認します。

    $ oc get -n <hosted_cluster_namespace> nodepool <node_pool_name> -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    status:
     conditions:
     - lastTransitionTime: "2024-05-20T15:00:40Z"
           message: 'Using release image: quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64' 
    1
    
           reason: AsExpected
           status: "True"
           type: ValidReleaseImage
    Copy to Clipboard Toggle word wrap

    1
    <4.y.z> をサポートされている OpenShift Container Platform バージョンに置き換えます。

8.7. ホステッドクラスターのコントロールプレーンの更新

Hosted Control Plane でホステッドクラスターを更新することで、OpenShift Container Platform のバージョンをアップグレードできます。HostedCluster カスタムリソース (CR) の .spec.release は、コントロールプレーンのバージョンを示します。HostedCluster は、.spec.release フィールドを HostedControlPlane.spec.release に更新し、適切な Control Plane Operator のバージョンを実行します。

HostedControlPlane リソースは、新しいバージョンの Cluster Version Operator (CVO) により、データプレーン内の OpenShift Container Platform コンポーネントとともに、新しいバージョンのコントロールプレーンコンポーネントのロールアウトを調整します。HostedControlPlane には次のアーティファクトが含まれています。

  • CVO
  • Cluster Network Operator (CNO)
  • Cluster Ingress Operator
  • Kube API サーバー、スケジューラー、およびマネージャーのマニフェスト
  • Machine approver
  • Autoscaler
  • Kube API サーバー、Ignition、Konnectivity など、コントロールプレーンエンドポイントの Ingress を有効にするインフラストラクチャーリソース

HostedCluster CR の .spec.release フィールドを設定すると、status.version.availableUpdates フィールドと status.version.conditionalUpdates フィールドの情報を使用してコントロールプレーンを更新できます。

手順

  1. 次のコマンドを実行して、ホステッドクラスターに hypershift.openshift.io/force-upgrade-to=<openshift_release_image> アノテーションを追加します。

    $ oc annotate hostedcluster \
      -n <hosted_cluster_namespace> <hosted_cluster_name> \
    1
    
      "hypershift.openshift.io/force-upgrade-to=<openshift_release_image>" \
    2
    
      --overwrite
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name><hosted_cluster_namespace> を、それぞれホステッドクラスター名とホステッドクラスター namespace に置き換えます。
    2
    <openshift_release_image> 変数は、アップグレードする新しい OpenShift Container Platform リリースイメージを指定します (例: quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64)。<4.y.z> をサポートされている OpenShift Container Platform バージョンに置き換えます。
  2. 次のコマンドを実行して、ホステッドクラスターの spec.release.image 値を変更します。

    $ oc patch hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> \
      --type=merge \
      -p '{"spec":{"release":{"image":"<openshift_release_image>"}}}'
    Copy to Clipboard Toggle word wrap

検証

  • 新しいバージョンがロールアウトされたことを確認するには、次のコマンドを実行して、ホステッドクラスターの .status.conditions.status.version の値を確認します。

    $ oc get -n <hosted_cluster_namespace> hostedcluster <hosted_cluster_name> \
      -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    status:
     conditions:
     - lastTransitionTime: "2024-05-20T15:01:01Z"
            message: Payload loaded version="4.y.z" image="quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64" 
    1
    
            status: "True"
            type: ClusterVersionReleaseAccepted
    #...
    version:
          availableUpdates: null
          desired:
          image: quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64 
    2
    
          version: 4.y.z
    Copy to Clipboard Toggle word wrap

    1 2
    <4.y.z> をサポートされている OpenShift Container Platform バージョンに置き換えます。

8.8. multicluster engine Operator のコンソールを使用したホステッドクラスターの更新

multicluster engine Operator のコンソールを使用して、ホステッドクラスターを更新できます。

重要

ホステッドクラスターを更新する前に、ホステッドクラスターの利用可能な更新と条件付き更新を参照する必要があります。間違ったリリースバージョンを選択すると、ホステッドクラスターが壊れる可能性があります。

手順

  1. All clusters を選択します。
  2. InfrastructureClusters に移動して、管理対象のホステッドクラスターを表示します。
  3. Upgrade available リンクをクリックして、コントロールプレーンとノードプールを更新します。

第9章 Hosted Control Plane の高可用性

9.1. Hosted Control Plane の高可用性について

次のアクションを実装することで、Hosted Control Plane の高可用性 (HA) を維持できます。

  • ホステッドクラスターの etcd メンバーを回復します。
  • ホステッドクラスターの etcd をバックアップおよび復元します。
  • ホステッドクラスターの障害復旧プロセスを実行します。

9.1.1. 管理クラスターコンポーネントの障害の影響

管理クラスターコンポーネントに障害が発生しても、ワークロードは影響を受けません。OpenShift Container Platform 管理クラスターでは、回復力を提供するために、コントロールプレーンがデータプレーンから分離されています。

次の表は、管理クラスターコンポーネントの障害がコントロールプレーンとデータプレーンに与える影響を示しています。ただし、この表は管理クラスターコンポーネントの障害のすべてのシナリオを網羅しているわけではありません。

Expand
表9.1 故障したコンポーネントが Hosted Control Plane に与える影響
故障したコンポーネントの名前Hosted Control Plane API ステータスホステッドクラスターデータプレーンのステータス

ワーカーノード

利用可能

利用可能

アベイラビリティーゾーン

利用可能

利用可能

管理クラスターの制御プレーン

利用可能

利用可能

管理クラスターのコントロールプレーンとワーカーノード

利用不可

利用可能

9.2. Hosted Control Plane の異常な etcd クラスターの回復

高可用性コントロールプレーンでは、3 つの etcd Pod が etcd クラスター内のステートフルセットの一部として実行されます。etcd クラスターを回復するには、etcd クラスターの健全性をチェックして、正常でない etcd Pod を特定します。

9.2.1. etcd クラスターのステータスの確認

任意の etcd Pod にログインすると、etcd クラスターの健全性ステータスを確認できます。

手順

  1. 次のコマンドを入力して、etcd Pod にログインします。

    $ oc rsh -n openshift-etcd -c etcd <etcd_pod_name>
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、etcd クラスターの健全性ステータスを出力します。

    sh-4.4# etcdctl endpoint status -w table
    Copy to Clipboard Toggle word wrap

    出力例

    +------------------------------+-----------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
    |          ENDPOINT            |       ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
    +------------------------------+-----------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
    | https://192.168.1xxx.20:2379 | 8fxxxxxxxxxx    |  3.5.12 |  123 MB |     false |      false |        10 |     180156 |             180156 |        |
    | https://192.168.1xxx.21:2379 | a5xxxxxxxxxx    |  3.5.12 |  122 MB |     false |      false |        10 |     180156 |             180156 |        |
    | https://192.168.1xxx.22:2379 | 7cxxxxxxxxxx    |  3.5.12 |  124 MB |      true |      false |        10 |     180156 |             180156 |        |
    +-----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
    Copy to Clipboard Toggle word wrap

9.2.2. 障害が発生した etcd Pod の回復

3 ノードクラスターの各 etcd Pod には、データを保存するための独自の永続ボリューム要求 (PVC) があります。データが破損しているか欠落しているために、etcd Pod が失敗する可能性があります。障害が発生した etcd Pod とその PVC を回復できます。

手順

  1. etcd Pod が失敗していることを確認するには、次のコマンドを入力します。

    $ oc get pods -l app=etcd -n openshift-etcd
    Copy to Clipboard Toggle word wrap

    出力例

    NAME     READY   STATUS             RESTARTS     AGE
    etcd-0   2/2     Running            0            64m
    etcd-1   2/2     Running            0            45m
    etcd-2   1/2     CrashLoopBackOff   1 (5s ago)   64m
    Copy to Clipboard Toggle word wrap

    失敗した etcd Pod のステータスは CrashLoopBackOff または Error である可能性があります。

  2. 次のコマンドを入力して、障害が発生した Pod とその PVC を削除します。

    $ oc delete pods etcd-2 -n openshift-etcd
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、新しい etcd Pod が起動して実行していることを確認します。

    $ oc get pods -l app=etcd -n openshift-etcd
    Copy to Clipboard Toggle word wrap

    出力例

    NAME     READY   STATUS    RESTARTS   AGE
    etcd-0   2/2     Running   0          67m
    etcd-1   2/2     Running   0          48m
    etcd-2   2/2     Running   0          2m2s
    Copy to Clipboard Toggle word wrap

9.3. オンプレミス環境での etcd のバックアップと復元

オンプレミス環境のホステッドクラスターで etcd をバックアップおよび復元して、障害を修正できます。

9.3.1. オンプレミス環境のホステッドクラスターでの etcd のバックアップと復元

ホステッドクラスターで etcd をバックアップおよび復元することで、3 ノードクラスターの etcd メンバー内にあるデータの破損や欠落などの障害を修正できます。etcd クラスターの複数メンバーでデータの損失や CrashLoopBackOff ステータスが発生する場合、このアプローチにより etcd クォーラムの損失を防ぐことができます。

重要

この手順には、API のダウンタイムが必要です。

前提条件

  • oc および jq バイナリーがインストールされている。

手順

  1. まず、環境変数を設定します。

    1. 必要に応じて値を置き換えて次のコマンドを入力し、ホステッドクラスターの環境変数を設定します。

      $ CLUSTER_NAME=my-cluster
      Copy to Clipboard Toggle word wrap
      $ HOSTED_CLUSTER_NAMESPACE=clusters
      Copy to Clipboard Toggle word wrap
      $ CONTROL_PLANE_NAMESPACE="${HOSTED_CLUSTER_NAMESPACE}-${CLUSTER_NAME}"
      Copy to Clipboard Toggle word wrap
    2. 必要に応じて値を置き換えて次のコマンドを入力し、ホステッドクラスターのリコンシリエーションを一時停止します。

      $ oc patch -n ${HOSTED_CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} \
        -p '{"spec":{"pausedUntil":"true"}}' --type=merge
      Copy to Clipboard Toggle word wrap
  2. 次に、次のいずれかの方法を使用して etcd のスナップショットを取得します。

    1. 以前にバックアップした etcd のスナップショットを使用します。
    2. 使用可能な etcd Pod がある場合は、次の手順を実行して、アクティブな etcd Pod からスナップショットを取得します。

      1. 次のコマンドを入力して、etcd Pod をリスト表示します。

        $ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd
        Copy to Clipboard Toggle word wrap
      2. 次のコマンドを入力して、Pod データベースのスナップショットを取得し、マシンのローカルに保存します。

        $ ETCD_POD=etcd-0
        Copy to Clipboard Toggle word wrap
        $ oc exec -n ${CONTROL_PLANE_NAMESPACE} -c etcd -t ${ETCD_POD} -- \
          env ETCDCTL_API=3 /usr/bin/etcdctl \
          --cacert /etc/etcd/tls/etcd-ca/ca.crt \
          --cert /etc/etcd/tls/client/etcd-client.crt \
          --key /etc/etcd/tls/client/etcd-client.key \
          --endpoints=https://localhost:2379 \
          snapshot save /var/lib/snapshot.db
        Copy to Clipboard Toggle word wrap
      3. 次のコマンドを入力して、スナップショットが成功したことを確認します。

        $ oc exec -n ${CONTROL_PLANE_NAMESPACE} -c etcd -t ${ETCD_POD} -- \
          env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status \
          /var/lib/snapshot.db
        Copy to Clipboard Toggle word wrap
    3. 次のコマンドを入力して、スナップショットのローカルコピーを作成します。

      $ oc cp -c etcd ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/snapshot.db \
        /tmp/etcd.snapshot.db
      Copy to Clipboard Toggle word wrap
      1. etcd 永続ストレージからスナップショットデータベースのコピーを作成します。

        1. 次のコマンドを入力して、etcd Pod をリスト表示します。

          $ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd
          Copy to Clipboard Toggle word wrap
        2. 実行中の Pod を検索し、その名前を ETCD_POD: ETCD_POD=etcd-0 の値として設定し、次のコマンドを入力してそのスナップショットデータベースをコピーします。

          $ oc cp -c etcd \
            ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/data/member/snap/db \
            /tmp/etcd.snapshot.db
          Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、etcd statefulset をスケールダウンします。

    $ oc scale -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd --replicas=0
    Copy to Clipboard Toggle word wrap
    1. 次のコマンドを入力して、2 番目と 3 番目のメンバーのボリュームを削除します。

      $ oc delete -n ${CONTROL_PLANE_NAMESPACE} pvc/data-etcd-1 pvc/data-etcd-2
      Copy to Clipboard Toggle word wrap
    2. 最初の etcd メンバーのデータにアクセスする Pod を作成します。

      1. 次のコマンドを入力して、etcd イメージを取得します。

        $ ETCD_IMAGE=$(oc get -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd \
          -o jsonpath='{ .spec.template.spec.containers[0].image }')
        Copy to Clipboard Toggle word wrap
      2. etcd データへのアクセスを許可する Pod を作成します。

        $ cat << EOF | oc apply -n ${CONTROL_PLANE_NAMESPACE} -f -
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: etcd-data
        spec:
          replicas: 1
          selector:
            matchLabels:
              app: etcd-data
          template:
            metadata:
              labels:
                app: etcd-data
            spec:
              containers:
              - name: access
                image: $ETCD_IMAGE
                volumeMounts:
                - name: data
                  mountPath: /var/lib
                command:
                - /usr/bin/bash
                args:
                - -c
                - |-
                  while true; do
                    sleep 1000
                  done
              volumes:
              - name: data
                persistentVolumeClaim:
                  claimName: data-etcd-0
        EOF
        Copy to Clipboard Toggle word wrap
      3. 次のコマンドを入力して、etcd-data Pod のステータスを確認し、実行されるまで待ちます。

        $ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd-data
        Copy to Clipboard Toggle word wrap
      4. 次のコマンドを入力して、etcd-data Pod の名前を取得します。

        $ DATA_POD=$(oc get -n ${CONTROL_PLANE_NAMESPACE} pods --no-headers \
          -l app=etcd-data -o name | cut -d/ -f2)
        Copy to Clipboard Toggle word wrap
    3. 次のコマンドを入力して、etcd スナップショットを Pod にコピーします。

      $ oc cp /tmp/etcd.snapshot.db \
        ${CONTROL_PLANE_NAMESPACE}/${DATA_POD}:/var/lib/restored.snap.db
      Copy to Clipboard Toggle word wrap
    4. 次のコマンドを入力して、etcd-data Pod から古いデータを削除します。

      $ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- rm -rf /var/lib/data
      Copy to Clipboard Toggle word wrap
      $ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- mkdir -p /var/lib/data
      Copy to Clipboard Toggle word wrap
    5. 次のコマンドを入力して、etcd スナップショットを復元します。

      $ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- \
           etcdutl snapshot restore /var/lib/restored.snap.db \
           --data-dir=/var/lib/data --skip-hash-check \
           --name etcd-0 \
           --initial-cluster-token=etcd-cluster \
           --initial-cluster etcd-0=https://etcd-0.etcd-discovery.${CONTROL_PLANE_NAMESPACE}.svc:2380,etcd-1=https://etcd-1.etcd-discovery.${CONTROL_PLANE_NAMESPACE}.svc:2380,etcd-2=https://etcd-2.etcd-discovery.${CONTROL_PLANE_NAMESPACE}.svc:2380 \
           --initial-advertise-peer-urls https://etcd-0.etcd-discovery.${CONTROL_PLANE_NAMESPACE}.svc:2380
      Copy to Clipboard Toggle word wrap
    6. 次のコマンドを入力して、Pod から一時的な etcd スナップショットを削除します。

      $ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- \
        rm /var/lib/restored.snap.db
      Copy to Clipboard Toggle word wrap
    7. 次のコマンドを入力して、データアクセスデプロイメントを削除します。

      $ oc delete -n ${CONTROL_PLANE_NAMESPACE} deployment/etcd-data
      Copy to Clipboard Toggle word wrap
    8. 次のコマンドを入力して、etcd クラスターをスケールアップします。

      $ oc scale -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd --replicas=3
      Copy to Clipboard Toggle word wrap
    9. 次のコマンドを入力して、etcd メンバー Pod が返され、使用可能であると報告されるのを待ちます。

      $ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd -w
      Copy to Clipboard Toggle word wrap
  4. 次のコマンドを入力して、ホステッドクラスターのリコンシリエーションを復元します。

    $ oc patch -n ${HOSTED_CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} \
      -p '{"spec":{"pausedUntil":"null"}}' --type=merge
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを入力して、ホステッドクラスターを手動でロールアウトします。

    $ oc annotate hostedcluster -n \
      <hosted_cluster_namespace> <hosted_cluster_name> \
      hypershift.openshift.io/restart-date=$(date --iso-8601=seconds)
    Copy to Clipboard Toggle word wrap

    この時点では、Multus アドミッションコントローラーとネットワークノードアイデンティティー Pod はまだ起動しません。

  6. 次のコマンドを入力して、etcd の 2 番目と 3 番目のメンバーの Pod とその PVC を削除します。

    $ oc delete -n ${CONTROL_PLANE_NAMESPACE} pvc/data-etcd-1 pod/etcd-1 --wait=false
    Copy to Clipboard Toggle word wrap
    $ oc delete -n ${CONTROL_PLANE_NAMESPACE} pvc/data-etcd-2 pod/etcd-2 --wait=false
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを入力して、ホステッドクラスターを手動で再度ロールアウトします。

    $ oc annotate hostedcluster -n \
      <hosted_cluster_namespace> <hosted_cluster_name> \
      hypershift.openshift.io/restart-date=$(date --iso-8601=seconds) \
      --overwrite
    Copy to Clipboard Toggle word wrap

    数分後、コントロールプレーン Pod が稼働します。

9.4. AWS での etcd のバックアップと復元

障害を修正するために、Amazon Web Services (AWS) 上のホステッドクラスターで etcd をバックアップおよび復元できます。

9.4.1. ホステッドクラスターの etcd のスナップショットを取得する

ホステッドクラスターの etcd をバックアップするには、etcd のスナップショットを作成する必要があります。後で、スナップショットを使用して etcd を復元できます。

重要

この手順には、API のダウンタイムが必要です。

手順

  1. 次のコマンドを入力して、ホステッドクラスターのリコンシリエーションを一時停止します。

    $ oc patch -n clusters hostedclusters/<hosted_cluster_name> \
      -p '{"spec":{"pausedUntil":"true"}}' --type=merge
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、すべての etcd-writer デプロイメントを停止します。

    $ oc scale deployment -n <hosted_cluster_namespace> --replicas=0 \
      kube-apiserver openshift-apiserver openshift-oauth-apiserver
    Copy to Clipboard Toggle word wrap
  3. etcd スナップショットを取得するには、次のコマンドを実行して、各 etcd コンテナーで exec コマンドを使用します。

    $ oc exec -it <etcd_pod_name> -n <hosted_cluster_namespace> -- \
      env ETCDCTL_API=3 /usr/bin/etcdctl \
      --cacert /etc/etcd/tls/etcd-ca/ca.crt \
      --cert /etc/etcd/tls/client/etcd-client.crt \
      --key /etc/etcd/tls/client/etcd-client.key \
      --endpoints=localhost:2379 \
      snapshot save /var/lib/data/snapshot.db
    Copy to Clipboard Toggle word wrap
  4. スナップショットのステータスを確認するには、次のコマンドを実行して、各 etcd コンテナーで exec コマンドを使用します。

    $ oc exec -it <etcd_pod_name> -n <hosted_cluster_namespace> -- \
      env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status \
      /var/lib/data/snapshot.db
    Copy to Clipboard Toggle word wrap
  5. スナップショットデータを、S3 バケットなど、後で取得できる場所にコピーします。以下の例を参照してください。

    注記

    次の例では、署名バージョン 2 を使用しています。署名バージョン 4 をサポートするリージョン (例: us-east-2 リージョン) にいる場合は、署名バージョン 4 を使用してください。そうしないと、スナップショットを S3 バケットにコピーするときにアップロードが失敗します。

    BUCKET_NAME=somebucket
    CLUSTER_NAME=cluster_name
    FILEPATH="/${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db"
    CONTENT_TYPE="application/x-compressed-tar"
    DATE_VALUE=`date -R`
    SIGNATURE_STRING="PUT\n\n${CONTENT_TYPE}\n${DATE_VALUE}\n${FILEPATH}"
    ACCESS_KEY=accesskey
    SECRET_KEY=secret
    SIGNATURE_HASH=`echo -en ${SIGNATURE_STRING} | openssl sha1 -hmac ${SECRET_KEY} -binary | base64`
    HOSTED_CLUSTER_NAMESPACE=hosted_cluster_namespace
    
    oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- curl -X PUT -T "/var/lib/data/snapshot.db" \
      -H "Host: ${BUCKET_NAME}.s3.amazonaws.com" \
      -H "Date: ${DATE_VALUE}" \
      -H "Content-Type: ${CONTENT_TYPE}" \
      -H "Authorization: AWS ${ACCESS_KEY}:${SIGNATURE_HASH}" \
      https://${BUCKET_NAME}.s3.amazonaws.com/${CLUSTER_NAME}-snapshot.db
    Copy to Clipboard Toggle word wrap

  6. 後で新しいクラスターでスナップショットを復元するには、ホステッドクラスターが参照する暗号化シークレットを保存します。

    1. 次のコマンドを実行してシークレットの暗号鍵を取得します。

      $ oc get hostedcluster <hosted_cluster_name> \
        -o=jsonpath='{.spec.secretEncryption.aescbc}'
      {"activeKey":{"name":"<hosted_cluster_name>-etcd-encryption-key"}}
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行してシークレットの暗号鍵を保存します。

      $ oc get secret <hosted_cluster_name>-etcd-encryption-key \
        -o=jsonpath='{.data.key}'
      Copy to Clipboard Toggle word wrap

      新しいクラスターでスナップショットを復元するときに、このキーを復号化できます。

  7. 次のコマンドを入力して、すべての etcd-writer デプロイメントを再起動します。

    $ oc scale deployment -n <control_plane_namespace> --replicas=3 \
      kube-apiserver openshift-apiserver openshift-oauth-apiserver
    Copy to Clipboard Toggle word wrap
  8. 次のコマンドを入力して、ホステッドクラスターのリコンシリエーションを再開します。

    $ oc patch -n <hosted_cluster_namespace> \
      -p '[\{"op": "remove", "path": "/spec/pausedUntil"}]' --type=json
    Copy to Clipboard Toggle word wrap

次のステップ

etcd スナップショットを復元します。

9.4.2. ホステッドクラスターでの etcd スナップショットの復元

ホステッドクラスターからの etcd のスナップショットがある場合は、それを復元できます。現在、クラスターの作成中にのみ etcd スナップショットを復元できます。

etcd スナップショットを復元するには、create cluster --render コマンドからの出力を変更し、HostedCluster 仕様の etcd セクションで restoreSnapshotURL 値を定義します。

注記

hcp create コマンドの --render フラグはシークレットをレンダリングしません。シークレットをレンダリングするには、hcp create コマンドで --render フラグと --render-sensitive フラグの両方を使用する必要があります。

前提条件

ホステッドクラスターで etcd スナップショットを作成している。

手順

  1. aws コマンドラインインターフェイス (CLI) で事前に署名された URL を作成し、認証情報を etcd デプロイメントに渡さずに S3 から etcd スナップショットをダウンロードできるようにします。

    ETCD_SNAPSHOT=${ETCD_SNAPSHOT:-"s3://${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db"}
    ETCD_SNAPSHOT_URL=$(aws s3 presign ${ETCD_SNAPSHOT})
    Copy to Clipboard Toggle word wrap
  2. 次の URL を参照するように HostedCluster 仕様を変更します。

    spec:
      etcd:
        managed:
          storage:
            persistentVolume:
              size: 4Gi
            type: PersistentVolume
            restoreSnapshotURL:
            - "${ETCD_SNAPSHOT_URL}"
        managementType: Managed
    Copy to Clipboard Toggle word wrap
  3. spec.secretEncryption.aescbc 値から参照したシークレットに、前の手順で保存したものと同じ AES キーが含まれていることを確認します。

9.5. OpenShift Virtualization 上のホステッドクラスターのバックアップと復元

障害に対処するために、OpenShift Virtualization 上のホステッドクラスターをバックアップおよび復元できます。

9.5.1. OpenShift Virtualization 上のホステッドクラスターのバックアップ

OpenShift Virtualization 上のホステッドクラスターをバックアップしても、ホステッドクラスターは動作を継続できます。バックアップには、Hosted Control Plane のコンポーネントとホステッドクラスターの etcd が含まれます。

ホステッドクラスターが外部インフラストラクチャー上でコンピュートノードを実行していない場合、KubeVirt CSI によってプロビジョニングされた永続ボリューム要求 (PVC) に保存されているホステッドクラスターのワークロードデータもバックアップされます。バックアップには、コンピュートノードとして使用される KubeVirt 仮想マシン (VM) は含まれません。これらの仮想マシンは、復元プロセスの完了後、自動的に再作成されます。

手順

  1. 次の例のような YAML ファイルを作成して、Velero バックアップリソースを作成します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: hc-clusters-hosted-backup
      namespace: openshift-adp
      labels:
        velero.io/storage-location: default
    spec:
      includedNamespaces: 
    1
    
      - clusters
      - clusters-hosted
      includedResources:
      - sa
      - role
      - rolebinding
      - deployment
      - statefulset
      - pv
      - pvc
      - bmh
      - configmap
      - infraenv
      - priorityclasses
      - pdb
      - hostedcluster
      - nodepool
      - secrets
      - hostedcontrolplane
      - cluster
      - datavolume
      - service
      - route
      excludedResources: [ ]
      labelSelector: 
    2
    
        matchExpressions:
        - key: 'hypershift.openshift.io/is-kubevirt-rhcos'
          operator: 'DoesNotExist'
      storageLocation: default
      preserveNodePorts: true
      ttl: 4h0m0s
      snapshotMoveData: true 
    3
    
      datamover: "velero" 
    4
    
      defaultVolumesToFsBackup: false 
    5
    Copy to Clipboard Toggle word wrap
    1
    このフィールドでは、バックアップするオブジェクトの namespace を選択します。ホステッドクラスターと Hosted Control Plane の両方の namespace を含めます。この例では、clusters はホステッドクラスターの namespace であり、clusters-hosted は Hosted Control Plane の namespace です。デフォルトでは、HostedControlPlane の namespace は clusters-<hosted_cluster_name> です。
    2
    ホステッドクラスターノードとして使用される仮想マシンのブートイメージは、大規模な PVC に保存されています。バックアップ時間とストレージサイズを削減するには、このラベルセレクターを追加して、この PVC をバックアップから除外できます。
    3
    このフィールドと datamover フィールドにより、CSI VolumeSnapshots をリモートクラウドストレージに自動的にアップロードできます。
    4
    このフィールドと snapshotMoveData フィールドにより、CSI VolumeSnapshots をリモートクラウドストレージに自動的にアップロードできます。
    5
    このフィールドは、Pod ボリュームファイルシステムバックアップをデフォルトですべてのボリュームに使用するかどうかを指定します。特定の PVC をバックアップするには、この値を false に設定します。
  2. 次のコマンドを入力して、YAML ファイルに変更を適用します。

    $ oc apply -f <backup_file_name>.yaml
    Copy to Clipboard Toggle word wrap

    <backup_file_name> は、ファイル名に置き換えます。

  3. バックアップオブジェクトのステータスと Velero ログでバックアッププロセスを監視します。

    • バックアップオブジェクトの状態を監視するには、次のコマンドを入力します。

      $ watch "oc get backups.velero.io -n openshift-adp <backup_file_name> -o jsonpath='{.status}' | jq"
      Copy to Clipboard Toggle word wrap
    • Velero ログを監視するには、次のコマンドを入力します。

      $ oc logs -n openshift-adp -ldeploy=velero -f
      Copy to Clipboard Toggle word wrap

検証

  • status.phase フィールドが Completed の場合、バックアッププロセスは完了したと見なすことができます。

9.5.2. OpenShift Virtualization 上のホステッドクラスターの復元

OpenShift Virtualization 上のホステッドクラスターをバックアップした後、そのバックアップを復元できます。

注記

復元プロセスは、バックアップを作成したのと同じ管理クラスター上でのみ完了できます。

手順

  1. HostedControlPlane namespace で Pod または永続ボリューム要求 (PVC) が実行されていないことを確認します。
  2. 管理クラスターから次のオブジェクトを削除します。

    • HostedCluster
    • NodePool
    • PVC
  3. 次の例のような復元マニフェスト YAML ファイルを作成します。

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: hc-clusters-hosted-restore
      namespace: openshift-adp
    spec:
      backupName: hc-clusters-hosted-backup
      restorePVs: true 
    1
    
      existingResourcePolicy: update 
    2
    
      excludedResources:
      - nodes
      - events
      - events.events.k8s.io
      - backups.velero.io
      - restores.velero.io
      - resticrepositories.velero.io
    Copy to Clipboard Toggle word wrap
    1
    このフィールドにより、含まれている永続ボリュームを使用して Pod の復元が開始されます。
    2
    existingResourcePolicyupdate に設定すると、既存のオブジェクトがバックアップコンテンツで上書きされます。この操作により、イミュータブルなフィールドを含むオブジェクトで問題が発生する可能性があります。そのため、HostedCluster、ノードプール、および PVC を削除しました。このポリシーを設定しなかった場合、Velero エンジンによって、すでに存在するオブジェクトの復元がスキップされます。
  4. 次のコマンドを入力して、YAML ファイルに変更を適用します。

    $ oc apply -f <restore_resource_file_name>.yaml
    Copy to Clipboard Toggle word wrap

    <restore_resource_file_name> は、ファイル名に置き換えます。

  5. 復元ステータスフィールドと Velero ログを確認して、復元プロセスを監視します。

    • 復元ステータスフィールドを確認するには、次のコマンドを入力します。

      $ watch "oc get restores.velero.io -n openshift-adp <backup_file_name> -o jsonpath='{.status}' | jq"
      Copy to Clipboard Toggle word wrap
    • Velero ログを確認するには、次のコマンドを入力します。

      $ oc logs -n openshift-adp -ldeploy=velero -f
      Copy to Clipboard Toggle word wrap

検証

  • status.phase フィールドが Completed の場合、復元プロセスは完了したと見なすことができます。

次のステップ

  • しばらくすると、KubeVirt 仮想マシンが作成され、ホステッドクラスターにコンピュートノードとして参加します。ホステッドクラスターのワークロードが期待どおりに再度実行されていることを確認してください。

9.6. AWS でホステッドクラスターの障害復旧

ホステッドクラスターを Amazon Web Services (AWS) 内の同じリージョンに復元できます。たとえば、管理クラスターのアップグレードが失敗し、ホステッドクラスターが読み取り専用状態になっている場合は、障害復旧が必要になります。

障害復旧プロセスには次の手順が含まれます。

  1. ソース管理クラスターでのホステッドクラスターのバックアップ
  2. 宛先管理クラスターでのホステッドクラスターの復元
  3. ホステッドクラスターのソース管理クラスターからの削除

プロセス中、ワークロードは引き続き実行されます。クラスター API は一定期間使用できない場合がありますが、ワーカーノードで実行されているサービスには影響しません。

重要

API サーバー URL を維持するには、ソース管理クラスターと宛先管理クラスターの両方に --external-dns フラグが必要です。これにより、サーバー URL は https://api-sample-hosted.sample-hosted.aws.openshift.com で終わります。以下の例を参照してください。

例: 外部 DNS フラグ

--external-dns-provider=aws \
--external-dns-credentials=<path_to_aws_credentials_file> \
--external-dns-domain-filter=<basedomain>
Copy to Clipboard Toggle word wrap

API サーバー URL を維持するために --external-dns フラグを含めない場合、ホステッドクラスターを移行することはできません。

9.6.1. バックアップおよび復元プロセスの概要

バックアップと復元のプロセスは、以下のような仕組みとなっています。

  1. 管理クラスター 1 (ソース管理クラスターと見なすことができます) では、コントロールプレーンとワーカーが外部 DNS API を使用して対話します。外部 DNS API はアクセス可能で、管理クラスター間にロードバランサーが配置されています。

  2. ホステッドクラスターのスナップショットを作成します。これには、etcd、コントロールプレーン、およびワーカーノードが含まれます。このプロセスの間、ワーカーノードは外部 DNS API にアクセスできなくても引き続きアクセスを試みます。また、ワークロードが実行され、コントロールプレーンがローカルマニフェストファイルに保存され、etcd が S3 バケットにバックアップされます。データプレーンはアクティブで、コントロールプレーンは一時停止しています。

  3. 管理クラスター 2 (宛先管理クラスターと見なすことができます) では、S3 バケットから etcd を復元し、ローカルマニフェストファイルからコントロールプレーンを復元します。このプロセスの間、外部 DNS API は停止し、ホステッドクラスター API にアクセスできなくなり、API を使用するワーカーはマニフェストファイルを更新できなくなりますが、ワークロードは引き続き実行されます。

  4. 外部 DNS API に再びアクセスできるようになり、ワーカーノードはそれを使用して管理クラスター 2 に移動します。外部 DNS API は、コントロールプレーンを参照するロードバランサーにアクセスできます。

  5. 管理クラスター 2 では、コントロールプレーンとワーカーノードが外部 DNS API を使用して対話します。リソースは、etcd の S3 バックアップを除いて、管理クラスター 1 から削除されます。ホステッドクラスターを管理クラスター 1 で再度設定しようとしても、機能しません。

9.6.2. AWS 上のホステッドクラスターのバックアップ

ターゲット管理クラスターでホステッドクラスターを回復するには、まず関連するすべてのデータをバックアップする必要があります。

手順

  1. 次のコマンドを入力して、ソース管理クラスターを宣言する config map ファイルを作成します。

    $ oc create configmap mgmt-parent-cluster -n default \
      --from-literal=from=${MGMT_CLUSTER_NAME}
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、ホステッドクラスターとノードプールのリコンシリエーションをシャットダウンします。

    $ PAUSED_UNTIL="true"
    Copy to Clipboard Toggle word wrap
    $ oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} \
      -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
    Copy to Clipboard Toggle word wrap
    $ oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} \
      -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
    Copy to Clipboard Toggle word wrap
    $ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 \
      kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator
    Copy to Clipboard Toggle word wrap
  3. 次の bash スクリプトを実行して、etcd をバックアップし、データを S3 バケットにアップロードします。

    ヒント

    このスクリプトを関数でラップし、メイン関数から呼び出します。

    # ETCD Backup
    ETCD_PODS="etcd-0"
    if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then
      ETCD_PODS="etcd-0 etcd-1 etcd-2"
    fi
    
    for POD in ${ETCD_PODS}; do
      # Create an etcd snapshot
      oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/client/etcd-client-ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db
      oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.db
    
      FILEPATH="/${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db"
      CONTENT_TYPE="application/x-compressed-tar"
      DATE_VALUE=`date -R`
      SIGNATURE_STRING="PUT\n\n${CONTENT_TYPE}\n${DATE_VALUE}\n${FILEPATH}"
    
      set +x
      ACCESS_KEY=$(grep aws_access_key_id ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g")
      SECRET_KEY=$(grep aws_secret_access_key ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g")
      SIGNATURE_HASH=$(echo -en ${SIGNATURE_STRING} | openssl sha1 -hmac "${SECRET_KEY}" -binary | base64)
      set -x
    
      # FIXME: this is pushing to the OIDC bucket
      oc exec -it etcd-0 -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- curl -X PUT -T "/var/lib/data/snapshot.db" \
        -H "Host: ${BUCKET_NAME}.s3.amazonaws.com" \
        -H "Date: ${DATE_VALUE}" \
        -H "Content-Type: ${CONTENT_TYPE}" \
        -H "Authorization: AWS ${ACCESS_KEY}:${SIGNATURE_HASH}" \
        https://${BUCKET_NAME}.s3.amazonaws.com/${HC_CLUSTER_NAME}-${POD}-snapshot.db
    done
    Copy to Clipboard Toggle word wrap

    etcd のバックアップの詳細は、「ホステッドクラスターでの etcd のバックアップと復元」を参照してください。

  4. 以下のコマンドを入力して、Kubernetes および OpenShift Container Platform オブジェクトをバックアップします。次のオブジェクトをバックアップする必要があります。

    • HostedCluster namespace の HostedCluster および NodePool オブジェクト
    • HostedCluster namespace の HostedCluster シークレット
    • Hosted Control Plane namespace の HostedControlPlane
    • Hosted Control Plane namespace の Cluster
    • Hosted Control Plane namespace の AWSClusterAWSMachineTemplate、および AWSMachine
    • Hosted Control Plane namespace の MachineDeploymentsMachineSets、および Machines
    • Hosted Control Plane namespace の ControlPlane シークレット

      1. 次のコマンドを入力します。

        $ mkdir -p ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS} \
          ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
        Copy to Clipboard Toggle word wrap
        $ chmod 700 ${BACKUP_DIR}/namespaces/
        Copy to Clipboard Toggle word wrap
      2. 次のコマンドを入力して、HostedCluster namespace から HostedCluster オブジェクトをバックアップします。

        $ echo "Backing Up HostedCluster Objects:"
        Copy to Clipboard Toggle word wrap
        $ oc get hc ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS} -o yaml > \
          ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
        Copy to Clipboard Toggle word wrap
        $ echo "--> HostedCluster"
        Copy to Clipboard Toggle word wrap
        $ sed -i '' -e '/^status:$/,$d' \
          ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
        Copy to Clipboard Toggle word wrap
      3. 次のコマンドを入力して、HostedCluster namespace から NodePool オブジェクトをバックアップします。

        $ oc get np ${NODEPOOLS} -n ${HC_CLUSTER_NS} -o yaml > \
          ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml
        Copy to Clipboard Toggle word wrap
        $ echo "--> NodePool"
        Copy to Clipboard Toggle word wrap
        $ sed -i '' -e '/^status:$/,$ d' \
          ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml
        Copy to Clipboard Toggle word wrap
      4. 次のシェルスクリプトを実行して、HostedCluster の namespace 内のシークレットをバックアップします。

        $ echo "--> HostedCluster Secrets:"
        for s in $(oc get secret -n ${HC_CLUSTER_NS} | grep "^${HC_CLUSTER_NAME}" | awk '{print $1}'); do
            oc get secret -n ${HC_CLUSTER_NS} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-${s}.yaml
        done
        Copy to Clipboard Toggle word wrap
      5. 次のシェルスクリプトを実行して、HostedCluster のコントロールプレーン namespace 内のシークレットをバックアップします。

        $ echo "--> HostedCluster ControlPlane Secrets:"
        for s in $(oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} | egrep -v "docker|service-account-token|oauth-openshift|NAME|token-${HC_CLUSTER_NAME}" | awk '{print $1}'); do
            oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-${s}.yaml
        done
        Copy to Clipboard Toggle word wrap
      6. 次のコマンドを入力して Hosted Control Plane をバックアップします。

        $ echo "--> HostedControlPlane:"
        Copy to Clipboard Toggle word wrap
        $ oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \
          ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-${HC_CLUSTER_NAME}.yaml
        Copy to Clipboard Toggle word wrap
      7. 次のコマンドを入力してクラスターをバックアップします。

        $ echo "--> Cluster:"
        Copy to Clipboard Toggle word wrap
        $ CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} \
          -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})
        Copy to Clipboard Toggle word wrap
        $ oc get cluster ${CL_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \
          ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-${HC_CLUSTER_NAME}.yaml
        Copy to Clipboard Toggle word wrap
      8. 次のコマンドを入力して AWS クラスターをバックアップします。

        $ echo "--> AWS Cluster:"
        Copy to Clipboard Toggle word wrap
        $ oc get awscluster ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \
          ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-${HC_CLUSTER_NAME}.yaml
        Copy to Clipboard Toggle word wrap
      9. 次のコマンドを入力して、AWS の MachineTemplate オブジェクトをバックアップします。

        $ echo "--> AWS Machine Template:"
        Copy to Clipboard Toggle word wrap
        $ oc get awsmachinetemplate ${NODEPOOLS} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \
          ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-${HC_CLUSTER_NAME}.yaml
        Copy to Clipboard Toggle word wrap
      10. 次のシェルスクリプトを実行して、AWS の Machines オブジェクトをバックアップします。

        $ echo "--> AWS Machine:"
        Copy to Clipboard Toggle word wrap
        $ CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})
        for s in $(oc get awsmachines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --no-headers | grep ${CL_NAME} | cut -f1 -d\ ); do
            oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} awsmachines $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-${s}.yaml
        done
        Copy to Clipboard Toggle word wrap
      11. 次のシェルスクリプトを実行して、MachineDeployments オブジェクトをバックアップします。

        $ echo "--> HostedCluster MachineDeployments:"
        for s in $(oc get machinedeployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
            mdp_name=$(echo ${s} | cut -f 2 -d /)
            oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-${mdp_name}.yaml
        done
        Copy to Clipboard Toggle word wrap
      12. 次のシェルスクリプトを実行して、MachineSets オブジェクトをバックアップします。

        $ echo "--> HostedCluster MachineSets:"
        for s in $(oc get machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
            ms_name=$(echo ${s} | cut -f 2 -d /)
            oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-${ms_name}.yaml
        done
        Copy to Clipboard Toggle word wrap
      13. 次のシェルスクリプトを実行して、Hosted Control Plane の namespace から Machines オブジェクトをバックアップします。

        $ echo "--> HostedCluster Machine:"
        for s in $(oc get machine -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
            m_name=$(echo ${s} | cut -f 2 -d /)
            oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-${m_name}.yaml
        done
        Copy to Clipboard Toggle word wrap
  5. 次のコマンドを入力して、ControlPlane ルートをクリーンアップします。

    $ oc delete routes -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all
    Copy to Clipboard Toggle word wrap

    このコマンドを入力すると、ExternalDNS Operator が Route53 エントリーを削除できるようになります。

  6. 次のスクリプトを実行して、Route53 エントリーがクリーンであることを確認します。

    function clean_routes() {
    
        if [[ -z "${1}" ]];then
            echo "Give me the NS where to clean the routes"
            exit 1
        fi
    
        # Constants
        if [[ -z "${2}" ]];then
            echo "Give me the Route53 zone ID"
            exit 1
        fi
    
        ZONE_ID=${2}
        ROUTES=10
        timeout=40
        count=0
    
        # This allows us to remove the ownership in the AWS for the API route
        oc delete route -n ${1} --all
    
        while [ ${ROUTES} -gt 2 ]
        do
            echo "Waiting for ExternalDNS Operator to clean the DNS Records in AWS Route53 where the zone id is: ${ZONE_ID}..."
            echo "Try: (${count}/${timeout})"
            sleep 10
            if [[ $count -eq timeout ]];then
                echo "Timeout waiting for cleaning the Route53 DNS records"
                exit 1
            fi
            count=$((count+1))
            ROUTES=$(aws route53 list-resource-record-sets --hosted-zone-id ${ZONE_ID} --max-items 10000 --output json | grep -c ${EXTERNAL_DNS_DOMAIN})
        done
    }
    
    # SAMPLE: clean_routes "<HC ControlPlane Namespace>" "<AWS_ZONE_ID>"
    clean_routes "${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}" "${AWS_ZONE_ID}"
    Copy to Clipboard Toggle word wrap

検証

すべての OpenShift Container Platform オブジェクトと S3 バケットをチェックし、すべてが想定どおりであることを確認します。

次のステップ

ホステッドクラスターを復元します。

9.6.3. ホステッドクラスターの復元

バックアップしたすべてのオブジェクトを収集し、宛先管理クラスターに復元します。

前提条件

ソース管理クラスターからデータをバックアップしている。

ヒント

宛先管理クラスターの kubeconfig ファイルが、KUBECONFIG 変数に設定されているとおりに、あるいは、スクリプトを使用する場合は MGMT2_KUBECONFIG 変数に設定されているとおりに配置されていることを確認します。export KUBECONFIG=<Kubeconfig FilePath> を使用するか、スクリプトを使用する場合は export KUBECONFIG=${MGMT2_KUBECONFIG} を使用します。

手順

  1. 以下のコマンドを入力して、新しい管理クラスターに、復元するクラスターの namespace が含まれていないことを確認します。

    # Just in case
    $ export KUBECONFIG=${MGMT2_KUBECONFIG}
    $ BACKUP_DIR=${HC_CLUSTER_DIR}/backup
    
    # Namespace deletion in the destination Management cluster
    $ oc delete ns ${HC_CLUSTER_NS} || true
    $ oc delete ns ${HC_CLUSTER_NS}-{HC_CLUSTER_NAME} || true
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを入力して、削除された namespace を再作成します。

    # Namespace creation
    $ oc new-project ${HC_CLUSTER_NS}
    $ oc new-project ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、HC namespace のシークレットを復元します。

    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-*
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを入力して、HostedCluster コントロールプレーン namespace のオブジェクトを復元します。

    # Secrets
    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-*
    
    # Cluster
    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-*
    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-*
    Copy to Clipboard Toggle word wrap
  5. ノードとノードプールを復元して AWS インスタンスを再利用する場合は、次のコマンドを入力して、HC コントロールプレーン namespace のオブジェクトを復元します。

    # AWS
    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-*
    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-*
    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-*
    
    # Machines
    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-*
    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-*
    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-*
    Copy to Clipboard Toggle word wrap
  6. 次の bash スクリプトを実行して、etcd データとホステッドクラスターを復元します。

    ETCD_PODS="etcd-0"
    if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then
      ETCD_PODS="etcd-0 etcd-1 etcd-2"
    fi
    
    HC_RESTORE_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-restore.yaml
    HC_BACKUP_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
    HC_NEW_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-new.yaml
    cat ${HC_BACKUP_FILE} > ${HC_NEW_FILE}
    cat > ${HC_RESTORE_FILE} <<EOF
        restoreSnapshotURL:
    EOF
    
    for POD in ${ETCD_PODS}; do
      # Create a pre-signed URL for the etcd snapshot
      ETCD_SNAPSHOT="s3://${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db"
      ETCD_SNAPSHOT_URL=$(AWS_DEFAULT_REGION=${MGMT2_REGION} aws s3 presign ${ETCD_SNAPSHOT})
    
      # FIXME no CLI support for restoreSnapshotURL yet
      cat >> ${HC_RESTORE_FILE} <<EOF
        - "${ETCD_SNAPSHOT_URL}"
    EOF
    done
    
    cat ${HC_RESTORE_FILE}
    
    if ! grep ${HC_CLUSTER_NAME}-snapshot.db ${HC_NEW_FILE}; then
      sed -i '' -e "/type: PersistentVolume/r ${HC_RESTORE_FILE}" ${HC_NEW_FILE}
      sed -i '' -e '/pausedUntil:/d' ${HC_NEW_FILE}
    fi
    
    HC=$(oc get hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME} -o name || true)
    if [[ ${HC} == "" ]];then
        echo "Deploying HC Cluster: ${HC_CLUSTER_NAME} in ${HC_CLUSTER_NS} namespace"
        oc apply -f ${HC_NEW_FILE}
    else
        echo "HC Cluster ${HC_CLUSTER_NAME} already exists, avoiding step"
    fi
    Copy to Clipboard Toggle word wrap
  7. ノードとノードプールを復元して AWS インスタンスを再利用する場合は、次のコマンドを入力してノードプールを復元します。

    $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-*
    Copy to Clipboard Toggle word wrap

検証

  • ノードが完全に復元されたことを確認するには、次の関数を使用します。

    timeout=40
    count=0
    NODE_STATUS=$(oc get nodes --kubeconfig=${HC_KUBECONFIG} | grep -v NotReady | grep -c "worker") || NODE_STATUS=0
    
    while [ ${NODE_POOL_REPLICAS} != ${NODE_STATUS} ]
    do
        echo "Waiting for Nodes to be Ready in the destination MGMT Cluster: ${MGMT2_CLUSTER_NAME}"
        echo "Try: (${count}/${timeout})"
        sleep 30
        if [[ $count -eq timeout ]];then
            echo "Timeout waiting for Nodes in the destination MGMT Cluster"
            exit 1
        fi
        count=$((count+1))
        NODE_STATUS=$(oc get nodes --kubeconfig=${HC_KUBECONFIG} | grep -v NotReady | grep -c "worker") || NODE_STATUS=0
    done
    Copy to Clipboard Toggle word wrap

次のステップ

クラスターをシャットダウンして削除します。

9.6.4. ホステッドクラスターのソース管理クラスターからの削除

ホステッドクラスターをバックアップして宛先管理クラスターに復元した後、ソース管理クラスターのホステッドクラスターをシャットダウンして削除します。

前提条件

データをバックアップし、ソース管理クラスターに復元している。

ヒント

宛先管理クラスターの kubeconfig ファイルが、KUBECONFIG 変数に設定されているとおりに、あるいは、スクリプトを使用する場合は MGMT_KUBECONFIG 変数に設定されているとおりに配置されていることを確認します。export KUBECONFIG=<Kubeconfig FilePath> を使用するか、スクリプトを使用する場合は export KUBECONFIG=${MGMT_KUBECONFIG} を使用します。

手順

  1. 以下のコマンドを入力して、deployment および statefulset オブジェクトをスケーリングします。

    重要

    spec.persistentVolumeClaimRetentionPolicy.whenScaled フィールドの値が Delete に設定されている場合は、データの損失につながる可能性があるため、ステートフルセットをスケーリングしないでください。

    回避策として、spec.persistentVolumeClaimRetentionPolicy.whenScaled フィールドの値を Retain に更新します。ステートフルセットをリコンサイルし、値を Delete に戻してしまうようなコントローラーが存在しないことを確認してください。そのようなコントローラーがあると、データの損失が発生する可能性があります。

    # Just in case
    $ export KUBECONFIG=${MGMT_KUBECONFIG}
    
    # Scale down deployments
    $ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all
    $ oc scale statefulset.apps -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all
    $ sleep 15
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、NodePool オブジェクトを削除します。

    NODEPOOLS=$(oc get nodepools -n ${HC_CLUSTER_NS} -o=jsonpath='{.items[?(@.spec.clusterName=="'${HC_CLUSTER_NAME}'")].metadata.name}')
    if [[ ! -z "${NODEPOOLS}" ]];then
        oc patch -n "${HC_CLUSTER_NS}" nodepool ${NODEPOOLS} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
        oc delete np -n ${HC_CLUSTER_NS} ${NODEPOOLS}
    fi
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを入力して、machine および machineset オブジェクトを削除します。

    # Machines
    for m in $(oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
        oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true
        oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true
    done
    
    $ oc delete machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all || true
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを入力して、クラスターオブジェクトを削除します。

    # Cluster
    $ C_NAME=$(oc get cluster -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)
    $ oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${C_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
    $ oc delete cluster.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを入力して、AWS マシン (Kubernetes オブジェクト) を削除します。実際の AWS マシンの削除を心配する必要はありません。クラウドインスタンスへの影響はありません。

    # AWS Machines
    for m in $(oc get awsmachine.infrastructure.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)
    do
        oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true
        oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true
    done
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを入力して、HostedControlPlane および ControlPlane HC namespace オブジェクトを削除します。

    # Delete HCP and ControlPlane HC NS
    $ oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} hostedcontrolplane.hypershift.openshift.io ${HC_CLUSTER_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
    $ oc delete hostedcontrolplane.hypershift.openshift.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all
    $ oc delete ns ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} || true
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを入力して、HostedCluster および HC namespace オブジェクトを削除します。

    # Delete HC and HC Namespace
    $ oc -n ${HC_CLUSTER_NS} patch hostedclusters ${HC_CLUSTER_NAME} -p '{"metadata":{"finalizers":null}}' --type merge || true
    $ oc delete hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME}  || true
    $ oc delete ns ${HC_CLUSTER_NS} || true
    Copy to Clipboard Toggle word wrap

検証

  • すべてが機能することを確認するには、次のコマンドを入力します。

    # Validations
    $ export KUBECONFIG=${MGMT2_KUBECONFIG}
    
    $ oc get hc -n ${HC_CLUSTER_NS}
    $ oc get np -n ${HC_CLUSTER_NS}
    $ oc get pod -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
    $ oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
    
    # Inside the HostedCluster
    $ export KUBECONFIG=${HC_KUBECONFIG}
    $ oc get clusterversion
    $ oc get nodes
    Copy to Clipboard Toggle word wrap

次のステップ

ホステッドクラスター内の OVN Pod を削除して、新しい管理クラスターで実行される新しい OVN コントロールプレーンに接続できるようにします。

  1. ホステッドクラスターの kubeconfig パスを使用して KUBECONFIG 環境変数を読み込みます。
  2. 以下のコマンドを入力します。

    $ oc delete pod -n openshift-ovn-kubernetes --all
    Copy to Clipboard Toggle word wrap

9.7. OADP を使用したホステッドクラスターの障害復旧

OpenShift API for Data Protection (OADP) Operator を使用して、Amazon Web Services (AWS) およびベアメタルで障害復旧を実行できます。

OpenShift API for Data Protection (OADP) を使用した障害復旧プロセスには、次の手順が含まれます。

  1. OADP を使用するために Amazon Web Services やベアメタルなどのプラットフォームを準備
  2. データプレーンのワークロードのバックアップ
  3. コントロールプレーンのワークロードのバックアップ
  4. OADP を使用したホステッドクラスターの復元

9.7.1. 前提条件

管理クラスターで次の前提条件を満たす必要があります。

  • OADP Operator をインストールした
  • ストレージクラスを作成した。
  • cluster-admin 権限でクラスターにアクセスできる。
  • カタログソースを通じて OADP サブスクリプションにアクセスできる。
  • S3、Microsoft Azure、Google Cloud Platform、MinIO など、OADP と互換性のあるクラウドストレージプロバイダーにアクセスできる。
  • 非接続環境の場合は、OADP と互換性のある Red Hat OpenShift Data FoundationMinIO などのセルフホスト型ストレージプロバイダーにアクセスできる。
  • Hosted Control Plane の Pod が稼働している。

9.7.2. OADP を使用するための AWS の準備

ホステッドクラスターの障害復旧を実行するには、Amazon Web Services (AWS) S3 互換ストレージで OpenShift API for Data Protection (OADP) を使用できます。DataProtectionApplication オブジェクトを作成すると、openshift-adp namespace に新しい velero デプロイメントと node-agent Pod が作成されます。

OADP を使用するために AWS を準備するには、「Multicloud Object Gateway を使用した OpenShift API for Data Protection の設定」を参照してください。

次のステップ

  • データプレーンのワークロードのバックアップ
  • コントロールプレーンのワークロードのバックアップ

9.7.3. OADP を使用するためのベアメタルの準備

ホステッドクラスターの障害復旧を実行するには、ベアメタル上で OpenShift API for Data Protection (OADP) を使用できます。DataProtectionApplication オブジェクトを作成すると、openshift-adp namespace に新しい velero デプロイメントと node-agent Pod が作成されます。

OADP を使用するためにベアメタルを準備するには、「AWS S3 互換ストレージを使用した OpenShift API for Data Protection の設定」を参照してください。

次のステップ

  • データプレーンのワークロードのバックアップ
  • コントロールプレーンのワークロードのバックアップ

9.7.4. データプレーンのワークロードのバックアップ

データプレーンのワークロードが重要でない場合は、この手順をスキップできます。OADP Operator を使用してデータプレーンワークロードをバックアップするには、「アプリケーションのバックアップ」を参照してください。

次のステップ

  • OADP を使用したホステッドクラスターの復元

9.7.5. コントロールプレーンのワークロードのバックアップ

Backup カスタムリソース (CR) を作成することで、コントロールプレーンのワークロードをバックアップできます。手順は、プラットフォームが AWS かベアメタルかによって異なります。

9.7.5.1. AWS におけるコントロールプレーンのワークロードのバックアップ

Backup カスタムリソース (CR) を作成することで、コントロールプレーンのワークロードをバックアップできます。

バックアッププロセスを監視および観察するには、「バックアップおよび復元プロセスの観察」を参照してください。

手順

  1. 次のコマンドを実行して、HostedCluster リソースのリコンシリエーションを一時停止します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \
      --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、ホステッドクラスターのインフラストラクチャー ID を取得します。

    $ oc get hostedcluster -n local-cluster <hosted_cluster_name> -o=jsonpath="{.spec.infraID}"
    Copy to Clipboard Toggle word wrap

    次のステップで使用するインフラストラクチャー ID をメモします。

  3. 次のコマンドを実行して、cluster.cluster.x-k8s.io リソースのリコンシリエーションを一時停止します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      patch cluster.cluster.x-k8s.io \
      -n local-cluster-<hosted_cluster_name> <hosted_cluster_infra_id> \
      --type json -p '[{"op": "add", "path": "/spec/paused", "value": true}]'
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、NodePool リソースのリコンシリエーションを一時停止します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \
      --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、AgentCluster リソースのリコンシリエーションを一時停止します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      annotate agentcluster -n <hosted_control_plane_namespace>  \
      cluster.x-k8s.io/paused=true --all'
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、AgentMachine リソースのリコンシリエーションを一時停止します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      annotate agentmachine -n <hosted_control_plane_namespace>  \
      cluster.x-k8s.io/paused=true --all'
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、HostedCluster リソースにアノテーションを付け、Hosted Control Plane namespace が削除されないようにします。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \
      hypershift.openshift.io/skip-delete-hosted-controlplane-namespace=true
    Copy to Clipboard Toggle word wrap
  8. Backup CR を定義する YAML ファイルを作成します。

    例9.1 例: backup-control-plane.yaml ファイル

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup_resource_name> 
    1
    
      namespace: openshift-adp
      labels:
        velero.io/storage-location: default
    spec:
      hooks: {}
      includedNamespaces: 
    2
    
      - <hosted_cluster_namespace> 
    3
    
      - <hosted_control_plane_namespace> 
    4
    
      includedResources:
      - sa
      - role
      - rolebinding
      - pod
      - pvc
      - pv
      - bmh
      - configmap
      - infraenv 
    5
    
      - priorityclasses
      - pdb
      - agents
      - hostedcluster
      - nodepool
      - secrets
      - hostedcontrolplane
      - cluster
      - agentcluster
      - agentmachinetemplate
      - agentmachine
      - machinedeployment
      - machineset
      - machine
      excludedResources: []
      storageLocation: default
      ttl: 2h0m0s
      snapshotMoveData: true 
    6
    
      datamover: "velero" 
    7
    
      defaultVolumesToFsBackup: true 
    8
    Copy to Clipboard Toggle word wrap
    1
    backup_resource_nameBackup リソースの名前に置き換えます。
    2
    特定の namespace を選択して、そこからオブジェクトをバックアップします。ホステッドクラスターの namespace と Hosted Control Plane の namespace を含める必要があります。
    3
    <hosted_cluster_namespace> を、ホステッドクラスター namespace の名前 (例: clusters) に置き換えます。
    4
    <hosted_control_plane_namespace> は、Hosted Control Plane の namespace の名前 (例: clusters-hosted) に置き換えます。
    5
    infraenv リソースを別の namespace に作成する必要があります。バックアッププロセス中に infraenv リソースを削除しないでください。
    6 7
    CSI ボリュームスナップショットを有効にし、コントロールプレーンのワークロードをクラウドストレージに自動的にアップロードします。
    8
    永続ボリューム (PV) の fs-backup バックアップ方法をデフォルトとして設定します。この設定は、Container Storage Interface (CSI) ボリュームスナップショットと fs-backup 方式を組み合わせて使用する場合に便利です。
    注記

    CSI ボリュームスナップショットを使用する場合は、PV に backup.velero.io/backup-volumes-excludes=<pv_name> アノテーションを追加する必要があります。

  9. 次のコマンドを実行して、Backup CR を適用します。

    $ oc apply -f backup-control-plane.yaml
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、status.phase の値が Completed になっているかどうかを確認します。

    $ oc get backups.velero.io <backup_resource_name> -n openshift-adp \
      -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap

次のステップ

  • OADP を使用したホステッドクラスターの復元

Backup カスタムリソース (CR) を作成することで、コントロールプレーンのワークロードをバックアップできます。

バックアッププロセスを監視および観察するには、「バックアップおよび復元プロセスの観察」を参照してください。

手順

  1. 次のコマンドを実行して、HostedCluster リソースのリコンシリエーションを一時停止します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \
      --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、ホステッドクラスターのインフラストラクチャー ID を取得します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      get hostedcluster -n <hosted_cluster_namespace> \
      <hosted_cluster_name> -o=jsonpath="{.spec.infraID}"
    Copy to Clipboard Toggle word wrap
  3. 次のステップで使用するインフラストラクチャー ID をメモします。
  4. 次のコマンドを実行して、cluster.cluster.x-k8s.io リソースのリコンシリエーションを一時停止します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      annotate cluster -n <hosted_control_plane_namespace> \
      <hosted_cluster_infra_id> cluster.x-k8s.io/paused=true
    Copy to Clipboard Toggle word wrap
  5. 次のコマンドを実行して、NodePool リソースのリコンシリエーションを一時停止します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \
      --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、AgentCluster リソースのリコンシリエーションを一時停止します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      annotate agentcluster -n <hosted_control_plane_namespace>  \
      cluster.x-k8s.io/paused=true --all
    Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、AgentMachine リソースのリコンシリエーションを一時停止します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      annotate agentmachine -n <hosted_control_plane_namespace>  \
      cluster.x-k8s.io/paused=true --all
    Copy to Clipboard Toggle word wrap
  8. 同一の管理クラスターに対してバックアップと復元を行う場合、Hosted Control Plane namespace が削除されるのを防ぐため、以下のコマンドを実行して HostedCluster リソースにアノテーションを付けます。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \
      hypershift.openshift.io/skip-delete-hosted-controlplane-namespace=true
    Copy to Clipboard Toggle word wrap
  9. Backup CR を定義する YAML ファイルを作成します。

    例9.2 例: backup-control-plane.yaml ファイル

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup_resource_name> 
    1
    
      namespace: openshift-adp
      labels:
        velero.io/storage-location: default
    spec:
      hooks: {}
      includedNamespaces: 
    2
    
      - <hosted_cluster_namespace> 
    3
    
      - <hosted_control_plane_namespace> 
    4
    
      - <agent_namespace> 
    5
    
      includedResources:
      - sa
      - role
      - rolebinding
      - pod
      - pvc
      - pv
      - bmh
      - configmap
      - infraenv
      - priorityclasses
      - pdb
      - agents
      - hostedcluster
      - nodepool
      - secrets
      - services
      - deployments
      - hostedcontrolplane
      - cluster
      - agentcluster
      - agentmachinetemplate
      - agentmachine
      - machinedeployment
      - machineset
      - machine
      excludedResources: []
      storageLocation: default
      ttl: 2h0m0s
      snapshotMoveData: true 
    6
    
      datamover: "velero" 
    7
    
      defaultVolumesToFsBackup: true 
    8
    Copy to Clipboard Toggle word wrap
    1
    backup_resource_nameBackup リソースの名前に置き換えます。
    2
    特定の namespace を選択して、そこからオブジェクトをバックアップします。ホステッドクラスターの namespace と Hosted Control Plane の namespace を含める必要があります。
    3
    <hosted_cluster_namespace> を、ホステッドクラスター namespace の名前 (例: clusters) に置き換えます。
    4
    <hosted_control_plane_namespace> は、Hosted Control Plane の namespace の名前 (例: clusters-hosted) に置き換えます。
    5
    <agent_namespace> は、AgentBMH、および InfraEnv CR が配置されている namespace (例: agents) に置き換えます。
    6 7
    CSI ボリュームスナップショットを有効にし、コントロールプレーンのワークロードをクラウドストレージに自動的にアップロードします。
    8
    永続ボリューム (PV) の fs-backup バックアップ方法をデフォルトとして設定します。この設定は、Container Storage Interface (CSI) ボリュームスナップショットと fs-backup 方式を組み合わせて使用する場合に便利です。
    注記

    CSI ボリュームスナップショットを使用する場合は、PV に backup.velero.io/backup-volumes-excludes=<pv_name> アノテーションを追加する必要があります。

  10. 次のコマンドを実行して、Backup CR を適用します。

    $ oc apply -f backup-control-plane.yaml
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、status.phase の値が Completed になっているかどうかを確認します。

    $ oc get backups.velero.io <backup_resource_name> -n openshift-adp \
      -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap

次のステップ

  • OADP を使用して、ホステッドクラスターを復元します。

9.7.6. OADP を使用したホステッドクラスターの復元

ホステッドクラスターを同じ管理クラスターに復元することも、新しい管理クラスターに復元することもできます。

9.7.6.1. OADP を使用してホステッドクラスターを同じ管理クラスターに復元する

Restore カスタムリソース (CR) を作成することで、ホステッドクラスターを復元できます。

  • インプレース 更新を使用している場合、InfraEnv にスペアノードは必要ありません。新しい管理クラスターからワーカーノードを再プロビジョニングする必要があります。
  • replace 更新を使用している場合は、ワーカーノードをデプロイするために InfraEnv 用の予備ノードがいくつか必要です。
重要

ホステッドクラスターをバックアップした後、復元プロセスを開始するには、そのクラスターを破棄する必要があります。ノードのプロビジョニングを開始するには、ホステッドクラスターを削除する前に、データプレーン内のワークロードをバックアップする必要があります。

前提条件

バックアッププロセスを監視および観察するには、「バックアップおよび復元プロセスの観察」を参照してください。

手順

  1. 次のコマンドを実行して、Hosted Control Plane namespace に Pod と永続ボリューム要求 (PVC) が存在しないことを確認します。

    $ oc get pod pvc -n <hosted_control_plane_namespace>
    Copy to Clipboard Toggle word wrap

    予想される出力

    No resources found
    Copy to Clipboard Toggle word wrap

  2. Restore CR を定義する YAML ファイルを作成します。

    restore-hosted-cluster.yaml ファイルの例

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: <restore_resource_name> 
    1
    
      namespace: openshift-adp
    spec:
      backupName: <backup_resource_name> 
    2
    
      restorePVs: true 
    3
    
      existingResourcePolicy: update 
    4
    
      excludedResources:
      - nodes
      - events
      - events.events.k8s.io
      - backups.velero.io
      - restores.velero.io
      - resticrepositories.velero.io
    Copy to Clipboard Toggle word wrap

    1
    <restore_resource_name>Restore リソースの名前に置き換えます。
    2
    <backup_resource_name>Backup リソースの名前に置き換えます。
    3
    永続ボリューム (PV) とその Pod のリカバリーを開始します。
    4
    既存のオブジェクトがバックアップされたコンテンツで上書きされるようにします。
    重要

    infraenv リソースを別の namespace に作成する必要があります。復元プロセス中に infraenv リソースを削除しないでください。新しいノードを再プロビジョニングするには、infraenv リソースが必須です。

  3. 次のコマンドを実行して、Restore CR を適用します。

    $ oc apply -f restore-hosted-cluster.yaml
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、status.phase の値が Completed になっているかどうかを確認します。

    $ oc get hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> \
      -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap
  5. 復元プロセスが完了したら、コントロールプレーンワークロードのバックアップ中に一時停止した HostedCluster リソースおよび NodePool リソースのリコンシリエーションを開始します。

    1. 次のコマンドを実行して、HostedCluster リソースのリコンシリエーションを開始します。

      $ oc --kubeconfig <management_cluster_kubeconfig_file> \
        patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \
        --type json \
        -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "false"}]'
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、NodePool リソースのリコンシリエーションを開始します。

      $ oc --kubeconfig <management_cluster_kubeconfig_file> \
        patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \
        --type json \
        -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "false"}]'
      Copy to Clipboard Toggle word wrap
  6. コントロールプレーンワークロードのバックアップ中に一時停止したエージェントプロバイダーリソースのリコンシリエーションを開始します。

    1. 次のコマンドを実行して、AgentCluster リソースのリコンシリエーションを開始します。

      $ oc --kubeconfig <management_cluster_kubeconfig_file> \
        annotate agentcluster -n <hosted_control_plane_namespace>  \
        cluster.x-k8s.io/paused- --overwrite=true --all
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、AgentMachine リソースのリコンシリエーションを開始します。

      $ oc --kubeconfig <management_cluster_kubeconfig_file> \
        annotate agentmachine -n <hosted_control_plane_namespace>  \
        cluster.x-k8s.io/paused- --overwrite=true --all
      Copy to Clipboard Toggle word wrap
  7. 次のコマンドを実行して、HostedCluster リソースの hypershift.openshift.io/skip-delete-hosted-controlplane-namespace- アノテーションを削除し、Hosted Control Plane namespace の手動削除を回避します。

    $ oc --kubeconfig <management_cluster_kubeconfig_file> \
      annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \
      hypershift.openshift.io/skip-delete-hosted-controlplane-namespace- \
      --overwrite=true --all
    Copy to Clipboard Toggle word wrap
9.7.6.2. OADP を使用したホステッドクラスターの新しい管理クラスターへの復元

Restore カスタムリソース (CR) を作成することにより、ホステッドクラスターを新しい管理クラスターに復元できます。

  • インプレース更新を使用している場合、InfraEnv リソースには予備のノードは必要ありません。代わりに、新しい管理クラスターからワーカーノードを再プロビジョニングする必要があります。
  • replace 更新を使用している場合は、ワーカーノードをデプロイするために InfraEnv リソース用の予備ノードがいくつか必要です。

前提条件

  • OpenShift API for Data Protection (OADP) を使用するように新しい管理クラスターを設定している。Restore CR がバックアップストレージにアクセスできるように、新しい管理クラスターには、バックアップ元の管理クラスターと同じ Data Protection Application (DPA) が必要です。
  • ホステッドクラスターの DNS を解決するために、新しい管理クラスターのネットワーク設定を設定している。

    • ホストの DNS は、新しい管理クラスターとホステッドクラスターの両方の IP に解決される必要があります。
    • ホステッドクラスターは、新しい管理クラスターの IP に解決する必要があります。

バックアッププロセスを監視および観察するには、「バックアップおよび復元プロセスの観察」を参照してください。

重要

バックアップを作成した管理クラスターではなく、ホステッドクラスターを復元する新しい管理クラスターで次の手順を実行します。

手順

  1. Restore CR を定義する YAML ファイルを作成します。

    restore-hosted-cluster.yaml ファイルの例

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: <restore_resource_name> 
    1
    
      namespace: openshift-adp
    spec:
      includedNamespaces: 
    2
    
      - <hosted_cluster_namespace> 
    3
    
      - <hosted_control_plane_namespace> 
    4
    
      - <agent_namespace> 
    5
    
      backupName: <backup_resource_name> 
    6
    
      cleanupBeforeRestore: CleanupRestored
      veleroManagedClustersBackupName: <managed_cluster_name> 
    7
    
      veleroCredentialsBackupName: <credentials_backup_name>
      veleroResourcesBackupName: <resources_backup_name>
      restorePVs: true 
    8
    
      preserveNodePorts: true
      existingResourcePolicy: update 
    9
    
      excludedResources:
      - pod
      - nodes
      - events
      - events.events.k8s.io
      - backups.velero.io
      - restores.velero.io
      - resticrepositories.velero.io
      - pv
      - pvc
    Copy to Clipboard Toggle word wrap

    1
    <restore_resource_name>Restore リソースの名前に置き換えます。
    2
    特定の namespace を選択して、そこからオブジェクトをバックアップします。ホステッドクラスターの namespace と Hosted Control Plane の namespace を含める必要があります。
    3
    <hosted_cluster_namespace> を、ホステッドクラスター namespace の名前 (例: clusters) に置き換えます。
    4
    <hosted_control_plane_namespace> は、Hosted Control Plane の namespace の名前 (例: clusters-hosted) に置き換えます。
    5
    <agent_namespace> は、AgentBMH、および InfraEnv CR が配置されている namespace (例: agents) に置き換えます。
    6
    <backup_resource_name>Backup リソースの名前に置き換えます。
    7
    Red Hat Advanced Cluster Management を使用していない場合は、このフィールドを省略できます。
    8
    永続ボリューム (PV) とその Pod のリカバリーを開始します。
    9
    既存のオブジェクトがバックアップされたコンテンツで上書きされるようにします。
  2. 次のコマンドを実行して、Restore CR を適用します。

    $ oc --kubeconfig <restore_management_kubeconfig> apply -f restore-hosted-cluster.yaml
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、status.phase の値が Completed であることを確認します。

    $ oc --kubeconfig <restore_management_kubeconfig> \
      get restore.velero.io <restore_resource_name> \
      -n openshift-adp -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、すべての CR が復元されていることを確認します。

    $ oc --kubeconfig <restore_management_kubeconfig> get infraenv -n <agent_namespace>
    Copy to Clipboard Toggle word wrap
    $ oc --kubeconfig <restore_management_kubeconfig> get agent -n <agent_namespace>
    Copy to Clipboard Toggle word wrap
    $  oc --kubeconfig <restore_management_kubeconfig> get bmh -n <agent_namespace>
    Copy to Clipboard Toggle word wrap
    $ oc --kubeconfig <restore_management_kubeconfig> get hostedcluster -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
    $ oc --kubeconfig <restore_management_kubeconfig> get nodepool -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
    $ oc --kubeconfig <restore_management_kubeconfig> get agentmachine -n <hosted_controlplane_namespace>
    Copy to Clipboard Toggle word wrap
    $ oc --kubeconfig <restore_management_kubeconfig> get agentcluster -n <hosted_controlplane_namespace>
    Copy to Clipboard Toggle word wrap
  5. 今後、新しい管理クラスターをメインの管理クラスターとして使用する予定の場合は、以下の手順を実行します。バックアップ元の管理クラスターをメインの管理クラスターとして使用する予定の場合は、「OADP を使用してホステッドクラスターを同じ管理クラスターに復元する」の手順 5 - 8 を完了します。

    1. 次のコマンドを実行して、バックアップした管理クラスターから Cluster API デプロイメントを削除します。

      $ oc --kubeconfig <backup_management_kubeconfig> delete deploy cluster-api \
        -n <hosted_control_plane_namespace>
      Copy to Clipboard Toggle word wrap

      一度に 1 つの Cluster API のみがクラスターにアクセスできるため、この手順により、新しい管理クラスターの Cluster API が正常に機能します。

    2. 復元プロセスが完了したら、コントロールプレーンワークロードのバックアップ中に一時停止した HostedCluster リソースおよび NodePool リソースのリコンシリエーションを開始します。

      1. 次のコマンドを実行して、HostedCluster リソースのリコンシリエーションを開始します。

        $ oc --kubeconfig <restore_management_kubeconfig> \
          patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \
          --type json \
          -p '[{"op": "replace", "path": "/spec/pausedUntil", "value": "false"}]'
        Copy to Clipboard Toggle word wrap
      2. 次のコマンドを実行して、NodePool リソースのリコンシリエーションを開始します。

        $ oc --kubeconfig <restore_management_kubeconfig> \
          patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \
          --type json \
          -p '[{"op": "replace", "path": "/spec/pausedUntil", "value": "false"}]'
        Copy to Clipboard Toggle word wrap
      3. 次のコマンドを実行して、Hosted Control Plane が使用可能であるとホステッドクラスターが報告していることを確認します。

        $ oc --kubeconfig <restore_management_kubeconfig> get hostedcluster
        Copy to Clipboard Toggle word wrap
      4. 次のコマンドを実行して、クラスター Operator が利用可能であるとホステッドクラスターが報告していることを確認します。

        $ oc get co --kubeconfig <hosted_cluster_kubeconfig>
        Copy to Clipboard Toggle word wrap
    3. コントロールプレーンワークロードのバックアップ中に一時停止したエージェントプロバイダーリソースのリコンシリエーションを開始します。

      1. 次のコマンドを実行して、AgentCluster リソースのリコンシリエーションを開始します。

        $ oc --kubeconfig <restore_management_kubeconfig> \
          annotate agentcluster -n <hosted_control_plane_namespace>  \
          cluster.x-k8s.io/paused- --overwrite=true --all
        Copy to Clipboard Toggle word wrap
      2. 次のコマンドを実行して、AgentMachine リソースのリコンシリエーションを開始します。

        $ oc --kubeconfig <restore_management_kubeconfig> \
          annotate agentmachine -n <hosted_control_plane_namespace>  \
          cluster.x-k8s.io/paused- --overwrite=true --all
        Copy to Clipboard Toggle word wrap
      3. 次のコマンドを実行して、Cluster リソースのリコンシリエーションを開始します。

        $ oc --kubeconfig <restore_management_kubeconfig> \
          annotate cluster -n <hosted_control_plane_namespace> \
          cluster.x-k8s.io/paused- --overwrite=true --all
        Copy to Clipboard Toggle word wrap
    4. 次のコマンドを実行して、ノードプールが予想通りに機能していることを確認します。

      $ oc --kubeconfig <restore_management_kubeconfig> \
        get nodepool -n <hosted_cluster_namespace>
      Copy to Clipboard Toggle word wrap

      出力例

      NAME       CLUSTER    DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
      hosted-0   hosted-0   3               3               False         False        4.17.11   False             False
      Copy to Clipboard Toggle word wrap

    5. オプション: 競合が存在せず、新しい管理クラスターが引き続き機能していることを確認するには、次の手順を実行して、バックアップ管理クラスターから HostedCluster リソースを削除します。

      1. バックアップ元の管理クラスターの ClusterDeployment リソースで、次のコマンドを実行して spec.preserveOnDelete パラメーターを true に設定します。

        $ oc --kubeconfig <backup_management_kubeconfig> patch \
          -n <hosted_control_plane_namespace> \
          ClusterDeployment/<hosted_cluster_name> -p \
          '{"spec":{"preserveOnDelete":'true'}}' \
          --type=merge
        Copy to Clipboard Toggle word wrap

        この手順は、ホストのプロビジョニングが解除されないようにします。

      2. 以下のコマンドを実行してマシンを削除します。

        $ oc --kubeconfig <backup_management_kubeconfig> patch \
          <machine_name> -n <hosted_control_plane_namespace> -p \
          '[{"op":"remove","path":"/metadata/finalizers"}]' \
          --type=merge
        Copy to Clipboard Toggle word wrap
        $ oc --kubeconfig <backup_management_kubeconfig> \
          delete machine <machine_name> \
          -n <hosted_control_plane_namespace>
        Copy to Clipboard Toggle word wrap
      3. 次のコマンドを実行して、AgentCluster および Cluster リソースを削除します。

        $ oc --kubeconfig <backup_management_kubeconfig> \
          delete agentcluster <hosted_cluster_name> \
          -n <hosted_control_plane_namespace>
        Copy to Clipboard Toggle word wrap
        $ oc --kubeconfig <backup_management_kubeconfig> \
          patch cluster <cluster_name> \
          -n <hosted_control_plane_namespace> \
          -p '[{"op":"remove","path":"/metadata/finalizers"}]' \
          --type=json
        Copy to Clipboard Toggle word wrap
        $ oc --kubeconfig <backup_management_kubeconfig> \
          delete cluster <cluster_name> \
          -n <hosted_control_plane_namespace>
        Copy to Clipboard Toggle word wrap
      4. Red Hat Advanced Cluster Management を使用する場合は、次のコマンドを実行してマネージドクラスターを削除します。

        $ oc --kubeconfig <backup_management_kubeconfig> \
          patch managedcluster <hosted_cluster_name> \
          -n <hosted_cluster_namespace> \
          -p '[{"op":"remove","path":"/metadata/finalizers"}]' \
          --type=json
        Copy to Clipboard Toggle word wrap
        $ oc --kubeconfig <backup_management_kubeconfig> \
          delete managedcluster <hosted_cluster_name> \
          -n <hosted_cluster_namespace>
        Copy to Clipboard Toggle word wrap
      5. 次のコマンドを実行して、HostedCluster リソースを削除します。

        $ oc --kubeconfig <backup_management_kubeconfig> \
          delete hostedcluster \
          -n <hosted_cluster_namespace> <hosted_cluster_name>
        Copy to Clipboard Toggle word wrap

9.7.7. バックアップと復元のプロセスの観察

OpenShift API for Data Protection (OADP) を使用してホステッドクラスターをバックアップおよび復元する場合は、プロセスを監視および観察できます。

手順

  1. 次のコマンドを実行して、バックアッププロセスを確認します。

    $ watch "oc get backups.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、復元プロセスを確認します。

    $ watch "oc get restores.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、Velero ログを確認します。

    $ oc logs -n openshift-adp -ldeploy=velero -f
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、すべての OADP オブジェクトの進行状況を確認します。

    $ watch "echo BackupRepositories:;echo;oc get backuprepositories.velero.io -A;echo; echo BackupStorageLocations: ;echo; oc get backupstoragelocations.velero.io -A;echo;echo DataUploads: ;echo;oc get datauploads.velero.io -A;echo;echo DataDownloads: ;echo;oc get datadownloads.velero.io -n openshift-adp; echo;echo VolumeSnapshotLocations: ;echo;oc get volumesnapshotlocations.velero.io -A;echo;echo Backups:;echo;oc get backup -A; echo;echo Restores:;echo;oc get restore -A"
    Copy to Clipboard Toggle word wrap

9.7.8. velero CLI を使用してバックアップおよび復元リソースを記述する

OpenShift API for Data Protection を使用する場合は、velero コマンドラインインターフェイス (CLI) を使用して、Backup および Restore リソースの詳細を取得できます。

手順

  1. 次のコマンドを実行して、コンテナーから velero CLI を使用するためのエイリアスを作成します。

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、Restore カスタムリソース (CR) の詳細を取得します。

    $ velero restore describe <restore_resource_name> --details 
    1
    Copy to Clipboard Toggle word wrap
    1
    <restore_resource_name>Restore リソースの名前に置き換えます。
  3. 次のコマンドを実行して、Backup CR の詳細を取得します。

    $ velero restore describe <backup_resource_name> --details 
    1
    Copy to Clipboard Toggle word wrap
    1
    <backup_resource_name>Backup リソースの名前に置き換えます。

9.8. OADP を使用したホステッドクラスターの自動障害復旧

ベアメタルまたは Amazon Web Services (AWS) プラットフォーム上のホステッドクラスターでは、OpenShift API for Data Protection (OADP) Operator を使用して、一部のバックアップおよび復元手順を自動化できます。

このプロセスには、以下のステップが必要です。

  1. OADP の設定
  2. Data Protection Application (DPA) の定義
  3. データプレーンのワークロードのバックアップ
  4. コントロールプレーンのワークロードのバックアップ
  5. OADP を使用したホステッドクラスターの復元

9.8.1. 前提条件

管理クラスターで次の前提条件を満たす必要があります。

  • OADP Operator をインストールした
  • ストレージクラスを作成した。
  • cluster-admin 権限でクラスターにアクセスできる。
  • カタログソースを通じて OADP サブスクリプションにアクセスできる。
  • S3、Microsoft Azure、Google Cloud Platform、MinIO など、OADP と互換性のあるクラウドストレージプロバイダーにアクセスできる。
  • 非接続環境の場合は、OADP と互換性のある Red Hat OpenShift Data FoundationMinIO などのセルフホスト型ストレージプロバイダーにアクセスできる。
  • Hosted Control Plane の Pod が稼働している。

9.8.2. OADP の設定

ホステッドクラスターが AWS 上にある場合は、「Multicloud Object Gateway を使用した OpenShift API for Data Protection の設定」の手順に従って OADP を設定します。

ホステッドクラスターがベアメタルプラットフォーム上にある場合は、「AWS S3 互換ストレージを使用した OpenShift API for Data Protection の設定」の手順に従って OADP を設定します。

9.8.3. DPA を使用したバックアップおよび復元プロセスの自動化

Data Protection Application (DPA) を使用すると、バックアップおよび復元プロセスの一部を自動化できます。DPA を使用すると、リソースのリコンシリエーションを一時停止して再起動する手順が自動化されます。DPA は、バックアップの場所や Velero Pod の設定などの情報を定義します。

DataProtectionApplication オブジェクトを定義することで DPA を作成できます。

手順

  • ベアメタルプラットフォームを使用する場合は、次の手順を実行して DPA を作成できます。

    1. 次の例のようなマニフェストファイルを作成します。

      例9.3 dpa.yaml ファイルの例

      apiVersion: oadp.openshift.io/v1alpha1
      kind: DataProtectionApplication
      metadata:
        name: dpa-sample
        namespace: openshift-adp
      spec:
        backupLocations:
          - name: default
            velero:
              provider: aws 
      1
      
              default: true
              objectStorage:
                bucket: <bucket_name> 
      2
      
                prefix: <bucket_prefix> 
      3
      
              config:
                region: minio 
      4
      
                profile: "default"
                s3ForcePathStyle: "true"
                s3Url: "<bucket_url>" 
      5
      
                insecureSkipTLSVerify: "true"
              credential:
                key: cloud
                name: cloud-credentials
                default: true
        snapshotLocations:
          - velero:
              provider: aws 
      6
      
              config:
                region: minio 
      7
      
                profile: "default"
              credential:
                key: cloud
                name: cloud-credentials
        configuration:
          nodeAgent:
            enable: true
            uploaderType: kopia
          velero:
            defaultPlugins:
              - openshift
              - aws
              - csi
              - hypershift
            resourceTimeout: 2h
      Copy to Clipboard Toggle word wrap
      1 6
      Velero のプロバイダーを指定します。ベアメタルと MinIO を使用している場合は、プロバイダーとして aws を使用できます。
      2
      バケット名を指定します (例: oadp-backup)。
      3
      バケットの接頭辞を指定します (例: hcp)。
      4 7
      この例のバケットリージョンは minio で、S3 API との互換性があるストレージプロバイダーです。
      5
      S3 エンドポイントの URL を指定します。
    2. 次のコマンドを実行して DPA オブジェクトを作成します。

      $ oc create -f dpa.yaml
      Copy to Clipboard Toggle word wrap

      DataProtectionApplication オブジェクトを作成すると、openshift-adp namespace に新しい velero デプロイメントと node-agent Pod が作成されます。

  • Amazon Web Services (AWS) を使用する場合は、次の手順を実行して DPA を作成できます。

    1. 次の例のようなマニフェストファイルを作成します。

      例9.4 dpa.yaml ファイルの例

      apiVersion: oadp.openshift.io/v1alpha1
      kind: DataProtectionApplication
      metadata:
        name: dpa-sample
        namespace: openshift-adp
      spec:
        backupLocations:
          - name: default
            velero:
              provider: aws
              default: true
              objectStorage:
                bucket: <bucket_name> 
      1
      
                prefix: <bucket_prefix> 
      2
      
              config:
                region: minio 
      3
      
                profile: "backupStorage"
              credential:
                key: cloud
                name: cloud-credentials
        snapshotLocations:
          - velero:
              provider: aws
              config:
                region: minio 
      4
      
                profile: "volumeSnapshot"
              credential:
                key: cloud
                name: cloud-credentials
        configuration:
          nodeAgent:
            enable: true
            uploaderType: kopia
          velero:
            defaultPlugins:
              - openshift
              - aws
              - csi
              - hypershift
            resourceTimeout: 2h
      Copy to Clipboard Toggle word wrap
      1
      バケット名を指定します (例: oadp-backup)。
      2
      バケットの接頭辞を指定します (例: hcp)。
      3 4
      この例のバケットリージョンは minio で、S3 API との互換性があるストレージプロバイダーです。
    2. 次のコマンドを実行して DPA リソースを作成します。

      $ oc create -f dpa.yaml
      Copy to Clipboard Toggle word wrap

      DataProtectionApplication オブジェクトを作成すると、openshift-adp namespace に新しい velero デプロイメントと node-agent Pod が作成されます。

次のステップ

  • データプレーンのワークロードをバックアップします。

9.8.4. データプレーンのワークロードのバックアップ

OADP Operator を使用してデータプレーンワークロードをバックアップするには、「アプリケーションのバックアップ」を参照してください。データプレーンのワークロードが重要でない場合は、この手順をスキップできます。

9.8.5. コントロールプレーンのワークロードのバックアップ

Backup カスタムリソース (CR) を作成することで、コントロールプレーンのワークロードをバックアップできます。

バックアッププロセスを監視および観察するには、「バックアップおよび復元プロセスの観察」を参照してください。

手順

  1. Backup CR を定義する YAML ファイルを作成します。

    例9.5 例: backup-control-plane.yaml ファイル

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup_resource_name> 
    1
    
      namespace: openshift-adp
      labels:
        velero.io/storage-location: default
    spec:
      hooks: {}
      includedNamespaces: 
    2
    
      - <hosted_cluster_namespace> 
    3
    
      - <hosted_control_plane_namespace> 
    4
    
      includedResources:
      - sa
      - role
      - rolebinding
      - pod
      - pvc
      - pv
      - bmh
      - configmap
      - infraenv 
    5
    
      - priorityclasses
      - pdb
      - agents
      - hostedcluster
      - nodepool
      - secrets
      - services
      - deployments
      - hostedcontrolplane
      - cluster
      - agentcluster
      - agentmachinetemplate
      - agentmachine
      - machinedeployment
      - machineset
      - machine
      - route
      - clusterdeployment
      excludedResources: []
      storageLocation: default
      ttl: 2h0m0s
      snapshotMoveData: true 
    6
    
      datamover: "velero" 
    7
    
      defaultVolumesToFsBackup: true 
    8
    Copy to Clipboard Toggle word wrap
    1
    backup_resource_name は、Backup リソースの名前に置き換えます。
    2
    特定の namespace を選択して、そこからオブジェクトをバックアップします。ホステッドクラスターの namespace と Hosted Control Plane の namespace を含める必要があります。
    3
    <hosted_cluster_namespace> を、ホステッドクラスター namespace の名前 (例: clusters) に置き換えます。
    4
    <hosted_control_plane_namespace> は、Hosted Control Plane の namespace の名前 (例: clusters-hosted) に置き換えます。
    5
    infraenv リソースを別の namespace に作成する必要があります。バックアッププロセス中に infraenv リソースを削除しないでください。
    6 7
    CSI ボリュームスナップショットを有効にし、コントロールプレーンのワークロードをクラウドストレージに自動的にアップロードします。
    8
    永続ボリューム (PV) の fs-backup バックアップ方法をデフォルトとして設定します。この設定は、Container Storage Interface (CSI) ボリュームスナップショットと fs-backup 方式を組み合わせて使用する場合に便利です。
    注記

    CSI ボリュームスナップショットを使用する場合は、PV に backup.velero.io/backup-volumes-excludes=<pv_name> アノテーションを追加する必要があります。

  2. 次のコマンドを実行して、Backup CR を適用します。

    $ oc apply -f backup-control-plane.yaml
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、status.phase の値が Completed であることを確認します。

    $ oc get backups.velero.io <backup_resource_name> -n openshift-adp \
      -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap

次のステップ

  • OADP を使用してホステッドクラスターを復元します。

9.8.6. OADP を使用したホステッドクラスターの復元

Restore カスタムリソース (CR) を作成することで、ホステッドクラスターを復元できます。

  • インプレース更新を使用している場合、InfraEnv リソースには予備のノードは必要ありません。新しい管理クラスターからワーカーノードを再プロビジョニングする必要があります。
  • replace 更新を使用している場合は、ワーカーノードをデプロイするために InfraEnv リソース用の予備ノードがいくつか必要です。
重要

ホステッドクラスターをバックアップした後、復元プロセスを開始するには、そのクラスターを破棄する必要があります。ノードのプロビジョニングを開始するには、ホステッドクラスターを削除する前に、データプレーン内のワークロードをバックアップする必要があります。

前提条件

バックアッププロセスを監視および観察するには、「バックアップおよび復元プロセスの観察」を参照してください。

手順

  1. 次のコマンドを実行して、Hosted Control Plane namespace に Pod と永続ボリューム要求 (PVC) が存在しないことを確認します。

    $ oc get pod pvc -n <hosted_control_plane_namespace>
    Copy to Clipboard Toggle word wrap

    予想される出力

    No resources found
    Copy to Clipboard Toggle word wrap

  2. Restore CR を定義する YAML ファイルを作成します。

    restore-hosted-cluster.yaml ファイルの例

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: <restore_resource_name> 
    1
    
      namespace: openshift-adp
    spec:
      backupName: <backup_resource_name> 
    2
    
      restorePVs: true 
    3
    
      existingResourcePolicy: update 
    4
    
      excludedResources:
      - nodes
      - events
      - events.events.k8s.io
      - backups.velero.io
      - restores.velero.io
      - resticrepositories.velero.io
    Copy to Clipboard Toggle word wrap

    1
    <restore_resource_name> は、Restore リソースの名前に置き換えます。
    2
    <backup_resource_name> は、Backup リソースの名前に置き換えます。
    3
    永続ボリューム (PV) とその Pod のリカバリーを開始します。
    4
    既存のオブジェクトがバックアップされたコンテンツで上書きされるようにします。
    重要

    InfraEnv リソースを別の namespace に作成する必要があります。復元プロセス中に InfraEnv リソースを削除しないでください。新しいノードを再プロビジョニングするには、InfraEnv リソースが必須です。

  3. 次のコマンドを実行して、Restore CR を適用します。

    $ oc apply -f restore-hosted-cluster.yaml
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、status.phase の値が Completed になっているかどうかを確認します。

    $ oc get hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> \
      -o jsonpath='{.status.phase}'
    Copy to Clipboard Toggle word wrap

9.8.7. バックアップと復元のプロセスの観察

OpenShift API for Data Protection (OADP) を使用してホステッドクラスターをバックアップおよび復元する場合は、プロセスを監視および観察できます。

手順

  1. 次のコマンドを実行して、バックアッププロセスを確認します。

    $ watch "oc get backups.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、復元プロセスを確認します。

    $ watch "oc get restores.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、Velero ログを確認します。

    $ oc logs -n openshift-adp -ldeploy=velero -f
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、すべての OADP オブジェクトの進行状況を確認します。

    $ watch "echo BackupRepositories:;echo;oc get backuprepositories.velero.io -A;echo; echo BackupStorageLocations: ;echo; oc get backupstoragelocations.velero.io -A;echo;echo DataUploads: ;echo;oc get datauploads.velero.io -A;echo;echo DataDownloads: ;echo;oc get datadownloads.velero.io -n openshift-adp; echo;echo VolumeSnapshotLocations: ;echo;oc get volumesnapshotlocations.velero.io -A;echo;echo Backups:;echo;oc get backup -A; echo;echo Restores:;echo;oc get restore -A"
    Copy to Clipboard Toggle word wrap

9.8.8. velero CLI を使用してバックアップおよび復元リソースを記述する

OpenShift API for Data Protection を使用する場合は、velero コマンドラインインターフェイス (CLI) を使用して、Backup および Restore リソースの詳細を取得できます。

手順

  1. 次のコマンドを実行して、コンテナーから velero CLI を使用するためのエイリアスを作成します。

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、Restore カスタムリソース (CR) の詳細を取得します。

    $ velero restore describe <restore_resource_name> --details 
    1
    Copy to Clipboard Toggle word wrap
    1
    <restore_resource_name>Restore リソースの名前に置き換えます。
  3. 次のコマンドを実行して、Backup CR の詳細を取得します。

    $ velero restore describe <backup_resource_name> --details 
    1
    Copy to Clipboard Toggle word wrap
    1
    <backup_resource_name>Backup リソースの名前に置き換えます。

第10章 Hosted Control Plane の認証と認可

OpenShift Container Platform のコントロールプレーンには、組み込みの OAuth サーバーが含まれています。OAuth アクセストークンを取得することで、OpenShift Container Platform API に対して認証できます。ホステッドクラスターを作成した後に、アイデンティティープロバイダーを指定して OAuth を設定できます。

10.1. CLI を使用してホステッドクラスターの OAuth サーバーを設定する

CLI を使用して、ホステッドクラスターの内部 OAuth サーバーを設定できます。

サポートされている次のアイデンティティープロバイダーに対して OAuth を設定できます。

  • oidc
  • htpasswd
  • keystone
  • ldap
  • basic-authentication
  • request-header
  • github
  • gitlab
  • google

OAuth 設定にアイデンティティープロバイダーを追加すると、デフォルトの kubeadmin ユーザープロバイダーが削除されます。

注記

アイデンティティープロバイダーを設定するときは、ホステッドクラスターに少なくとも 1 つの NodePool レプリカを事前に設定する必要があります。DNS 解決のトラフィックはワーカーノードを介して送信されます。htpasswd および request-header アイデンティティープロバイダー用に、NodePool レプリカを事前に設定する必要はありません。

前提条件

  • ホステッドクラスターを作成した。

手順

  1. 次のコマンドを実行して、ホスティングクラスターで HostedCluster カスタムリソース (CR) を編集します。

    $ oc edit hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  2. 次の例を使用して、HostedCluster CR に OAuth 設定を追加します。

    apiVersion: hypershift.openshift.io/v1alpha1
    kind: HostedCluster
    metadata:
      name: <hosted_cluster_name> 
    1
    
      namespace: <hosted_cluster_namespace> 
    2
    
    spec:
      configuration:
        oauth:
          identityProviders:
          - openID: 
    3
    
              claims:
                email: 
    4
    
                  - <email_address>
                name: 
    5
    
                  - <display_name>
                preferredUsername: 
    6
    
                  - <preferred_username>
              clientID: <client_id> 
    7
    
              clientSecret:
                name: <client_id_secret_name> 
    8
    
              issuer: https://example.com/identity 
    9
    
            mappingMethod: lookup 
    10
    
            name: IAM
            type: OpenID
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します。
    2
    ホステッドクラスターの namespace を指定します。
    3
    このプロバイダー名はアイデンティティー要求の値に接頭辞として付加され、アイデンティティー名が作成されます。プロバイダー名はリダイレクト URL の構築にも使用されます。
    4
    メールアドレスとして使用する属性のリストを定義します。
    5
    表示名として使用する属性のリストを定義します。
    6
    優先ユーザー名として使用する属性のリストを定義します。
    7
    OpenID プロバイダーに登録されたクライアントの ID を定義します。このクライアントを URL https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name> にリダイレクトできるようにする必要があります。
    8
    OpenID プロバイダーに登録されたクライアントのシークレットを定義します。
    9
    OpenID の仕様で説明されている Issuer Identifier。クエリーまたはフラグメントコンポーネントのない https を使用する必要があります。
    10
    このプロバイダーのアイデンティティーと User オブジェクトの間でマッピングを確立する方法を制御するマッピング方法を定義します。
  3. 変更を適用するためにファイルを保存します。

10.2. Web コンソールを使用してホステッドクラスターの OAuth サーバーを設定する

OpenShift Container Platform Web コンソールを使用して、ホステッドクラスターの内部 OAuth サーバーを設定できます。

サポートされている次のアイデンティティープロバイダーに対して OAuth を設定できます。

  • oidc
  • htpasswd
  • keystone
  • ldap
  • basic-authentication
  • request-header
  • github
  • gitlab
  • google

OAuth 設定にアイデンティティープロバイダーを追加すると、デフォルトの kubeadmin ユーザープロバイダーが削除されます。

注記

アイデンティティープロバイダーを設定するときは、ホステッドクラスターに少なくとも 1 つの NodePool レプリカを事前に設定する必要があります。DNS 解決のトラフィックはワーカーノードを介して送信されます。htpasswd および request-header アイデンティティープロバイダー用に、NodePool レプリカを事前に設定する必要はありません。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • ホステッドクラスターを作成した。

手順

  1. HomeAPI Explorer に移動します。
  2. Filter by kind ボックスを使用して、HostedCluster リソースを検索します。
  3. 編集する HostedCluster リソースをクリックします。
  4. Instances タブをクリックします。
  5. ホステッドクラスター名エントリーの横にあるオプションメニュー kebab をクリックし、Edit HostedCluster をクリックします。
  6. YAML ファイルに OAuth 設定を追加します。

    spec:
      configuration:
        oauth:
          identityProviders:
          - openID: 
    1
    
              claims:
                email: 
    2
    
                  - <email_address>
                name: 
    3
    
                  - <display_name>
                preferredUsername: 
    4
    
                  - <preferred_username>
              clientID: <client_id> 
    5
    
              clientSecret:
                name: <client_id_secret_name> 
    6
    
              issuer: https://example.com/identity 
    7
    
            mappingMethod: lookup 
    8
    
            name: IAM
            type: OpenID
    Copy to Clipboard Toggle word wrap
    1
    このプロバイダー名はアイデンティティー要求の値に接頭辞として付加され、アイデンティティー名が作成されます。プロバイダー名はリダイレクト URL の構築にも使用されます。
    2
    メールアドレスとして使用する属性のリストを定義します。
    3
    表示名として使用する属性のリストを定義します。
    4
    優先ユーザー名として使用する属性のリストを定義します。
    5
    OpenID プロバイダーに登録されたクライアントの ID を定義します。このクライアントを URL https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name> にリダイレクトできるようにする必要があります。
    6
    OpenID プロバイダーに登録されたクライアントのシークレットを定義します。
    7
    OpenID の仕様で説明されている Issuer Identifier。クエリーまたはフラグメントコンポーネントのない https を使用する必要があります。
    8
    このプロバイダーのアイデンティティーと User オブジェクトの間でマッピングを確立する方法を制御するマッピング方法を定義します。
  7. Save をクリックします。

Amazon Web Services (AWS) 上のホステッドクラスターで Cloud Credential Operator (CCO) を使用して、権限が限られた短期間のセキュリティー認証情報を提供する IAM ロールをコンポーネントに割り当てることができます。デフォルトでは、CCO は Hosted Control Plane で実行されます。

注記

CCO は、AWS 上のホステッドクラスターでのみ手動モードをサポートします。デフォルトでは、ホステッドクラスターは手動モードに設定されます。管理クラスターでは、手動以外のモードを使用する場合があります。

10.4. AWS 上のホステッドクラスターで CCO のインストールを検証する

Hosted Control Plane で Cloud Credential Operator (CCO) が正しく実行されていることを確認できます。

前提条件

  • Amazon Web Services (AWS) でホステッドクラスターを設定した。

手順

  1. 次のコマンドを実行して、ホステッドクラスターで CCO が手動モードで設定されていることを確認します。

    $ oc get cloudcredentials <hosted_cluster_name> \
      -n <hosted_cluster_namespace> \
      -o=jsonpath={.spec.credentialsMode}
    Copy to Clipboard Toggle word wrap

    予想される出力

    Manual
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、serviceAccountIssuer リソースの値が空でないことを確認します。

    $ oc get authentication cluster --kubeconfig <hosted_cluster_name>.kubeconfig \
      -o jsonpath --template '{.spec.serviceAccountIssuer }'
    Copy to Clipboard Toggle word wrap

    出力例

    https://aos-hypershift-ci-oidc-29999.s3.us-east-2.amazonaws.com/hypershift-ci-29999
    Copy to Clipboard Toggle word wrap

10.5. Operator が AWS STS を使用した CCO ベースのワークフローをサポートできるようにする

Operator Lifecycle Manager (OLM) で実行するプロジェクトを設計する Operator 作成者は、Cloud Credential Operator (CCO) をサポートするようにプロジェクトをカスタマイズすることで、STS 対応の OpenShift Container Platform クラスター上で Operator が AWS に対して認証できるようにすることができます。

この方法では、Operator が CredentialsRequest オブジェクトを作成します。Operator には、オブジェクトを作成するための RBAC 権限と、生成される Secret オブジェクトを読み取るための RBAC 権限が必要です。

注記

デフォルトでは、Operator デプロイメントに関連する Pod は、生成される Secret オブジェクトでサービスアカウントトークンを参照できるように、serviceAccountToken ボリュームをマウントします。

前提条件

  • OpenShift Container Platform 4.14 以降
  • STS モードのクラスター
  • OLM ベースの Operator プロジェクト

手順

  1. Operator プロジェクトの ClusterServiceVersion (CSV) オブジェクトを更新します。

    1. Operator が CredentialsRequests オブジェクトを作成する RBAC 権限を持っていることを確認します。

      例10.1 clusterPermissions リストの例

      # ...
      install:
        spec:
          clusterPermissions:
          - rules:
            - apiGroups:
              - "cloudcredential.openshift.io"
              resources:
              - credentialsrequests
              verbs:
              - create
              - delete
              - get
              - list
              - patch
              - update
              - watch
      Copy to Clipboard Toggle word wrap
    2. AWS STS を使用したこの CCO ベースのワークフロー方式のサポートを要求するために、次のアノテーションを追加します。

      # ...
      metadata:
       annotations:
         features.operators.openshift.io/token-auth-aws: "true"
      Copy to Clipboard Toggle word wrap
  2. Operator プロジェクトコードを更新します。

    1. Subscription オブジェクトによって Pod に設定された環境変数からロール ARN を取得します。以下に例を示します。

      // Get ENV var
      roleARN := os.Getenv("ROLEARN")
      setupLog.Info("getting role ARN", "role ARN = ", roleARN)
      webIdentityTokenPath := "/var/run/secrets/openshift/serviceaccount/token"
      Copy to Clipboard Toggle word wrap
    2. パッチを適用して適用できる CredentialsRequest オブジェクトがあることを確認してください。以下に例を示します。

      例10.2 CredentialsRequest オブジェクトの作成例

      import (
         minterv1 "github.com/openshift/cloud-credential-operator/pkg/apis/cloudcredential/v1"
         corev1 "k8s.io/api/core/v1"
         metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
      )
      
      var in = minterv1.AWSProviderSpec{
         StatementEntries: []minterv1.StatementEntry{
            {
               Action: []string{
                  "s3:*",
               },
               Effect:   "Allow",
               Resource: "arn:aws:s3:*:*:*",
            },
         },
      	STSIAMRoleARN: "<role_arn>",
      }
      
      var codec = minterv1.Codec
      var ProviderSpec, _ = codec.EncodeProviderSpec(in.DeepCopyObject())
      
      const (
         name      = "<credential_request_name>"
         namespace = "<namespace_name>"
      )
      
      var CredentialsRequestTemplate = &minterv1.CredentialsRequest{
         ObjectMeta: metav1.ObjectMeta{
             Name:      name,
             Namespace: "openshift-cloud-credential-operator",
         },
         Spec: minterv1.CredentialsRequestSpec{
            ProviderSpec: ProviderSpec,
            SecretRef: corev1.ObjectReference{
               Name:      "<secret_name>",
               Namespace: namespace,
            },
            ServiceAccountNames: []string{
               "<service_account_name>",
            },
            CloudTokenPath:   "",
         },
      }
      Copy to Clipboard Toggle word wrap

      あるいは、YAML 形式の CredentialsRequest オブジェクトから開始している場合 (たとえば、Operator プロジェクトコードの一部として)、別の方法で処理することもできます。

      例10.3 YAML フォームでの CredentialsRequest オブジェクト作成の例

      // CredentialsRequest is a struct that represents a request for credentials
      type CredentialsRequest struct {
        APIVersion string `yaml:"apiVersion"`
        Kind       string `yaml:"kind"`
        Metadata   struct {
           Name      string `yaml:"name"`
           Namespace string `yaml:"namespace"`
        } `yaml:"metadata"`
        Spec struct {
           SecretRef struct {
              Name      string `yaml:"name"`
              Namespace string `yaml:"namespace"`
           } `yaml:"secretRef"`
           ProviderSpec struct {
              APIVersion     string `yaml:"apiVersion"`
              Kind           string `yaml:"kind"`
              StatementEntries []struct {
                 Effect   string   `yaml:"effect"`
                 Action   []string `yaml:"action"`
                 Resource string   `yaml:"resource"`
              } `yaml:"statementEntries"`
              STSIAMRoleARN   string `yaml:"stsIAMRoleARN"`
           } `yaml:"providerSpec"`
      
           // added new field
            CloudTokenPath   string `yaml:"cloudTokenPath"`
        } `yaml:"spec"`
      }
      
      // ConsumeCredsRequestAddingTokenInfo is a function that takes a YAML filename and two strings as arguments
      // It unmarshals the YAML file to a CredentialsRequest object and adds the token information.
      func ConsumeCredsRequestAddingTokenInfo(fileName, tokenString, tokenPath string) (*CredentialsRequest, error) {
        // open a file containing YAML form of a CredentialsRequest
        file, err := os.Open(fileName)
        if err != nil {
           return nil, err
        }
        defer file.Close()
      
        // create a new CredentialsRequest object
        cr := &CredentialsRequest{}
      
        // decode the yaml file to the object
        decoder := yaml.NewDecoder(file)
        err = decoder.Decode(cr)
        if err != nil {
           return nil, err
        }
      
        // assign the string to the existing field in the object
        cr.Spec.CloudTokenPath = tokenPath
      
        // return the modified object
        return cr, nil
      }
      Copy to Clipboard Toggle word wrap
      注記

      CredentialsRequest オブジェクトを Operator バンドルに追加することは現在サポートされていません。

    3. ロール ARN と Web ID トークンパスを認証情報リクエストに追加し、Operator の初期化中に適用します。

      例10.4 Operator の初期化中に CredentialsRequest オブジェクトを適用する例

      // apply CredentialsRequest on install
      credReq := credreq.CredentialsRequestTemplate
      credReq.Spec.CloudTokenPath = webIdentityTokenPath
      
      c := mgr.GetClient()
      if err := c.Create(context.TODO(), credReq); err != nil {
         if !errors.IsAlreadyExists(err) {
            setupLog.Error(err, "unable to create CredRequest")
            os.Exit(1)
         }
      }
      Copy to Clipboard Toggle word wrap
    4. 次の例に示すように、CCO から Secret オブジェクトが表示されるのを Operator が待機できるようにします。この処理は、Operator がリコンサイルする他の項目とともに呼び出されます。

      例10.5 Secret オブジェクトを待機する例

      // WaitForSecret is a function that takes a Kubernetes client, a namespace, and a v1 "k8s.io/api/core/v1" name as arguments
      // It waits until the secret object with the given name exists in the given namespace
      // It returns the secret object or an error if the timeout is exceeded
      func WaitForSecret(client kubernetes.Interface, namespace, name string) (*v1.Secret, error) {
        // set a timeout of 10 minutes
        timeout := time.After(10 * time.Minute) 
      1
      
      
        // set a polling interval of 10 seconds
        ticker := time.NewTicker(10 * time.Second)
      
        // loop until the timeout or the secret is found
        for {
           select {
           case <-timeout:
              // timeout is exceeded, return an error
              return nil, fmt.Errorf("timed out waiting for secret %s in namespace %s", name, namespace)
                 // add to this error with a pointer to instructions for following a manual path to a Secret that will work on STS
           case <-ticker.C:
              // polling interval is reached, try to get the secret
              secret, err := client.CoreV1().Secrets(namespace).Get(context.Background(), name, metav1.GetOptions{})
              if err != nil {
                 if errors.IsNotFound(err) {
                    // secret does not exist yet, continue waiting
                    continue
                 } else {
                    // some other error occurred, return it
                    return nil, err
                 }
              } else {
                 // secret is found, return it
                 return secret, nil
              }
           }
        }
      }
      Copy to Clipboard Toggle word wrap
      1
      timeout 値は、CCO が追加された CredentialsRequest オブジェクトを検出して Secret オブジェクトを生成する速度の推定に基づいています。Operator がまだクラウドリソースにアクセスしていない理由を疑問に思っているクラスター管理者のために、時間を短縮するか、カスタムフィードバックを作成することを検討してください。
    5. 認証情報リクエストから CCO によって作成されたシークレットを読み取り、そのシークレットのデータを含む AWS 設定ファイルを作成することで、AWS 設定をセットアップします。

      例10.6 AWS 設定の作成例

      func SharedCredentialsFileFromSecret(secret *corev1.Secret) (string, error) {
         var data []byte
         switch {
         case len(secret.Data["credentials"]) > 0:
             data = secret.Data["credentials"]
         default:
             return "", errors.New("invalid secret for aws credentials")
         }
      
      
         f, err := ioutil.TempFile("", "aws-shared-credentials")
         if err != nil {
             return "", errors.Wrap(err, "failed to create file for shared credentials")
         }
         defer f.Close()
         if _, err := f.Write(data); err != nil {
             return "", errors.Wrapf(err, "failed to write credentials to %s", f.Name())
         }
         return f.Name(), nil
      }
      Copy to Clipboard Toggle word wrap
      重要

      シークレットは存在すると想定されますが、このシークレットを使用する場合、CCO がシークレットを作成する時間を与えるために、Operator コードは待機して再試行する必要があります。

      さらに、待機期間は最終的にタイムアウトになり、OpenShift Container Platform クラスターのバージョン、つまり CCO が、STS 検出による CredentialsRequest オブジェクトのワークフローをサポートしていない以前のバージョンである可能性があることをユーザーに警告します。このような場合は、別の方法を使用してシークレットを追加する必要があることをユーザーに指示します。

    6. AWS SDK セッションを設定します。以下に例を示します。

      例10.7 AWS SDK セッション設定の例

      sharedCredentialsFile, err := SharedCredentialsFileFromSecret(secret)
      if err != nil {
         // handle error
      }
      options := session.Options{
         SharedConfigState: session.SharedConfigEnable,
         SharedConfigFiles: []string{sharedCredentialsFile},
      }
      Copy to Clipboard Toggle word wrap

第11章 Hosted Control Plane のマシン設定の処理

スタンドアロン OpenShift Container Platform クラスターでは、マシン設定プールがノードのセットを管理します。MachineConfigPool カスタムリソース (CR) を使用してマシン設定を処理できます。

ヒント

NodePool CR の nodepool.spec.config フィールドで、任意の machineconfiguration.openshift.io リソースを参照できます。

ホストされたコントロールプレーンでは、MachineConfigPool CR は存在しません。ノードプールには、一連のコンピュートノードがあります。ノードプールを使用してマシン設定を処理できます。

注記

OpenShift Container Platform 4.18 以降では、ワーカーノードのデフォルトのコンテナーランタイムが runC から crun に変更になります。

11.1. ホストされたコントロールプレーンのノードプールの設定

ホストされたコントロールプレーンでは、管理クラスターの config map 内に MachineConfig オブジェクトを作成することでノードプールを設定できます。

手順

  1. 管理クラスターの config map 内に MachineConfig オブジェクトを作成するには、次の情報を入力します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <configmap_name>
      namespace: clusters
    data:
      config: |
        apiVersion: machineconfiguration.openshift.io/v1
        kind: MachineConfig
        metadata:
          labels:
            machineconfiguration.openshift.io/role: worker
          name: <machineconfig_name>
        spec:
          config:
            ignition:
              version: 3.2.0
            storage:
              files:
              - contents:
                  source: data:...
                mode: 420
                overwrite: true
                path: ${PATH} 
    1
    Copy to Clipboard Toggle word wrap
    1
    MachineConfig オブジェクトが保存されているノード上のパスを設定します。
  2. オブジェクトを config map に追加した後、次のように config map をノードプールに適用できます。

    $ oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
    apiVersion: hypershift.openshift.io/v1alpha1
    kind: NodePool
    metadata:
    # ...
      name: nodepool-1
      namespace: clusters
    # ...
    spec:
      config:
      - name: <configmap_name> 
    1
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    <configmap_name> は、設定マップの名前に置き換えます。

11.2. ノードプール内の kubelet 設定を参照する

ノードプール内の kubelet 設定を参照するには、kubelet 設定を config map に追加してから、その config map を NodePool リソースに適用します。

手順

  1. 次の情報を入力して、管理クラスターの config map 内に kubelet 設定を追加します。

    kubelet 設定を持つ ConfigMap オブジェクトの例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <configmap_name> 
    1
    
      namespace: clusters
    data:
      config: |
        apiVersion: machineconfiguration.openshift.io/v1
        kind: KubeletConfig
        metadata:
          name: <kubeletconfig_name> 
    2
    
        spec:
          kubeletConfig:
            registerWithTaints:
            - key: "example.sh/unregistered"
              value: "true"
              effect: "NoExecute"
    Copy to Clipboard Toggle word wrap

    1
    <configmap_name> は、設定マップの名前に置き換えます。
    2
    <kubeletconfig_name> は、KubeletConfig リソースの名前に置き換えます。
  2. 次のコマンドを入力して、config map をノードプールに適用します。

    $ oc edit nodepool <nodepool_name> --namespace clusters 
    1
    Copy to Clipboard Toggle word wrap
    1
    <nodepool_name> をノードプールの名前に置き換えます。

    NodePool リソース設定の例

    apiVersion: hypershift.openshift.io/v1alpha1
    kind: NodePool
    metadata:
    # ...
      name: nodepool-1
      namespace: clusters
    # ...
    spec:
      config:
      - name: <configmap_name> 
    1
    
    # ...
    Copy to Clipboard Toggle word wrap

    1
    <configmap_name> は、設定マップの名前に置き換えます。

11.3. ホステッドクラスターにおけるノードのチューニング設定

ホステッドクラスター内のノードでノードレベルのチューニングを設定するには、Node Tuning Operator を使用できます。ホストされたコントロールプレーンでは、Tuned オブジェクトを含む config map を作成し、ノードプールでそれらの config map を参照することで、ノードのチューニングを設定できます。

手順

  1. チューニングされた有効なマニフェストを含む config map を作成し、ノードプールでマニフェストを参照します。次の例で Tuned マニフェストは、任意の値を持つ tuned-1-node-label ノードラベルを含むノード上で vm.dirty_ratio を 55 に設定するプロファイルを定義します。次の ConfigMap マニフェストを tuned-1.yaml という名前のファイルに保存します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: tuned-1
          namespace: clusters
        data:
          tuning: |
            apiVersion: tuned.openshift.io/v1
            kind: Tuned
            metadata:
              name: tuned-1
              namespace: openshift-cluster-node-tuning-operator
            spec:
              profile:
              - data: |
                  [main]
                  summary=Custom OpenShift profile
                  include=openshift-node
                  [sysctl]
                  vm.dirty_ratio="55"
                name: tuned-1-profile
              recommend:
              - priority: 20
                profile: tuned-1-profile
    Copy to Clipboard Toggle word wrap
    注記

    Tuned 仕様の spec.recommend セクションのエントリーにラベルを追加しない場合は、ノードプールベースのマッチングが想定されるため、spec.recommend セクションの最も優先度の高いプロファイルがプール内のノードに適用されます。Tuned .spec.recommend.match セクションでラベル値を設定することにより、よりきめ細かいノードラベルベースのマッチングを実現できますが、ノードプールの .spec.management.upgradeType 値を InPlace に設定しない限り、ノードラベルはアップグレード中に保持されません。

  2. 管理クラスターに ConfigMap オブジェクトを作成します。

    $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml
    Copy to Clipboard Toggle word wrap
  3. ノードプールを編集するか作成して、ノードプールの spec.tuningConfig フィールドで ConfigMap オブジェクトを参照します。この例では、2 つのノードを含む nodepool-1 という名前の NodePool が 1 つだけあることを前提としています。

        apiVersion: hypershift.openshift.io/v1alpha1
        kind: NodePool
        metadata:
          ...
          name: nodepool-1
          namespace: clusters
        ...
        spec:
          ...
          tuningConfig:
          - name: tuned-1
        status:
        ...
    Copy to Clipboard Toggle word wrap
    注記

    複数のノードプールで同じ config map を参照できます。Hosted Control Plane では、Node Tuning Operator が Tuned CR の名前にノードプール名と namespace のハッシュを追加して、それらを区別します。この場合を除き、同じホステッドクラスターの異なる Tuned CR に、同じ名前の複数の TuneD プロファイルを作成しないでください。

検証

Tuned マニフェストを含む ConfigMap オブジェクトを作成し、それを NodePool で参照したことで、Node Tuning Operator により Tuned オブジェクトがホステッドクラスターに同期されます。どの Tuned オブジェクトが定義されているか、どの TuneD プロファイルが各ノードに適用されているかを確認できます。

  1. ホステッドクラスター内の Tuned オブジェクトをリスト表示します。

    $ oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io \
      -n openshift-cluster-node-tuning-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME       AGE
    default    7m36s
    rendered   7m36s
    tuned-1    65s
    Copy to Clipboard Toggle word wrap

  2. ホステッドクラスター内の Profile オブジェクトをリスト表示します。

    $ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io \
      -n openshift-cluster-node-tuning-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                           TUNED            APPLIED   DEGRADED   AGE
    nodepool-1-worker-1            tuned-1-profile  True      False      7m43s
    nodepool-1-worker-2            tuned-1-profile  True      False      7m14s
    Copy to Clipboard Toggle word wrap

    注記

    カスタムプロファイルが作成されていない場合は、openshift-node プロファイルがデフォルトで適用されます。

  3. チューニングが正しく適用されたことを確認するには、ノードでデバッグシェルを開始し、sysctl 値を確認します。

    $ oc --kubeconfig="$HC_KUBECONFIG" \
      debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio
    Copy to Clipboard Toggle word wrap

    出力例

    vm.dirty_ratio = 55
    Copy to Clipboard Toggle word wrap

11.4. Hosted Control Plane 用の SR-IOV Operator のデプロイ

ホスティングサービスクラスターを設定してデプロイすると、ホステッドクラスターで SR-IOV Operator へのサブスクリプションを作成できます。SR-IOV Pod は、コントロールプレーンではなくワーカーマシンで実行されます。

前提条件

AWS 上でホステッドクラスターを設定およびデプロイしている。

手順

  1. namespace と Operator グループを作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-sriov-network-operator
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: sriov-network-operators
      namespace: openshift-sriov-network-operator
    spec:
      targetNamespaces:
      - openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap
  2. SR-IOV Operator へのサブスクリプションを作成します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sriov-network-operator-subsription
      namespace: openshift-sriov-network-operator
    spec:
      channel: stable
      name: sriov-network-operator
      config:
        nodeSelector:
          node-role.kubernetes.io/worker: ""
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap

検証

  1. SR-IOV Operator の準備ができていることを確認するには、次のコマンドを実行し、結果の出力を表示します。

    $ oc get csv -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                         DISPLAY                   VERSION               REPLACES                                     PHASE
    sriov-network-operator.4.19.0-202211021237   SR-IOV Network Operator   4.19.0-202211021237   sriov-network-operator.4.19.0-202210290517   Succeeded
    Copy to Clipboard Toggle word wrap

  2. SR-IOV Pod がデプロイされていることを確認するには、次のコマンドを実行します。

    $ oc get pods -n openshift-sriov-network-operator
    Copy to Clipboard Toggle word wrap

11.5. ホステッドクラスターの NTP サーバーの設定

Butane を使用して、ホステッドクラスターの Network Time Protocol (NTP) サーバーを設定できます。

手順

  1. chrony.conf ファイルの内容を含む Butane 設定ファイル 99-worker-chrony.bu を作成します。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。

    99-worker-chrony.bu の設定例

    # ...
    variant: openshift
    version: 4.19.0
    metadata:
      name: 99-worker-chrony
      labels:
        machineconfiguration.openshift.io/role: worker
    storage:
      files:
      - path: /etc/chrony.conf
        mode: 0644  
    1
    
        overwrite: true
        contents:
          inline: |
            pool 0.rhel.pool.ntp.org iburst  
    2
    
            driftfile /var/lib/chrony/drift
            makestep 1.0 3
            rtcsync
            logdir /var/log/chrony
    # ...
    Copy to Clipboard Toggle word wrap

    1
    マシン設定ファイルの mode フィールドに 8 進数の値でモードを指定します。ファイルを作成して変更を適用すると、mode フィールドは 10 進数値に変換されます。
    2
    Dynamic Host Configuration Protocol (DHCP) サーバーが提供するタイムソースなど、有効で到達可能なタイムソースを指定します。
    注記

    マシン間通信の場合、User Datagram Protocol (UDP) ポート上の NTP は 123 です。外部 NTP タイムサーバーを設定した場合は、UDP ポート 123 を開く必要があります。

  2. Butane を使用して、Butane がノードに送信する設定を含む MachineConfig オブジェクトファイル 99-worker-chrony.yaml を生成します。以下のコマンドを実行します。

    $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
    Copy to Clipboard Toggle word wrap

    99-worker-chrony.yaml の設定例

    # Generated by Butane; do not edit
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: <machineconfig_name>
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
            - contents:
                source: data:...
              mode: 420
              overwrite: true
              path: /example/path
    Copy to Clipboard Toggle word wrap

  3. 管理クラスターの config map 内に 99-worker-chrony.yaml ファイルの内容を追加します。

    config map の例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <configmap_name>
      namespace: <namespace>  
    1
    
    data:
      config: |
        apiVersion: machineconfiguration.openshift.io/v1
        kind: MachineConfig
        metadata:
          labels:
            machineconfiguration.openshift.io/role: worker
          name: <machineconfig_name>
        spec:
          config:
            ignition:
              version: 3.2.0
            storage:
              files:
              - contents:
                  source: data:...
                mode: 420
                overwrite: true
                path: /example/path
    # ...
    Copy to Clipboard Toggle word wrap

    1
    <namespace> は、ノードプールを作成した namespace の名前 (clusters など) に置き換えます。
  4. 次のコマンドを実行して、config map をノードプールに適用します。

    $ oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

    NodePool の設定例

    apiVersion: hypershift.openshift.io/v1alpha1
    kind: NodePool
    metadata:
    # ...
      name: nodepool-1
      namespace: clusters
    # ...
    spec:
      config:
      - name: <configmap_name> 
    1
    
    # ...
    Copy to Clipboard Toggle word wrap

    1
    <configmap_name> は、設定マップの名前に置き換えます。
  5. InfraEnv カスタムリソース (CR) を定義する infra-env.yaml ファイルに NTP サーバーのリストを追加します。

    infra-env.yaml ファイルの例

    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    # ...
    spec:
      additionalNTPSources:
      - <ntp_server> 
    1
    
      - <ntp_server1>
      - <ntp_server2>
    # ...
    Copy to Clipboard Toggle word wrap

    1
    <ntp_server> は、NTP サーバーの名前に置き換えます。ホストインベントリーと InfraEnv CR の作成の詳細は、「ホストインベントリーの作成」を参照してください。
  6. 次のコマンドを実行して、InfraEnv CR を適用します。

    $ oc apply -f infra-env.yaml
    Copy to Clipboard Toggle word wrap

検証

  • 次のフィールドを確認し、ホストインベントリーのステータスを確認します。

    • conditions: イメージが正常に作成されたかどうかを示す標準の Kubernetes の状態。
    • isoDownloadURL: Discovery Image をダウンロードするための URL。
    • createdTime: イメージが最後に作成された時刻。InfraEnv CR を変更する場合は、新しいイメージをダウンロードする前に、必ずタイムスタンプを更新してください。

      次のコマンドを実行して、ホストインベントリーが作成されたことを確認します。

      $ oc describe infraenv <infraenv_resource_name> -n <infraenv_namespace>
      Copy to Clipboard Toggle word wrap
      注記

      InfraEnv CR を変更する場合は、createdTime フィールドを調べて、InfraEnv CR によって新しい Discovery Image が作成されたことを確認してください。すでにホストを起動している場合は、最新の Discovery Image でホストを再起動します。

第12章 ホステッドクラスターでのフィーチャーゲートの使用

ホステッドクラスターでフィーチャーゲートを使用して、デフォルトの機能セットに含まれていない機能を有効にすることができます。ホステッドクラスターでフィーチャーゲートを使用すると、TechPreviewNoUpgrade 機能セットを有効にすることができます。

12.1. フィーチャーゲートを使用した機能セットの有効化

OpenShift CLI を使用して HostedCluster カスタムリソース (CR) を編集することにより、ホステッドクラスターで TechPreviewNoUpgrade 機能セットを有効にすることができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、ホスティングクラスターで HostedCluster CR を編集するために開きます。

    $ oc edit hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  2. featureSet フィールドに値を入力して機能セットを定義します。以下に例を示します。

    apiVersion: hypershift.openshift.io/v1beta1
    kind: HostedCluster
    metadata:
      name: <hosted_cluster_name> 
    1
    
      namespace: <hosted_cluster_namespace> 
    2
    
    spec:
      configuration:
        featureGate:
          featureSet: TechPreviewNoUpgrade 
    3
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します。
    2
    ホステッドクラスターの namespace を指定します。
    3
    この機能セットは、現在のテクノロジープレビュー機能のサブセットです。
    警告

    クラスターで TechPreviewNoUpgrade 機能セットを有効にすると、元に戻すことができず、マイナーバージョンの更新が妨げられます。この機能セットを使用すると、該当するテクノロジープレビュー機能をテストクラスターで有効にして、完全にテストすることができます。実稼働クラスターではこの機能セットを有効にしないでください。

  3. 変更を適用するためにファイルを保存します。

検証

  • 次のコマンドを実行して、ホステッドクラスターで TechPreviewNoUpgrade フィーチャーゲートが有効になっていることを確認します。

    $ oc get featuregate cluster -o yaml
    Copy to Clipboard Toggle word wrap

第13章 Hosted Control Plane の可観測性

メトリクスセットを設定することで、Hosted Control Plane のメトリクスを収集できます。HyperShift Operator は、管理対象のホステッドクラスターごとに、管理クラスター内のモニタリングダッシュボードを作成または削除できます。

13.1. Hosted Control Plane のメトリクスセットの設定

Red Hat OpenShift Container Platform の Hosted Control Plane は、各コントロールプレーンの namespace に ServiceMonitor リソースを作成します。これにより、Prometheus スタックがコントロールプレーンからメトリクスを収集できるようになります。ServiceMonitor リソースは、メトリクスの再ラベル付けを使用して、etcd や Kubernetes API サーバーなどの特定のコンポーネントにどのメトリクスを含めるか、または除外するかを定義します。コントロールプレーンによって生成されるメトリクスの数は、それらを収集する監視スタックのリソース要件に直接影響します。

すべての状況に適用される固定数のメトリクスを生成する代わりに、コントロールプレーンごとに生成するメトリクスのセットを識別するメトリクスセットを設定できます。次のメトリクスセットがサポートされています。

  • Telemetry: このメトリクスはテレメトリーに必要です。このセットはデフォルトのセットであり、メトリクスの最小セットです。
  • SRE: このセットには、アラートを生成し、コントロールプレーンコンポーネントのトラブルシューティングを可能にするために必要なメトリクスが含まれています。
  • All: このセットには、スタンドアロンの OpenShift Container Platform コントロールプレーンコンポーネントによって生成されるすべてのメトリクスが含まれます。

メトリクスセットを設定するには、次のコマンドを入力して、HyperShift Operator デプロイメントで METRICS_SET 環境変数を設定します。

$ oc set env -n hypershift deployment/operator METRICS_SET=All
Copy to Clipboard Toggle word wrap

13.1.1. SRE メトリクスセットの設定

SRE メトリクスセットを指定すると、HyperShift Operator は、単一キー config を持つ sre-metric-set という名前の config map を検索します。config キーの値には、コントロールプレーンコンポーネント別に整理された RelabelConfigs のセットが含まれている必要があります。

次のコンポーネントを指定できます。

  • etcd
  • kubeAPIServer
  • kubeControllerManager
  • openshiftAPIServer
  • openshiftControllerManager
  • openshiftRouteControllerManager
  • cvo
  • olm
  • catalogOperator
  • registryOperator
  • nodeTuningOperator
  • controlPlaneOperator
  • hostedClusterConfigOperator

SRE メトリクスセットの設定を次の例に示します。

kubeAPIServer:
  - action:       "drop"
    regex:        "etcd_(debugging|disk|server).*"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "apiserver_admission_controller_admission_latencies_seconds_.*"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "apiserver_admission_step_admission_latencies_seconds_.*"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "scheduler_(e2e_scheduling_latency_microseconds|scheduling_algorithm_predicate_evaluation|scheduling_algorithm_priority_evaluation|scheduling_algorithm_preemption_evaluation|scheduling_algorithm_latency_microseconds|binding_latency_microseconds|scheduling_latency_seconds)"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "apiserver_(request_count|request_latencies|request_latencies_summary|dropped_requests|storage_data_key_generation_latencies_microseconds|storage_transformation_failures_total|storage_transformation_latencies_microseconds|proxy_tunnel_sync_latency_secs)"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "docker_(operations|operations_latency_microseconds|operations_errors|operations_timeout)"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "reflector_(items_per_list|items_per_watch|list_duration_seconds|lists_total|short_watches_total|watch_duration_seconds|watches_total)"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "etcd_(helper_cache_hit_count|helper_cache_miss_count|helper_cache_entry_count|request_cache_get_latencies_summary|request_cache_add_latencies_summary|request_latencies_summary)"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "transformation_(transformation_latencies_microseconds|failures_total)"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "network_plugin_operations_latency_microseconds|sync_proxy_rules_latency_microseconds|rest_client_request_latency_seconds"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "apiserver_request_duration_seconds_bucket;(0.15|0.25|0.3|0.35|0.4|0.45|0.6|0.7|0.8|0.9|1.25|1.5|1.75|2.5|3|3.5|4.5|6|7|8|9|15|25|30|50)"
    sourceLabels: ["__name__", "le"]
kubeControllerManager:
  - action:       "drop"
    regex:        "etcd_(debugging|disk|request|server).*"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "rest_client_request_latency_seconds_(bucket|count|sum)"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "root_ca_cert_publisher_sync_duration_seconds_(bucket|count|sum)"
    sourceLabels: ["__name__"]
openshiftAPIServer:
  - action:       "drop"
    regex:        "etcd_(debugging|disk|server).*"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "apiserver_admission_controller_admission_latencies_seconds_.*"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "apiserver_admission_step_admission_latencies_seconds_.*"
    sourceLabels: ["__name__"]
  - action:       "drop"
    regex:        "apiserver_request_duration_seconds_bucket;(0.15|0.25|0.3|0.35|0.4|0.45|0.6|0.7|0.8|0.9|1.25|1.5|1.75|2.5|3|3.5|4.5|6|7|8|9|15|25|30|50)"
    sourceLabels: ["__name__", "le"]
openshiftControllerManager:
  - action:       "drop"
    regex:        "etcd_(debugging|disk|request|server).*"
    sourceLabels: ["__name__"]
openshiftRouteControllerManager:
  - action:       "drop"
    regex:        "etcd_(debugging|disk|request|server).*"
    sourceLabels: ["__name__"]
olm:
  - action:       "drop"
    regex:        "etcd_(debugging|disk|server).*"
    sourceLabels: ["__name__"]
catalogOperator:
  - action:       "drop"
    regex:        "etcd_(debugging|disk|server).*"
    sourceLabels: ["__name__"]
cvo:
  - action: drop
    regex: "etcd_(debugging|disk|server).*"
    sourceLabels: ["__name__"]
Copy to Clipboard Toggle word wrap

13.2. ホステッドクラスターのモニタリングダッシュボードの有効化

config map を作成することにより、ホステッドクラスターでモニタリングダッシュボードを有効にできます。

手順

  1. local-cluster namespace に、hypershift-operator-install-flags config map を作成します。次の設定例を参照してください。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: hypershift-operator-install-flags
      namespace: local-cluster
    data:
      installFlagsToAdd: "--monitoring-dashboards --metrics-set=All" 
    1
    
      installFlagsToRemove: ""
    Copy to Clipboard Toggle word wrap
    1
    --monitoring-dashboards --metrics-set=All フラグは、すべてのメトリクスのモニタリングダッシュボードを追加します。
  2. hypershift namespace の HyperShift Operator デプロイメントが更新され、次の環境変数が含まれるまで数分待ちます。

        - name: MONITORING_DASHBOARDS
          value: "1"
    Copy to Clipboard Toggle word wrap

    モニタリングダッシュボードが有効になっている場合、HyperShift Operator が管理するホステッドクラスターごとに、HyperShift Operator が openshift-config-managed namespace に cp-<hosted_cluster_namespace>-<hosted_cluster_name> という名前の config map を作成します。<hosted_cluster_namespace> はホステッドクラスターの namespace、<hosted_cluster_name> はホステッドクラスターの名前です。その結果、管理クラスターの管理コンソールに新しいダッシュボードが追加されます。

  3. ダッシュボードを表示するには、管理クラスターのコンソールにログインし、Observe → Dashboards をクリックして、ホステッドクラスターのダッシュボードに移動します。
  4. オプション: ホステッドクラスターのモニタリングダッシュボードを無効にするには、hypershift-operator-install-flags config map から --monitoring-dashboards --metrics-set=All フラグを削除します。ホステッドクラスターを削除すると、対応するダッシュボードも削除されます。

13.2.1. ダッシュボードのカスタマイズ

各ホステッドクラスターのダッシュボードを生成するために、HyperShift Operator は、Operator の namespace (hypershift) の monitoring-dashboard-template config map に保存されているテンプレートを使用します。このテンプレートには、ダッシュボードのメトリクスを含む一連の Grafana パネルが含まれています。config map の内容を編集して、ダッシュボードをカスタマイズできます。

ダッシュボードが生成されると、次の文字列が特定のホステッドクラスターに対応する値に置き換えられます。

Expand
名前説明

__NAME__

ホステッドクラスターの名前

__NAMESPACE__

ホステッドクラスターの namespace

__CONTROL_PLANE_NAMESPACE__

ホステッドクラスターのコントロールプレーン Pod が配置される namespace

__CLUSTER_ID__

ホステッドクラスターの UUID。これはホステッドクラスターのメトリクスの _id ラベルと一致します。

第14章 Hosted Control Plane のネットワーク

スタンドアロン OpenShift Container Platform の場合、プロキシーサポートの主な目的は、クラスター内のワークロードが HTTP または HTTPS プロキシーを使用して外部サービスにアクセスするように設定されていること、設定されている場合は NO_PROXY 設定が適用されていること、プロキシー用に設定されているトラストバンドルを受け入れることを確認することです。

Hosted Control Plane の場合、プロキシーサポートには次の追加のユースケースが含まれます。

14.1. 外部サービスにアクセスする必要があるコントロールプレーンワークロード

コントロールプレーンで実行される Operator は、ホステッドクラスター用に設定されたプロキシーを介して外部サービスにアクセスする必要があります。通常、プロキシーにはデータプレーン経由でのみアクセスできます。コントロールプレーンワークロードは次のとおりです。

  • Control Plane Operator は、OAuth サーバー設定の作成時に、特定のアイデンティティープロバイダーからエンドポイントを検証して取得する必要があります。
  • OAuth サーバーには、LDAP 以外のアイデンティティープロバイダーアクセスが必要です。
  • OpenShift API サーバーはイメージレジストリーメタデータのインポートを処理します。
  • Ingress Operator には、外部のカナリアルートを検証するためのアクセス権が必要です。
  • ドメインネームサービス (DNS) プロトコルが期待どおりに動作できるように、Transmission Control Protocol (TCP) および User Datagram Protocol (UDP) のファイアウォールポート 53 を開く必要があります。

ホステッドクラスターでは、Control Plane Operator、Ingress Operator、OAuth サーバー、OpenShift API サーバー Pod から発信されたトラフィックを、データプレーン経由で設定済みのプロキシーに送信して、最終的な宛先に送信する必要があります。

注記

ホステッドクラスターがゼロコンピュートノードに削減されると、プロキシーアクセスを必要とするレジストリーからの OpenShift イメージストリームのインポートなど、一部の操作は実行できなくなります。

14.2. Ignition エンドポイントにアクセスする必要があるコンピュートノード

コンピュートノードが Ignition エンドポイントにアクセスするためにプロキシーを必要とする場合、コンピュートノードの作成時に設定されるユーザーデータスタブでプロキシーを設定する必要があります。マシンが Ignition URL にアクセスするためにプロキシーを必要とする場合、プロキシー設定はスタブに含まれています。

スタブは次の例のようになります。

---
{"ignition":{"config":{"merge":[{"httpHeaders":[{"name":"Authorization","value":"Bearer ..."},{"name":"TargetConfigVersionHash","value":"a4c1b0dd"}],"source":"https://ignition.controlplanehost.example.com/ignition","verification":{}}],"replace":{"verification":{}}},"proxy":{"httpProxy":"http://proxy.example.org:3128", "httpsProxy":"https://proxy.example.org:3129", "noProxy":"host.example.org"},"security":{"tls":{"certificateAuthorities":[{"source":"...","verification":{}}]}},"timeouts":{},"version":"3.2.0"},"passwd":{},"storage":{},"systemd":{}}
---
Copy to Clipboard Toggle word wrap

14.3. API サーバーにアクセスする必要があるコンピュートノード

このユースケースは、Hosted Control Plane を使用する OpenShift Service on AWS ではなく、セルフマネージドの Hosted Control Plane に関連します。

コントロールプレーンとの通信のために、Hosted Control Plane は、IP アドレス 172.20.0.1 をリッスンし、トラフィックを API サーバーに転送するすべてのコンピュートノードでローカルプロキシーを使用します。API サーバーにアクセスするために外部プロキシーが必要な場合、そのローカルプロキシーは外部プロキシーを使用してトラフィックを送信する必要があります。プロキシーが必要ない場合、Hosted Control Plane はローカルプロキシーとして、TCP 経由でのみパケットを転送する haproxy を使用します。プロキシーが必要な場合、Hosted Control Plane はカスタムプロキシー control-plane-operator-kubernetes-default-proxy を使用して、外部プロキシー経由でトラフィックを送信します。

14.4. 外部アクセスを必要とする管理クラスター

HyperShift Operator には、管理クラスターの OpenShift グローバルプロキシー設定を監視し、独自のデプロイメントにプロキシー環境変数を設定するコントローラーがあります。外部アクセスを必要とするコントロールプレーンのデプロイメントは、管理クラスターのプロキシー環境変数を使用して設定されます。

管理クラスターがプロキシー設定を使用している場合に、ホステッドクラスターにセカンダリーネットワークを設定するが、デフォルトの Pod ネットワークをアタッチしない場合は、セカンダリーネットワークの CIDR をプロキシー設定に追加します。具体的には、管理クラスターのプロキシー設定の noProxy セクションにセカンダリーネットワークの CIDR を追加する必要があります。これを行わないと、Kubernetes API サーバーが一部の API リクエストをプロキシー経由でルーティングします。ホステッドクラスター設定では、セカンダリーネットワークの CIDR が noProxy セクションに自動的に追加されます。

第15章 Hosted Control Plane のトラブルシューティング

Hosted Control Plane で問題が発生した場合は、次の情報を参照してトラブルシューティングを行ってください。

15.1. Hosted Control Plane のトラブルシューティング用の情報収集

ホステッドクラスターの問題をトラブルシューティングする必要がある場合は、must-gather コマンドを実行して情報を収集できます。このコマンドは、管理クラスターとホステッドクラスターの出力を生成します。

管理クラスターの出力には次の内容が含まれます。

  • クラスタースコープのリソース: これらのリソースは、管理クラスターのノード定義です。
  • hypershift-dump 圧縮ファイル: このファイルは、コンテンツを他の人と共有する必要がある場合に役立ちます。
  • namespace リソース: これらのリソースには、config map、サービス、イベント、ログなど、関連する namespace のすべてのオブジェクトが含まれます。
  • ネットワークログ: これらのログには、OVN ノースバウンドデータベースとサウスバウンドデータベース、およびそれぞれのステータスが含まれます。
  • ホステッドクラスター: このレベルの出力には、ホステッドクラスター内のすべてのリソースが含まれます。

ホステッドクラスターの出力には、次の内容が含まれます。

  • クラスタースコープのリソース: これらのリソースには、ノードや CRD などのクラスター全体のオブジェクトがすべて含まれます。
  • namespace リソース: これらのリソースには、config map、サービス、イベント、ログなど、関連する namespace のすべてのオブジェクトが含まれます。

出力にはクラスターからのシークレットオブジェクトは含まれませんが、シークレットの名前への参照が含まれる可能性があります。

前提条件

  • 管理クラスターへの cluster-admin アクセス権がある。
  • HostedCluster リソースの name 値と、CR がデプロイされる namespace がある。
  • hcp コマンドラインインターフェイスがインストールされている。詳細は、「Hosted Control Plane のコマンドラインインターフェイスのインストール」を参照してください。
  • OpenShift CLI (oc) がインストールされている。
  • kubeconfig ファイルがロードされ、管理クラスターを指している。

手順

  • トラブルシューティングのために出力を収集するには、次のコマンドを入力します。

    $ oc adm must-gather \
      --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:v<mce_version> \
      /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE \
      hosted-cluster-name=HOSTEDCLUSTERNAME \
      --dest-dir=NAME ; tar -cvzf NAME.tgz NAME
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    • <mce_version> は、使用している multicluster engine Operator のバージョン (例: 2.6) に置き換えます。
    • hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE パラメーターはオプションです。このパラメーターを使用しないと、ホステッドクラスターがデフォルトの namespace (clusters) にあるかのようにコマンドが実行します。
    • コマンドの結果を圧縮ファイルに保存する場合は、--dest-dir=NAME パラメーターを指定します。NAME は、結果を保存するディレクトリーの名前に置き換えます。

15.2. ホステッドクラスターの OpenShift Container Platform データの収集

multicluster engine Operator Web コンソールまたは CLI を使用して、ホステッドクラスターの OpenShift Container Platform デバッグ情報を収集できます。

15.2.1. CLI を使用したホステッドクラスターのデータの収集

CLI を使用して、ホステッドクラスターの OpenShift Container Platform デバッグ情報を収集できます。

前提条件

  • 管理クラスターへの cluster-admin アクセス権がある。
  • HostedCluster リソースの name 値と、CR がデプロイされる namespace がある。
  • hcp コマンドラインインターフェイスがインストールされている。詳細は、「Hosted Control Plane のコマンドラインインターフェイスのインストール」を参照してください。
  • OpenShift CLI (oc) がインストールされている。
  • kubeconfig ファイルがロードされ、管理クラスターを指している。

手順

  1. 次のコマンドを入力して、kubeconfig ファイルを生成します。

    $ hcp create kubeconfig --namespace <hosted_cluster_namespace> \
      --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
    Copy to Clipboard Toggle word wrap
  2. kubeconfig ファイルを保存した後、次のコマンド例を入力して、ホステッドクラスターにアクセスできます。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap
  3. .次のコマンドを入力して、must-gather 情報を収集します。

    $ oc adm must-gather
    Copy to Clipboard Toggle word wrap

15.2.2. Web コンソールを使用したホステッドクラスターのデータの収集

multicluster engine Operator Web コンソールを使用して、ホステッドクラスターの OpenShift Container Platform デバッグ情報を収集できます。

前提条件

  • 管理クラスターへの cluster-admin アクセス権がある。
  • HostedCluster リソースの name 値と、CR がデプロイされる namespace がある。
  • hcp コマンドラインインターフェイスがインストールされている。詳細は、「Hosted Control Plane のコマンドラインインターフェイスのインストール」を参照してください。
  • OpenShift CLI (oc) がインストールされている。
  • kubeconfig ファイルがロードされ、管理クラスターを指している。

手順

  1. Web コンソールで、All Clusters を選択し、トラブルシューティングするクラスターを選択します。
  2. 右上隅で、Download kubeconfig を選択します。
  3. ダウンロードした kubeconfig ファイルをエクスポートします。
  4. 次のコマンドを入力して、must-gather 情報を収集します。

    $ oc adm must-gather
    Copy to Clipboard Toggle word wrap

15.3. 非接続環境での must-gather コマンドの入力

非接続環境で must-gather コマンドを実行するには、次の手順を実行します。

手順

  1. 非接続環境で、Red Hat Operator のカタログイメージをミラーレジストリーにミラーリングします。詳細は、ネットワーク切断状態でのインストール を参照してください。
  2. 次のコマンドを実行して、ミラーレジストリーからイメージを参照するログを抽出します。

    REGISTRY=registry.example.com:5000
    IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel8@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8
    
    $ oc adm must-gather \
      --image=$IMAGE /usr/bin/gather \
      hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE \
      hosted-cluster-name=HOSTEDCLUSTERNAME \
      --dest-dir=./data
    Copy to Clipboard Toggle word wrap

15.4. OpenShift Virtualization でのホステッドクラスターのトラブルシューティング

OpenShift Virtualization でホステッドクラスターのトラブルシューティングを行う場合は、トップレベルの HostedCluster リソースと NodePool リソースから始めて、根本原因が見つかるまでスタックを下位に向かって作業します。以下の手順は、一般的な問題の根本原因を検出するのに役立ちます。

15.4.1. HostedCluster リソースが partial 状態でスタックする

HostedCluster リソースが保留中であるために Hosted Control Plane が完全にオンラインにならない場合は、前提条件、リソースの状態、ノードと Operator のステータスを確認して問題を特定します。

手順

  • OpenShift Virtualization 上のホステッドクラスターの前提条件をすべて満たしていることを確認します。
  • 進行を妨げる検証エラーがないか、HostedCluster リソースと NodePool リソースの状態を表示します。
  • ホステッドクラスターの kubeconfig ファイルを使用して、ホステッドクラスターのステータスを検査します。

    • oc get clusteroperators コマンドの出力を表示して、保留中のクラスター Operator を表示します。
    • oc get nodes コマンドの出力を表示して、ワーカーノードの準備ができていることを確認します。

15.4.2. ワーカーノードが登録されない

Hosted Control Plane にワーカーノードが登録されないために Hosted Control Plane が完全にオンラインにならない場合は、Hosted Control Plane のさまざまな部分のステータスを確認して問題を特定します。

手順

  • HostedClusterNodePool の障害の状態を表示して、問題の内容を示します。
  • 次のコマンドを入力して、NodePool リソースの KubeVirt ワーカーノード仮想マシン (VM) のステータスを表示します。

    $ oc get vm -n <namespace>
    Copy to Clipboard Toggle word wrap
  • 仮想マシンがプロビジョニング状態でスタックしている場合は、次のコマンドを入力して、仮想マシン namespace 内の CDI インポート Pod を表示し、インポーター Pod が完了していない理由を調べます。

    $ oc get pods -n <namespace> | grep "import"
    Copy to Clipboard Toggle word wrap
  • 仮想マシンが開始状態でスタックしている場合は、次のコマンドを入力して、virt-launcher Pod のステータスを表示します。

    $ oc get pods -n <namespace> -l kubevirt.io=virt-launcher
    Copy to Clipboard Toggle word wrap

    virt-launcher Pod が保留状態にある場合は、Pod がスケジュールされていない理由を調査してください。たとえば、virt-launcher Pod の実行に必要なリソースが十分存在しない可能性があります。

  • 仮想マシンが実行されていてもワーカーノードとして登録されていない場合は、Web コンソールを使用して、影響を受ける仮想マシンの 1 つへの VNC アクセスを取得します。VNC 出力は ignition 設定が適用されたかどうかを示します。仮想マシンが起動時に Hosted Control Plane Ignition サーバーにアクセスできない場合、仮想マシンは正しくプロビジョニングできません。
  • Ignition 設定が適用されても、仮想マシンがノードとして登録されない場合は、問題の特定: 仮想マシンコンソールログへのアクセス で、起動時に仮想マシンコンソールログにアクセスする方法を確認してください。

15.4.3. ワーカーノードが NotReady 状態でスタックする

クラスターの作成中、ネットワークスタックがロールアウトされる間、ノードは一時的に NotReady 状態になります。プロセスのこの部分は正常です。ただし、このプロセス部分にかかる時間が 15 分を超える場合は、ノードオブジェクトと Pod を調査して問題を特定します。

手順

  1. 次のコマンドを入力して、ノードオブジェクトの状態を表示し、ノードの準備ができていない理由を特定します。

    $ oc get nodes -o yaml
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを入力して、クラスター内で障害が発生している Pod を探します。

    $ oc get pods -A --field-selector=status.phase!=Running,status,phase!=Succeeded
    Copy to Clipboard Toggle word wrap

15.4.4. Ingress およびコンソールクラスター Operator がオンラインにならない

Ingress およびコンソールクラスター Operator がオンラインでないために Hosted Control Plane が完全にオンラインにならない場合は、ワイルドカード DNS ルートとロードバランサーを確認します。

手順

  • クラスターがデフォルトの Ingress 動作を使用する場合は、次のコマンドを入力して、仮想マシン (VM) がホストされている OpenShift Container Platform クラスターでワイルドカード DNS ルートが有効になっていることを確認します。

    $ oc patch ingresscontroller -n openshift-ingress-operator \
      default --type=json -p \
      '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
    Copy to Clipboard Toggle word wrap
  • Hosted Control Plane にカスタムベースドメインを使用する場合は、次の手順を実行します。

    • ロードバランサーが仮想マシン Pod を正しくターゲットにしていることを確認します。
    • ワイルドカード DNS エントリーがロードバランサー IP をターゲットにしていることを確認します。

15.4.5. ホステッドクラスターのロードバランサーサービスが利用できない

ロードバランサーサービスが利用できないために Hosted Control Plane が完全にオンラインにならない場合は、イベント、詳細、Kubernetes Cluster Configuration Manager (KCCM) Pod を確認します。

手順

  • ホステッドクラスター内のロードバランサーサービスに関連付けられたイベントおよび詳細を探します。
  • デフォルトでは、ホステッドクラスターのロードバランサーは、Hosted Control Plane の namespace 内の kubevirt-cloud-controller-manager によって処理されます。KCCM Pod がオンラインであることを確認し、ログでエラーや警告を確認します。Hosted Control Plane の namespace で KCCM Pod を特定するには、次のコマンドを入力します。

    $ oc get pods -n <hosted_control_plane_namespace> \
      -l app=cloud-controller-manager
    Copy to Clipboard Toggle word wrap

15.4.6. ホステッドクラスターの PVC が利用できない

ホステッドクラスターの永続ボリューム要求 (PVC) が利用できないために Hosted Control Plane が完全にオンラインにならない場合は、PVC イベントと詳細、およびコンポーネントログを確認します。

手順

  • PVC に関連するイベントと詳細を探して、どのエラーが発生しているかを把握します。
  • PVC が Pod に割り当てられていない場合は、ホステッドクラスター内の kubevirt-csi-node daemonset コンポーネントのログを表示して、問題をさらに調査します。各ノードの kubevirt-csi-node Pod を識別するには、次のコマンドを入力します。

    $ oc get pods -n openshift-cluster-csi-drivers -o wide \
      -l app=kubevirt-csi-driver
    Copy to Clipboard Toggle word wrap
  • PVC が永続ボリューム (PV) にバインドできない場合は、Hosted Control Plane の namespace 内の kubevirt-csi-controller コンポーネントのログを表示します。Hosted Control Plane の namespace 内の kubevirt-csi-controller Pod を識別するには、次のコマンドを入力します。

    $ oc get pods -n <hcp namespace> -l app=kubevirt-csi-driver
    Copy to Clipboard Toggle word wrap

15.4.7. 仮想マシンノードがクラスターに正しく参加していない

仮想マシンノードがクラスターに正しく参加していないために Hosted Control Plane が完全にオンラインにならない場合は、仮想マシンコンソールログにアクセスします。

手順

15.4.8. RHCOS イメージのミラーリングが失敗する

非接続環境の OpenShift Virtualization 上の Hosted Control Plane の場合、oc-mirror で、Red Hat Enterprise Linux CoreOS (RHCOS) イメージを内部レジストリーに自動的にミラーリングできません。最初のホステッドクラスターを作成するときに、ブートイメージを内部レジストリーで利用できないため、Kubevirt 仮想マシンが起動しません。

この問題を解決するには、RHCOS イメージを手動で内部レジストリーにミラーリングします。

手順

  1. 次のコマンドを実行して内部レジストリー名を取得します。

    $ oc get imagecontentsourcepolicy -o json \
      | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行してペイロードイメージを取得します。

    $ oc get clusterversion version -ojsonpath='{.status.desired.image}'
    Copy to Clipboard Toggle word wrap
  3. ホステッドクラスター上のペイロードイメージからブートイメージを含む 0000_50_installer_coreos-bootimages.yaml ファイルを抽出します。<payload_image> は、ペイロードイメージの名前に置き換えます。以下のコマンドを実行します。

    $ oc image extract \
      --file /release-manifests/0000_50_installer_coreos-bootimages.yaml \
      <payload_image> --confirm
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して RHCOS イメージを取得します。

    $ cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream \
      | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'
    Copy to Clipboard Toggle word wrap
  5. RHCOS イメージを内部レジストリーにミラーリングします。<rhcos_image> は、RHCOS イメージに置き換えます (例: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d9643ead36b1c026be664c9c65c11433c6cdf71bfd93ba229141d134a4a6dd94)。<internal_registry> は、内部レジストリーの名前に置き換えます (例: virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev)。以下のコマンドを実行します。

    $ oc image mirror <rhcos_image> <internal_registry>
    Copy to Clipboard Toggle word wrap
  6. ImageDigestMirrorSet オブジェクトを定義する rhcos-boot-kubevirt.yaml という名前の YAML ファイルを作成します。次の設定例を参照してください。

    apiVersion: config.openshift.io/v1
    kind: ImageDigestMirrorSet
    metadata:
      name: rhcos-boot-kubevirt
    spec:
      repositoryDigestMirrors:
        - mirrors:
            - virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev 
    1
    
          source: quay.io/openshift-release-dev/ocp-v4.0-art-dev 
    2
    Copy to Clipboard Toggle word wrap
    1
    内部レジストリーの名前を指定します (例: virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev)。
    2
    ダイジェストなしで RHCOS イメージを指定します (例: quay.io/openshift-release-dev/ocp-v4.0-art-dev)。
  7. 次のコマンドを実行して、rhcos-boot-kubevirt.yaml ファイルを適用し、ImageDigestMirrorSet オブジェクトを作成します。

    $ oc apply -f rhcos-boot-kubevirt.yaml
    Copy to Clipboard Toggle word wrap

15.4.9. 非ベアメタルクラスターを遅延バインディングプールに戻す

BareMetalHosts なしで遅延バインディングマネージドクラスターを使用している場合は、遅延バインディングクラスターを削除し、ノードを Discovery ISO に戻すための追加の手動手順を実行する必要があります。

BareMetalHosts のない遅延バインディングマネージドクラスターの場合、クラスター情報を削除しても、すべてのノードが自動的に Discovery ISO に戻されるわけではありません。

手順

遅延バインディングを使用する非ベアメタルノードのバインドを解除するには、次の手順を実行します。

  1. クラスター情報を削除します。詳細は、マネージメントからのクラスターの削除 を参照してください。
  2. ルートディスクをクリーンアップします。
  3. Discovery ISO を使用して手動で再起動します。

15.5. ベアメタル上のホステッドクラスターのトラブルシューティング

以下の情報は、ベアメタル上の Hosted Control Plane のトラブルシューティングに適用されます。

15.5.1. ベアメタル上の Hosted Control Plane にノードを追加できない

Assisted Installer を使用してプロビジョニングされたノードが含まれる Hosted Control Plane クラスターをスケールアップすると、ホストはポート 22642 が含まれる URL を使用して Ignition をプルできません。この URL は Hosted Control Plane では無効であり、クラスターに問題があることを示しています。

手順

  1. 問題を特定するには、assisted-service ログを確認します。

    $ oc logs -n multicluster-engine <assisted_service_pod_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    Assisted Service Pod の名前を指定します。
  2. ログで、次の例に似たエラーを見つけます。

    error="failed to get pull secret for update: invalid pull secret data in secret pull-secret"
    Copy to Clipboard Toggle word wrap
    pull secret must contain auth for \"registry.redhat.io\"
    Copy to Clipboard Toggle word wrap
  3. この問題を解決するには、multicluster engine for Kubernetes Operator のドキュメントの「プルシークレットを namespace に追加する」を参照してください。

    注記

    Hosted Control Plane を使用するには、スタンドアロン Operator として、または Red Hat Advanced Cluster Management の一部として、multicluster engine Operator がインストールされている必要があります。この Operator は Red Hat Advanced Cluster Management と密接な関係があるため、この Operator のドキュメントはこの製品のドキュメント内で公開されています。Red Hat Advanced Cluster Management を使用していない場合でも、ドキュメントの multicluster engine Operator について説明している部分は Hosted Control Plane に関連します。

15.6. Hosted Control Plane コンポーネントの再起動

Hosted Control Plane の管理者の場合は、hypershift.openshift.io/restart-date アノテーションを使用して、特定の HostedCluster リソースのすべてのコントロールプレーンコンポーネントを再起動できます。たとえば、証明書のローテーション用にコントロールプレーンコンポーネントを再起動する必要がある場合があります。

手順

  • コントロールプレーンを再起動するには、次のコマンドを入力して HostedCluster リソースにアノテーションを付けます。

    $ oc annotate hostedcluster \
      -n <hosted_cluster_namespace> \
      <hosted_cluster_name> \
      hypershift.openshift.io/restart-date=$(date --iso-8601=seconds) 
    1
    Copy to Clipboard Toggle word wrap
    1
    アノテーションの値が変わるたびに、コントロールプレーンが再起動されます。date コマンドは、一意の文字列のソースとして機能します。アノテーションはタイムスタンプではなく文字列として扱われます。

検証

コントロールプレーンを再起動すると、通常、次の Hosted Control Plane コンポーネントが再起動します。

注記

他のコンポーネントによって変更が実装されることに伴い、さらにいくつかのコンポーネントが再起動する場合があります。

  • catalog-operator
  • certified-operators-catalog
  • cluster-api
  • cluster-autoscaler
  • cluster-policy-controller
  • cluster-version-operator
  • community-operators-catalog
  • control-plane-operator
  • hosted-cluster-config-operator
  • ignition-server
  • ingress-operator
  • konnectivity-agent
  • konnectivity-server
  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler
  • machine-approver
  • oauth-openshift
  • olm-operator
  • openshift-apiserver
  • openshift-controller-manager
  • openshift-oauth-apiserver
  • packageserver
  • redhat-marketplace-catalog
  • redhat-operators-catalog

15.7. ホステッドクラスターと Hosted Control Plane のリコンシリエーションの一時停止

クラスターインスタンス管理者は、ホステッドクラスターと Hosted Control Plane のリコンシリエーションを一時停止できます。etcd データベースをバックアップおよび復元するときや、ホステッドクラスターまたは Hosted Control Plane の問題をデバッグする必要があるときは、リコンシリエーションを一時停止することができます。

手順

  1. ホステッドクラスターと Hosted Control Plane のリコンシリエーションを一時停止するには、HostedCluster リソースの pausedUntil フィールドを設定します。

    • 特定の時刻までリコンシリエーションを一時停止するには、次のコマンドを入力します。

      $ oc patch -n <hosted_cluster_namespace> \
        hostedclusters/<hosted_cluster_name> \
        -p '{"spec":{"pausedUntil":"<timestamp>"}}' \
        --type=merge 
      1
      Copy to Clipboard Toggle word wrap
      1
      RFC339 形式でタイムスタンプを指定します (例: 2024-03-03T03:28:48Z)。指定の時間が経過するまで、リコンシリエーションが一時停止します。
    • リコンシリエーションを無期限に一時停止するには、次のコマンドを入力します。

      $ oc patch -n <hosted_cluster_namespace> \
        hostedclusters/<hosted_cluster_name> \
        -p '{"spec":{"pausedUntil":"true"}}' \
        --type=merge
      Copy to Clipboard Toggle word wrap

      HostedCluster リソースからフィールドを削除するまで、リコンシリエーションは一時停止されます。

      HostedCluster リソースの一時停止リコンシリエーションフィールドが設定されると、そのフィールドは関連付けられた HostedControlPlane リソースに自動的に追加されます。

  2. pausedUntil フィールドを削除するには、次の patch コマンドを入力します。

    $ oc patch -n <hosted_cluster_namespace> \
      hostedclusters/<hosted_cluster_name> \
      -p '{"spec":{"pausedUntil":null}}' \
      --type=merge
    Copy to Clipboard Toggle word wrap

15.8. データプレーンをゼロにスケールダウンする

Hosted Control Plane を使用していない場合は、リソースとコストを節約するために、データプレーンをゼロにスケールダウンできます。

注記

データプレーンをゼロにスケールダウンする準備ができていることを確認してください。スケールダウンするとワーカーノードからのワークロードがなくなるためです。

手順

  1. 次のコマンドを実行して、ホステッドクラスターにアクセスするように kubeconfig ファイルを設定します。

    $ export KUBECONFIG=<install_directory>/auth/kubeconfig
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、ホステッドクラスターに関連付けられた NodePool リソースの名前を取得します。

    $ oc get nodepool --namespace <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  3. オプション: Pod のドレインを防止するには、次のコマンドを実行して、NodePool リソースに nodeDrainTimeout フィールドを追加します。

    $ oc edit nodepool <nodepool_name>  --namespace <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: hypershift.openshift.io/v1alpha1
    kind: NodePool
    metadata:
    # ...
      name: nodepool-1
      namespace: clusters
    # ...
    spec:
      arch: amd64
      clusterName: clustername 
    1
    
      management:
        autoRepair: false
        replace:
          rollingUpdate:
            maxSurge: 1
            maxUnavailable: 0
          strategy: RollingUpdate
        upgradeType: Replace
      nodeDrainTimeout: 0s 
    2
    
    # ...
    Copy to Clipboard Toggle word wrap

    1
    ホステッドクラスターの名前を定義します。
    2
    コントローラーがノードをドレインするのに費やす合計時間を指定します。デフォルトでは、nodeDrainTimeout: 0s 設定はノードドレインプロセスをブロックします。
    注記

    ノードドレインプロセスを一定期間継続できるようにするには、それに応じて、nodeDrainTimeout フィールドの値を設定できます (例: nodeDrainTimeout: 1m)。

  4. 次のコマンドを実行して、ホステッドクラスターに関連付けられた NodePool リソースをスケールダウンします。

    $ oc scale nodepool/<nodepool_name> --namespace <hosted_cluster_namespace> \
      --replicas=0
    Copy to Clipboard Toggle word wrap
    注記

    データプランをゼロにスケールダウンした後、コントロールプレーン内の一部の Pod は Pending ステータスのままになり、ホストされているコントロールプレーンは稼働したままになります。必要に応じて、NodePool リソースをスケールアップできます。

  5. オプション: 次のコマンドを実行して、ホステッドクラスターに関連付けられた NodePool リソースをスケールアップします。

    $ oc scale nodepool/<nodepool_name> --namespace <hosted_cluster_namespace> --replicas=1
    Copy to Clipboard Toggle word wrap

    NodePool リソースを再スケーリングした後、NodePool リソースが準備 Ready 状態で使用可能になるまで数分間待ちます。

検証

  • 次のコマンドを実行して、nodeDrainTimeout フィールドの値が 0s より大きいことを確認します。

    $ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -ojsonpath='{.spec.nodeDrainTimeout}'
    Copy to Clipboard Toggle word wrap

15.9. エージェントサービスの障害とエージェントがクラスターに参加しない問題

場合によっては、ブートアーティファクトを使用してマシンを起動した後、エージェントがクラスターに参加できないことがあります。この問題を確認するには、agent.service ログで次のエラーを確認します。

Error: copying system image from manifest list: Source image rejected: A signature was required, but no signature exists
Copy to Clipboard Toggle word wrap
注記

この問題は、署名が存在しない場合にイメージ署名の検証が失敗するために発生します。回避策として、コンテナーポリシーを変更して署名の検証を無効にできます。

手順

  1. /etc/containers/policy.json ファイルをオーバーライドするには、InfraEnv マニフェストに ignitionConfigOverride フィールドを追加します。これにより、コンテナーイメージの署名検証が無効になります。
  2. ignitionConfigOverride 内の base64 でエンコードされたコンテンツを、イメージレジストリーに応じて、必要な /etc/containers/policy.json 設定に置き換えます。

    {
        "default": [
            {
                "type": "insecureAcceptAnything"
            }
        ],
        "transports": {
            "docker": {
                "<REGISTRY1>": [
                    {
                        "type": "insecureAcceptAnything"
                    }
                ],
                "REGISTRY2": [
                    {
                        "type": "insecureAcceptAnything"
                    }
                ]
            },
            "docker-daemon": {
                "": [
                    {
                        "type": "insecureAcceptAnything"
                    }
                ]
            }
        }
    }
    Copy to Clipboard Toggle word wrap

    ignitionConfigOverride を含む InfraEnv マニフェストの例

    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: <hosted_cluster_name>
      namespace: <hosted_control_plane_namespace>
    spec:
      cpuArchitecture: s390x
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: <ssh_public_key>
      ignitionConfigOverride: '{"ignition":{"version":"3.2.0"},"storage":{"files":[{"path":"/etc/containers/policy.json","mode":420,"overwrite":true,"contents":{"source":"data:text/plain;charset=utf-8;base64,ewogICAgImRlZmF1bHQiOiBbCiAgICAgICAgewogICAgICAgICAgICAidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIgogICAgICAgIH0KICAgIF0sCiAgICAidHJhbnNwb3J0cyI6CiAgICAgICAgewogICAgICAgICAgICAiZG9ja2VyLWRhZW1vbiI6CiAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIiI6IFt7InR5cGUiOiJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dCiAgICAgICAgICAgICAgICB9CiAgICAgICAgfQp9"}}]}}'
    Copy to Clipboard Toggle word wrap

第16章 ホステッドクラスターの破棄

16.1. AWS 上のホステッドクラスターの破棄

コマンドラインインターフェイス (CLI) を使用して、Amazon Web Services (AWS) 上のホステッドクラスターとそのマネージドクラスターリソースを破棄できます。

16.1.1. CLI を使用した AWS 上のホステッドクラスターの破棄

コマンドラインインターフェイス (CLI) を使用して、Amazon Web Services (AWS) 上のホステッドクラスターを破棄できます。

手順

  1. 次のコマンドを実行して、multicluster engine Operator のマネージドクラスターリソースを削除します。

    $ oc delete managedcluster <hosted_cluster_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、クラスターの名前に置き換えます。
  2. 次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。

    $ hcp destroy cluster aws  \
      --name <hosted_cluster_name> \
    1
    
      --infra-id <infra_id> \
    2
    
      --role-arn <arn_role> \
    3
    
      --sts-creds <path_to_sts_credential_file> \
    4
    
      --base-domain <basedomain> 
    5
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ホステッドクラスターのインフラストラクチャー名を指定します。
    3
    Amazon Resource Name (ARN) を指定します (例: arn:aws:iam::820196288204:role/myrole)。
    4
    AWS Security Token Service (STS) 認証情報ファイルへのパスを指定します (例: /home/user/sts-creds/sts-creds.json)。
    5
    ベースドメインを指定します (例: example.com)。
    重要

    AWS Security Token Service (STS) のセッショントークンの有効期限が切れている場合は、次のコマンドを実行して、sts-creds.json という名前の JSON ファイルで STS 認証情報を取得してください。

    $ aws sts get-session-token --output json > sts-creds.json
    Copy to Clipboard Toggle word wrap

16.2. ベアメタル上のホステッドクラスターの破棄

コマンドラインインターフェイス (CLI) または multicluster engine Operator の Web コンソールを使用して、ベアメタル上のホステッドクラスターを破棄できます。

16.2.1. CLI を使用したベアメタル上のホステッドクラスターの破棄

コマンドラインインターフェイス (CLI) を使用してホステッドクラスターを作成した場合は、コマンドを実行して、そのホステッドクラスターとそのバックエンドリソースを破棄できます。

手順

  • 次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。

    $ oc delete -f <hosted_cluster_config>.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    ホステッドクラスターを作成したときにレンダリングされた設定 YAML ファイルの名前を指定します。
    注記

    設定ファイルで --render および --render-sensitive フラグを指定せずにホステッドクラスターを作成した場合は、バックエンドリソースを手動で削除する必要があります。

16.2.2. Web コンソールを使用したベアメタル上のホステッドクラスターの破棄

multicluster engine Operator の Web コンソールを使用して、ベアメタル上のホステッドクラスターを破棄できます。

手順

  1. コンソールで、InfrastructureClusters をクリックします。
  2. Clusters ページで、破棄するクラスターを選択します。
  3. Actions メニューで Destroy clusters を選択し、クラスターを削除します。

16.3. OpenShift Virtualization 上のホステッドクラスターの破棄

コマンドラインインターフェイス (CLI) を使用して、OpenShift Virtualization 上のホステッドクラスターとそのマネージドクラスターリソースを破棄できます。

16.3.1. CLI を使用した OpenShift Virtualization 上のホステッドクラスターの破棄

コマンドラインインターフェイス (CLI) を使用して、OpenShift Virtualization 上のホステッドクラスターとそのマネージドクラスターリソースを破棄できます。

手順

  1. 次のコマンドを実行して、multicluster engine Operator のマネージドクラスターリソースを削除します。

    $ oc delete managedcluster <hosted_cluster_name>
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。

    $ hcp destroy cluster kubevirt --name <hosted_cluster_name>
    Copy to Clipboard Toggle word wrap

16.4. IBM Z 上のホステッドクラスターの破棄

コマンドラインインターフェイス (CLI) を使用して、IBM Z コンピュートノードを含む x86 ベアメタル上のホステッドクラスターとそのマネージドクラスターリソースを破棄できます。

16.4.1. IBM Z コンピュートノードを含む x86 ベアメタル上のホステッドクラスターの破棄

IBM Z® コンピュートノードを含む x86 ベアメタル上のホステッドクラスターとそのマネージドクラスターを破棄するには、コマンドラインインターフェイス (CLI) を使用できます。

手順

  1. 次のコマンドを実行して、NodePool オブジェクトを 0 ノードにスケーリングします。

    $ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> \
      --replicas 0
    Copy to Clipboard Toggle word wrap

    NodePool オブジェクトを 0 にスケーリングすると、コンピュートノードがホステッドクラスターからデタッチされます。OpenShift Container Platform バージョン 4.17 では、この機能は KVM を使用する IBM Z にのみ適用されます。z/VM および LPAR の場合は、コンピュートノードを手動で削除する必要があります。

    コンピュートノードをクラスターに再アタッチする場合は、必要なコンピュートノードの数を指定して NodePool オブジェクトをスケールアップできます。z/VM および LPAR の場合、エージェントを再利用するには、Discovery イメージを使用してエージェントを再作成する必要があります。

    重要

    コンピュートノードがホステッドクラスターからデタッチされていない場合、または Notready 状態のままになっている場合は、次のコマンドを実行してコンピュートノードを手動で削除します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig delete \
      node <compute_node_name>
    Copy to Clipboard Toggle word wrap

    プロセッサーリソース/システムマネージャー (PR/SM) モードで OSA ネットワークデバイスを使用している場合、自動スケーリングはサポートされません。新しいエージェントはスケールダウンプロセス中に結合されるため、古いエージェントを手動で削除し、ノードプールをスケールアップする必要があります。

  2. 次のコマンドを入力して、コンピュートノードのステータスを確認します。

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    コンピュートノードがホステッドクラスターからデタッチされると、エージェントのステータスは auto-assign に変更されます。

  3. 次のコマンドを実行して、クラスターからエージェントを削除します。

    $ oc -n <hosted_control_plane_namespace> delete agent <agent_name>
    Copy to Clipboard Toggle word wrap
    注記

    クラスターからエージェントを削除した後、エージェントとして作成した仮想マシンを削除できます。

  4. 次のコマンドを実行して、ホステッドクラスターを破棄します。

    $ hcp destroy cluster agent --name <hosted_cluster_name> \
      --namespace <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

16.5. IBM Power 上のホステッドクラスターの破棄

コマンドラインインターフェイス (CLI) を使用して、IBM Power 上のホステッドクラスターを破棄できます。

16.5.1. CLI を使用した IBM Power 上のホステッドクラスターの破棄

IBM Power 上のホステッドクラスターを破棄するには、hcp コマンドラインインターフェイス (CLI) を使用できます。

手順

  • 次のコマンドを実行して、ホステッドクラスターを削除します。

    $ hcp destroy cluster agent
     --name=<hosted_cluster_name> \
    1
    
     --namespace=<hosted_cluster_namespace> \
    2
    
     --cluster-grace-period <duration> 
    3
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    3
    ホステッドクラスターを完全に破棄するまでの期間を指定します (例: 20m0s)。

16.6. OpenStack 上の Hosted Control Plane の破棄

16.6.1. CLI を使用したホステッドクラスターの破棄

hcp CLI ツールを使用して、Red Hat OpenStack Platform (RHOSP) 上のホステッドクラスターとその関連リソースを破棄できます。

前提条件

  • Hosted Control Plane の CLI である hcp がインストールされている。

手順

  • クラスターとそれに関連付けられたリソースを破棄するには、次のコマンドを実行します。

    $ hcp destroy cluster openstack --name=<cluster_name>
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <cluster_name>
    ホステッドクラスターの名前です。

    プロセスが完了すると、すべてのクラスターとそれに関連付けられているすべてのリソースが破棄されます。

16.7. 非ベアメタルエージェントマシン上のホステッドクラスターの破棄

コマンドラインインターフェイス (CLI) または multicluster engine Operator の Web コンソールを使用して、非ベアメタルエージェントマシン上のホステッドクラスターを破棄できます。

16.7.1. 非ベアメタルエージェントマシン上のホステッドクラスターの破棄

hcp コマンドラインインターフェイス (CLI) を使用して、非ベアメタルエージェントマシン上のホステッドクラスターを破棄できます。

手順

  • 次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。

    $ hcp destroy cluster agent --name <hosted_cluster_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。

multicluster engine Operator の Web コンソールを使用して、非ベアメタルエージェントマシン上のホステッドクラスターを破棄できます。

手順

  1. コンソールで、InfrastructureClusters をクリックします。
  2. Clusters ページで、破棄するクラスターを選択します。
  3. Actions メニューで Destroy clusters を選択し、クラスターを削除します。

第17章 ホステッドクラスターの手動インポート

ホステッドクラスターは、Hosted Control Plane が使用可能になった後、multicluster engine Operator に自動的にインポートされます。

17.1. インポートされたホステッドクラスターの管理の制限

ホステッドクラスターは、スタンドアロンの OpenShift Container Platform やサードパーティーのクラスターとは異なり、multicluster engine for Kubernetes Operator に自動的にインポートされます。ホステッドクラスターは、エージェントがクラスターのリソースを使用しないように、一部のエージェントを ホステッドモード で実行します。

ホステッドクラスターを自動的にインポートした場合は、管理クラスターの HostedCluster リソースを使用して、ホステッドクラスター内のノードプールとコントロールプレーンを更新できます。ノードプールとコントロールプレーンを更新するには、「ホステッドクラスターのノードプールの更新」と「ホステッドクラスターのコントロールプレーンの更新」を参照してください。

Red Hat Advanced Cluster Management (RHACM) を使用すると、ホステッドクラスターをローカルの multicluster engine Operator 以外の場所にインポートできます。詳細は、「Red Hat Advanced Cluster Management での multicluster engine for Kubernetes Operator ホステッドクラスターの検出」を参照してください。

このトポロジーでは、クラスターがホストされている multicluster engine for Kubernetes Operator のコマンドラインインターフェイスまたはコンソールを使用して、ホステッドクラスターを更新する必要があります。RHACM ハブクラスターを介してホステッドクラスターを更新することはできません。

17.3. ホステッドクラスターの手動インポート

ホステッドクラスターを手動でインポートする場合は、次の手順を実行します。

手順

  1. InfrastructureClusters をクリックし、インポートするホステッドクラスターを選択します。
  2. Import hosted cluster をクリックします。

    注記

    検出された ホステッドクラスターは、コンソールからインポートすることもできます。ただし、そのクラスターがアップグレード可能な状態である必要があります。Hosted Control Plane を使用できないため、ホステッドクラスターがアップグレード可能な状態ではない場合、クラスターへのインポートは無効になります。Import をクリックして、プロセスを開始します。クラスターが更新を受信している間、ステータスは Importing であり、その後、Ready に変わります。

17.4. AWS へのホステッドクラスターの手動インポート

コマンドラインインターフェイスを使用して、Amazon Web Services (AWS) にホステッドクラスターをインポートすることもできます。

手順

  1. 以下のサンプル YAML ファイルを使用して、ManagedCluster リソースを作成します。

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      annotations:
        import.open-cluster-management.io/hosting-cluster-name: local-cluster
        import.open-cluster-management.io/klusterlet-deploy-mode: Hosted
        open-cluster-management/created-via: hypershift
      labels:
        cloud: auto-detect
        cluster.open-cluster-management.io/clusterset: default
        name: <hosted_cluster_name> 
    1
    
        vendor: OpenShift
      name: <hosted_cluster_name>
    spec:
      hubAcceptsClient: true
      leaseDurationSeconds: 60
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
  2. 以下のコマンドを実行してリソースを適用します。

    $ oc apply -f <file_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <file_name> は、前のステップで作成した YAML ファイル名に置き換えます。
  3. Red Hat Advanced Cluster Management がインストールされている場合は、次のサンプル YAML ファイルを使用して KlusterletAddonConfig リソースを作成します。multicluster engine Operator のみをインストールした場合は、この手順を省略します。

    apiVersion: agent.open-cluster-management.io/v1
    kind: KlusterletAddonConfig
    metadata:
      name: <hosted_cluster_name> 
    1
    
      namespace: <hosted_cluster_namespace> 
    2
    
    spec:
      clusterName: <hosted_cluster_name>
      clusterNamespace: <hosted_cluster_namespace>
      clusterLabels:
        cloud: auto-detect
        vendor: auto-detect
      applicationManager:
        enabled: true
      certPolicyController:
        enabled: true
      iamPolicyController:
        enabled: true
      policyController:
        enabled: true
      searchCollector:
        enabled: false
    Copy to Clipboard Toggle word wrap
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    2
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
  4. 以下のコマンドを実行してリソースを適用します。

    $ oc apply -f <file_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <file_name> は、前のステップで作成した YAML ファイル名に置き換えます。
  5. インポートプロセスが完了すると、ホステッドクラスターがコンソールに表示されます。以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。

    $ oc get managedcluster <hosted_cluster_name>
    Copy to Clipboard Toggle word wrap

17.5. multicluster engine Operator へのホステッドクラスターの自動インポートの無効化

ホステッドクラスターは、コントロールプレーンが使用可能になった後、multicluster engine Operator に自動的にインポートされます。必要に応じて、ホステッドクラスターの自動インポートを無効にすることができます。

自動インポートを無効にしても、以前にインポートされたホステッドクラスターは影響を受けません。multicluster engine Operator 2.5 にアップグレードし、自動インポートが有効になっている場合、コントロールプレーンが使用可能な場合、インポートされていないすべてのホステッドクラスターが自動的にインポートされます。

注記

Red Hat Advanced Cluster Management がインストールされている場合は、すべての Red Hat Advanced Cluster Management アドオンも有効になります。

自動インポートが無効になっている場合、新しく作成されたホステッドクラスターのみが自動的にインポートされません。すでにインポートされているホステッドクラスターは影響を受けません。コンソールを使用するか、ManagedCluster および KlusterletAddonConfig カスタムリソースを作成することにより、クラスターを手動でインポートすることもできます。

手順

ホステッドクラスターの自動インポートを無効にするには、次の手順を実行します。

  1. ハブクラスターで、次のコマンドを入力して、multicluster engine Operator がインストールされている namespace の AddonDeploymentConfig リソースにある hypershift-addon-deploy-config 仕様を開きます。

    $ oc edit addondeploymentconfig hypershift-addon-deploy-config \
      -n multicluster-engine
    Copy to Clipboard Toggle word wrap
  2. 次の例に示すように、spec.customizedVariables セクションで、値が "true"autoImportDisabled 変数を追加します。

    apiVersion: addon.open-cluster-management.io/v1alpha1
    kind: AddOnDeploymentConfig
    metadata:
      name: hypershift-addon-deploy-config
      namespace: multicluster-engine
    spec:
      customizedVariables:
       - name: hcMaxNumber
         value: "80"
      - name: hcThresholdNumber
        value: "60"
      - name: autoImportDisabled
        value: "true"
    Copy to Clipboard Toggle word wrap
  3. 自動インポートを再度有効にするには、autoImportDisabled 変数の値を "false" に設定するか、AddonDeploymentConfig リソースから変数を削除します。

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat