リリースノート

このリリースでは、Cloud Credential Operator (CCO) ユーティリティー (ccoctl) を使用して、以下のクラウドプロバイダーにインストールされているクラスターの OpenID Connect (OIDC) のバインドされたサービスアカウント署名者キーをローテーションできます。

このリリースにより、OpenShift Container Platform クラスターを最大 90 日間ハイバネート状態にし、クラスターが正常に回復することを期待できるようになりました。このリリースより前は、最大 30 日間ハイバネートすることしかできませんでした。

詳細は、OpenShift Container Platform クラスターのハイバーネート を参照してください。

etcd 障害復旧ドキュメントが更新され、簡素化されました。通常の障害復旧の場合も、以前のバックアップを使用したクラスターの完全復元の場合も、より迅速にクラスターを復旧できるようになりました。

復元手順の多くのステップを完了できる 2 つのスクリプト (quorum-restore.sh と cluster-restore.sh) が導入されました。

さらに、正常なノードが少なくとも 1 つ存在する場合にクラスターをより迅速に復元するための手順が追加されました。残存ノードのいずれかが特定の基準を満たしている場合は、それを使用して復元を実行できます。

詳細は、障害復旧について を参照してください。

このリリースでは、クラスターをインストールしてから最大 1 年間は、シングルノード OpenShift クラスターをシャットダウンして再起動できます。クラスターのシャットダウン中に証明書の有効期限が切れた場合は、クラスターの再起動時に証明書署名要求 (CSR) を承認する必要があります。

この更新前は、シングルノード OpenShift クラスターをシャットダウンして再起動できるのは、クラスターのインストール後 120 日間でした。

詳細は、クラスターのグレースフルシャットダウン を参照してください。

Operator Lifecycle Manager (OLM) は、最初のリリースから OpenShift Container Platform 4 に含まれており、Operator として実行されるソリューションや高度なワークロードの実質的なエコシステムの実現と発展に貢献してきました。

OpenShift Container Platform 4.18 では、OpenShift Container Platform での Operator 管理方法を改善するために設計された次世代 Operator Lifecycle Manager である OLM v1 が一般提供 (GA) 機能として導入されました。

OpenShift Container Platform 4.18 で OLM v1 の一般提供が開始されたことに伴い、OpenShift Container Platform 4 のリリース以降に含まれる既存の OLM バージョンは OLM (Classic) と呼ばれるようになりました。

これまではテクノロジープレビュー機能としてのみ利用可能でしたが、OLM v1 の更新されたフレームワークでは、Operator 管理の簡素化、セキュリティーの強化、信頼性の向上により、OLM (Classic) の一部であった多くの概念が進化しています。

現在、Operator Lifecycle Manager (OLM) v1 は、次のすべての条件を満たすクラスター拡張機能のインストールをサポートしています。

OLM v1 は、インストールする拡張機能がこれらの制約を満たしているかどうかを確認します。インストールする拡張機能がこれらの制約を満たしていない場合、クラスター拡張機能の条件にエラーメッセージが出力されます。

特にミッションクリティカルな実稼働ワークロードのために、インターネット非接続環境でクラスターを実行することで高いセキュリティーを優先するクラスター管理者をサポートするために、OLM v1 は OpenShift Container Platform 4.18 以降で非接続環境をサポートします。

OpenShift CLI の oc-mirror プラグイン (oc) を使用して、クラスターに必要なイメージを完全または部分的な非接続環境のミラーレジストリーにミラーリングした後、oc-mirror プラグイン v1 または v2 のいずれかによって生成されたリソースセットを利用することで、OLM v1 はこれらの環境で適切に機能できます。

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

このリリースでは、クラスター拡張機能のインストール時または更新時に、次のアクションを実行してカタログコンテンツの選択を制御できます。

詳細は、カタログコンテンツの解決 を参照してください。

このリリースでは、Operator Controller と catalogd がプロキシー環境で実行できるようになり、信頼済み CA 証明書の基本的なサポートが含まれるようになりました。

クラスター管理者は、OpenShift Container Platform クラスターを次のマイナーバージョンに更新する前に、インストールされているすべての Operator がクラスターの次のマイナーバージョン (4.y+1) と互換性のあるバンドルバージョンに更新されていることを確認する必要があります。

OpenShift Container Platform 4.18 以降、OLM v1 は Operator のクラスターサービスバージョン (CSV) で olm.maxOpenShiftVersion アノテーションをサポートします。これは、OLM (Classic) の動作と同じように、インストールされた Operator を互換性のあるバージョンに更新する前に管理者がクラスターを更新することを防ぎます。

詳細は、OpenShift Container Platform バージョンとの互換性 を参照してください。

クラスター拡張機能がインストールされ、Operator Lifecycle Manager (OLM) v1 によって管理されるようになると、多くの場合、拡張機能はクラスター上で新しい API リソースを公開する CustomResourceDefinition オブジェクト (CRD) を提供できるようになります。通常、クラスター管理者はデフォルトでこれらのリソースへの完全な管理アクセス権を持ちますが、クラスター管理者以外のユーザー、つまり 通常のユーザー は十分な権限を持たない可能性があります。

OLM v1 では、インストールされた拡張機能が提供する API を通常のユーザーが操作できるように、ロールベースのアクセス制御 (RBAC) を自動的に設定または管理することはありません。クラスター管理者は、このようなユーザー向けにカスタムリソース (CR) を作成、表示、または編集するために必要な RBAC ポリシーを定義する必要があります。

詳細は、拡張機能リソースへのユーザーアクセス を参照してください。

OpenShift Container Platform 4.18 以降では、コンテナーイメージの sigstore 署名のランタイム検証を処理するための OLM v1 サポートがテクノロジープレビュー (TP) 機能として利用可能になっています。

Operator Lifecycle Manager (OLM) v1 は、OLM (Classic) で導入された OperatorConditions API をサポートしていません。

拡張機能が OperatorConditions API のみに依存して更新を管理している場合、拡張機能が正しくインストールされない可能性があります。この API に依存する拡張機能のほとんどは起動時に失敗しますが、一部は調整中に失敗する可能性があります。

回避策として、拡張機能を特定のバージョンに固定できます。拡張機能を更新する場合は、拡張機能のドキュメントを参照して、いつ拡張機能を新しいバージョンに固定すれば安全か確認してください。

SiteConfig v1 は、OpenShift Container Platform 4.18 以降で非推奨になります。ClusterInstance カスタムリソースを使用する SiteConfig Operator を通じて、同等の改良された機能が利用できるようになりました。詳細は、Red Hat ナレッジベースの Procedure to transition from SiteConfig CRs to the ClusterInstance API を参照してください。

SiteConfig Operator の詳細は、SiteConfig を参照してください。

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

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

このリリースでは、ワークロードデータを収集する Insights Runtime Extractor 機能が Insights Operator に導入されました。これにより、Red Hat がお客様のコンテナーのワークロードをより的確に把握できるようになります。テクノロジープレビューとして提供される Insights Runtime Extractor 機能は、ランタイムワークロードデータを収集し、Red Hat に送信します。Red Hat は、OpenShift Container Platform コンテナーの使用方法を推進および最適化するお客様の投資判断に役立つ分析情報を入手するために、収集したランタイムワークロードデータを使用します。詳細は、フィーチャーゲートを使用した機能の有効化 を参照してください。

このリリースでは、Insights Operator が収集するデータを決定するルールをリモートで設定するための Rapid Recommendations メカニズムが強化されました。

Rapid Recommendations 機能はバージョンに依存せず、既存の条件付きデータ収集メカニズムに基づいてビルドされます。

Insights Operator は、console.redhat.com で実行されているセキュアなリモートエンドポイントサービスに接続し、Red Hat がフィルタリングおよび収集するコンテナーログメッセージを決定するルールが含まれる定義を取得します。

条件付きデータ収集の定義は、pod.yml 設定ファイルの conditionalGathererEndpoint 属性を通じて設定されます。

conditionalGathererEndpoint: https://console.redhat.com/api/gathering/v2/%s/gathering_rules

conditionalGathererEndpoint: https://console.redhat.com/api/gathering/v2/%s/gathering_rules

事前設定済みのエンドポイント URL に、OpenShift Container Platform のターゲットバージョンを定義するためのプレースホルダー (%s) が追加されました。

Insights Operator は、以下の状況を検出するために、さらに多くのデータを収集するようになりました。このデータを他のアプリケーションで使用して、OpenShift Container Platform のデプロイメントをプロアクティブに管理するための修復推奨事項を生成できます。

インストールプログラムでは、Transit Gateway の修正が含まれる新しいバージョンの Cluster API Provider IBM Cloud プロバイダーが使用されるようになりました。IBM Cloud の Transit Gateway のコストを考慮して、OpenShift Container Platform クラスターの作成時に OpenShift Container Platform を使用して Transit Gateway を作成できるようになりました。詳細は、(OCPBUGS-37588) および (OCPBUGS-41938) を参照してください。

このリリースにより、クラスターのインストール時に ovn-kubernetes によって内部で使用される IPv4 join サブネットを設定できるようになりました。install-config.yaml ファイルで internalJoinSubnet パラメーターを設定し、クラスターを既存の Virtual Private Cloud (VPC) にデプロイできます。

詳細は、ネットワーク設定パラメーター を参照してください。

クラスターの更新時に、oc adm upgrade コマンドは次の利用可能なバージョンのリストを返します。4.18 oc クライアントバイナリーを使用している限り、更新を開始する前に、oc adm upgrade recommend コマンドを使用して提案を絞り込み、新しいターゲットリリースを推奨することができます。この機能は、更新サービスに接続されている OpenShift Container Platform バージョン 4.16 以降のクラスターで利用できます。

詳細は、CLI を使用したクラスター更新 を参照してください。

このリリースでは、AWS の Nutanix Cloud クラスター (NC2)、Azure の NC2 に OpenShift Container Platform をインストールできます。

詳細は、インフラストラクチャーの要件 を参照してください。

このリリースでは、コンピュートまたはコントロールプレーンマシン用の C4 および C4A マシンシリーズを使用して、GCP にクラスターをデプロイできます。これらのマシンでサポートされるディスクタイプは hyperdisk-balanced です。Hyperdisk ストレージを必要とするインスタンスタイプを使用する場合は、クラスター内のすべてのノードが Hyperdisk ストレージをサポートする必要があり、Hyperdisk ストレージを使用するようにデフォルトのストレージクラスを変更する必要があります。

マシンタイプの設定に関する詳細は、GCP のインストール設定パラメーター、C4 machine series (Compute Engine ドキュメント)、および C4A machine series (Compute Engine ドキュメント) を参照してください。

このリリースでは、GCP 上のクラスターを共有 VPC にインストールするときに、独自のプライベートホストゾーンを提供できます。その場合、Bring Your Own (BYO) ゾーンの要件として、そのゾーンは <cluster_name>.<base_domain>. などの DNS 名を使用し、ゾーンをクラスターの VPC ネットワークにバインドする必要があります。

詳細は、GCP 上のクラスターを共有 VPC にインストールするための前提条件 および Deployment Manager テンプレートを使用して GCP の共有 VPC にクラスターをインストールするための前提条件 を参照してください。

このリリースでは、プライベートクラウドまたはパブリッククラウドから名前付きの事前ロードされた RHCOS イメージオブジェクトを使用して、Nutanix にクラスターをインストールできます。OpenShift Container Platform クラスターごとに RHCOS イメージオブジェクトを作成してアップロードする代わりに、install-config.yaml ファイルで preloadedOSImageName パラメーターを使用できます。

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

RHOSP にシングルスタック IPv6 クラスターをデプロイできるようになりました。

OpenShift Container Platform クラスターをデプロイする前に、RHOSP を設定する必要があります。詳細は、シングルスタック IPv6 ネットワークを使用したクラスターの設定 を参照してください。

このリリースでは、OpenShift Container Platform クラスターをデプロイする Prism Element に対して、複数のサブネットを持つ Nutanix クラスターをインストールできます。

詳細は、障害ドメインの設定 および 追加の Nutanix 設定パラメーター を参照してください。

既存の Nutanix クラスターの場合、コンピュート または コントロールプレーン のマシンセットを使用して複数のサブネットを追加できます。

このリリースでは、ノードに複数のネットワークインターフェイスコントローラー (NIC) を備えた VMware vSphere クラスターをインストールできます。

詳細は、複数の NIC の設定 を参照してください。

既存の vSphere クラスターの場合、コンピュートマシンセット を使用して複数のサブネットを追加できます。

このリリースでは、Agent-based Installer を使用していれば、4 ノードまたは 5 ノードのコントロールプレーンをインストールできるようにクラスターを設定できるようになりました。この機能は、install-config.yaml ファイルで controlPlane.replicas パラメーターを 4 または 5 に設定することで有効になります。

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

このリリースでは、Agent-based Installer は、すべてのサポート対象プラットフォームで最小限の ISO イメージの作成をサポートします。以前は、最小限の ISO イメージは external プラットフォームでのみサポートされていました。

この機能は、agent-config.yaml ファイルの minimalISO パラメーターを使用して有効にできます。

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

このリリースでは、Agent-based Installer は、iSCSI ターゲットから OpenShift Container Platform クラスターを起動するために使用できるアセットの作成をサポートします。

詳細は、iSCSI ブート用のインストールアセットの準備 を参照してください。

ブートイメージの更新が、Amazon Web Services (AWS) クラスターで GA にプロモートされました。詳細は、ブートイメージの更新 を参照してください。

マシン設定ノードのカスタムリソースは、ノードへのマシン設定の更新の進行状況を監視するために使用できます。このカスタムリソースに、更新に関する詳細情報が表示されるようになりました。oc get machineconfignodes コマンドの出力で、以下の状態やその他の状態が報告されるようになりました。これらのステータスを使用して更新を追跡したり、更新中にエラーが発生した場合にノードのトラブルシューティングを行ったりできます。

クラスター上のレイヤー化機能にいくつかの重要な変更があります。

クラスター上のレイヤー化の詳細は、クラスター上のレイヤー化を使用してカスタムレイヤーイメージを適用する を参照してください。

このリリースにより、Microsoft Azure クラスターのテクノロジープレビューとして、OpenShift Container Platform に統合されたアップストリーム Cluster API を使用してマシンを管理する機能が導入されました。この機能は、Machine API を使用してマシンを管理するための追加または代替の機能になります。詳細は、Cluster API について を参照してください。

この更新により、OpenShift Lightspeed Operator のインストール時に、クラスター監視を有効にするためのチェックボックスがデフォルトでオンに設定されるようになりました。(OCPBUGS-42381)

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

この更新により、ユーザーのワークロードを監視するために、Prometheus の連続スクレイピングの間隔とルール評価の間隔を設定できるようになりました。

この更新では、cluster-monitoring-config および user-workload-monitoring-config config map のモニタリング設定の変更に対する早期検証が導入され、フィードバックループが短縮され、ユーザーエクスペリエンスが向上します。

この更新により、Alertmanager はプロキシー環境変数を使用するようになります。したがって、クラスター全体の HTTP プロキシーを設定した場合は、アラートレシーバーまたは Alertmanager のグローバル設定レベルで proxy_from_environment パラメーターを true に設定することで、プロキシーを有効にできます。

この更新により、複数のプロジェクトに対して同時にクエリーを実行するユーザーワークロードアラートおよび記録ルールを作成できるようになります。

Red Hat OpenStack Services on OpenShift (RHOSO) で実行されるクラスターの可観測性メトリクスを相関させることができるようになりました。両方の環境からメトリクスを収集することで、インフラストラクチャーレイヤーとアプリケーションレイヤー全体の問題を監視およびトラブルシューティングできます。

詳細は、RHOSO で実行されるクラスターのモニタリング を参照してください。

SR-IOV Network Operator を ARM アーキテクチャーで実行されるクラスターにデプロイできるようになりました。(OCPBUGS-56496)

このリリースでは、ソースとして Global Navigation Satellite System (GNSS) を使用して、グランドマスター (T-GM) クロックのホールドオーバー動作を設定できます。ホールドオーバーにより、GNSS ソースが利用できない場合でも T-GM クロックは同期パフォーマンスを維持できます。この期間中、T-GM クロックは内部オシレーターとホールドオーバーパラメーターに依存してタイミングの中断を削減します。

PTPConfig カスタムリソース (CR) で次のホールドオーバーパラメーターを設定することにより、ホールドオーバー動作を定義できます。

詳細は、GNSS をソースとするグランドマスタークロックのホールドオーバー を参照してください。

このリリースでは、次のネットワークタイプに対してマルチネットワークポリシーを設定できます。

詳細は、マルチネットワークポリシーの設定 を参照してください。

ip_whitelist アノテーションおよび ip_blacklist アノテーションの用語が、それぞれ ip_allowlist および ip_denylist に更新されました。現在、OpenShift Container Platform は、ip_whitelist および ip_blacklist アノテーションを引き続きサポートしています。ただし、これらのアノテーションは今後のリリースで削除される予定です。

OVN-Kubernetes ネットワークトラフィックは、CLI を介した次のネットワーク API の OVS サンプリングで表示できます。

CLI を使用して OVS サンプリングで OVN-Kubernetes ネットワークトラフィックを確認することは、パケットのトレースに役立つことを目的としています。これは、Network Observability Operator のインストール時にも使用できます。

詳細は、CLI を使用して OVS サンプリングで OVN-Kubernetes ネットワークトラフィックを確認する を参照してください。

OpenShift Container Platform 4.18 では、ユーザー定義のネットワークセグメンテーションが一般利用可能になりました。ユーザー定義ネットワーク (UDN) では、管理者が、namespace がスコープ指定された UserDefinedNetwork とクラスターがスコープ指定された ClusterUserDefinedNetwork カスタムリソースを使用してカスタムネットワークトポロジーを定義できるようにすることで、ネットワークセグメンテーション機能を強化しました。

管理者は、UDN を使用して、強化された分離機能、ワークロードの IP アドレス管理機能、および高度なネットワーク機能を備えた、カスタマイズしたネットワークトポロジーを作成できます。レイヤー 2 とレイヤー 3 の両方のトポロジータイプをサポートするユーザー定義のネットワークセグメンテーションにより、幅広いネットワークアーキテクチャーとトポロジーが可能になり、ネットワークの柔軟性、セキュリティー、パフォーマンスが向上します。サポートされている機能の詳細は、UDN サポートマトリックス を参照してください。

UDN のユースケースとしては、仮想マシン (仮想マシン) に静的 IP アドレスの有効期間を割り当てる場合や、レイヤー 2 のプライマリー Pod ネットワークを提供してユーザーがノード間で仮想マシンをライブマイグレーションできるようにする場合などがあります。これらの機能はすべて OpenShift Virtualization に完全に装備されています。ユーザーは UDN を使用して、より強力なネイティブマルチテナント環境を作成し、デフォルトでオープンになっているオーバーレイ Kubernetes ネットワークを保護できます。詳細は、ユーザー定義ネットワークについて を参照してください。

Ingress Controller の Dynamic Configuration Manager を使用すると、メモリーフットプリントを削減できます。Dynamic Configuration Manager は、動的 API 経由でエンドポイントの変更を伝播します。このプロセスにより、基礎となるルーターはリロードなしで変更 (スケールアップおよびスケールダウン) に適応できます。

Dynamic Configuration Manager を使用するには、次のコマンドを実行して TechPreviewNoUpgrade 機能セットを有効にします。

oc patch featuregates cluster -p '{"spec": {"featureSet": "TechPreviewNoUpgrade"}}' --type=merge

$ oc patch featuregates cluster -p '{"spec": {"featureSet": "TechPreviewNoUpgrade"}}' --type=merge

このリリースにより、以下の環境で OpenShift Container Platform サービスへの Ingress フローのネットワーク情報を表示できるようになりました。

詳細は、OpenShift Container Platform ネットワークフローマトリックス を参照してください。

このリリースでは、MetalLB に Border Gateway Protocol (BGP) ピアカスタムリソース用の新しいフィールドが含まれています。dynamicASN フィールドを使用して、BGP セッションのリモートエンドに使用する自律システム番号 (ASN) を検出できます。これは、spec.peerASN フィールドに ASN を明示的に設定する代わりに使用できます。

このリリースでは、Single Root I/O Virtualization (SR-IOV) で Remote Direct Memory Access (RDMA) Container Network Interface (CNI) を設定して、コンテナー間の高パフォーマンスで低遅延の通信を実現できます。RDMA と SR-IOV を組み合わせると、Data Plane Development Kit (DPDK) アプリケーション内で使用するために Mellanox Ethernet デバイスのハードウェアカウンターを公開するメカニズムが提供されます。

このリリースでは、システムでセキュアブートが有効になっている場合に、Single Root I/O Virtualization (SR-IOV) Network Operator を設定できます。SR-IOV Operator は、最初に Mellanox デバイスのファームウェアを手動で設定した後に設定されます。セキュアブートを有効にすると、システムの回復力が強化され、コンピューターの全体的なセキュリティーに対する重要な防御層が提供されます。

詳細は、セキュアブートが有効な場合における Mellanox カードでの SR-IOV Network Operator の設定 を参照してください。

このリリースでは、RHOSP で実行されているクラスターの Ingress コントローラーで、事前に作成された Floating IP アドレスを指定できるようになりました。

詳細は、Ingress Controller で Floating IP アドレスを指定する を参照してください。

SR-IOV Network Operator は、Intel NetSec アクセラレーターカードと Marvell Octeon 10 DPU をサポートするようになりました。(OCPBUGS-43451)

OVN-Kubernetes プラグインは、Open vSwitch (OVS) のデフォルトポート接続として Linux ブリッジインターフェイスを使用できるようになりました。これは、SmartNIC などのネットワークインターフェイスコントローラーが、基盤となるネットワークとホストをブリッジできるようになったことを意味します。(OCPBUGS-39226)

制限付きライブマイグレーションメソッドを開始し、ネットワークの重複に関する問題が存在する場合、Cluster Network Operator (CNO) は、その問題のネットワーク重複メトリクスを公開できるようになりました。これは、openshift_network_operator_live_migration_blocked メトリクスに新しい NetworkOverlap ラベルが含まれるようになったために可能になりました。(OCPBUGS-39096)

以前は、NetworkAttachmentDefinition CR はイミュータブルでした。このリリースでは、既存の NetworkAttachmentDefinition CR を編集できます。編集がサポートされていることにより、ネットワークインターフェイスの MTU の調整など、基盤となるネットワークインフラストラクチャーの変更に簡単に対応できます。

同じネットワーク name と type: ovn-k8s-cni-overlay を参照する各 NetworkAttachmentDefinition CR の設定が同期されていることを確認する必要があります。これらの値が同期している場合にのみ、ネットワークアタッチメントの更新は成功します。設定が同期されていない場合、OpenShift Container Platform がどの NetworkAttachmentDefinition CR を設定に使用するかが確定されないため、動作は未定義になります。

ネットワークの変更を Pod で有効にするには、ネットワークアタッチメント定義を使用するワークロードを再起動する必要があります。

crun は、OpenShift Container Platform で作成された新しいコンテナーのデフォルトのコンテナーランタイムになりました。runC ランタイムは引き続きサポートされており、必要に応じてデフォルトのランタイムを runC に変更できます。crun の詳細は、コンテナーエンジンとコンテナーランタイムについて を参照してください。デフォルトを runC に変更する方法については、CRI-O パラメーターを編集するための ContainerRuntimeConfig CR の作成 を参照してください。

OpenShift Container Platform 4.17.z から OpenShift Container Platform 4.18 に更新しても、コンテナーのランタイムは変更されません。

sigstore プロジェクトはテクノロジープレビューとして提供されており、これを OpenShift Container Platform でサプライチェーンのセキュリティー向上のために使用できます。クラスター全体のレベル、または特定の namespace に対して署名ポリシーを作成できます。詳細は、sigstore を使用したセキュアな署名管理 を参照してください。

OpenShift Container Platform 4.17 で導入された オンプレミスクラスターにワーカーノードを追加する プロセスが拡張されました。このリリースでは、ISO イメージファイルの代わりに Preboot Execution Environment (PXE) アセットを生成できるようになりました。また、ノード作成プロセスが失敗したかどうかにかかわらず、レポートが生成されるように設定することもできます。

Node Tuning Operator が、Intel および AMD CPU のカーネル引数と管理オプションを適切に選択できるようになりました。(OCPBUGS-43664)

クラスター Node Tuning Operator によって設定されるデフォルトのコンテナーランタイムは、必ずクラスターから継承され、Operator によりハードコードされることはありません。このリリースから、デフォルト値は crun になります。(OCPBUGS-45450)

oc-mirror プラグイン v2 が一般公開されました。これを使用するには、oc-mirror コマンドを実行するときに --v2 フラグを追加します。--v2 フラグが設定されていない場合に実行される以前のバージョン (oc-mirror プラグイン v1) は非推奨になりました。継続的なサポートと改善のために、oc-mirror プラグイン v2 に移行することが推奨されます。

詳細は、oc-mirror プラグイン v2 を使用した非接続インストールのイメージのミラーリング を参照してください。

oc-mirror プラグイン v2 は、Helm チャートのミラーリングをサポートするようになりました。また、oc-mirror プラグイン v2 は、HTTP/S プロキシーが有効になっている環境でも使用できるようになりました。これにより、エンタープライズセットアップとの幅広い互換性が確保されます。

oc-mirror プラグイン v2 では、Operator カタログの v1 後方互換フィルタリングが導入され、フィルタリングされたカタログが生成されます。この機能により、クラスター管理者は、元のカタログの完全なリストではなく、ミラーリングされた Operator のみを表示できます。

OpenShift Container Platform 4.18 以降で Operator Lifecycle Manager (OLM) v1 が一般提供 (GA) 機能としてリリースされるため、OpenShift Container Platform 4 以降に含まれている OLM の既存バージョンは OLM (Classic) と呼ばれるようになりました。

OLM v1 の GA リリースの詳細は、拡張機能 (OLM v1) リリースノートセクションを参照してください。OLM v1 に重点を置いた完全なドキュメントについては、拡張機能 ガイドを参照してください。

OLM (Classic) に重点を置いた完全なドキュメントについては、引き続き Operator ガイドを参照してください。

Oracle® Cloud Infrastructure (OCI) 上の OpenShift Container Platform クラスターのインストールが、ベアメタルマシンでサポートされるようになりました。Assisted Installer または Agent-based Installer を使用して、OCI にベアメタルクラスターをインストールできます。OCI にベアメタルクラスターをインストールするには、次のいずれかのインストールオプションを選択します。

このリリースでは、Amazon Web Services (AWS) 上のクラスター内のコントロールプレーンを x86 から arm64 アーキテクチャーに移行できます。詳細は、Amazon Web Services で x86 コントロールプレーンを arm64 アーキテクチャーに移行する を参照してください。

この機能では、image.config.openshift.io/cluster リソースに新しいフィールド imageStreamImportMode が導入されます。imageStreamImportMode フィールドは、イメージストリームのインポートモードの動作を制御します。imageStreamImportMode フィールドを、次のいずれかの値に設定できます。

詳細は、イメージコントローラーの設定パラメーター を参照してください。

imageStreamImportMode 機能を有効にするには、FeatureGate カスタムリソース (CR) で TechPreviewNoUpgrade 機能セットを有効にする必要があります。詳細は、フィーチャーゲートについて を参照してください。

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

以前のバージョンの OpenShift Container Platform では、読み取り専用としてマウントされたストレージは、ストレージエラーに関する特定のメトリクスや情報を返しませんでした。これにより、ストレージバックエンドが読み取り専用であった場合に、レジストリーがサイレントな失敗となる可能性がありました。このリリースでは、バックエンドが読み取り専用に設定されている場合にストレージ情報を返すために、次のアラートが追加されました。

cluster-compare プラグインは、クラスター設定とターゲット設定を比較する OpenShift CLI (oc) プラグインです。このプラグインは、設定可能な検証ルールとテンプレートを使用して、設定の差異を報告する一方で、想定内の差異は除外します。

たとえばプラグインは、オプションのコンポーネントやハードウェア固有のフィールドなど、想定内の違いを無視する一方で、フィールドの値の不一致、リソースの欠落、バージョンの不一致など、想定外の違いを強調できます。このように比較することで、ターゲット設定でクラスターコンプライアンスを簡単に評価できます。

cluster-compare プラグインは、開発、実稼働、およびサポートのシナリオで使用できます。

cluster-compare プラグインの詳細は、cluster-compare プラグインの概要 を参照してください。

このリリースでは、Node Tuning Operator にチューニング更新の延期に対するサポートが導入されました。管理者はこの機能を使用して、メンテナンス期間中に更新を適用するようにスケジュールできます。

詳細は、チューニング変更適用の延期 を参照してください。

このリリースでは、NUMA Resources Operator は、ターゲットノードへの Operator コンポーネントのインストールを有効にするカスタム SELinux ポリシーを作成しなくなりました。代わりに、Operator は組み込みのコンテナー SELinux ポリシーを使用します。この変更により、以前はインストール中にカスタム SELinux ポリシーを適用する際に必要であった追加のノードの再起動が不要になります。

このリリースでは、パフォーマンスプロファイルを適用すると、Node Tuning Operator がプラットフォームを検出し、それに応じてカーネル引数やその他のプラットフォーム固有のオプションを設定します。このリリースでは、次のプラットフォームを検出するためのサポートが追加されました。

このリリースでは、PerformanceProfile カスタムリソース (CR) を使用して、AMD EPYC Zen 4 CPU (Genoa および Bergamo など) を搭載したマシンでワーカーノードを設定できます。これらの CPU は、単一の NUMA ドメイン (NPS=1) で設定されている場合に完全にサポートされます。

以前は、LVMCluster カスタムリソース (CR) の thinPoolConfig.overprovisionRatio フィールドは、LVMCluster CR の作成中にのみ設定できました。このリリースにより、LVMCluster CR の作成後にも thinPoolConfig.overprovisionRatio フィールドを更新できるようになりました。

この機能により、LVMCluster カスタムリソース (CR) に次の新しいオプションフィールドが提供されます。

詳細は、LVMCluster カスタムリソースについて を参照してください。

OpenShift Container Platform は、Common Internet File System (CIFS) ダイアレクト/Server Message Block (SMB) プロトコル用の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。このドライバーを管理する CIFS/SMB CSI Driver Operator は、OpenShift Container Platform 4.16 でテクノロジープレビューステータスで導入されました。OpenShift Container Platform 4.18 では、一般提供が開始されました。

詳細は、CIFS/SMB CSI Driver Operator を参照してください。

Secrets Store Container Storage Interface (CSI) Driver Operator である secrets-store.csi.k8s.io を使用すると、OpenShift Container Platform がエンタープライズグレードの外部シークレットストアに保存されている複数のシークレット、キー、証明書をインラインの一時ボリュームとして Pod にマウントできます。Secrets Store CSI Driver Operator は、gRPC を使用してプロバイダーと通信し、指定された外部シークレットストアからマウントコンテンツを取得します。ボリュームがアタッチされると、その中のデータがコンテナーのファイルシステムにマウントされます。Secrets Store CSI Driver Operator は、OpenShift Container Platform 4.14 でテクノロジープレビュー機能として利用可能でした。OpenShift Container Platform 4.18 では、この機能の一般提供が開始されました。

Secrets Store CSI Driver の詳細は、Secrets Store CSI Driver Operator を参照してください。

Secrets Store CSI Driver Operator を使用して外部シークレットストアから CSI ボリュームにシークレットをマウントする方法については、外部シークレットストアを使用した機密データの Pod への提供 を参照してください。

OpenShift Container Platform 4.16 では、永続ボリューム (PV) が別のフェーズ (pv.Status.Phase) に移行するたびに更新されるタイムスタンプを持つ新しいパラメーター LastPhaseTransitionTime が導入されました。OpenShift Container Platform 4.18 では、この機能の一般提供が開始されました。

永続ボリュームの最終フェーズ遷移時間パラメーターの使用に関する詳細は、最終フェーズ遷移時間 を参照してください。

OpenShift Container Platform 4.17 では、テクノロジープレビュー機能として、複数の vSphere クラスター (vCenter) をまたいで OpenShift Container Platform をデプロイする機能が導入されました。OpenShift Container Platform 4.18 では、複数の vCenter に対するサポートが一般提供されるようになりました。

詳細は、vSphere CSI の複数の vCenter サポート および vSphere のインストール設定パラメーター を参照してください。

OpenShift Container Platform 4.18 より前は、永続ボリューム (PV) 回収ポリシーが常に適用されるとは限りませんでした。

バインドされた PV と永続ボリューム要求 (PVC) のペアの場合、PV 削除回収ポリシーが適用されるかどうは PV-PVC の削除順序によって決まります。PV を削除する前に PVC が削除された場合、PV は回収ポリシーを適用していました。しかし、PVC を削除する前に PV が削除された場合、回収ポリシーは適用されませんでした。この動作では、外部インフラストラクチャー内の関連付けられたストレージ資産は削除されませんでした。

OpenShift Container Platform 4.18 では、PV 回収ポリシーが常に一貫して適用されます。この機能はテクニカルプレビューです。

詳細は、永続ボリュームの回収ポリシー を参照してください。

OpenShift Container Platform 4.18 では、Local Storage Operator (LSO) のローカルボリューム (LV) とローカルボリュームセット (LVS) を削除する機能が向上し、アーティファクトが自動的に削除され、必要とする手順数が削減されます。

詳細は、ローカルボリュームまたはローカルボリュームセットの削除 を参照してください。

OpenShift Container Platform 4.18 では、テクノロジープレビュー機能として Container Storage Interface (CSI) ボリュームグループスナップショットが導入されています。この機能は CSI ドライバーによってサポートされている必要があります。CSI ボリュームグループスナップショットは、ラベルセレクターを使用して、スナップショット用に複数の永続ボリューム要求 (PVC) をグループ化します。ボリュームグループスナップショットは、同じ時点で取得された複数のボリュームからのコピーを表します。これは、複数のボリュームが含まれるアプリケーションに役立ちます。

OpenShift Data Foundation は、ボリュームグループのスナップショットをサポートしています。

CSI ボリュームグループスナップショットの詳細は、CSI ボリュームグループスナップショット を参照してください。

Google Cloud Platform Persistent Disk (GCP PD) Container Storage Interface (CSI) ドライバーは、ベアメタルおよび N4 マシンシリーズの C3 インスタンスタイプをサポートしています。C3 インスタンスタイプと N4 マシンシリーズは、ハイパーディスクバランスディスクをサポートします。

さらに、大規模ストレージ向けにハイパーディスクストレージプールがサポートされています。ハイパーディスクストレージプールは、購入した容量、スループット、および IOPS のコレクションであり、必要に応じてアプリケーションにプロビジョニングできます。

OpenShift Container Platform 4.18 では、この機能の一般提供が開始されました。

詳細は、ベアメタルおよび N4 マシンシリーズの C3 インスタンスタイプ を参照してください。

OpenShift Container Platform 4.18 では、OpenStack Manila は Container Storage Interface (CSI) 永続ボリューム (PV) の拡張をサポートしています。この機能は一般提供されています。

詳細は、永続ボリュームの拡張 および OpenShift Container Platform がサポートする CSI ドライバー を参照してください。

OpenShift Container Platform 4.18 では、Google Compute Platform (GCP) Filestore Container Storage Interface (CSI) ストレージが Workload Identity をサポートしています。これにより、ユーザーはサービスアカウントキーの代わりにフェデレーションアイデンティティーを使用して Google Cloud リソースにアクセスできます。OpenShift Container Platform 4.18 では、この機能の一般提供が開始されました。

詳細は、Google Compute Platform Filestore CSI Driver Operator を参照してください。

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

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

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

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

Shared Resource CSI Driver 機能は、OpenShift Container Platform 4.17 で非推奨となり、OpenShift Container Platform 4.18 からは削除されました。この機能は現在、Builds for Red Hat OpenShift 1.1 で一般提供されています。この機能を使用するには、Builds for Red Hat OpenShift 1.1 以降を使用している必要があります。

selected bundles 機能は、oc-mirror v2 の一般提供リリースから削除されました。この変更により、間違った Operator バンドルバージョンを指定するとクラスター内の Operator が壊れる可能性があるという問題が防止されます。(OCPBUGS-49419)

OpenShift Container Platform の次のマイナーリリースでは、Kubernetes 1.32 を使用する予定です。Kubernetes 1.32 では、非推奨の API が削除されました。

削除予定の Kubernetes API リストについては、アップストリームの Kubernetes ドキュメントで Deprecated API Migration Guide を参照してください。

削除予定である Kubernetes API のクラスターを確認する方法は、Navigating Kubernetes API deprecations and removals を参照してください。

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

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

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

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

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

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

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

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

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