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

OpenShift Container Platform 4.12 ブートイメージからインストールされた Red Hat Enterprise Linux CoreOS (RHCOS) ノードは、プラットフォーム固有のデフォルトコンソールを使用するようになりました。クラウドプラットフォームのデフォルトのコンソールは、そのクラウドプロバイダーが期待する特定のシステムコンソールに対応しています。VMware および OpenStack イメージは、プライマリーグラフィカルコンソールとセカンダリーシリアルコンソールを使用するようになりました。他のベアメタルインストールでは、デフォルトでグラフィカルコンソールのみが使用され、シリアルコンソールは有効になりません。coreos-installer を使用して実行されるインストールは、既存のデフォルトをオーバーライドして、シリアルコンソールを有効にすることができます。

既存のノードは影響を受けません。既存のクラスター上の新しいノードは、通常、クラスターのインストールに最初に使用されたブートイメージからインストールされるため、影響を受ける可能性はほとんどありません。

シリアルコンソールを有効にする方法については、次のドキュメントを参照してください。

OpenShift Container Platform は、テクノロジープレビュー機能として、IBM Z および LinuxONE (s390x アーキテクチャー) での IBM Secure Execution 用の Red Hat Enterprise Linux CoreOS (RHCOS) ノードの設定をサポートするようになりました。IBM Secure Execution は、KVM ゲストのメモリー境界を保護するハードウェア拡張機能です。IBM Secure Execution は、クラスターのワークロードに最高レベルの分離とセキュリティーを提供します。これは、IBM Secure Execution 対応の QCOW2 ブートイメージを使用して有効にすることができます。

IBM Secure Execution を使用するには、ホストマシンのホストキーが必要であり、Ignition 設定ファイルで指定する必要があります。IBM Secure Execution は、LUKS 暗号化を使用してブートボリュームを自動的に暗号化します。

詳細は、IBM Secure Execution を使用した RHCOS のインストール を参照してください。

RHCOS は、OpenShift Container Platform 4.12 で Red Hat Enterprise Linux (RHEL) 8.6 パッケージを使用するようになりました。これにより、最新の修正、機能、機能拡張、および最新のハードウェアサポートおよびドライバー更新を利用できます。OpenShift Container Platform 4.10 は延長更新サポート (EUS) リリースです。このリリースは、ライフサイクル全体に対して RHEL 8.4 EUS パッケージを引き続き使用します。

console.redhat.com の Assisted Installer SaaS は、Assisted Installer ユーザーインターフェイスまたは REST API を使用したマシン API 統合により、Nutanix プラットフォームへの OpenShift Container Platform のインストールをサポートします。統合により、Nutanix Prism ユーザーは 1 つのインターフェイスからインフラストラクチャーを管理でき、自動スケーリングが実現します。Nutanix と Assisted Installer SaaS の統合を有効にするには、追加のインストール手順がいくつかあります。詳細については、自動インストーラーのドキュメントを参照してください。

OpenShift Container Platform 4.12 以降、インストール時に AWS の永続的なロードバランサータイプとして Network Load Balancer (NLB) または Classic のいずれかを指定できます。その後、イングレスコントローラーが削除された場合、ロードバランサーのタイプは、インストール中に設定された lbType で保持されます。

詳細について は、ネットワークのカスタマイズを使用した AWS へのクラスターのインストール を参照してください。

今回の更新により、インストーラーによってプロビジョニングされたインフラストラクチャーを使用して OpenShift Container Platform を既存の VPC にインストールし、ワーカーノードを Local Zones サブネットに拡張できます。インストールプログラムは、NoSchedule taint を使用して、ユーザーアプリケーション用に指定された AWS ネットワークのエッジにワーカーノードをプロビジョニングします。エンドユーザーにおいて、Local Zones のロケーションにデプロイされたアプリケーションは低レイテンシーになります。

詳細は、AWS Local Zones を使用したクラスターインストール を参照してください。

OpenShift Container Platform が GCP Marketplace で利用できるようになりました。GCP Marketplace イメージを使用して OpenShift Container Platform をインストールすると、GCP を介して従量課金制 (時間単位、コア単位) で請求される自己管理型のクラスターデプロイを作成できますが、Red Hat によって直接サポートされます。

インストーラーでプロビジョニングされるインフラストラクチャーを使用したインストールについての詳細は、GCP Marketplace イメージの使用 を参照してください。ユーザーがプロビジョニングしたインフラストラクチャーを使用してインストールする方法は GCP での追加のワーカーマシンの作成 をご覧ください。

インストーラーは、GCP および Azure のブートストラップおよびコントロールプレーンホストからシリアルコンソールログを収集するようになりました。このログデータは標準のブートストラップログバンドルに追加されます。

詳細は、Troubleshooting installation issues を参照してください。

IBM Cloud VPC は、OpenShift Container Platform 4.12 で一般提供されるようになりました。

クラスターのインストールについて詳しくは、IBM Cloud VPC へのインストールの準備 を参照してください。

OpenShift Container Platform 4.16 は Kubernetes 1.29 を使用します。これにより、複数の非推奨 API が削除されました。

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

すべての OpenShift Container Platform 4.11 クラスターでは、OpenShift Container Platform 4.12 にアップグレードする前に、この管理者の承認が必要になります。

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

OpenShift Container Platform 4.12 以降、インストールプロセスの一部として機能セットを有効にできます。機能セットは、デフォルトで有効にされない OpenShift Container Platform 機能のコレクションです。

インストール時に機能セットを有効にする方法についての詳細は、フィーチャーゲートを使用した OpenShift Container Platform の機能の有効化 を参照してください。

OpenShift Container Platform 4.12 が、ARM アーキテクチャーベースの Azure インストーラーによってプロビジョニングされたインフラストラクチャーでサポートされるようになりました。AWS Graviton 3 プロセッサーがクラスターのデプロイで利用できるようになり、OpenShift Container Platform 4.11 でもサポートされます。インスタンスの可用性やインストールに関するドキュメントの詳細は、各種プラットフォームのサポートされるインストール方法 を参照してください。

oc-mirror CLI プラグインを使用してファイルベースのカタログ Operator イメージを Docker v2 形式ではなく OCI 形式でミラーリングする機能が、テクノロジープレビュー として利用できるようになりました。

詳細は､OCI フォーマットでのファイルベースのカタログ Operator イメージのミラーリング を参照してください。

OpenShift Container Platform 4.12 では、テクノロジープレビュー として GCP 上のクラスターを共有 VPC にインストールできます。このインストール方法では、クラスターは別の GCP プロジェクトの VPC を使用するように設定されています。共有 VPC により、組織は複数のプロジェクトから共通の VPC ネットワークにリソースを接続できるようになります。対象のネットワークの内部 IP アドレスを使用して、組織内の通信を安全かつ効率的に実行できます。

詳細は、GCP 上のクラスターを共有 VPC にインストール を参照してください。

今回の更新により、プロビジョニングネットワークのないベアメタルインストールで、プロキシーサーバー経由で Ironic API サービスにアクセスできるようになりました。このプロキシーサーバーは、Ironic API サービスに一貫した IP アドレスを提供します。metal3-ironic を含む Metal3 Pod が別の Pod に再配置された場合、一貫したプロキシーアドレスにより、Ironic API サービスとの継続的な通信が保証されます。

OpenShift Container Platform 4.12 では、サービスアカウントがアタッチされた仮想マシンを使用して GCP にクラスターをインストールできます。これにより、サービスアカウントの JSON ファイルを使用せずにインストールを実行できます。

詳細は 、GCP サービスアカウントの作成 をご覧ください。

OpenShift Container Platform 4.12 では、propagateUserTags パラメーターは、クラスター内の Operator が作成する AWS リソースのタグに指定されたユーザータグを含めるように指示するフラグです。

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

以前のバージョンの OpenShift Container Platform では、Ironic コンテナーイメージは Red Hat Enterprise Linux (RHEL) 8 をベースイメージとして使用していました。OpenShift Container Platform 4.12 以降、Ironic コンテナーイメージは RHEL 9 を基本イメージとして使用します。RHEL 9 ベースイメージは、Ironic コンポーネントでの CentOS Stream 9、Python 3.8、および Python 3.9 のサポートを追加します。

Ironic プロビジョニングサービスの詳細については、インストーラーによってプロビジョニングされたクラスターをベアメタルにデプロイする を参照してください。

OpenShift Container Platform 4.12 では、Red Hat OpenStack Platform (RHOSP) で実行されるクラスターが、従来の OpenStack クラウドプロバイダーから外部の Cloud Controller Manager (CCM) に切り替えられました。これは、Kubernetes がツリー内の従来のクラウドプロバイダーから、Cloud Controller Manager を使用して実装される外部クラウドプロバイダーに移行したことに伴う変更です。

詳細は、OpenStack Cloud Controller Manager を参照してください。

OpenShift Container Platform 4.12 では、分散コンピュートノード (DCN) アーキテクチャーを持つ Red Hat OpenStack Platform (RHOSP) クラウドへのクラスターデプロイメントが検証されました。これらのデプロイメントのリファレンスアーキテクチャーは近日中に公開されます。

このタイプのデプロイメントについては、Deploying Your Cluster at the Edge With OpenStack のブログ投稿で概説されています。

OpenShift Container Platform 4.12 が テクノロジープレビュー として AWS Outposts プラットフォームでサポートされるようになりました。AWS Outposts を使用すると、コントロールプレーンノードに AWS リージョンを使用しながら、エッジベースのワーカーノードをデプロイできます。詳細は、AWS Outposts のリモートワーカーを使用して AWS にクラスターをインストールする を参照してください。

エージェントベースのインストールでは、次の 2 つの入力モードがサポートされています。

優先モードでは、install-config.yaml ファイルを設定し、agent-config.yaml ファイルでエージェントベースの特定の設定を指定できます。詳細は、エージェントベースの OpenShift Container Platform インストーラーについて を参照してください。

エージェントベースの OpenShift Container Platform インストーラーは、Federal Information Processing Standards (FIPS) 準拠モードで OpenShift Container Platform クラスターをサポートします。install-config.yaml ファイルで fips フィールドの値を True に設定する必要があります。詳細は、FIPS 準拠について を参照してください。

非接続環境でエージェントベースのインストールを実行できます。非接続環境で使用されるイメージを作成するには、install-config.yaml ファイルの imageContentSources セクションにミラー情報または registries.conf ファイルが含まれている必要があります (ZTP マニフェストを使用している場合)。これらのファイルで使用する実際の設定オプションは、oc adm release mirror または oc mirror コマンドによって提供されます。詳細は、非接続インストールのミラーリングについて を参照してください。

イメージセット設定を作成するときに、graph: true フィールドを追加して、グラフデータイメージを構築し、ミラーレジストリーにプッシュできます。OpenShift Update Service (OSUS) を作成するには、graph-data イメージが必要です。graph: true フィールドは UpdateService カスタムリソースマニフェストも生成します。oc コマンドラインインターフェイス (CLI) は、UpdateService カスタムリソースマニフェストを使用して OSUS を作成できます。

次の IP アドレス設定でエージェント ISO イメージを作成できます。

詳細は、デュアルおよびシングル IP スタッククラスター を参照してください。

Kubernetes Operator 用のマルチクラスターエンジンをインストールし、エージェントベースの OpenShift Container Platform インストーラーを使用してハブクラスターをデプロイできます。詳細は、Kubernetes Operator 用マルチクラスターエンジンのエージェントベースでインストールされたクラスターの準備 を参照してください。

エージェントベースの OpenShift Container Platform インストーラーは、以下を検証します。

詳細は、インストールの検証 を参照してください。

エージェントベースの OpenShift Container Platform インストーラーを使用すると、エージェント ISO イメージを作成する前に、すべてのホストの IPv4、IPv6、またはデュアルスタック (IPv4 と IPv6 の両方) の静的 IP アドレスを設定できます。ZTP マニフェストを使用している場合、agent-config.yaml ファイルまたは NMStateConfig.yaml ファイルの hosts セクションに静的アドレスを追加できます。アドレスの設定は、NMState state examples で説明されているように、NMState の構文規則に従う必要があることに注意してください。

詳細は、ネットワークについて を参照してください。

エージェントベースの OpenShift Container Platform インストーラーを使用すると、インストール設定を定義し、すべてのノードの ISO を生成してから、生成された ISO を使用してターゲットシステムを起動することで無人インストールを実行できます。詳細は、エージェントベースの OpenShift Container Platform インストーラーを使用した OpenShift Container Platform クラスターのインストール を参照してください。

エージェントベースのインストールでは、ホスト名、NMState 形式のネットワーク設定、ルートデバイスヒント、ロールを設定できます。

詳細は、ルートデバイスヒントについて を参照してください。

エージェントベースの OpenShift Container Platform インストーラーを使用すると、DHCP に依存して全ノードのネットワークを設定する環境にデプロイできます。この IP は、すべてのノードがミーティングポイントとして使用するために必要です。詳細は、DHCP を参照してください。

ネットワーククラスターが切断されているか制限されている場合など、インターネットへのアクセスが制限されている環境でも、Nutanix にクラスターをインストールできるようになりました。このタイプのインストールでは、OpenShift Container Platform イメージレジストリーの内容をミラーリングし、インストールメディアを含むレジストリーを作成します。このレジストリーは、インターネットと閉域ネットワークの両方にアクセスできるミラーホスト上に作成できます。

詳細は、切断されたインストールのミラーリングについて および 制限されたネットワーク内の Nutanix へのクラスターのインストール を参照してください。

vSphere で実行されているクラスターに CSI ドライバーをインストールするには、次の要件を満たす必要があります。

上記よりも前のバージョンのコンポーネントは引き続きサポートされますが、非推奨です。これらのバージョンは引き続き完全にサポートされていますが、OpenShift Container Platform のバージョン 4.12 には、vSphere 仮想ハードウェアバージョン 15 以降が必要です。詳細は、非推奨および削除された機能 を参照してください。

上記の要件を満たさない場合、OpenShift Container Platform は OpenShift Container Platform 4.13 以降にアップグレードできません。

次の新しいクラスター機能が追加されました。

新しい定義済みクラスター機能セット (v4.12) が追加されました。これには、v4.11 のすべての機能と、今回のリリースで追加された新しい機能が含まれます。

詳細は、クラスター機能の有効化 を参照してください。

マルチアーキテクチャーのコンピュートマシンが含まれる OpenShift Container Platform 4.12 では、イメージストリームでマニフェストにリストされたイメージがサポートされるようになりました。マニフェストリストイメージの詳細は、OpenShift Container Platform クラスター上でのマルチアーキテクチャーコンピュートマシンの設定 を参照してください。

マルチアーキテクチャーのコンピュートマシンを含むクラスターでは、Operator の Subscription オブジェクトでノードアフィニティーをオーバーライドして、Operator がサポートするアーキテクチャーのノードで Pod をスケジュールできるようになりました。詳細は、ノードアフィニティーを使用した Operator のインストール場所の制御 を参照してください。

今回のリリースにより、Web コンソールの Administrator パースペクティブに複数の更新が追加されました。

今回のリリースにより、Web コンソールの Developer パースペクティブに複数の更新が含まれるようになりました。次のアクションを実行できます。

Krew を使用して OpenShift CLI (oc) のプラグインをインストールおよび管理する機能が、テクノロジープレビュー として利用できるようになりました。

詳細は､Krew を使用した CLI プラグインの管理 を参照してください。

OpenShift Container Platform 4.12 以降で、Security Profiles Operator (SPO) が使用可能になりました。

SPO を使用することで、セキュアコンピューティング (seccomp) プロファイルと SELinux プロファイルをカスタムリソースとして定義し、特定の namespace 内のすべてのノードにプロファイルを同期できます。

詳細は、Security Profiles Operator の概要 を参照してください。

Assisted Installer は、API VIP および Ingress VIP のデュアルスタックネットワークを備えた OpenShift Container Platform 4.12 以降のバージョンのベアメタル上でのインストールのみサポートしています。このサポートにより、IP アドレスのリストを取得できる api_vips と ingress_vips という 2 つの新しい設定が導入されます。従来の api_vip および ingress_vip 設定も OpenShift Container Platform 4.12 で行う必要があります。ただし、これらは 1 つの IP アドレスしか使用しないため、従来の api_vip および ingress_vip 設定を使用して、API VIP および Ingress VIP のデュアルスタックネットワークを設定する場合は、IPv4 アドレスを設定する必要があります。

デュアルスタックネットワークを使用する場合は、API VIP アドレスおよび Ingress VIP アドレスはプライマリー IP アドレスファミリーである必要があります。現在、Red Hat は、IPv6 をプライマリー IP アドレスファミリーとして使用するデュアルスタック VIP またはデュアルスタックネットワークをサポートしていません。ただし、Red Hat は、IPv4 をプライマリー IP アドレスファミリーとして使用するデュアルスタックネットワークをサポートしています。したがって、IPv6 エントリーの前に IPv4 エントリーを配置する必要があります。詳細については、自動インストーラーのドキュメントを参照してください。

Red Hat OpenShift Networking は、クラスターが 1 つまたは複数のハイブリッドクラスターのネットワークトラフィックを管理するために必要な高度なネットワーキング関連機能を使用して、Kubernetes CNI プラグインを超えて Kubernetes ネットワーキングを拡張する機能、プラグイン、高度なネットワーキング機能のエコシステムです。このネットワーキング機能のエコシステムは、イングレス、エグレス、負荷分散、高性能スループット、セキュリティー、クラスター間およびクラスター内のトラフィック管理を統合し、ロールベースの可観測性ツールを提供して本来の複雑さを軽減します。

詳細は、ネットワークについて を参照してください。

新しいクラスターをインストールすると、OVN-Kubernetes ネットワークプラグインがデフォルトのネットワークプラグインになります。これまでの OpenShift Container Platform バージョンは、すべて OpenShift SDN がデフォルトのネットワークプラグインでした。

OVN-Kubernetes ネットワークプラグインには、OpenShift SDN よりも幅広い機能が含まれています。

以前のバージョンと比較して、OpenShift Container Platform 4.12 ではスケール、パフォーマンス、および安定性が大幅に向上しています。

OpenShift SDN ネットワークプラグインを使用している場合は、次の点に注意してください。

OpenShift SDN との機能比較表など、OVN-Kubernetes の詳細 については、OVN-Kubernetes ネットワークプラグインについて を参照してください。

OpenShift SDN から OVN-Kubernetes への移行については、OpenShift SDN ネットワークプラグインからの移行 を参照してください。

今回の更新では、新しいステートレス Ingress Node Firewall Operator が導入されています。ノードレベルでファイアウォールルールを設定できるようになりました。詳細は、Ingress Node Firewall Operator を参照してください。

OVN-Kubernetes ネットワークプラグインで次のメトリックを使用できるようになりました。

次のメトリックが削除されました。

OpenShift Container Platform 4.12 からテクノロジープレビュー機能として、インストーラーによりプロビジョニングされたインフラストラクチャーを使用した単一 vCenter のインストールで複数の vCenter データセンターと複数の vCenter クラスターを設定できるようになりました。vCenter タグを使用すると、この機能を使用して、vCenter データセンターとコンピュートクラスターを openshift-region と openshift-zone に関連付けることができます。これらの関連付けによって障害ドメインが定義され、アプリケーションのワークロードを特定のロケーションおよび障害ドメインに関連付けることができます。

OpenShift Container Platform 4.12 以降、VMware vSphere インスタンスで Kubernetes NMState Operator を使用して、DNS サーバーまたは検索ドメイン、VLAN、ブリッジ、およびインターフェイス結合などのネットワーク設定を設定できます。

詳細は、Kubernetes NMState Operator について を参照してください。

OpenShift Container Platform 4.12 以降、OpenStack インスタンスで Kubernetes NMState Operator を使用して、DNS サーバーまたは検索ドメイン、VLAN、ブリッジ、およびインターフェイス結合などのネットワーク設定を設定できます。

詳細は、Kubernetes NMState Operator について を参照してください。

OpenShift Container Platform 4.12 では、External DNS Operator が AzureDNS の ExternalDNS ワイルドカード TXT レコードの形式を変更します。External DNS Operator は、アスタリスクを ExternalDNS ワイルドカード TXT レコードの any のものに置き換えます。競合が発生する可能性があるため、ExternalDNS ワイルドカード A および CNAME レコードが any の左端のサブドメインを持つことは避ける必要があります。

OpenShift Container Platform 4.12 の ExternalDNS のアップストリームバージョンは v0.13.1 です。

OpenShift Container Platform 4.12 では、Cluster Ingress Operator は route_metrics_controller_routes_per_shard という名前の新しいメトリクスをエクスポートします。メトリックの shard_name ラベルは、シャードの名前を指定します。このメトリクスは、各シャードによって許可されたルートの総数を示します。

次のメトリックは、Telemetry を通じて送信されます。

OpenShift Container Platform 4.12 では、AWS Load Balancer コントローラーは、複数の一致に対して Kubernetes Ingress 仕様を実装するようになりました。Ingress 内の複数のパスが要求に一致する場合、一致する最長のパスが優先されます。2 つのパスが引き続き一致する場合は、正確なパスタイプのパスが接頭辞パスタイプよりも優先されます。

AWS Load Balancer Operator は、EnableIPTargetType 機能ゲートを false に設定します。AWS Load Balancer コントローラーは、target-type ip のサービスとイングレスリソースのサポートを無効にします。

OpenShift Container Platform 4.12 の aws-load-balancer-controller のアップストリームバージョンは v2.4.4 です。

OpenShift Container Platform Custom Metrics Autoscaler Operator を使用して、デプロイされたクラスター内のメトリック (使用可能なワーカーノードの数など) に基づいて、デフォルトの Ingress コントローラーを動的にスケーリングできるようになりました。カスタムメトリクスオートスケーラーは、テクノロジープレビュー機能として利用できます。

詳細は､イングレスコントローラーの自動スケーリング を参照してください。

OpenShift Container Platform 4.12 では、maxConnections 設定のデフォルト値が 50000 になりました。OpenShift Container Platform 4.11 以降では、maxConnections 設定のデフォルト値は 20000 でした。

詳細は、Ingress Controller configuration parameters を参照してください。

自動 DNS 管理を停止し、手動 DNS 管理を開始するように Ingress コントローラーを設定できるようになりました。dnsManagementPolicy パラメーターを設定して、自動または手動の DNS 管理を指定します。

詳細については、DNS を手動で管理するための Ingress コントローラーの設る を参照してください。

OpenShift Container Platform 4.12 は以下の SR-IOV デバイスのサポートを追加します。

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

OpenShift Container Platform 4.12 は、以下のデバイスで OvS Hardware Offload のサポートを追加しています。

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

OpenShift Container Platform 4.12 は、SR-IOV デバイスのマルチネットワークポリシーを設定するためのサポートを追加します。

SR-IOV 追加ネットワークのマルチネットワークを設定できるようになりました。SR-IOV 追加ネットワークの設定はテクノロジープレビュー機能であり、カーネルネットワークインターフェイスカード (NIC) でのみサポートされます。

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

Ingress Controller を削除せずに、AWS Classic Load Balancer (CLB) と AWS Network Load Balancer (NLB) を切り替えるように Ingress Controller を更新できます。

詳細は、Configuring ingress cluster traffic on AWS を参照してください。

IP アドレス管理 CNI プラグインが IP を割り当てたシングルルート I/O 仮想化 (SR-IOV) CNI プラグインで作成された Pod は、IPv6 未承認ネイバーアドバタイズメントおよび/または IPv4 Gratuitous アドレス解決プロトコルをデフォルトでネットワークへ送信します。この機能強化により、特定の IP の新しい Pod の MAC アドレスがホストに通知され、正しい情報で ARP/NDP キャッシュが更新されます。

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

CoreDNS によってキャッシュされた成功および失敗した DNS クエリーの存続時間 (TTL) 期間を設定できるようになりました。

詳細については、CoreDNS キャッシュの調整 を参照してください。

以前は、OVN-Kubernetes が内部で使用するサブネットは、IPv4 の場合は 100.64.0.0/16、IPv6 の場合は fd98::/48 であり、変更できませんでした。これらのサブネットがインフラストラクチャー内の既存のサブネットと重複するインスタンスをサポートするために、これらの内部サブネットを変更して重複を回避できるようになりました。

詳細は、Cluster Network Operator 設定オブジェクト を参照してください。

RHOSP は OpenShift Container Platform と組み合わせることで、Egress IP アドレスの自動アタッチおよびデタッチをサポートするようになりました。任意の数の namespace に含まれる 1 つ以上の Pod からのトラフィックでは、クラスター外のサービスのソース IP アドレスに一貫性があります。このサポートは、デフォルトのネットワークプロバイダーとして OpenShift SDN および OVN-Kubernetes に適用されます。

OpenShift SDN ネットワークプラグインから OVN-Kubernetes ネットワークプラグインへの移行を計画している場合、次の機能の設定は、OVN-Kubernetes で動作するように自動的に変換されます。

OVN-Kubernetes への移行がどのように機能するかの詳細は、OpenShift SDN クラスターネットワークプロバイダーからの移行 を参照してください。

OVN-Kubernetes ネットワークプラグインの場合、エグレスファイアウォールは、ネットワークポリシー監査ログが使用するのと同じメカニズムを使用して、監査ログをサポートします。詳細は、エグレスファイアウォールとネットワークポリシールールのロギングを 参照してください。

今回の更新により、BGP モードで、ノードセレクターを使用して、IP アドレスの特定のプールを使用して、ノードのサブセットから MetalLB サービスをアドバタイズできるようになりました。この機能は、OpenShift Container Platform 4.11 でテクノロジープレビュー機能として導入され、BGP モードのみで OpenShift Container Platform 4.12 で一般的に利用できるようになりました。L2 モードは、テクノロジープレビュー機能のままです。

詳細は、ノードのサブセットからの IP アドレスプールのアドバタイズ を参照してください。

この更新では、MetalLB の追加のデプロイメント仕様が提供されます。カスタムリソースを使用して MetalLB をデプロイする場合、これらの追加のデプロイ仕様を使用して、MetalLB speaker および controller Pod がクラスターでデプロイおよび実行される方法を管理できます。たとえば、MetalLB デプロイメント仕様を使用して、MetalLB Pod がデプロイされる場所を管理し、MetalLB Pod の CPU 制限を定義し、MetalLB Pod にランタイムクラスを割り当てることができます。

MetalLB のデプロイメント仕様について詳しくは、MetalLB の デプロイメント仕様 を参照してください。

以前は、クラスターホストの nodeip-configuration サービスが、デフォルトルートが使用するインターフェイスから IP アドレスを選択していました。複数のルートが存在する場合、サービスはメトリック値が最も低いルートを選択します。その結果、ネットワークトラフィックが不適切なインターフェイスから配信される可能性がありました。

OpenShift Container Platform 4.12 では、ユーザーがヒントファイルを作成できる新しいインターフェイスが nodeip-configuration サービスに追加されました。ヒントファイルには変数 NODEIP_HINT が含まれています。この変数は、デフォルトの IP 選択ロジックをオーバーライドし、サブネット NODEIP_HINT 変数から特定のノード IP アドレスを選択します。NODEIP_HINT 変数を使用すると、ユーザーは使用する IP アドレスを指定できるため、ネットワークトラフィックが正しいインターフェイスから分散されるようになります。

詳細は、オプション: デフォルトのノード IP 選択ロジックのオーバーライドを参照してください。

OpenShift Container Platform 4.12 では、CoreDNS はバージョン 1.10.0 を使用します。これには以下の変更が含まれます。

今回の更新により、クラスター管理者はリロード間隔を設定して、ルートとエンドポイントの更新に応じて HAProxy が設定をリロードする頻度を減らすことができます。デフォルトの最小 HAProxy リロード間隔は 5 秒です。

詳細は、HAProxy の再ロード間隔の設定 を参照してください。

Network Observability Operator は、OpenShift Container Platform マイナーバージョンのリリースストリームとは独立して更新をリリースします。更新は、現在サポートされているすべての OpenShift Container Platform 4 バージョンでサポートされている単一のローリングストリームを介して使用できます。Network Observability Operator の新機能、機能拡張、バグ修正に関する情報は、Network Observability リリースノート に記載されています。

RHOSP 上で実行されるクラスターで、セカンダリーネットワークインターフェイスの IPv6 がサポートされるようになりました。

詳細は、RHOSP 上の Pod への IPv6 接続の有効化 を参照してください。

外部の OpenStack クラウドプロバイダーに切り替えた結果、そのプラットフォームで実行されるクラスターの LoadBalancer サービスで UDP がサポートされるようになりました。

ホスティングサービスクラスターを設定してデプロイした場合、ホステッドクラスターに SR-IOV Operator をデプロイできるようになりました。詳細は、ホステッドコントロールプレーン用の SR-IOV Operator のデプロイメント を参照してください。

今回の更新により、インストーラーによってプロビジョニングされたインフラストラクチャークラスターで、install-config.yaml ファイルの ingressVIP および apiVIP の設定が非推奨になりました。代わりに、ingressVIPs および apiVIPs の設定を使用してください。これらの設定は、イングレス VIP および API VIP サービスを使用してクラスターへの IPv4 および IPv6 アクセスを必要とするベアメタル上のアプリケーションのデュアルスタックネットワークをサポートします。ingressVIPs および apiVIPs の設定では、リスト形式を使用して、IPv4 アドレス、IPv6 アドレス、または両方の IP アドレス形式を指定します。リストの順序は、各サービスのプライマリーおよびセカンダリー VIP アドレスを示しています。デュアルスタックネットワークを使用する場合には、プライマリー IP アドレスは IPv4 ネットワークからのものである必要があります。

今回の更新により、BluefFeld-2 ネットワークデバイスをデータ処理ユニット (DPU) モードからネットワークインターフェイスコントローラー (NIC) モードに切り替えることができます。

詳細は、Switching BlueField-2 from DPU to NIC を参照してください。

以前は、OVN-Kubernetes ネットワークプラグイン を使用するクラスターの場合、クラスターのインストール時に、クラスターが Windows ノードをサポートできるようにハイブリッドネットワークを有効にすることができました。これで、インストール後にハイブリッドネットワークを有効化できるようになりました。詳細は、ハイブリッドネットワークの設定 を参照してください。

Service オブジェクト下の Network API の ServiceSpec コンポーネントは、ユーザーがサービスで作成する属性を記述します。OpenShift Container Platform 4.13 では、ServiceSpec コンポーネント内の allocateLoadBalancerNodePorts 属性がサポートされるようになりました。allocateLoadBalancerNodePorts 属性は、NodePorts が LoadBalancer 型のサービスに自動的に割り当てられるかどうかを定義します。

詳細は、Network API ServiceSpec objectを参照してください。

OpenShift Container Platform は、Google Compute Platform (GCP) Filestore の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。このドライバーを管理する GCP Filestore CSI Driver Operator は、テクノロジープレビュー機能です。

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

OpenShift Container Platform 4.8 以降、インツリーボリュームプラグインの同等の Container Storage Interface (CSI) ドライバーへの自動移行がテクノロジープレビュー機能として利用可能になりました。Amazon Web Services (AWS) Elastic Block Storage (EBS) のサポートは、OpenShift Container Platform 4.8 のこの機能で提供され、OpenShift Container Platform 4.12 では AWS EBS の自動移行に対するサポートが一般提供されます。AWS EBS の CSI 移行はデフォルトで有効化され、管理者によるアクションは不要になりました。

この機能は in-tree オブジェクトを自動的に対応する CSI 表現に変換するため、ユーザーに対して完全に透過的である必要があります。変換されたオブジェクトはディスクに保存され、ユーザーデータは移行されません。

in-tree ストレージプラグインを参照するストレージクラスは引き続き機能しますが、デフォルトのストレージクラスを CSI ストレージクラスに切り替えることが推奨されます。

詳細は、CSI 自動移行を参照してください。

OpenShift Container Platform 4.8 以降、インツリーボリュームプラグインの同等の Container Storage Interface (CSI) ドライバーへの自動移行がテクノロジープレビュー機能として利用可能になりました。Google Compute Engine Persistent Disk (GCP PD) のサポートは、OpenShift Container Platform 4.9 のこの機能で提供され、OpenShift Container Platform 4.12 では GCP PD の自動移行に対するサポートの一般提供が開始されます。GCP PD の CSI 移行はデフォルトで有効化され、管理者によるアクションは不要になりました。

この機能は in-tree オブジェクトを自動的に対応する CSI 表現に変換するため、ユーザーに対して完全に透過的である必要があります。変換されたオブジェクトはディスクに保存され、ユーザーデータは移行されません。

in-tree ストレージプラグインを参照するストレージクラスは引き続き機能しますが、デフォルトのストレージクラスを CSI ストレージクラスに切り替えることが推奨されます。

詳細は、CSI 自動移行を参照してください。

以下の条件が すべて 該当する場合、OpenShift Container Platform 4.12 から 4.13、および 4.13 から 4.14 への更新はブロックされます。

詳細は、CSI 自動移行を参照してください。

この新機能は、CSIStorageCapacity オブジェクトを使用して現在使用可能なストレージ容量を公開し、遅延バインディングで Container Storage Interface (CSI) ボリュームを使用する Pod のスケジューリングを強化します。現在、この機能をサポートする唯一の OpenShift Container Platform ストレージタイプは OpenShift Data Foundation です。

OpenShift Container Platform は、異なるゾーンおよびリージョンに OpenShift Container Platform for vSphere をデプロイする機能を提供します。この機能を使用することで、複数のコンピュートクラスターにデプロイできるため、単一障害点を回避するのに役立ちます。

詳細は、vSphere CSI トポロジー を参照してください。

ローカル一時ストレージリソース管理機能の一般提供が開始されました。この機能を使用すると、リクエストと制限を指定して、ローカル一時ストレージを管理できます。

詳細は、一時ストレージの管理 を参照してください。

ボリュームポピュレーターは datasource を使用して、事前に入力されたボリュームの作成を有効にします。

ボリュームの作成は現在有効になっており、テクノロジープレビュー機能としてサポートされています。ただし、OpenShift Container Platform にはボリュームポピュレーターは同梱されていません。

詳細は、ボリュームポピュレーター を参照してください。

OpenShift Container Platform 4.12 の場合、VMWare vSphere Container Storage Interface (CSI) Driver Operator には、以下の最小限のコンポーネントがインストールされている必要があります。

サードパーティーの CSI ドライバーがクラスターに存在する場合、OpenShift Container Platform はそれを上書きしません。サードパーティーの CSI ドライバーが存在すると、OpenShift Container Platform を OpenShift Container Platform 4.13 以降にアップグレードできなくなります。

詳細は、VMware vSphere CSI Driver Operator の要件 を参照してください。

OpenShift Container Platform 4.14 は、一般提供として Network File System (NFS) を備えた Azure File Container Storage Interface (CSI) Driver Operator をサポートします。

詳細は、NFS サポート を参照してください。

OpenShift Container Platform 4.12 から、Operator Lifecycle Manager (OLM) は プラットフォームの Operator タイプをテクノロジープレビュー機能として導入します。プラットフォーム Operator メカニズムは、同じく OpenShift Container Platform 4.12 で導入された RukPak コンポーネントのリソースに依存して、コンテンツの調達と管理を行います。

Platform Operator は OLM ベースの Operator であり、OpenShift Container Platform クラスターの Day 0 操作中または操作後にインストールでき、クラスターのライフサイクルに参加します。クラスター管理者は、Platform Operator を使用して OpenShift Container Platform インストールをさらにカスタマイズし、要件とユースケースを満たすことができます。

プラットフォーム Operator について、詳しくは プラットフォーム Operator の管理 を参照してください。RukPak とそのリソースについて、詳しくは Operator Framework のパッケージ化形式 を参照してください。

デフォルトでは、Operator をインストールすると、OpenShift Container Platform は Operator Pod をワーカーノードの 1 つにランダムにインストールします。

OpenShift Container Platform 4.12 では、Operator の Subscription オブジェクトにアフィニティー制約を追加することで、Operator Pod がインストールされる場所を制御できます。

詳細は、Operator のインストール場所の制御 を参照してください。

OpenShift Container Platform 4.12 では、ユーザーが作成した openshift- プレフィックスを持つ namespace に Operator がインストールされている場合、Pod セキュリティーアドミッションの同期がデフォルトで有効になります。クラスターサービスバージョン (CSV) が namespace に作成されると、同期が有効になります。同期されたラベルは、namespace のサービスアカウントのパーミッションを継承します。

詳細は、Pod セキュリティー標準とのセキュリティーコンテキスト制約の同期 を参照してください。

run bundle および bundle-upgrade サブコマンドで --security-context-config フラグを使用して、カタログ Pod のセキュリティーコンテキストを設定できます。このフラグにより、seccomp プロファイルが Pod のセキュリティーアドミッションに準拠できるようになります。このフラグは、restricted および legacy の値を許可します。値を指定しない場合、seccomp プロファイルはデフォルトで restricted になります。制限付きパーミッションではカタログ Pod を実行できない場合、次の例に示すとおり、フラグを legacy に設定します。

$ operator-sdk run bundle \
  --security-context-config=legacy

bundle validate サブコマンドで Operator Framework スイートのテストを使用することにより、Kubernetes 1.25 から削除された非推奨 API のバンドルマニフェストを確認できるようになりました。

以下に例を示します。

$ operator-sdk bundle validate .<bundle_dir_or_image> \
  --select-optional suite=operatorframework \
  --optional-values=k8s-version=1.25

Operator が Kubernetes 1.25 から削除された API のいずれかを使用するパーミッションを要求した場合に、コマンドは警告メッセージを表示します。

Kubernetes 1.25 から削除された API バージョンのいずれかが Operator のクラスターサービスバージョン (CSV) に含まれている場合に、コマンドはエラーメッセージを表示します。

詳細は Kubernetes 1.25 から削除されたベータ API および Operator SDK CLI リファレンス を参照してください。

OpenShift Container Platform 4.12 では、コントロールプレーンのマシンセットが導入されています。コントロールプレーンマシンセット は、計算マシンセットが計算マシンに提供するものと同様の管理機能をコントロールプレーンマシンに提供します。詳細は、「コントロールプレーンマシンの管理」を参照してください。

OpenShift Container Platform は、ClusterAutoscaler カスタムリソースで logVerbosity パラメーターを設定することにより、クラスターオートスケーラーのログレベルの詳細度の設定をサポートするようになりました。詳細は、ClusterAutoscaler リソース定義 を参照してください。

OpenShift Container Platform は、マシンセットが作成する Azure マシンでのブート診断の有効化をサポートするようになりました。詳細については、コンピューティングマシン または コントロールプレーンマシン の Azure ブート診断の有効化を参照してください。

Red Hat Enterprise Linux CoreOS (RHCOS) イメージの階層化により、ベース RHCOS イメージの上に新しいイメージを追加できます。このレイヤー化は、RHCOS の基本イメージを変更しません。代わりに、すべての RHCOS 機能を含む カスタムレイヤーイメージ を作成し、クラスター内の特定のノードに追加機能を追加します。

現在、RHCOS イメージの階層化により、Customer Experience and Engagement (CEE) と連携して、Red Hat Hotfix ポリシー に基づいて、RHCOS イメージの上に Hotfix パッケージを取得して適用することができます。将来のリリースでは、RHCOS イメージのレイヤー化を使用して、libreswan や numactl などのサードパーティーソフトウェアパッケージを組み込むことができるようになる予定です。

詳細は、RHCOS イメージのレイヤー化 を参照してください。

OpenShift Container Platform は、デフォルトのインターフェイス固有の安全な sysctl の更新をサポートするようになりました。

事前定義されたリストから sysctl を追加または削除できます。sysctls を追加すると、すべてのノードにわたって設定できます。インターフェイス固有の安全な sysctl リストの更新は、テクノロジープレビュー機能のみです。

詳しく は、インターフェイス固有の安全な sysctls リストの更新 を参照してください。

cron ジョブスケジュールのタイムゾーンの設定が、テクノロジープレビュー として提供されるようになりました。タイムゾーンが指定されていない場合、Kubernetes コントローラーマネージャーは、ローカルタイムゾーンを基準にしてスケジュールを解釈します。

詳細は、cron ジョブの作成 を参照してください。

Linux Control Group バージョン 2 (cgroup v2) の OpenShift Container Platform サポートは、テクノロジープレビューに昇格しました。cgroup v2 は、カーネル コントロールグループ の次のバージョンです。cgroups v2 は、統一された階層、より安全なサブツリー委任、Pressure Stall Information などの新機能、拡張されたリソース管理と分離など、複数の改善を提供します。詳細は、Enabling Linux Control Group version 2 (cgroup v2) を参照してください。

OpenShift Container Platform は、テクノロジープレビューで crun コンテナーランタイムをサポートするようになりました。必要に応じて、ContainerRuntimeConfig カスタムリソース (CR) を使用して、crun コンテナーランタイムとデフォルトのコンテナーランタイムを切り替えることができます。詳細 については、コンテナーエンジンとコンテナーランタイムについて を参照してください。

OpenShift Container Platform は、Self Node Remediation Operator によるコントロールプレーンフェンシングをサポートするようになりました。ノードに障害が発生した場合は、ワーカーノードとコントロールプレーンノードの両方で修復ストラテジーに従うことができます。詳細は、Red Hat OpenShift のワークロードの可用性 ドキュメントを参照してください。

OpenShift Container Platform は、Node Health Check Operator でのコントロールプレーンフェンシングをサポートするようになりました。ノードに障害が発生した場合は、ワーカーノードとコントロールプレーンノードの両方で修復ストラテジーに従うことができます。詳細は、Red Hat OpenShift のワークロードの可用性 ドキュメントを参照してください。

Node Health Check Operator には、Node Health Checks を管理するための Web コンソールプラグインも含まれるようになりました。詳細は、Red Hat OpenShift のワークロードの可用性 ドキュメントを参照してください。

Node Health Check Operator の最新バージョンのインストールまたは更新には、stable サブスクリプションチャネルを使用します。詳細は、Red Hat OpenShift のワークロードの可用性 ドキュメントを参照してください。

このリリースには、スタックコンポーネントと依存関係を監視するための次のバージョン更新が含まれています。

Pod トポロジー分散制約を使用して、OpenShift Container Platform Pod が複数のアベイラビリティーゾーンにデプロイされている場合に、Prometheus、Thanos Ruler、および Alertmanager Pod がネットワークトポロジー全体にどのように分散されるかを制御できるようになりました。

Prometheus Adapter (PA) でオプションの kubelet サービスモニターを設定できるようになりました。これにより、複数の自動スケーリングリクエスト間でデータの一貫性が向上します。このサービスモニターを有効にすると、PA によって実行される基礎となる PromQL クエリーが異なる Prometheus サーバー上にあることで、PA に同時に送信される 2 つのクエリーが異なる結果をもたらす可能性がなくなります。

このリリースでは、追加のキーを保持するために Alertmanager のシークレットを設定する場合、Alertmanager 設定がこれらのキーをファイル （テンプレート、TLS 証明書、またはトークンなど） として参照する場合は、設定は相対パスではなく絶対パスを使用してこれらのキーをポイントする必要があります。これらのキーは、/etc/alertmanager/config ディレクトリーの下にあります。OpenShift Container Platform の以前のリリースでは、Alertmanager 設定ファイルがキーと同じディレクトリーに配置されていたため、設定で相対パスを使用してこれらのキーを指すことができました。

クラスターレベルでは、デフォルトで systemd サービスが仮想ネットワークインターフェイスの受信パケットステアリング (RPS) マスクを設定します。RPS マスクは、パフォーマンスプロファイルで定義された予約済み CPU のリストに従って、仮想ネットワークインターフェイスからの割り込み要求をルーティングします。コンテナーレベルでは、CRI-O フックスクリプトもすべての仮想ネットワークデバイスの RPS マスクを設定します。

今回の更新により、パフォーマンスプロファイルで spec.workloadHints.realTime を False に設定すると、システムは systemd サービスと、RPS マスクを設定する CRI-O フックスクリプトの両方も無効にします。RPS は通常、低レイテンシーのリアルタイムワークロードのみを必要とするユースケースに関連するため、システムはこれらの RPS 機能を無効にします。

spec.workloadHints.realTime を False に設定した場合でも RPS 機能を維持するには、Red Hat ナレッジベースソリューション Performance addons operator advanced configuration の RPS 設定 セクションを参照してください。

ワークロードヒントの設定の詳細については、ワークロードヒントについて についてを参照してください。

tuned プロファイルは、デフォルトで fs.aio-max-nr sysctl 値を定義するようになり、デフォルトノードプロファイルの非同期 I/O パフォーマンスが向上しました。

低遅延チューニングが更新され、最新のカーネル機能とオプションを使用できるようになりました。2117780 の修正により、CPU ごとの新しい kthread である ktimers が導入されました。このスレッドは、適切な CPU コアに固定する必要があります。今回の更新では機能上の変更はなく、ワークロードの分離は同じままです。詳細は、2102450 を参照してください。

OpenShift Container Platform 4.12 では、C ステートと OS 制御の P ステートを有効にすることで、重要なワークロードとそうでないワークロードに対して異なる省電力設定を使用できます。新しい perPodPowerManagement ワークロードヒント、cpu-c-states.crio.io および cpu-freq-governor.crio.io CRI-O アノテーションを使用して設定を適用できます。この機能の詳細は、省電力設定 を参照してください。

OpenShift Container Platform 4.11 では、ワーカーノードを単一ノードの OpenShift クラスターに手動で追加できる機能が導入されました。この機能は、GitOps ZTP でも利用できるようになりました。

詳しくは、GitOps ZTP を使用した単一ノード OpenShift クラスターへのワーカーノードの追加 を参照してください。

OpenShift Container Platform 4.12 では、factory-precaching-cli ツールを使用して OpenShift Container Platform および Operator イメージを事前に工場でサーバーにキャッシュし、その事前キャッシュされたサーバーをデプロイメント用のサイトに含めることができます。factory-precaching-cli ツールの詳細については、単一ノード OpenShift デプロイメントのイメージの事前キャッシュ を参照してください。

OpenShift Container Platform 4.12 では、GitOps ZTP ワークフローで factory-precaching-cli ツールを使用できます。詳細は、単一ノード OpenShift デプロイメントのイメージの事前キャッシュ を参照してください。

Node Tuning Operator を使用して、ホステッドクラスター内のノードの OS レベルチューニングを設定できるようになりました。ノードチューニングを設定するには、Tuned オブジェクトを含む管理クラスターで設定マップを作成し、ノードプールで作成した設定マップを参照します。Tuned オブジェクトで定義されたチューニング設定は、ノードプール内のノードに適用されます。詳細は、ホステッドクラスターでのノードチューニングの設定 を参照してください。

カーネルモジュール管理 (KMM) Operator は、Special Resource Operator (SRO) を置き換えます。KMM には、接続環境専用の次の機能が含まれています。

インターネットにアクセスできる環境でハブおよびスポークをデプロイする場合、ハブクラスターにデプロイされたカーネルモジュール管理 (KMM) Operator を使用して、必要なカーネルモジュールの 1 つ以上のマネージドクラスターへのデプロイを管理できます。

Topology Aware Lifecycle Manager (TALM) では、より詳細なステータス情報とメッセージ、および再設計された条件が提供されるようになりました。ClusterLabelSelector フィールドを使用すると、更新するクラスターをより柔軟に選択できます。タイムアウト設定を使用して、クラスターの更新が失敗した場合にどうするかを決定できます。たとえば、失敗したクラスターをスキップして他のクラスターのアップグレードを続行するか、すべてのクラスターのポリシー修正を停止できます。詳細は、クラスター更新のための Topology Aware Lifecycle Manager を参照してください。

カプセル化は、すべての Kubernetes 固有のマウントポイントを別の namespace に移動して、デフォルトの namespace にある多数のマウントポイントの可視性とパフォーマンスへの影響を軽減するプロセスです。以前は、特に GitOps ZTP を使用してインストールされた分散ユニット (DU) 用に、マウント namespace のカプセル化が透過的に OpenShift Container Platform にデプロイされていました。OpenShift Container Platform v4.12 では、この機能が設定可能なオプションとして利用できるようになりました。

標準のホストオペレーティングシステムは、systemd を使用してすべてのマウント namespace (標準の Linux マウントと、Kubernetes が操作に使用する多数のマウントの両方) を常にスキャンします。kubelet と CRI-O の現在の実装はどちらも、すべてのコンテナーと Kubelet マウントポイントに最上位の namespace を使用します。これらのコンテナー固有のマウントポイントをプライベート namespace にカプセル化すると、systemd のオーバーヘッドが削減され、CPU パフォーマンスが向上します。カプセル化のセキュリティーは、Kubernetes 固有のマウントポイントを特権のないユーザーによる検査から安全な場所に保存することでも向上します。

詳細は、マウント namespace のカプセル化による CPU 使用率の最適化 を参照してください。

GitOps ZTP を使用してデプロイする単一ノードの OpenShift クラスターで、ワークロードのパーティション設定 CPU セットを設定できます。これを設定するには、SiteConfig カスタムリソース (CR) の cpuset フィールドとグループ PolicyGenTemplate CR の reserved フィールドを使用してクラスター管理 CPU リソースを指定します。cpuset に設定する値は、ワークロードのパーティション設定のためにクラスターの PerformanceProfile CR .spec.cpu.reserved フィールドに設定された値と一致する必要があります。

詳細は、ワークロードのパーティショニング を参照してください。

Red Hat Advanced Cluster Management (RHACM) および Topology Aware Lifecycle Manager (TALM) を使用して、GitOps ZTP でハブテンプレート関数を使用できるようになりました。ハブ側のクラスターテンプレートを使用すると、設定は似ているが値が異なる多くのクラスターに対して個別のポリシーを作成する必要がなくなります。詳細は、PolicyGenTemplate CR でのハブテンプレートの使用 を参照してください。

RHACM は SiteConfig CR を使用して、ArgoCD の Day 1 マネージドクラスターインストール CR を生成します。各 ArgoCD アプリケーションは、最大 300 個の SiteConfig CR を管理できます。詳細は、ArgoCD を使用したハブクラスターの設定 を参照してください。

GitOps ZTP v4.11+ では、デフォルトのポリシーコンプライアンス評価タイムアウト値を PolicyGenTemplate カスタムリソース (CR) で使用できます。この値は、RHACM が適用されたクラスターポリシーを再評価する前に、関連する ConfigurationPolicy CR がポリシー準拠または非準拠の状態を維持できる期間を指定します。

オプションで、PolicyGenTemplate CR の全ポリシーのデフォルト評価間隔をオーバーライドできるようになりました。

詳細は、PolicyGenTemplate CR のポリシーコンプライアンス評価タイムアウトの設定 を参照してください。

Assisted Installer は現在、以下の OpenShift Container Platform プラットフォームをサポートしています。

シングルノード OpenShift は、VSphere をサポートしていません。

このリリースでは、ハブクラスターを設定する際に、非認証レジストリーの使用がサポートされています。認証を必要としないレジストリーは、AgentServiceConfig リソースの spec.unauthenticatedRegistries の下に一覧表示されます。このリストにあるレジストリーのエントリーは、スポーククラスターのインストールに使用されるプルシークレットに含める必要はありません。assisted-service は、インストールに使用されるすべてのイメージレジストリーの認証情報がプルシークレットに含まれていることを確認して、プルシークレットを検証します。

詳細は、非認証レジストリーを使用するためのハブクラスターの設定 を参照してください。

GitOps ZTP を使用して、切断されたインストールを行うには、コンバージドフローが有効になっているスポーククラスターに OpenShift Container Platform バージョン 4.11 以前をデプロイする場合、デフォルトの Ironic エージェントイメージをローカルイメージリポジトリーにミラーリングする必要があります。デフォルトの Ironic エージェントイメージは次のとおりです。

イメージのミラーリングについて詳しくは、OpenShift Container Platform イメージリポジトリーのミラーリング を参照してください。

OpenShift Container Platform は、GitOps ZTP デプロイメントで Discovery ISO のカーネル引数の指定をサポートするようになりました。手動と自動の両方の GitOps ZTP デプロイメントで、Discovery ISO は、管理対象のベアメタルホストでの OpenShift Container Platform インストールプロセスの一部です。InfraEnv リソースを編集して、Discovery ISO のカーネル引数を指定できるようになりました。これは、特定の環境要件を持つクラスターのインストールに役立ちます。たとえば、rd.net.timeout.carrier カーネル引数を定義して、静的ネットワーク用にクラスターを設定するために役立てることができます。

カーネル引数を指定する方法の詳細については、GitOps ZTP を使用して、検出 ISO のカーネル引数を設定する および GitOps ZTP を使用して、手動インストール用に検出 ISO のカーネル引数を設定する を参照してください。

今回の更新により、AMD64 と AArch64 の両方の CPU アーキテクチャーを備えたホストを特徴とする OpenShift Container Platform 混合アーキテクチャークラスター (異種クラスターとも呼ばれる) を作成できるようになりました。Red Hat Advanced Cluster Management (RHACM) によって管理されるハブクラスターから異種スポーククラスターをデプロイできます。異種スポーククラスターを作成するには、デプロイされた AMD64 クラスターに AArch64 ワーカーノードを追加します。

デプロイされた AMD64 クラスターに AArch64 ワーカーノードを追加するには、InfraEnv カスタムリソース (CR) を使用して、ノードに必要な AArch64 アーキテクチャー、マルチアーキテクチャーリリースイメージ、およびオペレーティングシステムを指定できます。次に、Assisted Installer API と InfraEnv CR を使用して、AArch64 ワーカーノードを AMD64 クラスターにプロビジョニングできます。

HTTP は、PTP およびベアメタルイベントインフラストラクチャーのデフォルトトランスポートになりました。AMQ Interconnect は 2024 年 6 月 30 日にライフサイクル終了 (EOL) となります。

詳細は、PTP 高速イベント通知フレームワークについて を参照してください。

OpenShift Container Platform 4.12 では、アクティブな Insights の推奨事項がアラートとしてユーザーに提示されるようになりました。これらのアラートは、Alertmanager で表示および設定できます。

OpenShift Container Platform 4.12 では、Insights Operator が以下のメトリクスを収集するようになりました。

Red Hat OpenStack Platform (RHOSP) で実行されるクラスターの clouds.yaml ファイルで アプリケーション認証情報 を指定できるようになりました。アプリケーション認証情報は、設定ファイルにユーザーアカウントの詳細を埋め込む代わりの方法です。例として、ユーザーアカウントの詳細を含む clouds.yaml ファイルの次のセクションを参照してください。

clouds:
    openstack:
        auth:
            auth_url: https://127.0.0.1:13000
            password: thepassword
            project_domain_name: Default
            project_name: theprojectname
            user_domain_name: Default
            username: theusername
        region_name: regionOne

そのセクションを、アプリケーション認証情報を使用するセクションと比較します。

clouds:
    openstack:
        auth:
            auth_url: https://127.0.0.1:13000
            application_credential_id: '5dc185489adc4b0f854532e1af81ffe0'
            application_credential_secret: 'PDCTKans2bPBbaEqBLiT_IajG8e5J_nJB4kvQHjaAy6ufhod0Zl0NkNoBzjn_bWSYzk587ieIGSlT11c4pVehA'
        auth_type: "v3applicationcredential"
        region_name: regionOne

RHOSP 管理者としてクラスターでアプリケーション認証情報を使用するには、認証情報を作成します。次に、クラスターをインストールするときに、clouds.yaml ファイルでそれらを使用します。または、clouds.yaml ファイルを作成し、それを既存のクラスターにローテーションすることもできます。

OpenShift Container Platform 上でホストされるコントロールプレーンの API である hypershift.openshift.io API のデフォルトバージョンが v1beta1 になりました。既存クラスターの場合、現時点でアルファ版からベータ版への移行はサポートされていません。

OpenShift Container Platform のメジャー、マイナー、またはパッチバージョンのリリースごとに、HyperShift Operator がリリースされます。HyperShift コマンドラインインターフェイス (CLI) は、各 HyperShift Operator リリースの一部としてリリースされます。

HostedCluster および NodePool API リソースは API のベータ版で利用でき、OpenShift Container Platform および Kubernetes と同様のポリシーに従います。

OpenShift Container Platform でホストされたコントロールプレーンを使用する場合、etcd のスナップショットを取得し、S3 バケットなどの後で取得できる場所にアップロードすることで、etcd をバックアップおよび復元できます。必要に応じて、後でスナップショットを復元できます。詳細は、ホストされたクラスターでの etcd のバックアップと復元 を参照してください。

ホストされたクラスターの障害復旧が必要な状況では、ホストされたクラスターを AWS 内の同じリージョンに回復できます。詳細は、AWS リージョン内のホストされたクラスターの障害復旧 を参照してください。