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

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

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

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

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

LVM ストレージ Operator のデフォルトの名前空間は openshift-lvm-storage になりました。LVM ストレージは、引き続きカスタム 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 つ以上のクラスターを段階的に移行できます。既存および新規パイプラインは並行して実行されるため、制御された段階的かつダウンタイムなしにクラスターを移行できます。

詳細は、Migrating from SiteConfig CR to ClusterInstance CR を参照してください。

このリリースでは、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 プライベートゾーンの場所を指定できるようになりました。プライベートゾーンは、ホストプロジェクトまたはメインサービスプロジェクトとは異なるサービスプロジェクトに配置できます。

詳細は、Additional Google Cloud configuration parameters を参照してください。

今回のリリースにより、暗号化された仮想ネットワークを使用して Azure にクラスターをインストールできるようになりました。premiumIO パラメーターが true に設定されている Azure 仮想マシンを使用する必要があります。詳細は、暗号化を使用した仮想ネットワークの作成 および 要件と制限 を参照してください。

このリリースでは、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 ファームウェアを更新できるようにする必要があります。

詳細は、About the HostFirmwareComponents resource を参照してください。

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 の削除 を参照して ください。

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

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

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

OpenShift のイメージモードが設定されている場合、以下の変更を含むエラーレポートが改善されました。

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

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

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

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

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

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

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

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

今回のリリースにより、メトリクスサーバーのログの詳細度を設定できるようになりました。数値の詳細レベルを設定して、ログに記録された情報の量を制御できます。これにより、ログの詳細が大きくなります。

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

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 とサービスのルートを、プロバイダーネットワークに直接アドバタイズできるようになります。この機能により、次のような利点がいくつか得られます。

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

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

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

この機能は、フィルターされたログの定期的なサマリーを提供します。これは、基本的なログの削減には使用できません。オプションで、サマリーログの特定の間隔と、マスターオフセットログのしきい値（ナノ秒単位）を設定できます。

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

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

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

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

詳細は、ボンド 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 の統合の設定 を 参照してください。

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

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

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

詳細は、High availability for pod-level bonds on SR-IOV networks を参照してください。

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

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

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

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

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

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

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

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

以前のテクノロジープレビューおよび一般提供された oc adm upgrade status コマンドを使用すると、クラスター管理者はコマンドラインインターフェイス(CLI)を使用して OpenShift Container Platform クラスターの更新の状態についての概要情報を取得できます。コマンドを入力すると、コントロールプレーンの情報、ワーカーノードの情報、およびヘルス Insights の 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.19 との互換性のために更新されます。これらのベースイメージのランタイム機能と設定 API は、バグ修正と CVE への対応のためにサポートされます。

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

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

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

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

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

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

RHCOS では、Ignition のバージョン 2.20.0 が導入されました。この機能強化により、partx ユーティリティーを使用してマウントされたパーティションでディスクのパーティション設定がサポートされるようになりました。これは、dracut モジュールインストールに含まれています。さらにこの更新では、Proxmox 仮想環境のサポートが追加されました。

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

RHCOS に Afterburn バージョン 5.7.0 が含まれるようになりました。今回の更新で、Proxmox 仮想環境のサポートが追加されました。

今回のリリースで、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 のサポート を参照し てください。

このリリースでは、パフォーマンスプロファイルの適用時に受信パケットステアリング(RPS)は設定されなくなりました。RPS 設定は、レイテンシーの影響を受けやすいスレッド内で直接送信など、ネットワークシステムコールを実行するコンテナーに影響します。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 デプロイメントには特に利点があります。これにより、負荷が大きい場合でもシームレスな操作が可能になります。

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