第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)
  • 以前は、エージェントプラットフォーム上の NodePool API では ARM64 アーキテクチャーは許可されていませんでした。その結果、エージェントプラットフォーム上に異種クラスターをデプロイできませんでした。このリリースでは、API により、エージェントプラットフォーム上で ARM64 ベースの NodePool リソースが許可されます。(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 のコンソールを介してエージェントプラットフォーム上にホステッドクラスターを作成した場合。
    • ホステッドクラスターの 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 以前では、ベアメタルエージェントプラットフォーム上にホステッドクラスターを作成し、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

開発者プレビュー

開発者プレビュー

テクノロジープレビュー

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat