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

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

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

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

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

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

今回のリリースでは、以下の概念に関連する拡張機能が追加されました。

1.1.1.1. Hosted Control Plane と OpenShift Container Platform の比較

OpenShift Container Platform のドキュメントでは、Hosted Control Plane とスタンドアロンの OpenShift Container Platform の違いが強調されています。詳細は、Hosted Control Plane と OpenShift Container Platform の違い を参照してください。

1.1.1.2. Hosted Control Plane のプロキシー設定

Hosted Control Plane のプロキシーサポートを設定する場合と、スタンドアロン OpenShift Container Platform のプロキシーサポートを設定する場合ではいくつかの違いがあります。詳細は、Hosted Control Plane のネットワーク を参照してください。

1.1.1.3. ワーカーノードのデフォルトのコンテナーランタイムは crun です。

OpenShift Container Platform 4.18 以降の Hosted Control Plane では、ワーカーノードのデフォルトのコンテナーランタイムが runC から crun に変更されます。

1.1.2. バグ修正

  • 以前は、プラットフォームパラメーターが agentBareMetal または none に設定された Hosted Control Plane クラスター上で ARM64 アーキテクチャーを使用するノードプールを作成できませんでした。この問題は、AWS または Microsoft Azure プラットフォーム上で実行される Hosted Control Plane クラスターでは発生しませんでした。このリリースでは、修正により、platform が agentBareMetal または none に設定されている Hosted Control Plane クラスターで ARM64 アーキテクチャーを使用するノードプールを作成できるようになりました。(OCPBUGS-48579)
  • 以前は、非接続環境で Hosted Control Plane CLI を使用してクラスターを作成しようとすると、インストールコマンドが失敗していました。コマンドをホストするレジストリーに問題がありました。このリリースでは、コマンドレジストリーが修正され、非接続環境で Hosted Control Plane CLI を使用してクラスターを作成できるようになりました。(OCPBUGS-48170)
  • 以前は、クラスター上の Kubernetes EndpointSlice に誤ったアドレスが渡されていました。この問題により、IPv6 非接続環境のエージェントベースのクラスターに MetalLB Operator をインストールできませんでした。このリリースでは、修正によりアドレス評価方法が変更されます。Red Hat Marketplace Pod はクラスター API サーバーに正常に接続できるようになり、MetalLB Operator のインストールと IPv6 非接続環境での Ingress トラフィックの処理が可能になります。(OCPBUGS-46665)
  • 以前は、エージェントプラットフォーム上の Hosted Control Plane では、NodePool API で ARM64 アーキテクチャーは許可されていませんでした。その結果、異種クラスターをエージェントプラットフォームにデプロイできませんでした。このリリースでは、API により、エージェントプラットフォーム上で ARM64 アーキテクチャーノードプールが許可されます。(OCPBUGS-4673)
  • 以前は、デフォルトの node-monitor-grace-period 値は 50 秒でした。そのためノードは、Kubernetes コンポーネントが再接続し、調整し、リクエストを完了するために必要な時間の間、準備状態を維持できませんでした。このリリースでは、デフォルトの node-monitor-grace-period 値は 55 秒です。これにより問題は解決され、デプロイメントが完了するため二必要な時間が十分に確保されます。(OCPBUGS-46008)
  • 以前は、IBM Cloud Workspace ID が適切に取得されなかったため、IBMPowerVSMachine オブジェクトのプロバイダー ID が適切に入力されませんでした。そのため、ホステッドクラスターですべての証明書署名要求 (CSR) が保留中になりました。このリリースでは、IBMPowerVSMachine オブジェクトのプロバイダー ID が適切に入力されるようになりました。その結果、保留中の CSR はなくなり、すべての CO が利用可能な状態に遷移します。(OCPBUGS-44944)
  • 以前は、クラスター作成者アカウントにプライベート DNS ホストゾーンが存在する共有 VPC を使用してホステッドクラスターを作成すると、プライベートリンクコントローラーがローカルゾーンに route53 DNS レコードを作成できませんでした。このリリースでは、Ingress 共有ロールによってプライベートリンクコントローラーにレコードが追加されます。VPC エンドポイントは、VPC 所有者アカウントで VPC エンドポイントを作成するロールを共有するために使用されます。ホステッドクラスターは、クラスター作成者アカウントにプライベートホストゾーンが存在する共有 VPC 設定で作成されます。(OCPBUGS-44630)
  • 以前は、ホステッドクラスターの controllerAvailabilityPolicy パラメーターが SingleReplica に設定されていた場合、ネットワークコンポーネントの podAntiAffinity ルールによってコンポーネントの可用性がブロックされていました。このリリースにより、この問題は解決されました。(OCPBUGS-39313)
  • 以前は、コアオペレーティングシステムの変更により、Hosted Control Plane の定期的な適合ジョブが失敗していました。この失敗したジョブにより、OpenShift API のデプロイメントが失敗していました。このリリースでは、更新時に 1 つのファイルがコピーされるのではなく、個々の信頼済み認証局 (CA) 証明書が再帰的にコピーされるため、定期的な適合ジョブが成功し、OpenShift API が期待どおりに実行されます。(OCPBUGS-38943)
  • 以前は、AWS または Azure 以外のプラットフォームでは ARM64 アーキテクチャーの NodePool リソースを作成できませんでした。このバグにより検証エラーが発生し、ベアメタルコンピュートノードの追加が妨げられ、NodePool リソースの作成時に CEL 検証ブロックが発生しました。この修正では、"self.platform.type == 'None'" を追加することで NodePool 仕様の検証ルールが変更されます。その結果、AWS や Azure 以外のベアメタルプラットフォームで ARM64 アーキテクチャー仕様の NodePool リソースを作成できるようになり、機能が拡張されました。(OCPBUGS-46440)
  • 以前は、共有 VPC にホステッドクラスターを作成すると、プライベートリンクコントローラーが共有 VPC 内の VPC エンドポイントを管理するための共有 VPC ロールを引き受けられない場合がありました。このリリースでは、プライベートリンクコントローラーでのすべての調整に対してクライアントが作成されるため、無効なクライアントから回復できます。その結果、ホステッドクラスターエンドポイントとホステッドクラスターが正常に作成されます。(OCPBUGS-45184)

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

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

        $ oc get nodes --kubeconfig

      • 次のコマンドを実行して、クラスターにバインドされているエージェント数が 0 と報告されていることを確認します。 

        $ oc get agents -A

  • デュアルスタックネットワークを使用する環境でホステッドクラスターを作成すると、次の DNS 関連の問題が発生する可能性があります。

    • service-ca-operator Pod の CrashLoopBackOff 状態: Pod が Hosted Control Plane 経由で Kubernetes API サーバーに到達しようとすると、kube-system namespace のデータプレーンプロキシーがリクエストを解決できないため、Pod はサーバーに到達できません。この問題は、HAProxy セットアップでフロントエンドが IP アドレスを使用し、バックエンドが Pod が解決できない DNS 名を使用するために発生します。
    • Pod が ContainerCreating 状態でスタックします。この問題は、DNS Pod が DNS 解決で必要とする metrics-tls シークレットを openshift-service-ca-operator リソースが生成できないために発生します。その結果、Pod は Kubernetes API サーバーを解決できません。これらの問題を解決するには、デュアルスタックネットワークの DNS サーバー設定を行います。
  • エージェントプラットフォームでは、Hosted Control Plane 機能により、エージェントがイグニションのプルに使用するトークンが定期的にローテーションされます。その結果、少し前に作成されたエージェントリソースがある場合、Ignition のプルに失敗する可能性があります。回避策として、エージェント仕様で IgnitionEndpointTokenReference プロパティーのシークレットを削除し、その後にエージェントリソースのラベルを追加または変更します。システムは新しいトークンを使用してシークレットを再作成します。

  • ホステッドクラスターをそのマネージドクラスターと同じ 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 を指定する必要があります。

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

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

重要

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

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

Amazon Web Services (AWS) 上の OpenShift Container Platform の Hosted Control Plane

一般提供

一般提供

一般提供

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

テクノロジープレビュー

一般提供

一般提供

ベアメタル上の OpenShift Container Platform の Hosted Control Plane

一般提供

一般提供

一般提供

OpenShift Virtualization 上の OpenShift Container Platform の Hosted Control Plane

一般提供

一般提供

一般提供

非ベアメタルエージェントマシンを使用した 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, Inc.