リリースノート

この更新前は、Kubernetes API Server の自己署名ループバック証明書は 1 年で期限切れになりました。このリリースにより、証明書の有効期限が 3 年に延長されました。

この更新前は、--dry-run=server オプションを指定して istag リソースを削除すると、サーバーからイメージが誤って実際に削除されていました。この予期しない削除は、dry-run オプションが oc delete istag コマンドに誤って実装されていたために発生していました。このリリースにより、dry-run オプションが oc delete istag コマンドに関連付けられました。その結果、イメージオブジェクトの誤削除が防止され、--dry-run=server オプションを使用する場合でも istag オブジェクトはそのまま残ります。

この更新により、API サーバーの自己署名ループバック証明書が期限切れになるのを防ぎ、Kubernetes 4.16.z 内における安定したセキュアな接続を確保します。この機能拡張では、新しいバージョンからソリューションをバックポートし、特定のプルリクエストをチェリーピックして、選択されたバージョンに適用します。これにより、証明書関連の問題が原因でサービスが中断される可能性が低減され、Kubernetes 4.16.z デプロイメントでのユーザーエクスペリエンスが向上します。

この更新により、OpenShift Container Platform との通信フローマトリックスが強化されました。この機能は、プライマリーノードでオープンポート 17697 (TCP) および 6080 (TCP) のサービスを自動的に生成し、すべてのオープンポートに対応するエンドポイントスライスがあることを確認します。これにより、正確かつ最新の通信フローマトリックスが実現し、通信マトリックスの全体的なセキュリティーと効率が向上して、より包括的で信頼性の高い通信マトリックスがユーザーに提供されます。

LVM Storage Operator は、ネットワーク通信を必要なコンポーネントのみに制限するために、インストール中に Kubernetes NetworkPolicy オブジェクトを適用するようになりました。この機能は、OpenShift Container Platform クラスター上の LVM Storage デプロイメントに対して、デフォルトのネットワーク分離を適用します。

LVM Storage Operator を使用して永続ボリューム (PV) を作成する場合、PV には kubernetes.io/hostname ラベルが含まれるようになりました。このラベルは、PV がどのノードに配置されているかを示し、ワークロードに関連付けられたノードを簡単に特定できるようにします。この変更は新規に作成された PV にのみ適用されます。既存の PV は変更されません。

LVM Storage Operator のデフォルトの namespace は openshift-lvm-storage になりました。LVM Storage は、引き続きカスタム namespace にインストールできます。

OpenShift Container Platform 4.20 では、マネージドクラスターを SiteConfig カスタムリソース (CR) から ClusterInstance CR へ移行するのを支援するための siteconfig-converter ツールが導入されました。SiteConfig CR を使用してマネージドクラスターを定義することは非推奨となり、今後のリリースで削除される予定です。ClusterInstance CR は、クラスターを定義するためのより統一された汎用的な方法を提供します。これは、GitOps ZTP ワークフローでクラスターデプロイメントを管理するための推奨される方法です。

siteconfig-converter ツールを使用すると、SiteConfig CR を ClusterInstance CR に変換し、一度に 1 つ以上のクラスターを段階的に移行できます。既存および新規パイプラインは並行して実行されるため、ダウンタイムを発生させることなく、制御された段階的な方法でクラスターを移行できます。

詳細は、SiteConfig CR から ClusterInstance CR への移行 を参照してください。

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

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

現在、この機能は一般提供されています。

詳細は、ローカルアービターノードの設定 を参照してください。

フェンシング機能を備えた 2 ノード OpenShift クラスターは、ハードウェアのフットプリントを削減しながら、高可用性 (HA) を実現します。この構成は、完全な 3 ノードのコントロールプレーンクラスターをデプロイすることが現実的ではない分散環境またはエッジ環境向けに設計されています。

2 ノードクラスターにはコンピュートノードは含まれません。2 台のコントロールプレーンマシンが、クラスターの管理に加えて、ユーザーワークロードを実行します。

詳細は、フェンシング機能を備えた 2 ノード OpenShift クラスターのインストール準備 を参照してください。

このリリースにより、TechPreviewNoUpgrade 機能セットを有効にして、Webhook を使用するクラスター拡張機能をクラスターにデプロイできます。

詳細は、サポートされる拡張機能 を参照してください。

このリリースにより、virt-launcher Pod からのコマンドラインログを Kubernetes クラスター全体で収集できるようになりました。JSON でエンコードされたログは namespaces/<namespace-name>/pods/<pod-name>/virt-launcher.json パスに保存されるため、仮想マシンのトラブルシューティングとデバッグが容易になります。

このリリースにより、Cluster Version Operator (CVO) のログレベルの詳細度がクラスター管理者によって変更できるようになりました。

詳細は、CVO ログレベルの変更 を参照してください。

OpenShift Container Platform 4.18 では、テクノロジープレビュー機能として、ノードごとに複数のネットワークインターフェイスコントローラー (NIC) を使用する VMware vSphere クラスターのインストールが可能になりました。現在、この機能は一般提供されています。

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

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

このリリースにより、Google Cloud 上のクラスターを共有 VPC にインストールするときに、DNS プライベートゾーンの場所を指定できるようになりました。プライベートゾーンは、ホストプロジェクトまたはメインサービスプロジェクトとは異なるサービスプロジェクトに配置できます。

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

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

このリリースにより、IBM Cloud Paks を使用してクラスターをインストールする場合は、ポート 443 で icr.io および cp.icr.io へのアウトバウンドアクセスを許可する必要があります。このアクセスは、IBM Cloud Pak コンテナーイメージに必要です。詳細は、ファイアウォールの設定 を参照してください。

このリリースにより、Intel ベースの Confidential VM を使用して Azure にクラスターをインストールできます。以下のマシンサイズがサポートされるようになりました。

詳細は、Confidential VM の有効化 を参照してください。

このリリースにより、etcd の専用データディスクを使用して OpenShift Container Platform クラスターを Azure にインストールできます。この設定により、各コントロールプレーンノードに個別のマネージドディスクが割り当てられ、そのディスクが etcd データにのみ使用されます。そのため、クラスターのパフォーマンスと安定性が向上します。この機能は、テクノロジープレビューとして利用できます。詳細は、etcd 専用ディスクの設定 を参照してください。

このリリースにより、マルチアーキテクチャー機能をサポートするベアメタル環境をインストールできるようになります。仮想メディアを使用して、既存の x86_64 クラスターから x86_64 と aarch64 の両方のアーキテクチャーをプロビジョニングできます。つまり、多様なハードウェア環境をより効率的に管理できます。

詳細は、マルチアーキテクチャーのコンピュートマシンを使用したクラスターの設定 を参照してください。

このリリースにより、ベアメタルの HostFirmwareComponents リソースがネットワークインターフェイスコントローラー (NIC) を記述します。NIC ホストのファームウェアコンポーネントを更新するには、サーバーが Redfish をサポートしており、かつ Redfish を使用した NIC ファームウェアの更新を許可している必要があります。

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

OpenShift Container Platform 4.17 では、以前に 削除された Kubernetes API が誤って再導入されていました。これは OpenShift Container Platform 4.20 で再度削除されました。

クラスターを OpenShift Container Platform 4.19 から 4.20 に更新する前に、クラスター管理者は手動で承認を行う必要があります。この安全策は、ワークロード、ツール、またはその他のコンポーネントが、OpenShift Container Platform 4.20 で削除された Kubernetes API に依然として依存している場合に発生する可能性のある更新の問題を防ぐのに役立ちます。

管理者は、クラスターの更新に進む前に、次のアクションを実行する必要があります。

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

詳細は、Kubernetes API の削除 を参照してください。

以前は、IBM Power Virtual Server にクラスターをインストールするときに、既存の Transit Gateway または Virtual Private Cloud (VPC) の名前しか指定できませんでした。名前の一意性が保証されていないため、競合やインストールが失敗する可能性がありました。このリリースでは、Transit Gateway および VPC に Universally Unique Identifiers (UUID) を使用できるようになりました。一意の識別子を使用すると、インストールプログラムは正しい Transit Gateway または VPC を明確に特定できます。これにより、命名の競合が回避され、問題が解決されます。

このリリースでは、新しい Oracle インフラストラクチャー製品にテクノロジープレビュークラスターをインストールできます。

次の新しい Oracle Distributed Cloud インフラストラクチャータイプが利用できるようになりました。

次の新しい Oracle Edge Cloud インフラストラクチャータイプが利用可能になりました。

詳細は、Assisted Installer を使用して Oracle Distributed Cloud にクラスターをインストールする および Assisted Installer を使用して Oracle Edge Cloud にクラスターをインストールする を参照してください。

VMware vSphere クラスター用の更新されたブートイメージが、テクノロジープレビュー機能としてサポートされるようになりました。この機能を使用すると、クラスターを更新するたびにノードのブートイメージが更新されるようにクラスターを設定できます。デフォルトでは、クラスター更新時にクラスター内のブートイメージは更新されません。詳細は、ブートイメージの更新 を参照してください。

以下のマシン設定の変更により、オンクラスターのカスタムレイヤー化イメージを持つノードの再起動が発生しなくなりました。

詳細は、オンクラスターイメージモードの既知の制限 を参照してください。

Image Mode for OpenShift が設定されている場合、エラーレポートが改善され、以下のような変更が含まれます。

オンクラスターカスタムレイヤー化イメージを持つノード上の MachineConfig オブジェクトで kernelType パラメーターを使用して、ノードにリアルタイムカーネルをインストールできるようになりました。以前は、オンクラスターカスタムレイヤー化イメージを持つノードでは、kernelType パラメーターは無視されていました。詳細は、リアルタイムカーネルのノードへの追加 を参照してください。

イメージレジストリーへの接続が遅く、信頼性が低いクラスターでは、PinnedImageSet オブジェクトを使用して、イメージが必要になる前に事前にイメージをプルし、それらのイメージをマシン設定プールに関連付けることができます。これにより、必要なときにそのプール内のノードでイメージが利用できるようになります。Machine Config Operator 用の must-gather には、クラスター内のすべての PinnedImageSet オブジェクトが含まれます。詳細は、ノードへのイメージのピニング を参照してください。

マシン設定ノードのカスタムリソースが一般提供になりました。これを使用すると、ノードに対するマシン設定の更新の進行状況を監視できます。

コントロールプレーンとワーカープールに加えて、カスタムマシン設定プールの更新ステータスも確認できるようになりました。この機能そのものは変更されていません。ただし、コマンド出力および MachineConfigNode オブジェクトのステータスフィールドの一部の情報は、更新されています。Machine Config Operator 用の must-gather には、クラスター内のすべての MachineConfigNodes オブジェクトが含まれます。詳細は、マシン設定ノードのステータスの確認について を参照してください。

このリリースには、hostmount-anyuid-v2 という名前の新しい Security Context Constraints (SCC) が含まれます。この SCC は、hostmount-anyuid SCC と同じ機能を提供しますが、seLinuxContext: RunAsAny が含まれています。hostmount-anyuid SCC は、信頼された Pod がホスト上の任意のパスにアクセスできるように意図されたものでしたが、実際にはコンテナーによるほとんどのパスへのアクセスを SELinux が妨げてしまいます。このため、この SCC が追加されました。hostmount-anyuid-v2 は、UID 0 を含む任意の UID としてホストファイルシステムへのアクセスを許可し、privileged SCC の代わりに使用することを目的としています。付与には注意が必要です。

Cluster API を使用してマシンを管理するクラスターでは、コンピュートマシンが AWS Capacity Reservation を使用するかどうかを決定するための追加の制約を指定できます。詳細は、Capacity Reservation の設定オプション を参照してください。

ClusterAutoscaler CR の spec.scaleUp.newPodScaleUpDelay パラメーターを使用して、クラスターオートスケーラーが新しく保留中の Pod を認識し、Pod を新しいノードにスケジュールするまでの遅延を設定できるようになりました。遅延後もノードがスケジュールされていないままの場合、クラスターオートスケーラーは新しいノードをスケールアップできます。この遅延により、クラスターオートスケーラーは適切なノードを見つけるための追加時間を確保したり、既存の Pod のスペースが使用可能になるまで待機したりできるようになります。詳細は、クラスターオートスケーラーの設定 を参照してください。

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

このリリースにより、Metrics Server のログの詳細度を設定できるようになりました。数値の詳細レベルを設定して、ログに記録される情報の量を制御できます。数値が大きいほど、ログの詳細度が高くなります。

詳細は、モニタリングコンポーネントのログレベルの設定 を参照してください。

OpenShift Container Platform 4.20 では、Red Hat OpenShift Service Mesh がバージョン 3.1.0 に更新され、Red Hat OpenShift AI がサポートされるようになりました。このバージョン更新では、重要な CVE 修正が組み込まれ、その他のバグが解決され、セキュリティーとパフォーマンスを向上させるために Istio がバージョン 1.26.2 にアップグレードされます。詳細は、Service Mesh 3.1.0 リリースノート を参照してください。

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 ルーティングについて を参照してください。

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

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

事前設定済みユーザー定義ネットワークエンドポイントは、テクノロジープレビューとして利用でき、フィーチャーゲート PreconfiguredUDNAddresses によって制御されます。IP アドレス、MAC アドレス、デフォルトゲートウェイなどのオーバーレイネットワーク設定を明示的に制御できるようになりました。この機能は、ClusterUserDefinedNetwork (CUDN) カスタムリソース (CR) の一部としてレイヤー 2 で使用できます。管理者はエンドポイントを事前設定して、中断することなく KubeVirt 仮想マシン (VM) を移行できます。この機能を有効にするには、CUDN CR にある新規フィールド reservedSubnets、infrastructureSubnets、および defaultGatewayIPs を使用します。設定の詳細は、ユーザー定義ネットワークの追加設定の詳細 を参照してください。現在、静的 IP アドレスは ClusterUserDefinedNetworks CR に対してのみサポートされ、MTV でのみ使用できます。

クラスターのインストール時に configure-ovs.sh シェルスクリプトを使用して br-ex ブリッジを設定した場合、インストール後のタスクとして br-ex ブリッジを NMState に移行できます。詳細は、設定済みの br-ex ブリッジの NMState への移行 を参照してください。

linuxptp-daemon によって生成されるログの量を削減するために、PTP Operator の強化されたログ削減機能を設定できるようになりました。

この機能は、フィルタリングされたログの定期的な要約を提供しますが、これは基本的なログ削減では利用できません。必要に応じて、サマリーログの特定の間隔と、マスターオフセットログのしきい値 (ナノ秒単位) を設定できます。

詳細は、強化された PTP ロギングの設定 を参照してください。

このリリースにより、次のデュアルポート NIC のみを使用する AArch64 アーキテクチャーノードで、冗長性が追加された PTP 通常クロックを設定できます。

この機能は、テクノロジープレビューとして利用できます。詳細は、デュアルポート NIC を使用して PTP 通常クロックの冗長性を向上させる を参照してください。

このリリースにより、Bond CNI プラグイン設定の一部として xmitHashPolicy を使用し、集約されたインターフェイス間で負荷分散するための送信ハッシュポリシーを指定できるようになりました。この機能は、テクノロジープレビューとして利用できます。

詳細は、Bond CNI セカンダリーネットワークの設定 を参照してください。

OpenShift Container Platform 4.20 では、アプリケーション namespace 内で SR-IOV ネットワークを直接作成および管理できるようになりました。この新しい機能により、ネットワーク設定をより細かく制御できるようになり、ワークフローが簡素化されます。

以前は、SR-IOV ネットワークの作成は、クラスター管理者が設定する必要がありました。これで、これらのリソースを独自の namespace で直接管理できるようになり、次のようないくつかの重要な利点が得られます。

詳細は、namespaced SR-IOV リソースの設定 を参照してください。

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

詳細は、MetalLB と FRR-K8s の統合の設定 を参照してください。

このテクノロジープレビュー機能では、F Status Relay Operator が導入されています。Operator は、アップストリームスイッチの障害を検出するためのヘルスチェックとして Link Aggregation Control Protocol (LACP) を使用し、SR-IOV ネットワーク Virtual Function (VF) による Pod レベルのボンディングを使用するワークロードの高可用性を実現します。

この機能がないと、基盤となる Physical Function (PF) が up 状態を引き続き報告している間に、アップストリームスイッチに障害が発生する可能性があります。PF に接続された VF も up のままになり、これにより Pod がデッドエンドポイントにトラフィックを送信し、パケットロスが発生します。

PF Status Relay Operator は、PF の LACP ステータスを監視することでこれを防ぎます。障害が検出されると、Operator はアタッチされている VF のリンク状態を強制的にダウンさせ、Pod のボンディングをトリガーしてバックアップパスにフェイルオーバーします。これにより、ワークロードが利用可能のままになり、パケットロスが最小限に抑えられます。

詳細は、SR-IOV ネットワークにおける Pod レベルボンディングの高可用性 を参照してください。

このリリースにより、OpenShift Container Platform は、Ingress トラフィックと Egress トラフィックを制御するために、Kubernetes ネットワークポリシーを追加のシステム namespace にデプロイします。今後のリリースでは、追加のシステム namespace と Red Hat Operator のネットワークポリシーが含まれる可能性があります。

このリリースでは、PTP Operator はテクノロジープレビュー機能として補助なしホールドオーバーを提供します。アップストリームのタイミング信号が失われた場合、PTP Operator は、境界クロックまたはタイムスレーブクロックのいずれかとして設定された PTP デバイスを自動的にホールドオーバーモードにします。自動配置のホールドオーバーモードを使用すると、クラスターノードの継続的で安定したタイムソースを維持し、時刻同期の中断を最小限に抑えることができます。

詳細は、PTP デバイスの設定 を参照してください。

このリリースでは、OpenShift Container Platform に、自動化されたプロビジョニングとライフサイクル管理のために、Data Center on a Chip Architecture (DOCA) Platform Framework (DPF) Operator によって管理される NVIDIA BlueField-3 Data Processing Unit (DPU) のサポートがテクノロジープレビュー機能として導入されました。このソリューションは、お客様に次の主要な利点を提供します。

このデプロイメントでは、インフラストラクチャークラスターとテナントクラスターで構成されるデュアルクラスターモデルが使用されます。また、Firefly、SNAP、Telemetry、DPU 上のサードパーティーネットワーク機能など、将来の DOCA サービスへの道も開かれます。

sigstore ClusterImagePolicy および ImagePolicy オブジェクトのサポートが一般提供になりましたAPI バージョンは config.openshift.io/v1 になりました。詳細は、sigstore を使用したセキュアな署名管理 を参照してください。

Pod とコンテナーを Linux ユーザー名前空間にデプロイするためのサポートが一般提供になり、デフォルトで有効になります。個々のユーザー名前空間で Pod とコンテナーを実行すると、侵害されたコンテナーから他の Pod やノード自体に及ぶ可能性のあるいくつかの脆弱性を軽減できます。この変更には、ユーザー名前空間で使用するために特別に設計された 2 つの新しい Security Context Constraints (restricted-v3 と nested-container) が含まれています。また、/proc ファイルシステムを Pod で unmasked として設定することもできます。詳細は、Linux ユーザー名前空間での Pod の実行 を参照してください。

インプレース Pod サイズ変更機能を使用すると、Pod を再作成または再起動せずに、サイズ変更ポリシーを適用して、実行中の Pod 内のコンテナーの CPU およびメモリーリソースを変更できます。詳細は、手動で Pod リソースレベルを調整する を参照してください。

イメージボリュームを使用して、Open Container Initiative (OCI)準拠のコンテナーイメージを Pod に直接マウントできます。詳細は、OCI イメージの Pod へのマウント を参照してください。

製品名、GPU メモリー容量、コンピュート機能、ベンダー名、ドライバーバージョンなどの特定のデバイス属性に基づいて、Pod が GPU をリクエストできるようになりました。これらの属性は、インストールするサードパーティーの DRA リソースドライバーを使用して公開されます。詳細は、GPU の Pod への割り当て を参照してください。

以前はテクノロジープレビューでしたが、現在は一般提供になっている oc adm upgrade recommend コマンドを使用すると、システム管理者はコマンドラインインターフェイス (CLI) を使用して、OpenShift Container Platform クラスターの更新前チェックを実行できます。更新前のチェックは、潜在的な問題を特定し、ユーザーが更新を開始する前にそれらの問題に対処できるようにします。precheck コマンドを実行してその出力を検査することで、ユーザーはクラスターの更新の準備をし、更新をいつ開始するかについて情報に基づいた決定を下すことができます。

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

以前はテクノロジープレビューでしたが、現在は一般提供になっている oc adm upgrade status コマンドを使用すると、クラスター管理者は、コマンドラインインターフェイス (CLI) を使用して、OpenShift Container Platform クラスターの更新の状態に関する概要情報を取得できます。コマンドを入力すると、コントロールプレーン情報、ワーカーノード情報、およびヘルスインサイトの 3 種類の情報が提供されます。

このコマンドは、現在、Hosted Control Plane (HCP) クラスターではサポートされていません。

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

オペランドイメージは、ランタイム時に Operator コントローラーによって動的にデプロイされ、通常はコントローラーのデプロイメントテンプレート内の環境変数によって参照されます。

OpenShift Container Platform 4.20 より前では、oc-mirror プラグイン v2 はこれらの環境変数にアクセスできましたが、ログレベルなどのイメージ以外の参照を含むすべての値をミラーリングしようとしたため、失敗していました。この更新により、OpenShift Container Platform はこれらの環境変数で参照されるコンテナーイメージのみを識別し、ミラーリングします。

詳細は、oc-mirror プラグイン v2 の ImageSet 設定パラメーター を参照してください。

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

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

このリリースにより、Red Hat が提供する Operator カタログが OperatorHub からソフトウェアカタログに移動され、コンソールの Operator ナビゲーション項目の名前が Ecosystem に変更されました。統合ソフトウェアカタログでは、Operator、Helm チャート、その他のインストール可能なコンテンツが同じコンソールビューに表示されます。

デフォルトまたはカスタムのカタログソースを管理するには、コンソールまたは CLI で OperatorHub カスタムリソース (CR) を引き続き操作します。

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

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

この更新により、kdump は x86_64、arm64、s390x、ppc64le を含む、サポートされているすべてのアーキテクチャーで一般提供されました。この機能拡張により、ユーザーはカーネルの問題をより効率的に診断して解決できるようになります。

RHCOS では、Ignition のバージョン 2.20.0 が導入されました。この機能拡張により、dracut モジュールのインストールに含まれるようになった partx ユーティリティーを使用して、マウントされたパーティションを持つディスクのパーティション分割がサポートされるようになりました。さらに、この更新では、Proxmox Virtual Environment がサポートされるようになりました。

RHCOS には Butane バージョン 0.23.0 が含まれるようになりました。

RHCOS に Afterburn バージョン 5.7.0 が含まれるようになりました。この更新で、Proxmox Virtual Environment がサポートされるようになりました。

このリリースにより、coreos-installer ユーティリティーがバージョン 0.23.0 に更新されました。

OpenShift Container Platform 4.20 では、NUMA Resources Operator はデフォルトで高可用性 (HA) モードを自動的に有効にします。このモードでは、NUMA Resources Operator は、クラスター内のコントロールプレーンノードごとに 1 つのスケジューラーレプリカを作成して、冗長性を確保します。このデフォルトの動作は、NUMAResourcesScheduler カスタムリソースで spec.replicas フィールドが指定されていない場合に発生します。または、特定のスケジューラーレプリカ数を明示的に設定してデフォルトの HA 動作をオーバーライドしたり、spec.replicas フィールドを 0 に設定してスケジューラー自体を完全に無効にしたりすることもできます。コントロールプレーンノードの数が 3 を超える場合でも、レプリカの最大数は 3 です。

詳細は、NUMA 対応スケジューラーの高可用性 (HA) の管理 を参照してください。

このリリースにより、NUMA Resources Operator は、スケジュール可能として設定されたコントロールプレーンノードを管理できるようになりました。この機能により、コントロールプレーンノードにトポロジー対応のワークロードをデプロイできるようになります。これは、コンパクトクラスターなどのリソースが制限された環境で特に役立ちます。

この機能拡張により、NUMA Resources Operator は、コントロールプレーンノード上でも、最も適切な NUMA トポロジーを持つノード上で NUMA 対応 Pod をスケジュールできるようになります。

詳細は、NUMA Resources Operator による、スケジューリング可能なコントロールプレーンノードのサポート を参照してください。

このリリースにより、Performance Profile を適用する際に、Receive Packet Steering (RPS) は設定されなくなりました。RPS 設定は、レイテンシーの影響を受けやすいスレッド内で直接、send などのネットワークシステムコールを実行するコンテナーに影響します。RPS が設定されていない場合にレイテンシーの影響を回避するには、ネットワーク呼び出しをヘルパースレッドまたはプロセスに移動します。

以前の RPS 設定では、全体的な Pod カーネルネットワークパフォーマンスを犠牲にして、レイテンシーの問題が解決されていました。現在のデフォルト設定は、パフォーマンスへの影響を覆い隠すのではなく、開発者に基盤となるアプリケーション設計への対処を要求することで、透明性を高めています。

以前の動作に戻すには、performance.openshift.io/enable-rps アノテーションを PerformanceProfile マニフェストに追加します。

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: example-performanceprofile
  annotations:
    performance.openshift.io/enable-rps: "enable"

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: example-performanceprofile
  annotations:
    performance.openshift.io/enable-rps: "enable"

このリリースにより、PerformanceProfile カスタムリソースを使用して、Intel Sierra Forest CPU を搭載したマシン上のワーカーノードを設定できます。これらの CPU は、単一の NUMA ドメイン (NPS=1) で設定された場合にサポートされます。

このリリースにより、PerformanceProfile カスタムリソースを使用して、AMD Turin CPU を備えたマシンでワーカーノードを設定できるようになりました。これらの CPU は、単一の NUMA ドメイン (NPS=1) で設定されている場合に完全にサポートされます。

この新機能は、OpenShift Container Platform における TLS 証明書のローテーションを強化し、95% の期待されるクラスター可用性を確保します。これは、特にトランザクションレートの高いクラスターやシングルノード OpenShift デプロイメントにとって有益であり、高い負荷がかかった状態でもシームレスな運用を確保します。

この更新により、etcd 製品ドキュメントが更新され、OpenShift Container Platform クラスターのレイテンシーを削減するための追加要件が含まれるようになりました。この更新により、etcd を使用するための前提条件およびセットアップ手順が明確になり、ユーザーエクスペリエンスが改善されました。その結果、この機能は etcd での Transport Layer Security (TLS) 1.3 のサポートを導入し、データ送信のセキュリティーとパフォーマンスを向上させ、etcd が最新のセキュリティー標準に準拠し、潜在的な脆弱性を軽減します。暗号化が改善されたことで、etcd とそのクライアント間の通信がよりセキュアになりました。詳細は、etcd のクラスターレイテンシーの要件 を参照してください。

Secrets Store CSI Driver Operator バージョン 4.20 は、アップストリームの v1.5.2 リリースをベースとするようになりました。Secrets Store CSI Driver Operator は、ネットワーク通信を必要なコンポーネントのみに制限するために、インストール時に Kubernetes NetworkPolicy オブジェクトを適用するようになりました。

ボリュームポピュレーター機能により、事前に設定されているボリュームを作成できます。

OpenShift Container Platform 4.20 では、永続ボリューム要求 (PVC) およびスナップショットのみから適切なカスタムリソース (CR) にのみ、ボリュームの事前処理のデータソースとして使用できるオブジェクトを拡張する、ボリュームポピュレーターの機能用に新規 field dataSourceRef が導入されています。

OpenShift Container Platform には、対応する VolumePopulator インスタンスがない状態でボリュームポピュレーターを使用している PVC に関するイベントを報告する volume-data-source-validator が同梱されるようになりました。以前の OpenShift Container Platform バージョンでは VolumePopulator インスタンスは必要なかったので、4.12 以降からアップグレードする場合は、登録されていないポピュレーターに関するイベントを受信する可能性があります。以前に volume-data-source-validator を自分でインストールしていた場合は、そのバージョンを削除できます。

OpenShift Container Platform 4.12 でテクノロジープレビュー機能として導入されたボリュームポピュレーター機能が、一般提供としてサポートされるようになりました。

ボリュームの設定はデフォルトで有効になっています。ただし、OpenShift Container Platform にはボリュームポピュレーターは同梱されていません。

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

Performance Plus を有効にすることで、513 GiB 以上の以下の種類のディスクについて、1 秒あたりの入出力操作 (IOPS) とスループットの上限を引き上げることができます。

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

Performance Plus の詳細は、Azure Disk の Performance Plus を参照してください。

変更ブロック追跡により、この機能をサポートする Container Storage Interface (CSI) ドライバーによって管理される永続ボリューム (PV) の、効率的かつ増分的なバックアップと障害復旧が可能になります。

変更ブロック追跡により、コンシューマーは 2 つのスナップショット間で変更されたブロックのリストを要求できます。これは、バックアップソリューションベンダーにとって有用な機能です。ボリューム全体ではなく、変更ブロックのみをバックアップすることで、バックアッププロセスがより効率的になります。

変更ブロック追跡の詳細については、こちらの ナレッジベース記事 を参照してください。

OpenShift Container Platform 4.20 では、AWS Elastic File Storage (EFS) One Zone ボリュームのサポートが一般提供として導入されています。この機能により、ファイルシステムの Domain Name System (DNS) 名前解決が失敗した場合でも、EFS CSI ドライバーはマウントターゲットにフォールバックできます。マウントターゲットとは、Virtual Private Cloud (VPC) 内の AWS EC2 インスタンスやその他の AWS コンピュートインスタンスが、EFS ファイルシステムに接続してマウントできるようにするネットワークエンドポイントです。

One Zone に関する詳細は、One Zone のサポート を参照してください。

ボリュームの特定の操作により Pod の起動に遅延が発生し、Pod のタイムアウトが生じる可能性があります。

fsGroup: 多数のファイルを含むボリュームの場合、ボリュームがマウントされるときに、OpenShift Container Platform が、Pod の securityContext で指定された fsGroup と一致するように、各ボリュームの内容の所有権と権限をデフォルトで再帰的に変更するため、Pod の起動タイムアウトが発生する可能性があります。これは時間がかかり、Pod の起動が遅くなる可能性があります。securityContext 内の fsGroupChangePolicy パラメーターを使用して、OpenShift Container Platform がボリュームの所有者および権限を確認し管理する方法を制御できます。

Pod レベルでこのパラメーターを変更する機能は、OpenShift Container Platform 4.10 で導入されました。4.20 では、一般提供される機能として、Pod レベルに加えて、このパラメーターを namespace レベルに設定できます。

SELinux: SELinux (Security-Enhanced Linux) は、システム上のすべてのオブジェクト (ファイル、プロセス、ネットワークポートなど) にセキュリティーラベル (コンテキスト) を割り当てるセキュリティーメカニズムです。これらのラベルにより、プロセスが何にアクセスできるか決まります。Pod が起動すると、コンテナーランタイムは、Pod の SELinux コンテキストに合わせて、ボリューム上のすべてのファイルに対して再帰的にラベルの再設定を行います。ファイルが多いボリュームの場合、これにより Pod の起動時間が大幅に長くなる可能性があります。マウントオプションは、-o context マウントオプションを使用して正しい SELinux ラベルでボリュームを直接マウントしようとすることで、すべてのファイルの再帰的なラベル付けを回避するように指定します。これにより、Pod のタイムアウト問題を回避することができます。

RWOP および SELinux マウントオプション: ReadWriteOncePod (RWOP) 永続ボリュームは、デフォルトで SELinux マウント機能を使用します。マウントオプションは、テクノロジープレビュー機能として OpenShift Container Platform 4.15 で導入され、4.16 で一般提供されるようになりました。

RWO、RWX および SELinux マウントオプション: ReadWriteOnce (RWO) および ReadWriteMany (RWX) ボリュームは、デフォルトでラベルの再帰的な再設定を使用します。RWO/RWX のマウントオプションは、OpenShift Container Platform 4.17 で開発者プレビュー機能として導入されましたが、現在は 4.20 でテクノロジープレビュー機能としてサポートされています。

今後のマウントオプションのデフォルトへの移行を支援するために、OpenShift Container Platform 4.20 では、潜在的な競合を知らせるために Pod の作成時および Pod の実行時に SELinux 関連の競合を報告し、解決できるようにします。このレポートの詳細については、こちらの ナレッジベースの記事 を参照してください。

SELinux 関連の競合を解決できない場合は、選択した Pod または namespace のデフォルトとして、今後のマウントオプションへの移行を事前にオプトアウトできます。

OpenShift Container Platform 4.20 では、RWO および RWX ボリュームのマウントオプション機能をテクノロジープレビュー機能として評価できます。

fsGroup の詳細は、fsGroup を使用して Pod のタイムアウトを減らす を参照してください。

SELinux の詳細は、seLinuxChangePolicy を使用して Pod のタイムアウトを減らす を参照してください。

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.20 では、この機能は一般提供されています。

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

デフォルトで、OpenShift Container Platform は、単一の IP アドレスまたはサブネットに更新できるように、すべての IPv4 クライアントへのアクセスを提供する Manila ストレージクラスを作成します。OpenShift Container Platform 4.20 では、nfs-ShareClient パラメーターを使用して、複数のクライアント IP アドレスまたはサブネットを使用するカスタムストレージクラスを定義することで、クライアントアクセスを制限できます。

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

詳細は、Manila 共有アクセスルールのカスタマイズ を参照してください。

使いやすさを強化し、STS (Security Token Service)と非 STS サポートを提供するために、Amazon Web Services (AWS) Elastic File Service (EFS)クロスアカウントサポート手順が修正されました。

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

この更新前は、コンテナーイメージ フォームフローはアプリケーションの定義済みアイコンの限定セットのみを提供していました。

この更新により、コンテナーイメージ フォームを使用してアプリケーションをインポートするときに、カスタムアイコンを追加できるようになりました。既存のアプリケーションの場合、app.openshift.io/custom-icon アノテーションを適用し、対応する Topology ノードにカスタムアイコンを追加します。

その結果、Topology ビューでアプリケーションをより適切に特定し、プロジェクトをより明確に整理できます。

Confidential Computing with AMD Secure Encrypted Virtualization (AMD SEV) on Google Cloud の使用は非推奨となり、今後のリリースでは削除される可能性があります。

代わりに、AMD Secure Encrypted Virtualization Secure Nested Paging (AMD SEV-SNP) を使用できます。

Docker v2 レジストリーのサポートは非推奨となり、今後のリリースで削除される予定です。今後のリリースでは、すべてのミラーリング操作に Open Container Initiative (OCI) 仕様をサポートするレジストリーが必要になります。さらに、oc-mirror v2 は OCI 形式でカスタムカタログイメージのみを生成するようになりましたが、非推奨となった oc-mirror v1 は引き続き Docker v2 形式をサポートします。

Red Hat Marketplace は非推奨になりました。Marketplace のパートナーソフトウェアを使用するお客様は、Marketplace Operator から Red Hat Ecosystem Catalog の Operator に移行する方法について、ソフトウェアベンダーに問い合わせる必要があります。今後の OpenShift Container Platform リリースでは、Marketplace インデックスが削除される予定です。詳細は、Sunset of the Red Hat Marketplace, operated by IBM を参照してください。

Red Hat Quay Container Security Operator は非推奨となり、今後の OpenShift Container Platform リリースで削除される予定です。Red Hat Quay Container Security Operator の公式な代替は Red Hat Advanced Cluster Security for Kubernetes です。

OpenShift Container Platform 4.20 では、以下の Kubernetes API が削除されました。4.20 に更新する前に、マニフェスト、自動化機能、および API クライアントを、新しくサポートされる API バージョンを使用するように移行する必要があります。削除された API の移行についての詳細は、Kubernetes のドキュメント を参照してください。

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

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

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

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

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