リリースノート

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

RHCOS は iscsi_bft ドライバーをサポートするようになり、iSCSI Boot Firmware Table (iBFT) で動作する iSCSI デバイスから直接ブートできるようになります (テクノロジープレビュー)。これにより、iSCSI デバイスをインストールのルートディスクとしてターゲットにすることができます。

詳細は、RHEL ドキュメント を参照してください。

お客様が管理する暗号鍵をインストールプログラムに提供することで、インストール中に Azure ストレージアカウントを暗号化できるようになりました。Azure ストレージアカウントの暗号化に必要なパラメーターに関する説明は、インストール設定パラメーター を参照してください。

TechPreviewNoUpgrade 機能フラグを有効にすると、Cluster CAPI Operator は Cluster API Provider OpenStack をデプロイし、そのライフサイクルを管理します。Cluster CAPI Operator は、現在の OpenShift Container Platform クラスターの Cluster リソースおよび OpenStackCluster リソースを自動的に作成します。

Machine API リソースの設定方法と同様に、Cluster API Machine および OpenStackMachine リソースを設定できるようになりました。クラスター API リソースは機能的には Machine API リソースと同等ですが、構造的には同一ではないことに注意することが重要です。

インストールプロセスの一環として、独自の IBM® Key Protect for IBM Cloud® ルート鍵を指定できるようになりました。このルート鍵は、コントロールプレーンとコンピュートマシンのルート (ブート) ボリューム、およびクラスターのデプロイ後にプロビジョニングされる永続ボリューム (データボリューム) を暗号化するために使用されます。

詳細は、IBM Cloud のユーザー管理の暗号化 を参照してください。

切断または制限されたネットワーククラスターなど、インターネットアクセスが制限された環境の IBM Cloud® にクラスターをインストールできるようになりました。このタイプのインストールでは、OpenShift Container Platform インストールイメージの内容をミラーリングするレジストリーを作成します。このレジストリーは、インターネットと制限されたネットワークの両方にアクセスできるミラーホスト上に作成できます。

詳細は、制限されたネットワーク内の IBM Cloud へのクラスターのインストール を参照してください。

install-config.yaml ファイルのエッジコンピュートプールにゾーン名を設定することで、Amazon Web Services (AWS) Wavelength Zonese に OpenShift Container Platform クラスターをすばやくインストールするか、Wavelength Zone のサブネットを使用して既存の VPC にクラスターをインストールできます。

インストール後のタスクを実行して、AWS 上の既存の OpenShift Container Platform クラスターを拡張し、AWS Wavelength Zone を使用することもできます。

詳細は、AWS Wavelength Zone 上のコンピュートノードを使用して AWS にクラスターをインストールする および 既存のクラスターの拡張による AWS Local Zones または Wavelength Zones の使用 を参照してください。

AWS Local Zones インフラストラクチャーにクラスターをデプロイする前に、インフラストラクチャーのニーズを満たすようにクラスターネットワークの最大伝送単位 (MTU) をカスタマイズできます。

install-config.yaml 設定ファイルで networking.clusterNetworkMTU パラメーターを指定することにより、クラスターの MTU をカスタマイズできます。

詳細は、クラスターネットワーク MTU のカスタマイズ を参照してください。

OpenShift Container Platform バージョン 4.14 では、テクノロジープレビューとして AWS Outposts で実行されているコンピュートノードを使用して、クラスターを AWS にインストールできます。OpenShift Container Platform 4.15 では、AWS 上のクラスターを既存の VPC にインストールし、インストール後の設定タスクとして AWS Outposts にコンピュートノードをプロビジョニングできます。

詳細は、AWS 上のクラスターを既存の VPC にインストールする および AWS VPC クラスターを AWS Outpost に拡張する を参照してください。

デフォルトでは、インストールプログラムは、コントロールプレーンとコンピュートマシンを単一の Nutanix Prism Element (クラスター) にインストールします。OpenShift Container Platform クラスターのフォールトトレランスを向上させるために、障害ドメインを設定することで、これらのマシンが複数の Nutanix クラスターに分散されるように指定できるようになりました。

詳細は、複数の Prism 要素を使用したフォールトトレランスのデプロイメント を参照してください。

OpenShift Container Platform 4.15 は、Machine Config Operator (MCO) を使用して、RHCOS カーネルで 64k ページサイズを有効にする機能をサポートするようになりました。この設定は、64 ビット ARM アーキテクチャーを使用するマシンに限定されます。詳細は、マシン設定タスク のドキュメントを参照してください。

OpenShift Container Platform 4.15 では、インストール中に Operator Lifecycle Manager (OLM) 機能を無効にすることができます。詳細は、Operator Lifecycle Manager の機能 を参照してください。

Day 2 デプロイメントとして、etcd をルートボリューム (Cinder) から専用のエフェメラルローカルディスクに移動できるようになりました。このテクノロジープレビュー機能を使用すると、RHOSP インストールのパフォーマンスの問題を解決したり、阻止したりできます。

詳細は、ローカルディスク上の rootVolume および etcd を使用した OpenStack へのデプロイ を参照してください。

Agent-based インストール用の install-config.yaml ファイルを作成する際に、vSphere を使用するようにクラスターを設定できるようになりました。詳細は、追加の VMware vSphere 設定パラメーター を参照してください。

Agent-based インストール用の install-config.yaml ファイルを作成する際に、ベアメタルプラットフォームの追加設定を行うことができるようになりました。これらの新しいオプションには、ホスト設定、ネットワーク設定、ベースボード管理コントローラー (BMC) の詳細が含まれます。

これらのフィールドは、クラスターの初期プロビジョニング中には使用されませんが、インストール後にフィールドを設定する必要がなくなります。詳細は、Agent-based Installer 用の追加のベアメタル設定パラメーター を参照してください。

Redfish プロトコルで Dell iDRAC ベースボード管理コントローラー (BMC) を使用して、インストーラーがプロビジョニングしたインストール中にベアメタルプラットフォームの Redundant Array of Independent Disks (RAID) を設定できるようになりました。詳細は、オプション: RAID の設定 を参照してください。

マルチアーキテクチャーのコンピュートマシンを備えた OpenShift Container Platform 4.15 クラスターでは、クラスター内の 64 ビット ARM コンピュートマシン上の Red Hat Enterprise Linux CoreOS (RHCOS) カーネルで 64k ページサイズを有効にできるようになりました。このパラメーターの設定に関する詳細は、Red Hat Enterprise Linux CoreOS (RHCOS) カーネルでの 64k ページの有効化 を参照してください。

このリリースでは、Web コンソールの 管理者 パースペクティブに次の更新が導入されています。

このリリースでは、Web コンソールの 開発者 パースペクティブに次の更新が導入されています。

OpenShift Container Platform 4.15 の IBM Z® および IBM® LinuxONE リリースでは、OpenShift Container Platform のコンポーネントと概念に、改良点と新機能が追加されました。

このリリースでは、IBM Z® および IBM® LinuxONE 上で次の機能がサポートされます。

OpenShift Container Platform は、IBM Z および IBM LinuxONE 上の論理パーティション (LPAR) での OpenShift Container Platform 4.15 のユーザーがプロビジョニングしたインストールをサポートするようになりました。

インストール手順は、以下のドキュメントを参照してください。

OpenShift Container Platform 4.15 の IBM Power® リリースでは、OpenShift Container Platform コンポーネントに改良点と新機能が追加されました。

このリリースでは、IBM Power® で次の機能がサポートされます。

このリリースでは、Azure クラスター上の Operator Lifecycle Manager (OLM) によって管理される一部の Operator は、Microsoft Entra Workload ID を使用して手動モードで Cloud Credential Operator (CCO) を使用できるようになります。これらの Operator は、クラスターの外部で管理される短期認証情報を使用して認証します。

詳細は、Azure AD Workload Identity を使用した OLM 管理 Operator の CCO ベースのワークフロー を参照してください。

OpenShift Container Platform は、north-south トラフィック とも呼ばれる外部トラフィックの暗号化をサポートするようになりました。IPsec は、east-west トラフィック と呼ばれる Pod 間のネットワークトラフィックの暗号化を、すでにサポートしています。両方の機能を一緒に使用して、OpenShift Container Platform クラスターに完全な転送中の暗号化を提供できます。

この機能は次のプラットフォームでサポートされています。

詳細は、外部 IPsec エンドポイントの IPsec 暗号化の有効化 を参照してください。

以前は、1 つの Pod (Pod X) が削除され、同様の設定で 2 番目の Pod (Pod Y) が作成された場合、Pod Y は Pod X と同じ IPv6 アドレスを持つ可能性がありますが、MAC アドレスは異なりました。このシナリオでは、ルーターは MAC アドレスの変更を認識せず、Pod X の MAC アドレスにトラフィックを送信し続けます。

今回の更新により、macvlan CNI プラグインを使用して作成された Pod (IP アドレス管理 CNI プラグインによって IP が割り当てられている) は、デフォルトで IPv6 の自発的近隣広告をネットワークに送信するようになりました。この機能拡張により、IPv6 の近隣キャッシュを更新するために、特定の IP の新しい Pod の MAC アドレスがネットワークファブリックに通知されます。

Whereabouts 調整スケジュールは 1 日に 1 回実行されるようにハードコードされており、再設定できませんでした。このリリースでは、ConfigMap オブジェクトにより、Whereabouts cron スケジュールの設定が有効になりました。詳細は、Whereabouts IP リコンサイラーのスケジュールの設定 を参照してください。

EgressFirewall および AdminPolicyBasedExternalRoute カスタムリソースポリシーのステータス管理に対して、次の更新が行われました。

この更新により、MetalLB は、MetalLB と Border Gateway Protocol (BGP) ピア間の通信に関連する追加のメトリクスを公開します。詳細は、BGP および BFD の MetalLB メトリクス を参照してください。

OpenShift Container Platform は、チューニング CNI プラグインを使用した all-multicast モードの設定をサポートするようになりました。この更新により、Pod の Security Context Constraints (SCC) に NET_ADMIN 機能を付与する必要がなくなり、Pod の潜在的な脆弱性を最小限に抑えてセキュリティーが強化されます。

all-multicast モードの詳細は、all-multicast モードについて を参照してください。

この更新により、IPv6 ネットワーク用の multi-network ポリシーを作成できるようになりました。詳細は、IPv6 ネットワークでの multi-network ポリシーのサポート を参照してください。

このリリースでは、Ingress ネットワーキングメトリクスが OpenShift Container Platform Web コンソール内から表示できるようになりました。詳細は、Ingress Operator ダッシュボード を参照してください。

OpenShift Container Platform 4.15 以降、CoreDNS は 1.10.1 から 1.11.1 に更新されました。

CoreDNS のこの更新により、com や org などのトップレベルドメインと名前を共有する ExternalName サービスのクエリーに対して、CoreDNS が誤って応答を返す問題が解決されました。外部サービスのサブドメインのクエリーは、その外部サービスに解決されるべきではありません。詳細は、関連する CoreDNS GitHub の問題 を参照してください。

OpenShift Container Platform 4.15 以降、CoreDNS は 1.10.1 から 1.11.1 に更新されました。

CoreDNS のこの更新により、メトリクス coredns_forward_healthcheck_failures_total、coredns_forward_requests_total、coredns_forward_responses_total、および coredns_forward_request_duration_seconds など、再配置された特定のメトリクスが非推奨になり、削除されました。詳細は、CoreDNS メトリクス を参照してください。

OpenShift Container Platform 4.15 では、以下の SR-IOV デバイスのサポートが追加されました。

詳細は、サポート対象のデバイス を参照してください。

このリリースでは、NodeNetworkConfigurationPolicy リソースを使用して、既存のクラスター内の Single Root I/O Virtualization (SR-IOV) ネットワーク Virtual Function (VF) のホストネットワーク設定を管理できるようになりました。

たとえば、ホストネットワークの Quality of Service (QoS) ポリシーを設定して、アタッチされた SR-IOV ネットワーク VF によるホストリソースへのネットワークアクセスを管理できます。詳細は、Virtual Function のノードネットワーク設定ポリシー を参照してください。

この更新により、ネットワークポリシーの更新中にノードを並行してドレインするように SR-IOV Network Operator を設定できるようになります。ノードを並列にドレインするオプションにより、SR-IOV ネットワーク設定の展開が高速化されます。SriovNetworkPoolConfig カスタムリソースを使用して、並列ノードドレインを設定し、Operator が並列ドレインできるプール内のノードの最大数を定義できます。

詳細は、SR-IOV ネットワークポリシーの更新中に並列ノードドレインを設定する を参照してください。

このリリースでは、Image Registry Operator を活用して Azure 上のプライベートストレージエンドポイントを使用できるようになりました。この機能を使用すると、OpenShift Container Platform がプライベート Azure クラスターにデプロイされている場合に、ストレージアカウントのプライベートエンドポイントをシームレスに設定できるため、ユーザーは公開用ストレージエンドポイントを公開せずに Image Registry をデプロイできます。

詳細は、以下のセクションを参照してください。

このリリースでは、LVMCluster カスタムリソース (CR) が、以前の LVM Storage インストールからボリュームグループをリカバリーするためのサポートを提供します。deviceClasses.name フィールドが以前の LVM Storage インストールのボリュームグループの名前に設定されている場合、LVM Storage は現在の LVM Storage インストールでそのボリュームグループに関連するリソースを再作成します。これにより、以前の LVM Storage インストールから LVM Storage の再インストールまでのデバイスを使用するプロセスが簡素化されます。

詳細は、ワーカーノードでの Logical Volume Manager クラスターの作成 を参照してください。

この機能は、選択したデバイスを強制的にワイプするために、LVMCluster カスタムリソース (CR) に新しいオプションのフィールド forceWipeDevicesAndDestroyAllData を提供します。このリリースより前は、デバイスをワイプするにはホストに手動でアクセスする必要がありました。このリリースでは、手動介入なしでディスクを強制的に消去できます。これにより、ディスクを消去するプロセスが簡素化されます。

詳細は、ワーカーノードでの Logical Volume Manager クラスターの作成 を参照してください。

この機能は、LVM Storage をマルチノードクラスターにデプロイするためのサポートを提供します。以前は、LVM Storage はシングルノード設定のみをサポートしていました。このリリースでは、LVM Storage はすべての OpenShift Container Platform デプロイメントトポロジーをサポートします。これにより、マルチノードクラスター上でローカルストレージをプロビジョニングできるようになります。

詳細は、LVM Storage のデプロイメント を参照してください。

この機能は、mdadm ユーティリティーを使用して作成された RAID アレイを LVM Storage と統合するためのサポートを提供します。LVMCluster カスタムリソース (CR) は、deviceSelector.paths フィールドおよび deviceSelector.optionalPaths フィールドで、RAID アレイへのパスを追加するためのサポートを提供します。

詳細は、ソフトウェア RAID アレイと LVM Storage の統合 を参照してください。

このリリースでは、LVM Storage は Federal Information Processing Standards (FIPS) に準拠するように設計されています。LVM Storage が FIPS モードで OpenShift Container Platform にインストールされている場合、LVM Storage は、x86_64 アーキテクチャー上でのみ FIPS 140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。

OpenShift Container Platform 4.13 より前では、デフォルトのストレージクラスがなかった場合、デフォルトのストレージクラスを要求するために作成された永続ボリューム要求 (PVC) は、手動で削除して再作成しない限り、無期限に保留状態のままになりました。OpenShift Container Platform 4.14 以降では、テクノロジープレビュー機能として、デフォルトのストレージクラスがこれらの PVC に遡って割り当てられるため、保留状態に残らないようになります。デフォルトのストレージクラスが作成されるか、既存のストレージクラスの 1 つがデフォルトとして宣言されると、これらの以前に保留された PVC がデフォルトのストレージクラスに割り当てられます。現在、この機能は一般提供されています。

詳細は、デフォルトのストレージクラスが存在しない を参照してください。

この機能には、オプションのフィールド forceWipeDevicesAndDestroyAllData があり、wipefs を呼び出すかどうかを定義します。これにより、パーティションテーブルの署名 (マジックストリング) が削除され、ディスクを Local Storage Operator (LSO) プロビジョニングに使用できるようになります。署名以外のデータは消去されません。現在、この機能は一般提供されています。この機能は LocalVolumeSet (LVS) には適用されないことに注意してください。

詳細は、Local Storage Operator を使用したローカルボリュームのプロビジョニング を参照してください。

OpenShift Container Platform 4.13 以降、Container Storage Interface (CSI) ドライバーは、テクノロジープレビュー機能として、ノードが正常に停止しないときにボリュームを自動的にデタッチできるようになりました。ノードが正常にシャットダウンしなかった場合、ノードに out-of-service テイントを手動で追加し、ノードからボリュームを自動的にデタッチできます。現在、この機能は一般提供されています。

詳細は、正常ではないノードシャットダウン後の CSK ボリュームのデタッチ を参照してください。

Google Compute Platform (GCP) Container Storage Interface (CSI) Driver Operator の共有 Virtual Private Cloud (VPC) が、一般提供機能としてサポートされるようになりました。共有 VPC により、ネットワーク管理が簡素化され、一貫したネットワークポリシーが可能になり、ネットワークリソースの一元的なビューが提供されます。

詳細は、GCP Filestore Storage のストレージクラスの作成 を参照してください。

ユーザー管理型の暗号化機能を使用すると、インストール中に OpenShift Container Platform ノードのルートボリュームを暗号化するキーを提供でき、すべてのマネージドストレージクラスが指定された暗号化キーを使用してプロビジョニングされたストレージボリュームを暗号化できるようになります。この機能は、Google Cloud Platform (GCP) 永続ディスク (PD) ストレージ、Microsoft Azure Disk、および Amazon Web Services (AWS) Elastic Block Storage (EBS) 用の OpenShift Container Platform 4.13 で導入され、現在は IBM Virtual Private Cloud (VPC) Block ストレージでサポートされています。

以前は、SELinux が有効になっていると、永続ボリューム (PV) を Pod に接続するときに永続ボリュームのファイルのラベルが変更され、PV に多くのファイルが含まれている場合にタイムアウトが発生したり、ストレージバックエンドが過負荷になったりする可能性がありました。

OpenShift Container Platform 4.15 では、この機能をサポートする Container Storage Interface (CSI) ドライバーの場合、ドライバーは正しい SELinux ラベルを使用してボリュームを直接マウントするため、ボリュームのラベルを再帰的に変更する必要がなくなり、Pod の起動が大幅に高速化されます。

これはテクノロジープレビュー機能としてサポートされています。

次の条件が当てはまる場合、この機能はデフォルトで有効になります。

専用、ハイブリッド、パブリックおよびマルチクラウド環境をサポートする Oracle® Cloud Infrastructure (OCI) インフラストラクチャー上でクラスターワークロードを実行できます。Red Hat と Oracle はどちらも、OCI 上の OpenShift Container Platform クラスターでの OCI の実行をテスト、検証、サポートしています。

OCI は、規制コンプライアンス、パフォーマンス、費用対効果のニーズを満たすサービスを提供します。OCI Resource Manager 設定にアクセスして、OCI リソースをプロビジョニングおよび設定できます。

詳細は、Assisted Installer を使用した OCI へのクラスターのインストール を参照してください。

エージェントベースのインストーラを使用して Oracle® Cloud Infrastructure (OCI) にクラスターをインストールすると、専用、ハイブリッド、パブリックおよびマルチクラウド環境をサポートするインフラストラクチャー上でクラスターのワークロードを実行できます。

エージェントベースのインストーラーは、Assisted Installation サービスを使いやすくするだけでなく、接続環境または非接続環境のいずれかにクラスターをインストールする機能を備えています。

OCI は、規制コンプライアンス、パフォーマンス、費用対効果のニーズを満たすサービスを提供します。OCI は、64 ビット x86 インスタンスと 64 ビット ARM インスタンスをサポートします。

詳細は、Agent-based Installer を使用した OCI へのクラスターのインストール を参照してください。

Operator Lifecycle Manager (OLM) は、最初のリリースから OpenShift Container Platform 4 に含まれています。OpenShift Container Platform 4.14 では、OLM の次世代イテレーションのためのコンポーネントがテクノロジープレビュー機能として導入されており、このフェーズでは OLM 1.0 として知られています。この更新されたフレームワークは、OLM の以前のバージョンの一部であった概念の多くを進化させ、新しい機能を追加します。

OpenShift Container Platform 4.15 の OLM 1.0 のテクノロジープレビューフェーズ中に、管理者はこのリリースに追加された以下の機能を試すことができます。

詳細は、Operator Lifecycle Manager 1.0 について を参照してください。

オプションの olm.deprecations スキーマは、ファイルベースのカタログ内の Operator パッケージ、バンドル、およびチャネルの非推奨情報を定義します。Operator の作成者は、deprecations.yaml ファイルでこのスキーマを使用して、サポートステータスや推奨されるアップグレードパスなど、Operator に関する関連メッセージをカタログからこれらの Operator を実行しているユーザーに提供できます。Operator がインストールされると、指定されたメッセージが、関連する Subscription オブジェクトのステータス状況として表示されます。

olm.deprecations スキーマの詳細は、Operator Framework のパッケージ化形式 を参照してください。

このリリースでは、Operator Lifecycle Manager (OLM) によって管理される Operator は、Microsoft Entra Workload ID 用に設定された Azure クラスター上で実行するときに、トークン認証をサポートできるようになります。Cloud Credential Operator (CCO) を更新すると、Operator の作成者が Operator による Microsoft Entra Workload ID のサポートを有効にしている場合に限り、特定の短期認証情報の半自動プロビジョニングが可能になります。

詳細は、Azure AD Workload Identity を使用した OLM 管理 Operator の CCO ベースのワークフロー を参照してください。

このリリースでは、テクノロジープレビューとして個々のノードの更新を監視できます。詳細は、マシン config ノードのステータスの確認 を参照してください。

vSphere 障害ドメインリソースを使用すると、コントロールプレーンマシンセットを使用して、プライマリー VMware vSphere インフラストラクチャーとは別のハードウェアにコントロールプレーンマシンをデプロイできます。コントロールプレーンマシンセットは、定義された障害ドメイン全体でコントロールプレーンマシンのバランスをとり、インフラストラクチャーにフォールトトレランス機能を提供する際に役立ちます。

詳細は、VMware vSphere 障害ドメイン設定のサンプル および サポートされているクラウドプロバイダー を参照してください。

/dev/fuse デバイスを使用して特権のない Pod を設定すると、より高速なビルドにアクセスできます。

詳細は、/dev/fuse を使用した高速ビルドへのアクセス を参照してください。

OpenShift Container Platform 4.15 以降、ログのリンクはデフォルトで有効化されています。ログのリンクにより、Pod のコンテナーログにアクセスできるようになります。

ImageContentSourcePolicy (ICSP)、ImageDigestMirrorSet (IDMS)、および ImageTagMirrorSet (ITMS) オブジェクトが、同じクラスター内で同時に機能するようになりました。以前は、新しい IDMS または ITMS オブジェクトを使用するには、ICSP オブジェクトを削除する必要がありました。これで、クラスターのインストール後に 3 種類のオブジェクトのいずれかまたはすべてを使用して、リポジトリーミラーリングを設定できるようになります。詳細は、Image Registry リポジトリーのミラーリングについて を参照してください。

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

このリリースでは、Metrics Server コンポーネントをクラスター内モニタリングスタックに追加するためのテクノロジープレビューオプションが導入されています。FeatureGate カスタムリソースが TechPreviewNoUpgrade オプションで設定されている場合、テクノロジープレビュー機能として、Prometheus Adapter の代わりに Metrics Server が自動的にインストールされます。インストールされると、Metrics Server は、リソースメトリクスを収集して metrics.k8s.io Metrics API サービスで公開し、他のツールや API で使用できるようにします。Prometheus Adapter の代わりに Metrics Server を使用すると、コアプラットフォームの Prometheus スタックがこの機能を処理しなくなります。詳細は、Cluster Monitoring Operator の config map API リファレンスの MetricsServerConfig および フィーチャーゲートを使用した機能の有効化 を参照してください。

ユーザー定義プロジェクトは、リモート書き込みを使用して、Prometheus によって収集されたサンプルデータをリモートストレージに送信できるようになりました。この機能を使用するには、RemoteWriteSpec リソースの sendExemplars オプションを使用して、リモート書き込みを設定します。詳細は、Cluster Monitoring Operator の config map API リファレンスの RemoteWriteSpec を参照してください。

ユーザー定義プロジェクトのアプリケーションは、Thanos Querier のルールテナンシーポートを介して、アプリケーション namespace のアラートをクエリーする API アクセスが可能となりました。HTTP 要求に namespace パラメーターが含まれている場合、Thanos Querier のポート 9093 経由で /api/v1/alerts エンドポイントにアクセスするクエリーを構築できるようになりました。以前のリリースでは、Thanos Querier のルールテナンシーポートは /api/v1/alerts エンドポイントへの API アクセスを提供しませんでした。

モニタリングスタックのデフォルトの Prometheus 設定が更新され、スクレイピング時のジッターが許容されるようになりました。データストレージのチャンク圧縮が最適ではないモニタリングデプロイメントの場合、この更新はデータ圧縮の最適化に役立ち、その結果、これらのデプロイメントで時系列データベースによって使用されるディスク領域が削減されます。

アラートと時間集計が正確となるように、kubelet サービスモニターの陳腐化処理が改されました。この改善された機能はデフォルトでアクティブになり、専用のサービスモニター機能は廃止されます。その結果、専用サービスモニター機能が無効化され、現在は非推奨となっており、DedicatedServiceMonitors リソースを enabled に設定しても効果はありません。

コンポーネントのモニタリングでタスクが失敗したときに提供される理由がより詳細に表示されるようになり、報告された障害の原因が openshift-monitoring namespace にデプロイされたコンポーネントにあるのか、openshift-user-workload-monitoring namespace にあるのかをより簡単に特定できるようになりました。Cluster Monitoring Operator (CMO) がタスクの失敗を報告した場合、失敗の原因を特定するために次の理由が追加されています。

ハブテンプレートを使用して、マネージドクラスターに適用される生成されたポリシーにグループとサイトの値を入力することで、複数のクラスターの設定を管理できます。グループおよびサイトの PolicyGenTemplate (PGT) CR でハブテンプレートを使用すると、ハブクラスター上のポリシーの数を大幅に減らすことができます。詳細は、ハブテンプレートを使用して PolicyGenTemplate CR グループのグループとサイトの設定を指定する を参照してください。

レイテンシーテスト用の Cloud-native Network Functions (CNF) テストイメージ (cnf-tests) が簡素化されました。新しいイメージには、レイテンシー測定のための 3 つのテストが含まれています。テストはデフォルトで実行され、クラスター上に設定されたパフォーマンスプロファイルが必要です。パフォーマンスプロファイルが設定されていない場合、テストは実行されません。

次の変数の使用は推奨されなくなりました。

junit レポートを生成するには、--ginkgo.junit-report フラグを --junit に置き換えます。

詳細は、プラットフォーム検証のためのレイテンシーテストの実行 を参照してください。

OpenShift Container Platform 4.15 の場合、Bare Metal Operator がクラスターからホストを削除すると、ホストの電源もオフになります。この機能拡張により、ハードウェアのメンテナンスと管理が合理化されます。

このリリースでは、非ベアメタルエージェントマシンを使用して、Hosted Control Plane クラスターをプロビジョニングできます。詳細は、非ベアメタルエージェントマシンを使用した Hosted Control Plane クラスターの設定 (テクノロジープレビュー) を参照してください。

このリリースでは、OpenShift Container Platform コンソールを使用して、ホストされたクラスターを KubeVirt プラットフォームで作成できるようになりました。Kubernetes Operator (MCE) のマルチクラスターエンジンにより、ホステッドクラスタービューが有効になります。詳細は、コンソールを使用したホステッドクラスターの作成 を参照してください。

このリリースでは、追加のネットワークの設定、仮想マシン用の Guaranteed CPU へのアクセス要求、およびノードプールの KubeVirt 仮想マシンのスケジュール管理を実行できるようになりました。詳細は、追加のネットワーク、Guaranteed CPU、およびノードプールの仮想マシンのスケジュールを設定する を参照してください。

OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。

Bare Metal Event Relay Operator は非推奨になりました。Bare Metal Event Relay Operator を使用してベアメタルホストを監視する機能は、今後の OpenShift Container Platform リリースでは削除される予定です。

Service Binding Operator は非推奨となり、OpenShift Container Platform 4.16 リリースで削除されます。Red Hat は、現行リリースのライフサイクル中はこのコンポーネントの重大なバグ修正とサポートを提供しますが、今後このコンポーネントに対する機能強化は行われません。

このリリースでは、コアプラットフォームモニタリングのための専用サービスモニター機能は非推奨になりました。openshift-monitoring namespace の cluster-monitoring-config config map オブジェクトで dedicatedServiceMonitors を設定することで専用サービスモニターを有効にする機能は、今後の OpenShift Container Platform リリースでは削除される予定です。この機能に代わり、アラートと時間集計が正確となるように Prometheus 機能が改善されました。この改善された機能はデフォルトでアクティブになり、専用のサービスモニター機能は廃止されます。

このリリースでは、コアプラットフォーム監視用の Prometheus アダプターコンポーネントは非推奨となり、今後のリリースで削除される予定です。Red Hat は、現行リリースのライフサイクル中はこのコンポーネントのバグ修正とサポートを提供しますが、今後このコンポーネントに対する機能強化は行われません。代わりに、新しい Metrics Server コンポーネントが監視スタックに追加されました。Metrics Server は、その機能については Prometheus に依存しないため、よりシンプルで軽量なソリューションです。Metrics Server は、スケーラビリティーとリソースメトリクスをより正確に追跡できるようにします。このリリースでは、FeatureGate カスタムリソースで TechPreviewNoUpgrade オプションを有効にすると、Metrics Server の改善機能がデフォルトで利用できるようになります。

このリリースでは、実験的な oc registry info コマンドは非推奨になりました。

統合された OpenShift Image Registry に関する情報を表示するには、oc get imagestream -n openshift を実行し、IMAGE REPOSITORY 列を確認します。

OpenShift Container Platform 4.15 では、OPENSHIFT_DEFAULT_REGISTRY 変数のサポートが削除されました。この変数は主に、以前のセットアップの内部 Image Registry で下位互換性を有効にするために使用されました。REGISTRY_OPENSHIFT_SERVER_ADDR 変数を代わりに使用できます。

OpenShift Container Platform 4.15 の時点で、kuryr を使用した RHOSP へのクラスターインストールのサポートは削除されました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以下の機能拡張は、この z-stream リリースに含まれています。

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

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

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

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

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

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

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