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

RHCOS は、OpenShift Container Platform 4.14 で Red Hat Enterprise Linux (RHEL) 9.2 パッケージを使用するようになりました。これらのパッケージにより、OpenShift Container Platform インスタンスが最新の修正、機能、拡張機能、ハードウェアサポート、およびドライバーの更新を確実に受け取ることができます。この変更から除外される OpenShift Container Platform 4.12 は、ライフサイクル全体にわたって RHEL 8.6 延長更新サポート (EUS) パッケージを引き続き使用する EUS リリースです。

OpenShift Container Platform 4.14 では、クラスターとは別のアカウントのプライベートホスト型ゾーンを持つ共有 Virtual Private Cloud (VPC) を使用するクラスターを AWS にインストールできます。詳細は、AWS 上のクラスターを既存の VPC へインストールする を参照してください。

この更新により、AWS でのクラスターのブートストラップ中に、S3 バケットの自動削除をオプトアウトできるようになりました。このオプションは、S3 バケットの削除を阻止するセキュリティーポリシーがある場合に便利です。

OpenShift Container Platform 4.14 では、アウトバウンドネットワーキングに NAT ゲートウェイを使用するクラスターをインストールできます。これはテクノロジープレビュー (TP) として利用できます。詳細は、追加の Azure 設定パラメーター を参照してください。

OpenShift Container Platform 4.14 では、pd-balanced ディスクタイプを使用して GCP にクラスターをインストールできます。このディスクタイプはコンピュートノードでのみ使用可能であり、コントロールプレーンノードでは使用できません。詳細は、追加の GCP 設定パラメーター を参照してください。

OpenShift Container Platform 4.14 では、インストール中に Build、DeploymentConfig、ImageRegistry、および MachineAPI の機能を無効にすることができます。MachineAPI 機能を無効にできるのは、ユーザーがプロビジョニングしたインフラストラクチャーを使用してクラスターをインストールする場合のみです。詳細は、クラスター機能 を参照してください。

インストール中に、Azure AD Workload Identity を使用するように Microsoft Azure クラスターを設定できるようになりました。Azure AD Workload Identity を使用すると、クラスターコンポーネントはクラスターの外部で管理される短期のセキュリティー認証情報を使用します。

Azure 上の OpenShift Container Platform クラスターの短期認証情報の実装に関する詳細は、Azure AD Workload Identity を参照してください。

インストール時にこの認証情報管理ストラテジーを設定する方法については、短期認証情報を使用するように Azure クラスターを設定する を参照してください。

Microsoft Azure のユーザー定義タグは、以前は OpenShift Container Platform 4.13 でテクノロジープレビューとして導入され、現在は、OpenShift Container Platform 4.14 で一般提供が開始されました。詳細は、Azure のユーザー定義タグの設定 を参照してください。

Azure にクラスターをインストールするときに、Confidential VM を有効にできます。機密コンピューティングを使用して、インストール中に仮想マシンのゲスト状態ストレージを暗号化できます。この機能は、このページの既知の問題セクションに記載されている既知の問題により、テクノロジープレビューとなっています。詳細は、Confidential VM の有効化 を参照してください。

クラスターをテクノロジープレビューとして Azure にインストールする際に、トラステッド起動機能を有効化できます。これらの機能には、セキュアブートと仮想化された Trusted Platform Module が含まれます。詳細は、Azure 仮想マシンのトラステッド起動の有効化 を参照してください。

Google Cloud Platform (GCP) でユーザー定義のラベルとタグを設定して、リソースをグループ化し、リソースのアクセスとコストを管理できるようになりました。ユーザー定義のラベルは、OpenShift Container Platform インストールプログラムとそのコアコンポーネントによって作成されたリソースにのみ適用できます。ユーザー定義のタグは、OpenShift Container Platform Image Registry Operator で作成されたリソースにのみ適用できます。詳細は、GCP のユーザー定義のラベルとタグの管理 を参照してください。

OpenShift Container Platform 4.14 では、インストーラーがプロビジョニングしたインフラストラクチャー (IPI) およびユーザーがプロビジョニングしたインフラストラクチャー (UPI) 用に、制限されたネットワーク内の Microsoft Azure にクラスターをインストールできます。IPI の場合、既存の Azure Virtual Network (VNet) 上にインストールリリースコンテンツの内部ミラーを作成できます。UPI の場合、独自に提供するインフラストラクチャーを使用して Microsoft Azure にクラスターをインストールできます。詳細は、制限されたネットワークでの Azure へのクラスターのインストール および user-provisioned infrastructure を使用した制限されたネットワークでの Azure へのクラスターのインストール を参照してください。

インストーラーがプロビジョニングしたインフラストラクチャーを使用して、ベアメタルにクラスターをインストールする場合、バイパスデバイスエイリアス (deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:0:0:0" など) を使用してインストールディスクを指定できるようになりました。このパラメーターは、エージェントベースのインストール中に指定することもできます。このタイプのディスクエイリアスは、再起動後も保持されます。詳細は、ベアメタル用の install-config.yaml ファイルの設定 または Agent-based インストールのルートデバイスヒントについて を参照してください。

デフォルトでは、インストールプログラムは、セキュリティーグループを作成し、コントロールプレーンとコンピュートマシンに接続します。デフォルトのセキュリティーグループに関連付けられたルールは変更できません。

OpenShift Container Platform 4.14 では、クラスターを既存の Amazon Virtual Private Cloud (VPC) にデプロイする場合、追加の既存の AWS セキュリティーグループをコントロールプレーンとコンピュートマシンに適用できます。これらのセキュリティーグループは、クラスターのデプロイ先となる VPC に関連付ける必要があります。カスタムセキュリティーグループを適用すると、これらのマシンの受信トラフィックまたは送信トラフィックを制御する必要がある場合に、組織のセキュリティーニーズを満たすことができます。詳細は、既存の AWS セキュリティーグループのクラスターへの適用 を参照してください。

OpenShift Container Platform 4.14 は、非推奨の API を削除した Kubernetes 1.27 を使用します。

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

すべての OpenShift Container Platform 4.13 クラスターは、OpenShift Container Platform 4.14 に更新する前に、この管理者の承認を必要とします。

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

3 ノードクラスターのデプロイは、OpenShift Container Platform 4.14 以降の Nutanix でサポートされています。このタイプの OpenShift Container Platform クラスターは、よりリソース効率の高いクラスターです。これは、コンピュートマシンとしても機能する 3 台のコントロールプレーンマシンのみで構成されます。詳細は、Nutanix への 3 ノードクラスターのインストール を参照してください。

OpenShift Container Platform 4.14 では、Confidential 仮想マシンを使用したクラスターのインストールが一般提供になりました。現在、Confidential 仮想マシンは 64 ビット ARM アーキテクチャーではサポートされていません。詳細は、Confidential VM の有効化 を参照してください。

rootVolume.types パラメーターを使用して、RHOSP で 1 つ以上のルートボリュームタイプを指定できるようになりました。このパラメーターは、コントロールプレーンとコンピュートマシンの両方で使用できます。

Dynamic Host Configuration Protocol (DHCP) が存在しない環境では、静的 IP アドレスを使用してブートストラップ、コントロールプレーン、およびコンピュートノードをプロビジョニングできます。

静的 IP アドレスを持つノードを実行するようにクラスターをデプロイした後、これらの静的 IP アドレスのいずれかを使用するようにマシンをスケーリングできます。さらに、マシンセットを使用して、設定済みの静的 IP アドレスの 1 つを使用するようにマシンを設定できます。

詳細は、vSphere へのクラスターのインストール ドキュメントの「vSphere ノードの静的 IP アドレス」セクションを参照してください。

ベアメタルホストのカスタムリソース (CR) に ValidatingWebhooks パラメーターが含まれるようになりました。このパラメーターを使用すると、ベアメタル Operator は CR を受け入れる前に設定エラーを把握し、設定エラーを含むメッセージをユーザーに返すようになりました。

OpenShift Container Platform 4.14 の場合、Amazon Web Services (AWS) にクラスターをすばやくインストールして、コンピュートノードを Local Zone の場所に拡張できます。インストール設定ファイルにゾーン名を追加すると、インストールプログラムによって、各 Local Zone で必要なリソース、ネットワーク、およびコンピュートの作成が完全に自動化されます。詳細は、AWS Local Zones へのクラスターの迅速なインストール を参照してください。

このリリースには、クラウドプロバイダー認証に手動モードで Cloud Credential Operator (CCO) を使用するクラスターのインストールおよび更新のエクスペリエンスを向上させる変更が含まれています。oc adm release extract コマンドの次のパラメーターにより、クラウド認証情報の手動設定が簡素化されます。

これらのパラメーターの使用方法を理解するには、設定のインストール手順と、手動で維持された認証情報によるクラスターの更新の準備 の手順を参照してください。

OpenShift Container Platform 4.14 には、インストーラーがプロビジョニングしたインフラストラクチャーで使用するための新しい VMware vSphere 設定パラメーター template が含まれています。このパラメーターを使用すると、インストール設定ファイル内の既存の Red Hat Enterprise Linux CoreOS (RHCOS) イメージテンプレートまたは仮想マシンへの絶対パスを指定できるようになります。その後、インストールプログラムはイメージテンプレートまたは仮想マシンを使用して、vSphere ホストに RHCOS を迅速にインストールできます。

このインストール方法は、vSphere ホストに RHCOS イメージをアップロードする代替方法です。

OpenShift Container Platform 4.14 は、64 ビット ARM アーキテクチャーベースの Google Cloud Platform インストーラープロビジョニングおよびユーザーがプロビジョニングしたインフラストラクチャーでサポートされるようになりました。64 ビット ARM クラスター上で、oc mirror CLI プラグインの切断された環境も使用できるようになりました。インスタンスの可用性やインストールに関する詳細は、各種プラットフォームのサポートされるインストール方法 を参照してください。

デフォルトで、インストールプログラムは、コントロールプレーンおよびコンピュートマシンの起動に使用される Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードしてインストールします。この機能拡張により、インストール設定ファイル (install-config.yaml) を変更してカスタム RHCOS イメージを指定することで、デフォルトの動作をオーバーライドできるようになりました。クラスターをデプロイする前に、次のインストールパラメーターを変更できます。

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

OpenShift Container Platform 4.14 では、クラウドプロバイダーへのシングルノード OpenShift のインストールに対するサポートが拡張されています。シングルノード OpenShift のインストールオプションには、Amazon Web Services (AWS)、Google Cloud Platform (GCP)、および Microsoft Azure が含まれます。サポートされているプラットフォームの詳細は、シングルノード openshift でサポートされているクラウドプロバイダー を参照してください。

マルチアーキテクチャーのコンピュートマシンを備えた OpenShift Container Platform 4.14 クラスターが、Google Cloud Platform (GCP) で Day 2 操作としてサポートされるようになりました。ベアメタルインストール上のマルチアーキテクチャーコンピュートマシンを備えた OpenShift Container Platform クラスターが一般提供されるようになりました。マルチアーキテクチャーコンピュートマシンを備えたクラスターとサポートされているプラットフォームの詳細は、 マルチアーキテクチャーコンピュートマシンを備えたクラスターについて を参照してください。

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

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

OpenShift Container Platform 4.14 では、oc-mirror はカタログの multi-arch OCI ローカルイメージをサポートします。

OCI レイアウトは、ディスク上に保持されているイメージを識別する index.json ファイルで構成されます。この index.json ファイルは、任意の数の単一または multi-arch イメージを参照できます。ただし、oc-mirror は、特定の OCI レイアウトで一度に単一つのイメージのみを参照します。OCI レイアウトに格納されるイメージは、single-arch イメージ (イメージマニフェスト) または multi-arch イメージ (マニフェストリスト) のいずれかになります。

ImageSetConfiguration に OCI イメージが保存されます。カタログの処理後、カタログコンテンツには、レイアウト内のすべてのイメージのコンテンツを表す新しいレイヤーが追加されます。ImageBuilder は、single-arch イメージと multi-arch イメージの両方のイメージ更新を処理できるように変更されています。

OpenShift Container Platform 4.14 では、新しい oc コマンドラインインターフェイス (CLI) フラグである --web が、oc login コマンドで使用できるようになりました。

この機能拡張により、Web ブラウザーを使用してログインできるようになり、コマンドラインにアクセストークンを挿入する必要がなくなりました。

詳細は、Web ブラウザーを使用した OpenShift CLI へのログイン を参照してください。

新しい oc CLI フラグ、--import-mode が oc new-build コマンドに追加されました。この機能拡張により、--import-mode フラグを Legacy または PreserverOriginal に設定できるようになり、単一のサブマニフェストまたはすべてのマニフェストを使用して、ビルドをトリガーできるようになります。

新しい oc CLI フラグ、--import-mode が、oc new-app コマンドに追加されました。この機能拡張により、--import-mode フラグを Legacy または PreserverOriginal に設定し、続いて単一のサブマニフェストまたはすべてのマニフェストを使用して、新しいアプリケーションを作成できるようになります。

詳細は、インポートモードの設定 を参照してください。

OpenShift Container Platform 4.14 以降、延長更新サポート (EUS) は IBM Z® プラットフォームに拡張されています。詳細は、OpenShift EUS の概要 を参照してください。

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

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

OpenShift Container Platform は、IBM Z® および IBM® LinuxONE (s390x アーキテクチャー) 上における IBM Secure Execution 用の Red Hat Enterprise Linux CoreOS (RHCOS) ノードの設定をサポートするようになりました。

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

OpenShift Container Platform 4.14 以降、延長更新サポート (EUS) は IBM Power® プラットフォームに拡張されています。詳細は、OpenShift EUS の概要 を参照してください。

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

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

このリリースでは、特定の Security Context Constraints (SCC) を使用するようワークロードに要求できるようになりました。特定の SCC を設定すると、必要な SCC が、クラスター内の別の SCC によってプリエンプトされるのを防ぐことができます。詳細は、特定の SCC を必要とするためのワークロードの設定 を参照してください。

このリリースでは、次のシステム namespace が常に privileged Pod セキュリティーアドミッションプロファイルに設定されます。

詳細は、特権付き namespace を参照してください。

このリリースでは、ユーザーがラベル同期された namespace で自動的にラベル付けされた値から Pod セキュリティーアドミッションラベルを手動で変更すると、そのラベルの同期は無効になります。ユーザーは、必要に応じて、同期を再度有効にすることができます。詳細は、Pod のセキュリティーアドミッション同期 namespace の除外 を参照してください。

このリリースでは、Amazon Web Services (AWS) クラスター上の Operator Lifecycle Manager (OLM) によって管理される一部の Operator は、Security Token Service (STS) を使用して手動モードで Cloud Credential Operator (CCO) を使用できるようになります。これらの Operator は、クラスターの外部で管理される限定された権限の短期認証情報を使用して認証します。詳細は、クラウドプロバイダー上の Operator のトークン認証 を参照してください。

このリリースでは、noProxy フィールドが設定されており、クラスター全体のプロキシーなしでルートに到達できる場合、Authentication Operator はプロキシーをバイパスし、設定された Ingress ルートを通じて直接接続チェックを実行します。以前は、Authentication Operator は、noProxy 設定に関係なく、常にクラスター全体のプロキシーを介して接続チェックを実行していました。詳細は、クラスター全体のプロキシーの設定 を参照してください。

vSphere にクラスターをインストールする際に、IPv6 をデュアルスタッククラスター上のプライマリー IP アドレスファミリーとして設定できます。新しいクラスターのインストール時にこの機能を有効にするには、マシンネットワーク、クラスターネットワーク、サービスネットワーク、API VIP、イングレス VIP の IPv4 アドレスファミリーの前に IPv6 アドレスファミリーを指定します。

OVN-Kubernetes ネットワークプラグインは、特定のワークロードに対する追加のデフォルトゲートウェイの定義をサポートします。IPv4 と IPv6 の両方のアドレスファミリーがサポートされています。各デフォルトゲートウェイは、AdminPolicyBasedExternalRoute オブジェクトを使用して定義します。このオブジェクトでは、静的と動的の 2 種類のネクストホップを指定できます。

定義するネクストホップは、指定する namespace セレクターによってスコープが設定されます。その後、namespace セレクターに一致する特定のワークロードに外部ゲートウェイを使用できるようになります。

詳細は、セカンダリーネットワークインターフェイスを介した外部ゲートウェイの設定 を参照してください。

Ingress Node Firewall Operator は、OpenShift Container Platform 4.12 のテクノロジープレビュー機能に指定されました。このリリースでは、Ingress Node Firewall Operator が一般提供されました。ノードレベルでファイアウォールルールを設定できるようになりました。詳細は、Ingress Node Firewall Operator を参照してください。

このリリースでは、Open vSwitch (OVS) ネットワークスタックが、予約されていない CPU を動的に使用できるようになりました。予約されていない CPU のこの動的な使用は、パフォーマンスプロファイルが適用されているマシン config プール内のノードでデフォルトで発生します。利用可能な予約されていない CPU を動的に使用することで、OVS のコンピュートリソースが最大化され、需要が高い期間のワークロードのネットワーク遅延が最小限に抑えられます。OVS は、Guaranteed QoS Pod 内のコンテナーに割り当てられた分離された CPU を動的に使用できないままとなります。この分離により、重要なアプリケーションのワークロードの中断が回避されます。

Whereabouts IPAM CNI プラグインの以前のリリースでは、ネットワークインターフェイスごとに 1 つの IP アドレスのみを割り当てることができました。

現在、Whereabouts は、デュアルスタック IPv4/IPv6 機能をサポートするために、任意の数の IP アドレスの割り当てをサポートしています。デュアルスタック IP アドレスを動的に割り当てるための設定の作成 を参照してください。

このリリースでは、SR-IOV ネットワークの Non-Uniform Memory Access (NUMA) ノードの Topology Manager に対するアドバタイズを除外できるようになりました。SR-IOV ネットワークの NUMA ノードをアドバタイズしないため、NUMA 対応の Pod スケジューリング中に、より柔軟に SR-IOV ネットワークをデプロイできます。

たとえば、シナリオによっては、単一 NUMA ノード上の Pod の CPU およびメモリーリソースを最大化することが優先されます。Topology Manager に Pod の SR-IOV ネットワークリソースの NUMA ノードに関するヒントを提供しないことで、Topology Manager は SR-IOV ネットワークリソースと Pod の CPU およびメモリーリソースを異なる NUMA ノードにデプロイできます。以前の OpenShift Container Platform リリースでは、Topology Manager はすべてのリソースを同じ NUMA ノードに配置しようとしていました。

NUMA 対応の Pod スケジューリングにおける、より柔軟な SR-IOV ネットワークデプロイメントについて、詳しくは NUMA 対応スケジューリング用 SR-IOV ネットワークトポロジーの除外 を参照してください。

このリリースでは、OpenShift Container Platform が HAProxy 2.6 に更新されました。

以前は、Ingress コントローラーの syslog メッセージの最大長は 1024 バイトでした。現在は、最大値を増やすことができるようになりました。詳細は、サイドカーの使用時に Ingress コントローラーによる HAProxy ログの長さの変更を許可する を参照してください。

このリリースでは、NMstate Operator と、NodeNetworkState (NNS)、NodeNetworkConfigurationPolicy (NNCP)、および NodeNetworkConfigurationEnhancement (NNCE) などのリソースに、Web コンソールからアクセスできるようになりました。Networking ページのコンソールの Administrator パースペクティブでは、NodeNetworkConfigurationPolicy ページの NNCP と NNCE に、そして NodeNetworkState ページの NNS にアクセスできます。NMState リソースの詳細と、コンソールでこれを更新する方法の詳細は、ノードネットワーク設定の更新 を参照してください。

IPsec は、OpenShift Container Platform 4.14 のデフォルトである OVN-Kubernetes ネットワークプラグインを使用するクラスターの IBM Cloud プラットフォームでサポートされるようになりました。詳細は、IPsec 暗号化の設定 を参照してください。

OpenShift Container Platform は、north-south トラフィック とも呼ばれる外部トラフィックの暗号化をサポートするようになりました。IPsec は、east-west トラフィック と呼ばれる Pod 間のネットワークトラフィックの暗号化を、すでにサポートしています。両方の機能を組み合わせて使用すると、OpenShift Container Platform クラスターに完全な転送中の暗号化を提供できます。これはテクノロジープレビュー機能として利用できます。

この機能を使用するには、使用するネットワークインフラストラクチャーに合わせて調整された IPsec 設定を定義する必要があります。詳細は、外部 IPsec エンドポイントの IPsec 暗号化の有効化 を参照してください。

このリリースでは、シングルスタック IPv6 クラスターで Kubernetes NMState Operator を使用できるようになりました。

この更新により、EgressService カスタムリソース (CR) を使用して、ロードバランサーサービスの背後にある Pod の Egress トラフィックを管理できるようになりました。これはテクノロジープレビュー機能として利用できます。

EgressService CR を使用して、次の方法で Egress トラフィックを管理できます。

詳細は、egress サービスの設定 を参照してください。

この更新により、BGPPeer カスタムリソースで、仮想ルーティングおよび転送 (VRF) インスタンスを指定できるようになりました。MetalLB は、VRF に属するインターフェイスを通じてサービスをアドバタイズできます。これはテクノロジープレビュー機能として利用できます。詳細は、ネットワーク VRF を介したサービスの公開 を参照してください。

この更新により、NodeNetworkConfigurationPolicy カスタムリソースを使用して、仮想ルーティングおよび転送 (VRF) インスタンスをネットワークインターフェイスに関連付けることができます。VRF インスタンスをネットワークインターフェイスに関連付けることにより、トラフィックの分離、独立したルーティングの決定、およびネットワークリソースの論理的な分離をサポートできます。この機能は、テクノロジープレビューとしてのみ利用できます。詳細は、例: VRF インスタンスノードのネットワーク設定ポリシーを使用したネットワークインターフェイス を参照してください。

Broadcom BCM57504 ネットワークインターフェイスコントローラーのサポートが、SR-IOV Network Operator で利用できるようになりました。詳細は、サポートされるデバイス を参照してください。

このリリースでは、Red Hat OpenShift Networking OVN-Kubernetes ネットワークプラグインで、Pod のセカンダリーネットワークインターフェイスを設定できます。OVN-Kubernetes は、セカンダリーネットワークとして、レイヤー 2 スイッチおよび localnet スイッチトポロジーネットワークの両方をサポートします。セカンダリーネットワークとしての OVN-Kubernetes について、詳しくは OVN-Kubernetes 追加ネットワークの設定 を参照してください。

このリリース以降、OVN-Kubernetes ベースのクラスターデプロイメントでグローバル IP アドレス転送が無効になります。これは、ルーターとして機能するノードによる、クラスター管理者にとって望ましくない影響を防ぐためです。OVN-Kubernetes では、マネージドインターフェイスごとに転送を有効化および制限できるようになりました。

Network リソースの gatewayConfig.ipForwarding 仕様を使用して、OVN-Kubernetes マネージドインターフェイス上のすべてのトラフィックの IP 転送を制御できます。OVN-Kubernetes に関連するすべてのトラフィックのみを転送するには、Restricted を指定します。すべての IP トラフィックの転送を許可するには、Global を指定します。新規インストールの場合、デフォルトは Restricted です。4.14 にアップグレードされたクラスターはこの変更の影響を受けません。IP 転送の動作は変更されず、引き続きグローバルに有効になります。IP 転送をグローバルに有効にする方法の詳細は、 IP 転送をグローバルに有効にする を参照してください。

管理ネットワークポリシーは、テクノロジープレビュー機能として利用できます。OVN-Kubernetes CNI プラグインを実行しているクラスターで、Network Policy V2 API に含まれる AdminNetworkPolicy リソースと BaselineAdminNetworkPolicy リソースを有効化できます。クラスター管理者は、namespace が作成される前に、クラスター範囲のポリシーと保護措置をクラスター全体に適用できます。ネットワーク管理者は、ユーザーが上書きできないネットワークトラフィック制御を強制することで、クラスターを保護できます。ネットワーク管理者は、必要に応じて、クラスター内のユーザーが上書きできる任意のベースラインネットワークトラフィック制御を強制できます。現在、これらの API はクラスター内トラフィックのポリシーの表現のみをサポートしています。

このリリースでは、コンテナー namespace 内のマスターインターフェイスに基づいて MAC-VLAN、IP-VLAN、および VLAN サブインターフェイスを作成する機能が一般提供になりました。この機能を使用すると、別のネットワークアタッチメント定義で、Pod ネットワーク設定の一部としてマスターインターフェイスを作成できます。これにより、ノードのネットワーク設定を知らなくても、このインターフェイスに基づいて VLAN、MACVLAN、または IPVLAN を作成できます。詳細は、コンテナーネットワーク namespace でのマスターインターフェイスの設定について を参照してください。

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

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

このリリースでは、新しい Container Network Interface (CNI) ネットワークプラグインタイプである Tanzu Application Platform (TAP) デバイスプラグインが導入されています。このプラグインを使用すると、コンテナー内に TAP デバイスを作成できます。これにより、ユーザー空間プログラムがネットワークフレームを処理し、従来のネットワークインターフェイスを介する代わりに、ユーザー空間アプリケーションとの間でフレームを送受信するインターフェイスとして機能できるようになります。詳細は、TAP 追加ネットワークの設定 を参照してください。

OpenShift Container Platform バージョン 4.14 以降では、カーネルにトラフィックを注入する必要がある DPDK アプリケーションは、TAP CNI プラグインを利用して非特権 Pod で実行できます。詳細は、TAP CNI を使用してカーネルアクセスでルートレス DPDK ワークロードを実行する を参照してください。

特定の HTTP リクエストおよびレスポンスヘッダーは、Ingress コントローラーを使用してグローバルに、または特定のルートに対して、設定または削除できるようになりました。次のヘッダーを設定または削除できます。

詳細は、Ingress コントローラーでの HTTP 要求ヘッダーと応答ヘッダーの設定または削除 および ルートでの HTTP 要求ヘッダーと応答ヘッダーの設定または削除 を参照してください。

追加のネットワークインターフェイスで EgressIP アドレスを使用することが一般的に可能になりました。この機能により、OpenShift Container Platform 管理者は、ルーティング、アドレス指定、セグメンテーション、セキュリティーポリシーなどのネットワーク側面をより高度に制御できるようになります。トラフィックのセグメント化や特殊な要件を満たすなどの目的で、ワークロードトラフィックを特定のネットワークインターフェイス経由でルーティングすることもできます。

詳細は、追加のネットワークインターフェイスで Egress IP を使用する場合の考慮事項 を参照してください。

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

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

OpenShift Container Platform 4.13 リリースでは、168.254.0.0/16 IP アドレス範囲は、Open Virtual Network Infrastructure Controller がトランジットスイッチサブネットに使用する予約済み IP アドレス範囲でした。OpenShift Container Platform 4.14 の場合、Open Virtual Network Infrastructure Controller は予約済み IP アドレス範囲として 100.88.0.0/16 を使用します。100.88.0.0/16 の範囲は、接続されているネットワークと競合できません。OCPBUGS-20178 および CIDR 範囲の定義 を参照してください。

このリリースでは、Image Registry Operator がオプションのコンポーネントになりました。この機能は、Image Registry Operator が必要ない場合に、通信環境における OpenShift Container Platform の全体的なリソースフットプリントを削減する際に役立ちます。Image Registry Operator の無効化の詳細は、クラスター機能の選択 を参照してください。

このリリースでは、論理ボリュームマネージャー (LVM) クラスターのカスタムリソース (CR) が、deviceSelector 設定で OR ロジックを提供します。以前のリリースでは、デバイスパスの paths 設定の指定には、AND ロジックのみが使用されていました。このリリースでは、OR ロジックをサポートする optionalPaths 設定を指定することもできます。詳細は、論理ボリュームマネージャーストレージを使用した永続ストレージ の CR の例を参照してください。

このリリースでは、論理ボリュームマネージャー (LVM) クラスターのカスタムリソース (CR) が、deviceClasses の下の fstype 設定を持つ ext4 ファイルシステムのサポートを提供します。デフォルトのファイルシステムは xfs です。詳細は、論理ボリュームマネージャーストレージを使用した永続ストレージ の CR の例を参照してください。

OpenShift Container Platform 4.14 は、AWS Elastic File Storage (EFS) Container Storage Interface (CSI) Driver Operator を使用して、Security Token Service (STS) を設定するための合理化および標準化された手順を提供します。

詳細は、Security Token Service のロール Amazon リソースネームの取得 を参照してください。

OpenShift Container Platform 4.14 では、ReadWriteOncePod (RWOP) と呼ばれる永続ボリューム (PV) および永続ボリューム要求 (PVC) の新しいアクセスモードが導入されています。これは、単一ノード上の単一 Pod でのみ使用できます。これは、シングルノード上で多数の Pod によって PV または PVC を使用できる既存の ReadWriteOnce アクセスモードと比較されます。これはテクノロジープレビュー機能として利用できます。

詳細は、アクセスモード を参照してください。

OpenShift Container Platform は、Google Compute Platform (GCP) Filestore Storage の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。GCP Filestore CSI Driver Operator は、OpenShift Container Platform 4.12 に導入され、テクノロジープレビュー機能としてサポートされていました。GCP Filestore CSI Driver Operator は現在、一般提供されています。詳細は、Google Compute Platform Filestore CSI Driver Operator を参照してください。

VMware vSphere の自動 CSI 移行機能は、in-tree オブジェクトを対応する CSI 表現に自動的に変換します。理想的には、ユーザーに対して完全に透過的である必要があります。in-tree ストレージプラグインを参照するストレージクラスは引き続き機能しますが、デフォルトのストレージクラスを CSI ストレージクラスに切り替えることを検討してください。

OpenShift Container Platform 4.14 では、vSphere の CSI 移行はあらゆる状況においてデフォルトで有効になっており、管理者によるアクションは必要ありません。

ただし、vSphere in-tree 永続ボリューム (PV) を使用していて、OpenShift Container Platform 4.12 または 4.13 から 4.14 にアップグレードする場合は、vSphere vCenter および ESXI ホストを 7.0 Update 3L または 8.0 Update 2 に更新します。更新しない場合、OpenShift Container Platform のアップグレードがブロックされます。vSphere を更新したくない場合は、管理者承認を実行して、OpenShift Container Platform のアップグレードを続行できます。ただし、管理者承認を使用すると、既知の問題が発生する可能性があります。管理者承認に進む前に、こちらの ナレッジベースの記事 をよくお読みください。

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

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 の詳細は、Secrets Store CSI Driver を参照してください。

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

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

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

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

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

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

このリリースでは、Operator Lifecycle Manager (OLM) によって管理される Operator は、Security Token Service (STS) を使用する Amazon Web Services (AWS) クラスター上で実行する際のトークン認証をサポートできるようになりました。Cloud Credential Operator (CCO) は、Operator の作成者が Operator による AWS STS のサポートを有効にしている場合、特定の権限が限定された短期認証情報のプロビジョニングを半自動化するように更新されています。OLM ベースの Operator を有効化して、AWS STS で CCO ベースのワークフローをサポートする方法の詳細は、クラウドプロバイダー上の Operator のトークン認証 を参照してください。

このリリースでは、Operator の作成者は、複数のアーキテクチャーとオペレーティングシステム、または プラットフォーム をサポートするように Operator プロジェクトを設定できます。Operator の作成者は、次のアクションを実行して、複数のプラットフォームのサポートを設定できます。

詳細は、マルチプラットフォームサポートのための Operator プロジェクトの設定 を参照してください。

Machine Config Operator は、イメージレジストリーの認証局の配布を処理するようになりました。この変更によるエンドユーザーへの影響はありません。

このリリースでは、追加のメトリクスをクエリーして、マシンとマシン config プールの状態をより詳しく監視できるようになりました。

Prometheus の使用方法に関する詳細は、利用可能なメトリクスのリストの表示 を参照してください。

このリリースでは、初回起動時にアクセスできない Tang サーバーを使用し、Tang が有効化された Network-Bound Disk Encryption (NBDE) を使用して、OpenShift Container Platform クラスターをプロビジョニングできるようになりました。

詳細は、暗号化しきい値の設定 および ディスク暗号化とミラーリングの設定 を参照してください。

以前の OpenShift Container Platform バージョンでは、MCO はマシン設定ファイルから証明書を直接読み取り、処理していました。これにより、ローテーションの問題が発生し、証明書が一時停止したマシン config プールの背後でスタックされるなど、望ましくない状況が発生しました。

このリリースでは、証明書はブートストラップからマシン設定ファイルにテンプレート化されなくなりました。代わりに、これらは Ignition オブジェクトに直接置かれ、コントローラー config を使用してディスクに書き込まれ、通常のクラスター操作中に Machine Config Daemon (MCD) によって処理されます。その後、ControllerConfig リソースを使用して、証明書を表示できるようになります。

Machine Config Controller (MCC) は、次の証明書データを保持します。

MCC は、イメージレジストリー証明書とそれに関連するユーザーバンドル証明書も処理します。これは、証明書がマシン config プールのステータスにバインドされず、よりタイムリーにローテーションされることを意味します。マシン設定ファイルに保存されている以前にリストされた CA は削除され、クラスターのインストール中に見つかったテンプレート化されたファイルは存在しなくなります。これらの証明書にアクセスする方法の詳細は、証明書の表示と操作 を参照してください。

このリリースでは、Nutanix クラスターでコントロールプレーンマシンセットがサポートされています。詳細は、Control Plane Machine Set Operator のスタートガイド を参照してください。

このリリースでは、RHOSP 上で実行されるクラスターでコントロールプレーンマシンセットがサポートされます。

詳細は、Control Plane Machine Set Operator のスタートガイド を参照してください。

このリリースにより、既存の AWS 配置グループ内にマシンをデプロイするようにマシンセットを設定できるようになりました。この機能を Elastic Fabric Adaptor (EFA) インスタンスで使用すると、指定した配置グループ内のマシンのネットワークパフォーマンスを向上させることができます。この機能は、コンピュート と コントロールプレーン のマシンセットで使用できます。

このリリースでは、Azure Confidential VM、トラステッド起動、またはその両方を使用するマシンをデプロイするように、マシンセットを設定できるようになりました。これらのマシンは、セキュアブートや専用の virtual Trusted Platform Module (vTPM) インスタンスなどの Unified Extensible Firmware Interface (UEFI) セキュリティー機能を使用できます。

この機能は、コンピュート と コントロールプレーン のマシンセットで使用できます。

このリリースでは、descheduler オペランドのリソース制限が削除されました。これにより、メモリー不足エラーによって失敗することなく、多くのノードと Pod を含む大規模なクラスターに対して、descheduler を使用できるようになります。

Pod トポロジー分散制約を設定するための matchLabelKeys パラメーターが、OpenShift Container Platform 4.14 で一般提供されるようになりました。以前は、TechPreviewNoUpgrade 機能セットを有効にすることで、パラメーターをテクノロジープレビュー機能として利用できました。matchLabelKeys パラメーターは、Pod ラベルキーのリストを取得して、分散を計算する Pod を選択します。

詳細は、Pod トポロジー分散制約を使用した Pod 配置の制御 を参照してください。

このリリースでは、TechPreviewNoUpgrade 機能セットを有効にすることで、MaxUnavailableStatefulSet 機能セット設定パラメーターがテクノロジープレビュー機能として利用できるようになります。更新中に使用できなくなる StatefulSet Pod の最大数を定義できるようになりました。これにより、アップグレード時のアプリケーションのダウンタイムが短縮されます。

詳細は、フィーチャーゲートについて を参照してください。

このリリースでは、Pod Disruption Budget (PDB) に対する異常な Pod エビクションポリシーの指定が、OpenShift Container Platform で一般提供され、TechPreviewNoUpgrade featureSet から削除されました。これは、ノードドレイン中に誤動作しているアプリケーションを排除するのに役立ちます。

詳細は、異常な Pod のエビクションポリシーの指定 を参照してください。

OpenShift Container Platform 4.14 以降、新規インストールではデフォルトで Control Groups バージョン 2 (cgroup v2、cgroup2、または cgroupsv2 とも呼ばれる) が使用されます。この機能拡張には、多くのバグ修正、パフォーマンスの向上、新機能との統合機能が含まれています。cgroup v1 は、初期インストール日が OpenShift Container Platform 4.14 より前の、アップグレードされたクラスターで引き続き使用されています。cgroup v1 は、node.config オブジェクトの cgroupMode フィールドを v1 に変更することで、引き続き使用できます。

詳細は、ノードでの Linux cgroup バージョンの設定 を参照してください。

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

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

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

管理者はこのリリースにより、コアプラットフォームのメトリクスに基づいて、新しいアラートルールを作成できます。しきい値を調整したりラベルを変更したりして、既存のプラットフォームアラートルールの設定を変更できるようになりました。openshift-monitoring namaespace のコアプラットフォームメトリクスに基づいてクエリー式を作成することにより、新しいカスタムアラートルールを定義して追加できます。この機能は、OpenShift Container Platform 4.12 リリースではテクノロジープレビューとして含まれていましたが、現在は、OpenShift Container Platform 4.14 で一般提供されています。詳細は、コアプラットフォームモニタリングのアラートルールの管理 を参照してください。

このリリースでは、以下を含むすべての監視コンポーネントのリソース要求と制限を指定できるようになりました。

OpenShift Container Platform の以前のバージョンでは、Prometheus、Alertmanager、Thanos Querier、および Thanos Ruler のオプションのみを設定できました。

このリリースでは、追加の node-exporter コレクターの Cluster Monitoring Operator (CMO) config map 設定をカスタマイズできます。次の node-exporter コレクターはオプションになり、config map 設定で、それぞれを個別に有効または無効にできます。

さらに、netdev および netclass コレクターの関連コレクター設定から、ネットワークデバイスを除外できるようになりました。また、maxProcs オプションを使用して、node-exporter を実行できるプロセスの最大数を設定できるようになりました。

このリリースでは、OpenShift Container Platform Web コンソールの Observe セクションのモニタリングページが、動的プラグイン としてデプロイされます。この変更により、Cluster Monitoring Operator (CMO) が、OpenShift Container Platform Web コンソール監視プラグインリソースをデプロイするコンポーネントになりました。CMO 設定を使用して、コンソール監視プラグインリソースの次の機能を設定できるようになりました。

このリリースでは、Performance Addon Operator (PAO) の must-gather イメージは、低遅延チューニングに関連するデバッグデータをキャプチャーするための must-gather コマンドの引数として必要とされなくなりました。PAO must-gather イメージの機能は、イメージ引数なしで must-gather コマンドによって使用されるデフォルトのプラグインイメージの下に置かれるようになりました。低遅延チューニングに関連するデバッグ情報の収集の詳細は、Red Hat Support 用の低遅延チューニングデバッグデータの収集 を参照してください。

このリリースでは、Operator の must-gather イメージを使用して NUMA Resources Operator のデータを収集するように、must-gather ツールが更新されました。NUMA Resources Operator のデバッグ情報の収集に関する詳細は、NUMA Resources Operator データの収集 を参照してください。

このリリースでは、Pod の C ステートをより詳細に制御できるようになりました。C ステートを完全に無効にする代わりに、C ステートの最大遅延をマイクロ秒単位で指定できるようになりました。このオプションは、cpu-c-states.crio.io アノテーションで設定できます。これは、より浅い C ステートを完全に無効にするのではなく、一部を有効にすることで、優先度の高いアプリケーションの節電を最適化するのに役立ちます。Pod の C 状態の制御に関する詳細は、優先度の高い Pod の省電力モードを無効にする を参照してください。

この更新により、デュアルスタックハブクラスターから IPv6 アドレススポーククラスターをプロビジョニングできるようになります。Zero Touch Provisioning (ZTP) 環境では、ブート ISO をホストするハブクラスター上の HTTP サーバーが、IPv4 ネットワークと IPv6 ネットワークの両方をリッスンするようになりました。プロビジョニングサービスは、ターゲットスポーククラスター上のベースボード管理コントローラー (BMC) アドレススキームもチェックし、インストールメディアに一致する URL を提供します。これらの更新により、デュアルスタックハブクラスターから、シングルスタックの IPv6 スポーククラスターをプロビジョニングできる機能が提供されます。

RHOSP 上で実行されるクラスターでデュアルスタックネットワーク設定が利用できるようになりました。これはテクノロジープレビューの機能です。インストーラーがプロビジョニングしたインフラストラクチャーにクラスターをデプロイメントするときに、デュアルスタックネットワークを設定できます。

詳細は、デュアルスタックネットワークを使用したクラスターの設定 を参照してください。

OpenShift Container Platform 4.14 では、RHOSP 上で実行されるクラスターのセキュリティーが強化されています。デフォルトでは、OpenStack クラウドプロバイダーは、ロードバランサーの manage-security-groups オプションを true に設定し、クラスターの操作に必要なノードポートのみが開かれるようにします。以前は、コンピュートプレーンマシンとコントロールプレーンマシンの両方のセキュリティーグループが、すべての受信トラフィックに対して、広範囲のノードポートを開くように設定されていました。

ロードバランサーの設定で manage-security-groups オプションを false に設定し、セキュリティーグループルールがノードポート範囲 30000 から 32767 までの 0.0.0.0/0 からのトラフィックを許可するようにすることで、以前の設定を使用することを選択できます。

4.14 にアップグレードされたクラスターの場合は、デプロイメントをすべてのトラフィックに開放する permissive セキュリティーグループルールを手動で削除する必要があります。たとえば、ノードポート範囲 30000 から 32767 までの 0.0.0.0/0 からのトラフィックを許可するルールを削除する必要があります。

GitOps ZTP を使用して、ztp-site-generate コンテナーの GitOps ZTP プラグインによって提供されるベースソース CR に加えて、カスタム CR を含めることができるようになりました。詳細は、GitOps ZTP パイプラインへのカスタムコンテンツの追加 を参照してください。

GitOps ZTP を使用して、OpenShift Container Platform のさまざまなバージョンを実行しているマネージドクラスターをプロビジョニングできるようになりました。これは、ハブクラスターと GitOps ZTP プラグインのバージョンが、マネージドクラスター上で実行されている OpenShift Container Platform のバージョンに依存しないことを意味します。詳細は、バージョンに依存しないように GitOps ZTP サイト設定リポジトリーを準備する を参照してください。

このリリースにより、Topology Aware Lifecycle Manager を使用してシングルノード OpenShift クラスター上のアプリケーションをアップグレードする前に、アプリケーションのワークロードイメージを事前キャッシュできるようになりました。詳細は、シングルノード OpenShift クラスターでの TALM を使用したユーザー指定イメージの事前キャッシュ を参照してください。

このリリースでは、SiteConfig CR の automaticCleaningMode フィールドを使用して、インストール前にパーティションテーブルを削除できます。詳細は、シングルノード OpenShift SiteConfig CR インストールリファレンス を参照してください。

この更新により、SiteConfig CR に nodeLabels フィールドを追加して、マネージドクラスター内のノードのカスタムロールを作成できるようになりました。カスタムラベルを追加する方法の詳細は、SiteConfig および GitOps ZTP を使用したマネージドクラスターのデプロイ、GitOps ZTP インストールおよび設定 CR の手動生成、および シングルノード OpenShift SiteConfig CR インストールリファレンス を参照してください。

このリリースでは、コントロールプレーンのハードウェア速度を "Standard"、"Slower"、またはデフォルトの "" のいずれかに設定できます。これにより、システムが使用する速度を決定できます。これはテクノロジープレビューの機能です。詳細は、etcd のチューニングパラメーターの設定 を参照してください。

この更新により、SiteConfig カスタムリソース定義 (CRD) の apiVIP フィールドと ingressVIP フィールドは非推奨となり、代わりに複数形の apiVIPs と ingressVIPs が使用されるようになりました。

OpenShift Container Platform の Hosted Control Plane が、ベアメタルおよび OpenShift Virtualization プラットフォームで一般提供されるようになりました。AWS 上の Hosted Control Plane は、引き続きテクノロジープレビュー機能として提供されます。

このリリースでは、同一の Hosted Control Plane から 64 ビット ARM および AMD64 上のアプリケーションワークロードをスケジュールできます。詳細は、AWS のホストされたクラスターで ARM NodePool オブジェクトを作成する を参照してください。

このリリースでは、IBM Z 上で Hosted Control Plane をテクノロジープレビュー機能として使用できます。詳細は、64 ビット x84 ベアメタルで IBM Z コンピュートノード用のホスティングクラスターを設定する (テクノロジープレビュー) を参照してください。

このリリースでは、IBM Power 上で Hosted Control Plane をテクノロジープレビュー機能として使用できます。詳細は、IBM Power コンピュートノードの Hosted Control Plane を作成するために 64 ビット x86 OpenShift Container Platform クラスターでホスティングクラスターを設定する (テクノロジープレビュー) を参照してください。

OpenShift Container Platform 4.14 では、Insights Operator がオンデマンドで収集操作を実行できるようになりました。オンデマンドでの収集操作の実行に関する詳細は、Insights Operator の収集操作の実行 を参照してください。

OpenShift Container Platform 4.14 テクノロジープレビュークラスターでは、Insights Operator は個々の Pod で収集操作を実行します。これは、新しいオンデマンドデータ収集機能をサポートします。