リリースノート

このリリースにより、外部の OpenID Connect (OIDC) アイデンティティープロバイダーとの直接統合を有効にして、認証用のトークンを発行できるようになりました。これにより、組み込みの OAuth サーバーがバイパスされ、外部アイデンティティープロバイダーが直接使用されます。

外部 OIDC プロバイダーと直接統合することで、組み込みの OAuth サーバーの機能に制限されることなく、お好みの OIDC プロバイダーの高度な機能を活用できます。組織は単一のインターフェイスからユーザーとグループを管理できるだけでなく、複数のクラスターやハイブリッド環境全体での認証を合理化できます。既存のツールやソリューションと統合することもできます。

直接認証はテクノロジープレビュー機能として利用できます。

詳細は、外部 OIDC アイデンティティープロバイダーによる直接認証の有効化 を参照してください。

OpenShift Container Platform 4.19 では、アップストリーム Kubernetes の動作に合わせて、ServiceAccountTokenNodeBinding 機能がデフォルトで有効になっています。この機能により、既存のバインディングオプションに加えて、サービスアカウントトークンをノードオブジェクトに直接バインドできるようになります。この変更の利点には、バインドされたノードが削除されたときにトークンが自動的に無効化されることによるセキュリティーの強化や、異なるノード間でのトークンリプレイ攻撃に対する保護の強化などがあります。

このリリースには、OpenShift Container Platform の etcd に関する既存のドキュメントをすべて統合した etcd セクションが含まれています。詳細は、etcd の概要 を参照してください。

OpenShift Container Platform 4.19 には、以前のリリースの スタートガイド に代わる チュートリアル ガイドが含まれるようになりました。既存のチュートリアルが更新され、このガイドは実践的なチュートリアルコンテンツのみに焦点を当てるようになりました。また、このガイドは、Red Hat 全体で推奨されている OpenShift Container Platform の実践的な学習リソースへの導入部としても役立ちます。

詳細は、チュートリアル を参照してください。

PolicyGenerator リソースと Red Hat Advanced Cluster Management (RHACM) を使用して、GitOps ZTP でマネージドクラスターのポリシーをデプロイできるようになりました。PolicyGenerator API は Open Cluster Management 標準の一部であり、PolicyGenTemplate API では不可能な、リソースにパッチを適用する一般的な方法を提供します。PolicyGenTemplate リソースを使用してポリシーを管理およびデプロイすることは、今後の OpenShift Container Platform リリースでは非推奨になります。

詳細は、PolicyGenerator リソースを使用したマネージドクラスターポリシーの設定 を参照してください。

クラスターのインフラストラクチャーコストを削減しながら高可用性 (HA) を維持するために、2 つのコントロールプレーンノードと 1 つのローカルアービターノードを使用して、OpenShift Container Platform クラスターを設定できます。この設定は、ベアメタルのインストールの場合にのみサポートされます。

ローカルアービターノードは、コントロールプレーンのクォーラム決定に参加する低コストの共存マシンです。標準のコントロールプレーンノードとは異なり、アービターノードはコントロールプレーンサービスの完全なセットを実行しません。この設定を使用すると、3 つのコントロールプレーンノードではなく 2 つの完全にプロビジョニングされたコントロールプレーンノードのみを使用して、クラスター内の HA を維持できます。

この機能を有効にするには、install-config.yaml ファイルでアービターマシンプールを定義し、TechPreviewNoUpgrade 機能セットを有効にする必要があります。

ローカルアービターノードの設定は、テクノロジープレビュー機能として利用できます。詳細は、ローカルアービターノードの設定 を参照してください。

このリリースにより、ZTP リファレンスに再起動ポリシーが追加されました。このポリシーは Topology Aware Lifecycle Manager (TALM) によって適用され、遅延チューニング変更などの設定変更で再起動が必要な場合に、スポーククラスターのフリート全体で再起動を調整します。再起動ポリシーが適用されると、TALM は選択したクラスター上の対象の MachineConfigPool オブジェクト内のすべてのノードを再起動します。

個々の変更ごとにノードを再起動する代わりに、ポリシーを通じてすべての設定の更新を適用してから、単一の調整された再起動をトリガーできます。

詳細は、設定変更のための再起動の調整 を参照してください。

このリリースにより、拡張機能をインストールしようとすると、Operator Controller がインストールプロセスのドライランを実行します。このドライランは、指定されたサービスアカウントに、バンドルによって定義されたロールとバインディングに必要なロールベースアクセス制御 (RBAC) ルールがあるか確認します。

サービスアカウントに必要な RBAC ルールがない場合、実際のインストールが続行される前に事前チェックが失敗し、レポートが生成されます。

詳細は、クラスター拡張機能のパーミッション事前チェック (テクノロジープレビュー) を参照してください。

このリリースにより、registry+v1 Operator バンドルのテクノロジープレビュー機能として、OwnNamespace または SingleNamespace インストールモードを使用し、特定の namespace に拡張機能をデプロイできます。

詳細は、特定の namespace でのクラスター拡張機能のデプロイ (テクノロジープレビュー) を参照してください。

このリリースにより、ノードの起動時に定義される静的にスライスされた GPU に依存するのではなく、Dynamic Accelerator Slicer (DAS) Operator を使用して OpenShift Container Platform で GPU アクセラレーターを動的にスライスすることができます。これにより、特定のワークロードの需要に基づき GPU を動的にスライスし、効率的なリソース利用を実現できます。

詳細は、Dynamic Accelerator Slicer (DAS) Operator を参照してください。

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

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

OpenShift Container Platform 4.18 では、Insights Operator に、Red Hat がコンテナーのワークロードをより適切に理解できるようにするためのテクノロジープレビュー機能として Insights Runtime Extractor ワークロードデータ収集機能が導入されました。現在、バージョン 4.19 では、この機能が一般提供されています。Insights Runtime Extractor 機能は、ランタイムワークロードデータを収集し、Red Hat に送信します。

OpenShift Container Platform 4.19 では、インストールプログラムは、IBM Cloud へのインストール中にクラスターインフラストラクチャーをプロビジョニングするために、Terraform ではなく Cluster API を使用します。

このリリースにより、暗号化された仮想ネットワークを使用して Azure にクラスターをインストールできるようになりました。premiumIO パラメーターが true に設定されている Azure 仮想マシンを使用する必要があります。詳細は、Microsoft のドキュメント Creating a virtual network with encryption および Requirements and Limitations を参照してください。

OpenShift Container Platform クラスターを Amazon Web Services (AWS) のマレーシア (ap-southeast-5) およびタイ (ap-southeast-7) リージョンにインストールできるようになりました。

詳細は、サポートされている Amazon Web Services (AWS) リージョン を参照してください。

OpenShift Container Platform 4.19 では、インストールプログラムは、Microsoft Azure Stack Hub での installer-provisioned infrastructure インストール中に、Terraform ではなく Cluster API を使用してクラスターをプロビジョニングします。

64 ビット x86 アーキテクチャーに基づくマシンタイプ向けの追加の Microsoft Azure インスタンスタイプが、OpenShift Container Platform 4.19 でテストされました。

Dxv6 マシンシリーズでは、次のインスタンスタイプがテストされています。

Lsv4 および Lasv4 マシンシリーズでは、次のインスタンスタイプがテストされています。

ND および NV マシンシリーズでは、次のインスタンスタイプがテストされています。

詳細は、Azure のテスト済みインスタンスタイプ および Azure のドキュメント (Microsoft ドキュメント) を参照してください。

2025 年 9 月 30 日に、Microsoft Azure のすべての新しい仮想マシン (VM) のデフォルトの送信アクセス接続が廃止されます。セキュリティーを強化するために、Azure はデフォルトでセキュアなモデルへ移行しており、インターネットへのデフォルトの送信アクセスが無効化される予定です。ただし、OpenShift Container Platform の設定変更は必要ありません。デフォルトでは、インストールプログラムはロードバランサーの送信ルールを作成します。

詳細は、Azure Updates (Microsoft ドキュメント)、Azure’s outbound connectivity methods (Microsoft ドキュメント)、および Azure にクラスターをインストールするための準備 を参照してください。

このリリースにより、Google Cloud で追加の Confidential Computing プラットフォームを使用できるようになります。インストール前に install-config.yaml ファイルで有効にしたり、マシンセットおよびコントロールプレーンマシンセットを使用してインストール後に設定したりできる、サポートされる新しいプラットフォームは次のとおりです。

詳細は、Google Cloud のインストール設定パラメーター、マシンセットを使用した Confidential 仮想マシンの設定 (コントロールプレーン)、および マシンセットを使用した Confidential 仮想マシンの設定 (コンピュート) を参照してください。

このリリースにより、デフォルトの cluster-provisioned DNS ソリューションの代わりに、user-provisioned ドメインネームサーバー (DNS) を有効にできます。たとえば、組織のセキュリティーポリシーにより、Google Cloud DNS などのパブリック DNS サービスの使用が許可されていない場合があります。API サーバーと Ingress サーバーの IP アドレスに対してのみ DNS を管理できます。この機能を使用する場合は、api.<cluster_name>.<base_domain>. および *.apps.<cluster_name>.<base_domain>. のレコードを含む独自の DNS ソリューションを提供する必要があります。user-provisioned DNS の有効化は、テクノロジープレビュー機能として利用できます。

詳細は、ユーザー管理 DNS の有効化 を参照してください。

このリリースにより、テクノロジープレビュー機能として、複数のストレージディスクを備えた VMware vSphere にクラスターをインストールできます。これらの追加ディスクを、etcd ストレージなどのクラスター内の特別な機能に割り当てることができます。

詳細は、オプションの vSphere 設定パラメーター を参照してください。

このリリースにより、Microsoft Azure にクラスターをインストールするときに、ブート診断の収集を有効にできます。ブート診断は、仮想マシンブート障害を特定するための Azure 仮想マシン (VM) のデバッグ機能です。コンピュートマシン、コントロールプレーンマシン、またはすべてのマシンの install-config.yaml ファイルで bootDiagnostics パラメーターを設定できます。

詳細は、追加の Azure 設定パラメーター を参照してください。

OpenShift Container Platform 4.19 は Kubernetes 1.32 を使用していますが、Kubernetes 1.32 ではいくつかの 非推奨 API が削除されています。

クラスターを OpenShift Container Platform 4.18 から 4.19 に更新する前に、クラスター管理者は手動で確認を行う必要があります。これは、OpenShift Container Platform 4.19 に更新した後、クラスター上で実行されている、またはクラスターと対話しているワークロード、ツール、またはその他のコンポーネントによって、削除された API が引き続き使用されているという問題を防ぐのに役立ちます。管理者は、削除が予定されている使用中の API に対するクラスターの評価を実施し、影響を受けるコンポーネントを移行して適切な新規 API バージョンを使用する必要があります。これが完了すると、管理者による承認が可能です。

すべての OpenShift Container Platform 4.18 クラスターは、OpenShift Container Platform 4.19 に更新する前に、この管理者の承認が必要です。

詳細は、OpenShift Container Platform 4.19 への更新の準備 を参照してください。

このリリースにより、OpenShift Container Platform 障害ドメインを VMware vSphere ホストグループにマップできるようになります。これにより、vSphere ストレッチクラスター設定によって提供される高可用性を活用できるようになります。この機能は、OpenShift Container Platform 4.19 でテクノロジープレビューとして利用できます。

インストール時にホストグループを設定する方法については、VMware vSphere ホストグループの有効化 を参照してください。

既存のクラスターのホストグループを設定する方法については、vSphere 上のクラスターに複数のホストグループを指定する を参照してください。

このリリースにより、Agent-based Installer を使用して Nutanix にクラスターをインストールできるようになりました。Agent-based Installer を使用して Nutanix にクラスターをインストールするには、install-config.yaml ファイルで platform パラメーターを nutanix に設定します。

詳細は、Agent-based Installer のドキュメントの 必要な設定パラメーター を参照してください。

VMware vSphere Foundation (VVF) 9 および VMware Cloud Foundation (VCF) 9 に OpenShift Container Platform をインストールできるようになりました。

Red Hat Enterprise Linux CoreOS (RHCOS) イメージレイヤー化 は、Image Mode for OpenShift と呼ばれるようになりました。この変更の一環として、クラスター上のレイヤー化 は クラスター上のイメージモード、クラスター外のレイヤー化 は クラスター外のイメージモード と呼ばれるようになりました。

ブートイメージ更新 機能は、ブートイメージ管理 と呼ばれるようになりました。

以前はクラスター上のレイヤー化と呼ばれていた Image Mode for OpenShift が一般提供 (GA) になりました。GA への昇格に伴い、次の変更が導入されました。

以前は、ブートイメージ更新と呼ばれていたブートイメージ管理機能は、現在、Google Cloud および Amazon Web Services (AWS) クラスターのデフォルトの動作になっています。そのため、OpenShift Container Platform 4.19 に更新すると、クラスター内のブートイメージは自動的にバージョン 4.19 に更新されます。今後の更新でも、Machine Config Operator (MCO) がクラスター内のブートイメージを再び更新します。ブートイメージはマシンセットに関連付けられており、新しいノードをスケーリングするときに使用されます。更新後に作成する新しいノードはすべて、新しいバージョンに基づいています。現在のノードはこの機能の影響を受けません。

4.19 にアップグレードする前に、このデフォルトの動作をオプトアウトするか、続行する前にこの変更を承認する必要があります。詳細は、ブートイメージ管理の無効化 を参照してください。

インストールプログラムによって作成された Machine Config Server (MCS) CA バンドルは、openshift-machine-config-operator namespace の machine-config-server-ca config map に保存されるようになりました。バンドルは以前は kube-system namespace の root-ca configmap に保存されていました。OpenShift Container Platform 4.19 に更新されたクラスターでは、root-ca configmap は使用されなくなりました。この変更は、この CA バンドルが Machine Config Operator (MCO) によって管理されていることを明確にするために行われました。

MCS 署名鍵は、openshift-machine-config-operator namespace の machine-config-server-ca シークレットに保存されます。

MCS の CA および MCS 証明書は有効期間が 10 年で、MCO によって約 8 年で自動的にローテーションされます。OpenShift Container Platform 4.19 に更新すると、CA 署名鍵は存在しなくなります。その結果、MCO 証明書コントローラーが起動すると、CA バンドルは直ちに期限切れとみなされます。この有効期限により、クラスターが 10 年経過していなくても、証明書のローテーションが直ちに行われます。それ以降、次のローテーションは標準の 8 年周期で行われます。

MCO 証明書の詳細は、Machine Config Operator 証明書 を参照してください。

このリリースにより、テクノロジープレビュー機能として、Amazon Web Services (AWS) 上の Cluster API と Machine API 間で一部のリソースを移行できます。詳細は、Machine API リソースの Cluster API リソースへの移行 を参照してください。

この機能をサポートするために、OpenShift Container Platform Cluster API ドキュメントに AWS クラスターの追加設定の詳細が含まれるようになりました。

このリリースにより、コントロールプレーンマシンセットによって作成されたマシンのマシン名の接頭辞をカスタマイズできます。この機能は、ControlPlaneMachineSet カスタムリソースの spec.machineNamePrefix パラメーターを変更することで有効になります。

詳細は、コントロールプレーンマシン名へのカスタム接頭辞の追加 を参照してください。

このリリースにより、On-Demand Capacity Reservations および Capacity Blocks for ML などの Capacity Reservations を使用するマシンを Amazon Web Services クラスターにデプロイできます。

これらの機能は、コンピュート および コントロールプレーン マシンセットで設定できます。

このリリースにより、テクノロジープレビュー機能として、vSphere クラスターの仮想マシン (VM) コントローラーに最大 29 個のディスクを追加できるようになりました。この機能は、コンピュート および コントロールプレーン マシンセットで利用できます。

このリリースには、クラスター内モニタリングスタックコンポーネントと依存関係に関する以下のバージョン更新が含まれています。

このリリースにより、v2 から v3 へと移行する Prometheus コンポーネントに大規模な更新が導入されました。モニタリングスタックとその他のコアコンポーネントには、スムーズにアップグレードするために必要な調整がすべて含まれています。ただし、一部のユーザー管理設定では変更が必要になる場合があります。主な変更点は次のとおりです。

Prometheus v2 と v3 の間の変更の詳細は、Prometheus 3.0 migration guide を参照してください。

OpenShift Container Platform 4.13 では、デフォルトのプラットフォームモニタリングのメトリクス収集プロファイルを設定して、デフォルトの量のメトリクスデータまたは最小量のメトリクスデータを収集する機能が導入されました。OpenShift Container Platform 4.19 では、メトリクス収集プロファイルが一般提供されました。

詳細は、メトリクス収集プロファイルについて および メトリクス収集プロファイルの選択を 参照してください。

このリリースにより、外部 Alertmanager インスタンスは通信にクラスター全体の HTTP プロキシー設定を使用するようになりました。Cluster Monitoring Operator (CMO) は、クラスター全体のプロキシー設定を読み取り、Alertmanager エンドポイントに適切なプロキシー URL を設定します。

このリリースにより、OpenShift Container Platform 4.18 で導入された厳密な検証が改善されました。エラーメッセージに影響を受けたフィールドが明確に示されるようになり、検証は大文字と小文字を区別するようになったため、より正確で一貫性のある設定が可能になりました。

詳細は、(OCPBUGS-42671) および (OCPBUGS-54516) を参照してください。

ルートアドバタイズメントを有効にすると、OVN-Kubernetes ネットワークプラグインが、クラスターユーザー定義ネットワーク (CUDN) に関連付けられた Pod とサービスのルートを、プロバイダーネットワークに直接アドバタイズできるようになります。この機能により、次のような利点がいくつか得られます。

詳細は、ルートアドバタイズメントについて を参照してください。

このリリースにより、ルート API の .spec.tls.externalCertificate フィールドを利用して、サードパーティーの証明書管理ソリューションで OpenShift Container Platform ルートを設定できるようになりました。これにより、シークレットを介して外部で管理されている TLS 証明書を参照できるようになり、手動による証明書管理が不要になり、プロセスが合理化されます。外部で管理される証明書を使用することで、エラーが削減され、証明書の更新プロセスがスムーズになり、OpenShift ルーターが更新された証明書を迅速に提供できるようになります。詳細は、外部管理証明書を使用したルートの作成 を参照してください。

Cluster Network Operator (CNO) が、Border Gateway Protocol (BGP) ルーティングの有効化をサポートするようになりました。BGP を使用すると、基盤となるプロバイダーネットワークへのルートをインポートおよびエクスポートしたり、マルチホーミング、リンク冗長性、高速コンバージェンスを使用したりできます。BGP 設定は、FRRConfiguration カスタムリソース (CR) を使用して管理されます。

MetalLB Operator をインストールした以前のバージョンの OpenShift Container Platform からアップグレードする場合は、カスタムの frr-k8s 設定を metallb-system namespace から openshift-frr-k8s namespace に手動で移行する必要があります。これらの CR を移動するには、次のコマンドを入力します。

移行が完了したら、metallb-system namespace から FRR-K8s カスタムリソースを削除できます。

詳細は、BGP ルーティングについて を参照してください。

このリリースにより、Gateway API リソースを使用して Ingress クラスタートラフィックを管理するためのサポートが一般提供されます。Gateway API は、標準化されたオープンソースエコシステムを使用して、OpenShift Container Platform クラスターのトランスポート層 (L4) とアプリケーション層 (L7) 内で堅牢なネットワークソリューションを提供します。

詳細は、OpenShift Container Platform ネットワークを使用した Gateway API を参照してください。

このリリースにより、OpenShift Container Platform が Gateway API CRD のライフサイクルを管理するようになりました。つまり、Ingress Operator は必要なバージョン管理とリソースの管理を処理します。以前の OpenShift Container Platform バージョンで作成された Gateway API リソースは、Ingress Operator に必要な仕様に準拠するように再作成および再デプロイする必要があります。

詳細は、Ingress Operator による Gateway API 管理継承の準備 を参照してください。

OpenShift Container Platform 4.19 では、Red Hat OpenShift Service Mesh がバージョン 3.0.2 に、Gateway API がバージョン 1.2.1 に更新されます。詳細は、Service Mesh 3.0.0 リリースノート および Gateway API 1.2.1 changelog を参照してください。

このリリースにより、AWS に OpenShift Container Platform クラスターをインストールするときに、ロードバランサーを割り当ててデプロイメントをカスタマイズできるようになりました。この機能により、最適なトラフィック分散、高いアプリケーション可用性、中断のないサービス、ネットワークのセグメンテーションが確保されます。

詳細は、AWS のインストール設定パラメーター および ロードバランサーを特定のサブネットに割り当てるを 参照してください。

このリリースにより、デュアルポートネットワークインターフェイスコントローラー (NIC) を使用して、Precision Time Protocol (PTP) の通常クロックの冗長性を向上させることができます。オーディナリークロックのデュアルポート NIC 設定では、1 つのポートに障害が発生した場合、スタンバイポートが引き継ぎ、PTP タイミング同期を維持します。

詳細は、デュアルポート NIC を使用して PTP 通常クロックの冗長性を向上させる を参照してください。

SriovOperatorConfig オブジェクトで featureGates.resourceInjectorMatchCondition 機能を有効にして、Network Resources Injector Webhook の範囲を制限できるようになりました。この機能を有効にすると、Webhook はセカンダリーネットワークアノテーション k8s.v1.cni.cncf.io/networks を持つ Pod にのみ適用されます。

この機能が無効になっている場合、Webhook の failurePolicy はデフォルトで Ignore に設定されます。この設定により、Webhook が利用できない場合に、SR-IOV ネットワークを要求する Pod が必要なリソース注入なしでデプロイされる可能性があります。この機能が有効になっていて、Webhook が利用できない場合でも、アノテーションのない Pod はデプロイされ、他のワークロードへの不要な中断が阻止されます。

詳細は、Network Resources Injector について を参照してください。

このリリースでは、OpenShift Container Platform に Data Processing Unit (DPU) Operator が導入され、Operator を使用して DPU デバイスを管理できるようになりました。DPU Operator は、データネットワーク、ストレージ、セキュリティーワークロードのオフロードを有効にするなど、DPU が設定されたコンピュートノード上のコンポーネントを管理します。DPU デバイス管理を有効にすると、クラスターのパフォーマンスが向上し、レイテンシーが短縮され、セキュリティーが強化され、全体的にクラスターインフラストラクチャーの効率が向上します。詳細は、DPU および DPU Operator について を参照してください。

管理者は、ClusterUserDefinedNetwork カスタムリソースを使用して、Localnet トポロジーにセカンダリーネットワークをデプロイできるようになりました。この機能により、localnet ネットワークに接続された Pod と仮想マシンが物理ネットワークに Egress できるようになります。詳細は、Localnet トポロジー用の ClusterUserDefinedNetwork CR の作成 を参照してください。

Linux ブリッジ Network Attachment Definition (NAD) のポート分離を有効にすると、同じ仮想 LAN (VLAN) 上で実行される仮想マシン (VM) または Pod が相互に分離して動作できるようになります。詳細は、Linux ブリッジ NAD のポート分離の有効化 を参照してください。

特にクラスター内のノードが大量の Pod を実行している場合に、Whereabouts のパフォーマンスを向上させるために、Fast IP Address Management (IPAM) 機能を有効化できるようになりました。Fast IPAM 機能は、Whereabouts Controller によって管理される nodeslicepools を使用して、ノードの IP アドレスの割り当てを最適化します。詳細は、Whereabouts IPAM CNI プラグインの高速 IPAM 設定 を参照してください。

このリリースにより、OpenShift Container Platform に番号のない BGP ピアリングが導入されました。これは、テクノロジープレビュー機能として利用可能です。BGP ピアカスタムリソースの spec.interface フィールドを使用して、番号のない BGP ピアリングを設定できます。

外部 DNS サーバーに到達できない非接続環境では、NMState カスタムリソース定義 (CRD) にカスタム DNS ホスト名を指定することで、Kubernetes NMState Operator のヘルスプローブの問題を解決できます。詳細は、DNS 接続の問題を解決するためのカスタム DNS ホスト名の作成 を参照してください。

このリリースでは、PTP イベント REST API v1 およびイベントコンシューマーアプリケーションサイドカーのサポートが削除されました。

代わりに、O-RAN 準拠の PTP イベント REST API v2 を使用する必要があります。

詳細は、REST API v2 を使用した PTP イベントコンシューマーアプリケーションの開発 を参照してください。

クラスターの RouteExternalCertificate フィーチャーゲートを有効にした場合、以前に削除されたシークレットを再度追加できるようになりました。(OCPBUGS-33958)

OpenShift Container Platform 4.19 以降、oc-mirror プラグイン v2 は、コンテナーイメージに対する cosign のタグベース署名のミラーリングおよび検証をサポートします。

Operator プロジェクトの以下のベースイメージは、OpenShift Container Platform 4.19 との互換性のために更新されます。これらのベースイメージのランタイム機能と設定 API は、バグ修正と CVE への対応のためにサポートされます。

詳細は、Updating the base image for existing Ansible- or Helm-based Operator projects for OpenShift Container Platform 4.19 and later (Red Hat ナレッジベース) を参照してください。

OpenShift Container Platform 4.19 では、Bare Metal as a Service (BMaaS) を使用して、OpenShift Container Platform 以外のノードをデプロイできます。BMaaS ノードは、コンテナー化や仮想化に適さない可能性のあるワークロードを実行できます。たとえば、ハードウェアへの直接アクセスを必要とするアプリケーション、高性能コンピューティングタスクを実行するアプリケーション、またはレガシーアプリケーションでクラスターから独立して動作するアプリケーションなどのワークロードは、BMaaS を使用したデプロイメントに適しています。

詳細は、ベアメタルをサービスとして使用する を参照してください。

このリリースにより、インストール時に何もしなかった場合でも、AWS OpenShift Container Platform クラスターが STS を使用するように設定できます。

詳細は、既存のクラスターで AWS Security Token Service (STS) を有効にする を参照してください。

RHCOS は、OpenShift Container Platform 4.19 で Red Hat Enterprise Linux (RHEL) 9.6 パッケージを使用します。これらのパッケージにより、OpenShift Container Platform インスタンスが最新の修正、機能、機能拡張、ハードウェアサポート、およびドライバーの更新を確実に受け取ることができます。

この更新により、リアルタイムカーネルが無効になっている ARM インフラストラクチャーノードで、メモリーを大量に消費する高パフォーマンスのワークロードのパフォーマンスを向上させるために、より大きなカーネルページサイズを指定できるようになりました。詳細は、カーネルページサイズの設定 を参照してください。

このリリースには、cluster-compare プラグインに対する次の使いやすさと機能の更新が含まれています。

利用可能なテンプレート関数の完全なリストについては、テンプレート関数のリファレンス を参照してください。

この更新により、パフォーマンスプロファイルを適用して、Hosted Control Plane のノードを低レイテンシーに調整できるようになりました。詳細は、Hosted Control Plane のパフォーマンスプロファイルの作成 を参照してください。

このリリースにより、コントロールプレーンは TLS 1.3 をサポートします。コントロールプレーンに Modern TLS セキュリティープロファイルを使用できるようになりました。

詳細は、コントロールプレーンの TLS セキュリティープロファイルの設定 を参照してください。

このリリースでは、External Secrets Operator for Red Hat OpenShift を使用して外部シークレットストアで認証し、シークレットを取得し、取得したシークレットをネイティブ Kubernetes シークレットに注入できるようになりました。External Secrets Operator for Red Hat OpenShift は、テクノロジープレビューとして利用可能です。

詳細は、External Secrets Operator for Red Hat OpenShift の概要 を参照してください。

このリリースにより、Secrets Store CSI ドライバーを使用することで、非接続クラスターでもシークレットストアプロバイダーのサポートが可能になりました。

詳細は、非接続環境のサポート を参照してください。

クロスサブスクリプションサポートにより、1 つの Azure サブスクリプションに OpenShift Container Platform クラスターを配置し、Azure File Container Storage Interface (CSI) ドライバーを使用して、別の Azure サブスクリプションに Azure ファイル共有をマウントできるようになります。サブスクリプションは同じテナント内にある必要があります。

OpenShift Container Platform 4.19 では、この機能が一般提供されています。

詳細は、AWS EFS CSI クロスアカウントのサポート を参照してください。

Volume Attributes Classes は、管理者が提供するストレージの "クラス" を記述する手段を提供するものです。それぞれのクラスを別々のサービス品質レベルに対応させることができます。

OpenShift Container Platform 4.19 の Volume Attributes Classes は、AWS Elastic Block Storage (EBS) および Google Cloud Platform (GCP) Persistent Disk (PD) Container Storage Interface (CSI) でのみ利用できます。

Volume Attributes Classes を永続ボリューム要求 (PVC) に適用できます。クラスターで新しい Volume Attributes Classes が使用可能になった場合は、必要に応じて新しい Volume Attributes Classes で PVC を更新できます。

Volume Attributes Classes には、それに属するボリュームを記述するパラメーターがあります。パラメーターを省略すると、ボリュームのプロビジョニング時にデフォルトが使用されます。ユーザーが、パラメーターを省略した異なる Volume Attributes Class を持つ PVC を適用すると、CSI ドライバーの実装に応じてパラメーターのデフォルト値が使用される場合があります。詳細は、関連する CSI ドライバーのドキュメントを参照してください。

Volume Attributes Classes は、OpenShift Container Platform 4.19 ではテクノロジープレビューのステータスで提供されます。

詳細は、Volume Attributes Classes を参照してください。

OpenShift Container Platform 4.19 では、永続ボリューム要求の使用状況を表示するための新しいコマンドが導入されました。この機能はテクノロジープレビューです。

詳細は、PVC 使用状況の統計情報の表示 を参照してください。

以前は、永続ボリューム要求 (PVC) を、基盤となるストレージプロバイダーでサポートされていないサイズまで拡張することがありました。この場合、拡張コントローラーは通常、ボリュームの拡張を永久に試行し、失敗し続けます。

この新機能を使用すると、PVC を回復し、別のサイズ変更値を提供できます。サイズ変更のリカバリーは、OpenShift Container Platform 4.19 で一般提供としてサポートされています。

ボリュームのサイズ変更の詳細は、永続ボリュームの拡張 を参照してください。

ボリュームのサイズ変更時の回復の詳細は、ボリュームの拡張時の障害からの回復 を参照してください。

以前は、ツリー内から Container Storage Interface (CSI) に移行された VMware vSphere 永続ボリュームのサイズを変更できませんでした。OpenShift Container Platform 4.19 では、移行されたボリュームのサイズ変更がサポートされています。この機能は一般提供されています。

ボリュームのサイズ変更の詳細は、永続ボリュームの拡張 を参照してください。

場合によって、クラスター管理者は Day 2 運用として VMware vSphere Container Storage Interface (CSI) ドライバーを無効にし、vSphere CSI ドライバーが vSphere セットアップと接続されないようにする必要があります。

この機能は、OpenShift Container Platform 4.17 でテクノロジープレビューのステータスで導入されました。この機能は、OpenShift Container Platform 4.19 で一般提供としてサポートされるようになりました。

詳細は、vSphere でのストレージの無効化と有効化 を参照してください。

VMware vSphere バージョン 7 の場合、OpenShift Container Platform ではノードあたりのボリュームの最大数が 59 に制限されます。

ただし、OpenShift Container Platform 4.19 for vSphere バージョン 8 以降では、ノードあたりの許容ボリューム数を最大 255 まで増やすことができます。それ以外の場合、デフォルト値は 59 のままになります。

この機能はテクノロジープレビューです。

詳細は、vSphere のノードあたりの最大ボリュームの増加 を参照してください。

現在のデータストアの容量が不足している場合、またはよりパフォーマンスの高いデータストアに移行する場合は、VMware vSphere Cloud Native Storage (CNS) ボリュームをデータストア間で移行できます。これは、接続されたボリュームと切断されたボリュームの両方に適用されます。

OpenShift Container Platform は、vCenter UI を使用した CNS ボリュームの移行を完全にサポートするようになりました。移行されたボリュームは期待どおりに動作し、永続ボリュームが機能しなくなることはありません。CNS ボリュームは、Pod によって使用されている間にも移行できます。

この機能は OpenShift Container Platform 4.17 で開発プレビューとして導入されましたが、4.19 では完全にサポートされるようになりました。

データストア間で CNS ボリュームを移行するには、VMware vSphere 8.0.2 以降または vSphere 7.0 Update 3o 以降が必要です。

詳細は、vSphere のデータストア間での CNS ボリュームの移行 を参照してください。

デフォルトでは、Filestore インスタンスは、同じ Google Cloud プロジェクトと Virtual Private Cloud (VPC) ネットワークを共有するすべてのクライアントにルートレベルの読み取り/書き込みアクセス権を付与します。ネットワークファイルシステム (NFS) エクスポートオプションを使用すると、Filestore インスタンスの特定の IP 範囲と特定のユーザー/グループ ID へのアクセスを制限できます。ストレージクラスを作成するときに、nfs-export-options-on-create パラメーターを使用して、これらのオプションを設定できます。

NFS エクスポートオプションは、OpenShift Container Platform 4.19 で一般提供としてサポートされています。

詳細は、NFS エクスポートオプション を参照してください。

Web コンソールでは Patternfly 6 が使用されるようになりました。Web コンソールでの Patternfly 4 のサポートは利用できなくなりました。

このリリースにより、Web コンソールに次の更新も導入されています。次のアクションを実行できるようになりました。

OpenShift SDN マルチテナントモードを使用する oc adm pod-network コマンドが oc adm --help 出力から削除されました。oc adm pod-network コマンドが使用される場合、非推奨であることを示すエラーメッセージがユーザーに表示されます。

このリリースでは、動的プラグインの useModal フックのサポートが非推奨になりました。

このリリース以降、useOverlay API フックを使用してモーダルを起動します。

OpenShift Container Platform 4.17 では、削除された Kubernetes API admissionregistration.k8s.io/v1beta1 が誤って再導入されました。この API は非推奨であり、今後の OpenShift Container Platform リリースで削除される予定です。この API を使用している箇所がある場合は、すべて admissionregistration.k8s.io/v1 に移行してください。

削除予定の Kubernetes API がクラスターにあるかどうかを確認する方法は、Kubernetes API の非推奨化と削除 を参照してください。

OpenShift Container Platform 4.16 で非推奨化された cgroup v1 はサポートされなくなり、OpenShift Container Platform から削除されました。クラスターで cgroup v1 を使用している場合は、OpenShift Container Platform 4.19 にアップグレードする前に cgroup v2 を設定する必要があります。すべてのワークロードは cgroup v2 と互換性がある必要があります。

クラスターで cgroup v2 を設定する方法は、OpenShift Container Platform バージョン 4.18 ドキュメントの Linux cgroup の設定 を参照してください。

cgroup v2 の詳細は、Linux cgroup バージョン 2 について および Red Hat OpenShift ワークロードのコンテキストにおける Red Hat Enterprise Linux 9 の変更点 (Red Hat ブログ) を参照してください。

このリリースにより、パッケージベースの RHEL ワーカーノードのインストールのサポートが削除されました。

RHCOS イメージレイヤー化により、この機能が置き換えられ、ワーカーノードのベースオペレーティングシステムへの追加パッケージのインストールがサポートされます。

クラスター内の RHEL ノードを識別して削除する方法は、OpenShift Container Platform 4.18 から新しいバージョンへの更新の準備 を参照してください。イメージレイヤー化の詳細は、RHCOS イメージレイヤー化 を参照してください。

Kubernetes 1.32 では、以下の非推奨 API が削除されたため、マニフェストと API クライアントを移行して、適切な API バージョンを使用する必要があります。削除された API の移行の詳細は、Kubernetes のドキュメント を参照してください。

このリリースにより、Operator プロジェクトの関連するスキャフォールディングおよびテストツールを含む、Red Hat がサポートするバージョンの Operator SDK CLI ツールが OpenShift Container Platform でリリースされなくなりました。

Red Hat は、OpenShift Container Platform 4 の製品ライフサイクル (Red Hat カスタマーポータル) に従って、OpenShift Container Platform の以前のバージョンでリリースされた Operator SDK のバージョンに対してバグ修正とサポートを提供します。

既存の Operator プロジェクトを含む Operator の作成者は、OpenShift Container Platform 4.18 でリリースされた Operator SDK CLI ツールのバージョン を使用してプロジェクトを維持し、OpenShift Container Platform の新しいバージョンを対象とする Operator リリースを作成できます。詳細は、Updating the base image for existing Ansible- or Helm-based Operator projects for OpenShift Container Platform 4.19 and later (Red Hat ナレッジベース) を参照してください。

コミュニティーによって管理されているサポート対象外の Operator SDK のバージョンは、Operator SDK (Operator Framework) を参照してください。

今回のリリースで修正された問題は特にありません。

OpenShift Container Platform 4.19 クラスターをこの最新リリースに更新するには、CLI を使用したクラスターの更新 を参照してください。

今回のリリースで修正された問題は特にありません。

OpenShift Container Platform 4.19 クラスターをこの最新リリースに更新するには、CLI を使用したクラスターの更新 を参照してください。

OpenShift Container Platform 4.19 クラスターをこの最新リリースに更新するには、CLI を使用したクラスターの更新 を参照してください。

OpenShift Container Platform 4.19 クラスターをこの最新リリースに更新するには、CLI を使用したクラスターの更新 を参照してください。

OpenShift Container Platform 4.19 クラスターをこの最新リリースに更新するには、CLI を使用したクラスターの更新 を参照してください。

OpenShift Container Platform 4.19 クラスターをこの最新リリースに更新するには、CLI を使用したクラスターの更新 を参照してください。

今回のリリースでは、以下の問題が修正されています。

OpenShift Container Platform 4.19 クラスターをこの最新リリースに更新するには、CLI を使用したクラスターの更新 を参照してください。

今回のリリースでは、以下の問題が修正されています。

OpenShift Container Platform 4.19 クラスターをこの最新リリースに更新するには、CLI を使用したクラスターの更新 を参照してください。

OpenShift Container Platform 4.19 クラスターをこの最新リリースに更新するには、CLI を使用したクラスターの更新 を参照してください。

OpenShift Container Platform 4.19 クラスターをこの最新リリースに更新するには、CLI を使用したクラスターの更新 を参照してください。

OpenShift Container Platform 4.19 クラスターをこの最新リリースに更新するには、CLI を使用したクラスターの更新 を参照してください。