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

OpenShift Container Platform 4.10 にはスタートガイドが追加されました。OpenShift Container Platform を使い始めることで、基本的な用語を定義し、開発者および管理者向けのロールベースの次のステップを提供します。

チュートリアルは、Web コンソールおよび OpenShift CLI (oc) インターフェイスを使用して新規ユーザーについて説明します。新規ユーザーは、スタートガイドを使用して以下のタスクを実行できます。

詳細は、Getting Started with OpenShift Container Platformを参照してください。

coreos-installer ユーティリティーには、ライブ ISO イメージおよび PXE イメージから RHCOS をベアメタルにインストールする際に、より柔軟なカスタマイズを可能にする iso customize および pxe customize サブコマンドが含まれるようになりました。

これには、カスタムの認証局または自己署名証明書を使用する HTTPS サーバーから Ignition 設定をフェッチするようにインストールをカスタマイズする機能が含まれます。

RHCOS は、OpenShift Container Platform 4.10 で Red Hat Enterprise Linux (RHEL) 8.4 パッケージを使用するようになりました。これらのパッケージは、NetworkManager の機能など、最新の修正、機能、拡張、および最新のハードウェアサポートとドライバーの更新を提供します。

OpenShift Container Platform 4.10 インストーラーは、AWS へのインストールに新規のデフォルトコンポーネントタイプを使用します。インストールプログラムはデフォルトで以下のコンポーネントを使用します。

以前は、ユーザーがベアメタルインストーラーでプロビジョニングされたインフラストラクチャーに OpenShift Container Platform をインストールした場合、Ironic サーバーと通信するための静的 IP や vLAN などのカスタムネットワークインターフェイスを設定する場所がありませんでした。

ベアメタルのみで Day1 インストールを設定する場合、ユーザーは install-config.yaml ファイルの API を使用して、ネットワーク設定 (networkConfig) をカスタマイズできるようになりました。この設定は、インストールおよびプロビジョニングプロセス中に設定され、ホストごとの静的 IP の設定などの高度なオプションが含まれます。

OpenShift Container Platform 4.10 は ARM ベースの AWS EC2 およびベアメタルプラットフォームでサポートされるようになりました。インスタンスの可用性およびインストールのドキュメントは、さまざまなプラットフォームのサポートされるインストール方法 を参照してください。

以下の機能は ARM の OpenShift Container Platform でサポートされます。

以下の Operator は ARM の OpenShift Container Platform でサポートされます。

OpenShift Container Platform 4.10 では、テクノロジープレビューのインストーラーでプロビジョニングされるインフラストラクチャーを使用して IBM Cloud にクラスターをインストールするためのサポートが導入されました。

以下の制限は、IPI を使用する IBMCloud に適用されます。

詳細は、IBMCloud へのインストールの準備を参照してください。

OpenShift Container Platform 4.10 では、インストーラーでプロビジョニングされるインフラストラクチャーを使用してクラスターをインストールする場合は、シンプロビジョニングされたディスクのサポートが導入されました。ディスクは、thin、thick、または eagerZeroedThick としてプロビジョニングできます。VMware vSphere のディスクプロビジョニングモードについての詳細は、Installation configuration parameters を参照してください。

Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Images (AMI) が AWS GovCloud リージョンで利用可能になりました。これらの AMI の可用性は、クラスターをデプロイするためにカスタム RHCOS AMI をアップロードする必要がなくなるため、インストールプロセスが改善されます。

詳細は、AWS のクラスターの government リージョンへのインストール について参照してください。

OpenShift Container Platform 4.10 以降、クラスターを既存の IAM ロールで設定する場合、インストールプログラムはクラスターのデプロイ時に shared タグをロールに追加しなくなりました。今回の機能拡張により、カスタム IAM ロールを使用する組織のインストールプロセスが改善されましたが、セキュリティーポリシーにより shared タグが使用されなくなりました。

vSphere で実行しているクラスターに CSI ドライバーをインストールするには、以下のコンポーネントがインストールされている必要があります。

上記よりも前のバージョンのコンポーネントは引き続きサポートされますが、非推奨です。これらのバージョンは引き続き完全にサポートされていますが、OpenShift Container Platform のバージョン 4.11 には、vSphere 仮想ハードウェアバージョン 15 以降が必要です。

OpenShift Container Platform 4.10 では、テクノロジープレビューとしてインストーラーでプロビジョニングされるインフラストラクチャーを使用して Alibaba Cloud にクラスターをインストールする機能が導入されました。このタイプのインストールでは、インストールプログラムを使用して、インストールプログラムがプロビジョニングし、クラスターが管理するインフラストラクチャーにクラスターをデプロイできます。

OpenShift Container Platform 4.10 では、インストーラーでプロビジョニングされるインフラストラクチャーを使用した Azure Stack Hub へのクラスターのインストールのサポートが導入されました。このタイプのインストールでは、インストールプログラムを使用して、インストールプログラムがプロビジョニングし、クラスターが管理するインフラストラクチャーにクラスターをデプロイできます。

詳細は、インストーラーでプロビジョニングされるインフラストラクチャーを使用した Azure Stack Hub へのクラスターのインストール について参照してください。

OpenShift Container Platform 4.10 は、OpenShift Update Service によって提供される条件付き更新パスの使用をサポートするようになりました。条件更新パスは、識別されたリスクと、これらのリスクがクラスターに適用される条件を伝えます。Web コンソールの Administrator パースペクティブは、クラスターが既知のリスクと一致しない推奨されるアップグレードパスのみを提供します。ただし、OpenShift CLI (oc) 4.10 以降を使用して、OpenShift Container Platform 4.10 クラスターの追加のアップグレードパスを表示できます。ドキュメントの参照など、関連するリスク情報がパスに表示されます。管理者は参照資料を確認し、サポートの実行を選択できますが、推奨されなくなったアップグレードは推奨されません。

詳細は、Conditional updates および Updating along a conditional upgrade path を参照してください。

本リリースでは、oc-mirror OpenShift CLI (oc) プラグインがテクノロジープレビューとして導入されています。oc-mirror プラグインを使用して、非接続環境のイメージをミラーリングできます。

詳細は、Mirroring images for a disconnected installation using the oc-mirror plug-in を参照してください。

これで、Data Plane Development Kit (OVS-DPDK) ネットワークを使用して Open vSwitch でコンピュートマシンを実行する Red Hat OpenStack Platform (RHOSP) にクラスターをインストールできます。これらのマシンで実行されるワークロードは、OVS-DPDK のパフォーマンスとレイテンシーの改善から利点を得ることができます。

詳細は、Installing a cluster on RHOSP that supports DPDK-connected compute machines を参照してください。

RHOSP にクラスターをインストールするときに、コンピューティングマシンアフィニティーを選択できるようになりました。デフォルトでは、コンピュートマシンは soft-anti-affinity サーバーポリシーでデプロイされますが、anti-affinity または soft-affinity ポリシーを選択することも可能です。

OpenShift Container Platform 4.10 以降、OpenShift コンソールの動的プラグインを作成する機能がテクノロジープレビュー機能として利用可能になりました。この機能を使用して、以下のような複数の方法でランタイム時にインターフェイスをカスタマイズできます。

動的プラグインの詳細は、動的プラグインの OpenShift Container Platform Web コンソールへの追加を参照してください。

今回の更新により、Web コンソールでデバッグターミナルを表示できるようになりました。Pod に CrashLoopBackOff 状態にあるコンテナーがある場合、デバッグ Pod を起動できます。端末インターフェイスが表示され、クラッシュループコンテナーのデバッグに使用できます。

さらに、Pod ステータスのポップアップウィンドウに、Pod 詳細ページの Logs タブおよび Events タブへのリンクが表示されるようになりました。

今回の更新により、ユーザー設定 ページでワークロード通知をカスタマイズできるようになりました。通知 タブのユーザーワークロード通知 を使用すると、Cluster Overview ページまたはドロワーに表示されるユーザーワークロード通知を非表示にすることができます。

今回の更新により、管理者以外のユーザーが Project Overview、ResourceQuotas、および API Explorer ページの AppliedClusterResourceQuota の使用を表示し、利用可能なクラスタースコープのクォータを判別できるようになりました。さらに、AppliedClusterResourceQuota の詳細は Search ページで確認できます。

OpenShift Container Platform では、Overview Details カードの Cluster Settings で、クラスターについてのサポートレベル情報を About モーダルで表示でき、クラスターがサポートされていない場合に通知を通知ドロワーに追加できるようになりました。概要 ページから、サービスレベルアグリーメント (SLA) でサブスクリプション設定を管理できます。

複数の IP アドレスファミリーを使用するサービスを作成する場合、Service オブジェクト定義で ipFamilyPolicy: PreferDualStack または ipFamilyPolicy: RequireDualStack を明示的に指定する必要があります。この変更により、OpenShift Container Platform の以前のリリースとの後方互換性が失われます。

詳細は、BZ#2045576 を参照してください。

クラスターのインストール後に、OpenShift SDN クラスターネットワークプロバイダーまたは OVN-Kubernetes クラスターネットワークプロバイダーを使用している場合、ハードウェア MTU およびクラスターネットワーク MTU 値を変更できます。クラスター全体で MTU を変更すると、混乱が生じ、各ノードが数回再起動される必要があります。詳細は、クラスターネットワーク MTU の変更を参照してください。

OVN-Kubernetes CNI ネットワークプロバイダーは、egress トラフィックがノードゲートウェイに送信される方法の設定についてサポートを追加します。デフォルトでは、egress トラフィックは OVN で処理され、クラスターを終了するために処理され、トラフィックはカーネルルーティングテーブルの特殊なルートによる影響を受けません。

今回の機能拡張により、gatewayConfig.routingViaHost フィールドが追加されました。今回の更新により、このフィールドをインストール後のアクティビティーとしてランタイム時に設定でき、これが true に設定される場合、egress トラフィックは Pod からホストネットワークスタックに送信されます。今回の更新では、カーネルルーティングテーブルで手動で設定されたルートに依存する非常に特殊なインストールおよびアプリケーションが得られます。

今回の機能拡張により、Open vSwitch ハードウェアオフロード機能との対話が可能になりました。今回の更新により、gatewayConfig.routingViaHost フィールドが true に設定されている場合、egress トラフィックがホストネットワークスタックによって処理されるため、オフロードのパフォーマンス上の利点は受けられなくなりました。

設定についての詳細は、OVN-Kubernetes CNI クラスターネットワークプロバイダーの設定 を 参照してください。

以下のメトリックがクラスターで利用可能になりました。sdn_controller で始まるメトリック名は OpenShift SDN CNI ネットワークプロバイダーに固有のものです。ovn で始まるメトリック名は OVN-Kubernetes CNI ネットワークプロバイダーに固有のものです。

ovnkube_master_resource_update_total メトリックは 4.10 リリースに対して削除されます。

OpenShift Container Platform Web コンソールでネットワークポリシー機能を使用する場合、ポリシーの影響を受ける Pod がリスト表示されます。これらのポリシーセクションで組み合わせた namespace および Pod セレクターの変更時に、このリストが変更されます。

影響を受ける Pod のリストには、ユーザーがアクセス可能な Pod のみが含まれます。

oc adm must-gather コマンドは、ネットワークパケットのキャプチャーの収集を単純化する方法で強化されています。

以前のバージョンでは、oc adm must-gather は単一のデバッグ Pod のみを起動することができました。今回の機能拡張により、デバッグ Pod を同時に複数のノードで起動できるようになりました。

この機能拡張を使用すると、ネットワーク通信問題のトラブルシューティングを単純化するために、複数のノードでパケットキャプチャーを同時に実行できます。新しい --node-selector 引数は、パケットキャプチャーを収集するノードを特定する方法を提供します。

詳細は、Network trace methods および Collecting a host network trace を参照してください。

Pod レベルでのボンディングは、高可用性とスループットを必要とする Pod 内のワークロードを有効にするために不可欠です。Pod レベルのボンディングでは、カーネルモードインターフェイスで複数の Single Root I/O Virtualization (SR-IOV) 仮想機能インターフェイスからボンドインターフェイスを作成できます。SR-IOV Virtual Function は Pod に渡され、カーネルドライバーに割り当てられます。

Pod レベルのボンディングが必要なシナリオには、異なる Physical Function 上の複数の SR-IOV Virtual Function からのボンディングインターフェイスの作成が含まれます。ホストの 2 つの異なる Physical Function からボンディングインターフェイスを作成して、Pod レベルで高可用性を実現するために使用できます。

クラスター管理者は、1 つ以上の egress IP アドレスを namespace に関連付けることができます。egress IP アドレスにより、一貫性のあるソース IP アドレスが、クラスターから出る特定の namespace からのトラフィックに関連付けられます。

OVN-Kubernetes および OpenShift SDN クラスターネットワークプロバイダーの場合、以下のパブリッククラウドプロバイダーで egress IP アドレスを設定できます。

詳細は、クラスターネットワークプロバイダーについての該当するドキュメントを参照してください。

OpenShift SDN クラスターネットワークプロバイダーを使用する場合、ipBlock および ipBlock.except を使用して、ネットワークポリシーで egress ルールを使用できるようになりました。NetworkPolicy オブジェクトの egress 配列で egress ポリシーを定義します。

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

今回の機能拡張により、特定の MIME タイプについて HAProxy Ingress コントローラーでグローバル HTTP トラフィック圧縮を設定する機能が追加されました。今回の更新により、大量の圧縮ルーティングされたトラフィックが大量にある場合に、ingress ワークロードの gzip 圧縮が可能になりました。

詳細は、Using router compression を参照してください。

クラスター管理者は、デフォルトドメインの設定済みのサーバーを使用した DNS 名前解決を許可するように DNS サーバーを設定できるようになりました。DNS 転送設定には、/etc/resolv.conf ファイルおよびアップストリーム DNS サーバーで指定されたデフォルトのサーバーの両方を設定できます。

詳細は、DNS 転送の使用 を参照してください。

この機能拡張により、Operator のログレベルを個別にまたはクラスター全体で手動で変更する機能が追加されます。

詳細は、Setting the CoreDNS log level を参照してください。

Ingress コントローラーの syslog メッセージの最大長を 480 から 4096 バイト間の任意の値に設定できるようになりました。

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

DNS Operator を使用して CoreDNS 転送ポリシーを設定できるようになりました。デフォルト値は Random で、値を RoundRobin または Sequential に設定できます。

詳細は、DNS 転送の使用 を参照してください。

Open vSwitch ハードウェアオフロードを設定して、互換性のあるベアメタルノードでデータ処理のパフォーマンスを向上できるようになりました。ハードウェアオフロードは、CPU からデータ処理タスクを削除し、ネットワークインターフェイスコントローラーの専用のデータ処理ユニットに転送するデータを処理する方法です。この機能の利点として、データ処理の高速化、CPU ワークロードの軽減、コンピューティングコストの削減などがあります。

詳細は、ハードウェアオフロードの設定を参照してください。

AWS、Azure、および GCP などのクラウドプロバイダーの Red Hat 外部 DNS Operator を使用して DNS レコードを作成できるようになりました。OperatorHub を使用して外部 DNS Operator をインストールできます。パラメーターを使用して、必要に応じて ExternalDNS を設定できます。

詳細は、Understanding the External DNS Operator を参照してください。

クラスター管理者は、OpenShift Container Platform の Internal と Extrenal の間でロードバランサースコープを変更するように Ingress Controller エンドポイントパブリッシング戦略を設定できるようになりました。

詳細は、Ingress Controller エンドポイント公開戦略を参照してください。

Red Hat Open Stack Platform (RHOSP) で実行されるクラスターの場合、Open vSwitch (OVS) ハードウェアオフロードを有効にできます。

詳細は、OVS ハードウェアオフロードの有効化を参照してください。

RHOSP で実行されるクラスターの場合、Kuryr は、Pod ネットワーク上に少なくとも 1 つの Pod を持つ名前空間の Neutron ネットワークとサブネットのみを作成するようになりました。さらに、名前空間内のプールは、Pod ネットワーク上の少なくとも 1 つの Pod が名前空間内に作成された後に作成されます。

これで、分散コンピュートノード (DCN) 設定を使用する Red Hat Open Stack Platform (RHOSP) デプロイメントにクラスターをデプロイできます。このデプロイメント設定には、いくつかの制限があります。

RHOSP で実行されるクラスターは、Cloud Provider Open Stack を使用できるようになりました。この機能は、TechPreviewNoUpgrade 機能セットの一部として利用できます。

OpenShift Container Platform は、インストーラーでプロビジョニングされるクラスターの networkConfig 設定を提供するようになりました。インストーラーでプロビジョニングされるインストールでは、networkConfig 設定と NMState YAML 設定を install-config.yaml ファイルに追加します。さらに、Bare Metal Operator を使用する際に、networkConfig 設定および NMState YAML 設定をベアメタルホストリソースに追加できます。

networkConfig 設定で最もよく使われるユースケースは、インストール時またはクラスターを拡張する間にホストのネットワークインターフェイスに静的 IP アドレスを設定することです。

詳細は、install-config.yaml ファイルでのホストネットワークインターフェイスの設定について参照してください。

PtpConfig プロファイルで複数のネットワークインターフェイスを指定できるようになり、RAN vDU アプリケーションを実行しているノードが Precision Time Protocol Telecom Boundary Clock (PTP T-BC) として機能するノードに対応できるようになりました。境界クロックとして設定されるインターフェイスが PTP 高速イベントに対応するようになりました。

詳細は、Configuring linuxptp services as boundary clock を参照してください。

Intel 800-Series Columbiaville NIC が、境界クロックまたは通常のクロックとして設定されるインターフェイスに対して完全にサポートされるようになりました。Columbiaville NIC は、以下の設定でサポートされています。

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

OpenShift Container Platform は、ベアメタル、IBM Power、IBM Z、および LinuxONE インストールの Kubernetes NMState Operator を提供するようになりました。Kubernetes NMState Operator は依然として、他のすべてのプラットフォームでのテクノロジープレビューです。詳細は、Kubernetes NMState 演算子についてをご覧ください。

Mellanox MT2892 カード で SR-IOV サポートが利用できるようになりました。

管理者は、Network Observability Operator をインストールして、コンソールで OpenShift Container Platform クラスターのネットワークトラフィックを監視できるようになりました。さまざまなグラフィック表現でネットワークトラフィックデータを表示および監視できます。Network Observability Operator は、eBPF テクノロジーを使用してネットワークフローを作成します。その後、ネットワークフローは OpenShift Container Platform 情報で強化され、Loki に保存されます。ネットワークトラフィック情報を使用して、詳細なトラブルシューティングと分析を行うことができます。

Network Observability Operator は、OpenShift Container Platform の 4.12 リリースで一般公開 (GA) ステータスとなり、OpenShift Container Platform 4.10 でもサポートされています。

詳細は、Network Observability を参照してください。

MetalLB および MetalLB Operator の以下の拡張機能は、本リリースに含まれています。

詳細は、About MetalLB and the MetalLB Operator を参照してください。

OpenShift Container Platform は HostFirmwareSettings および FirmwareSchema リソースをサポートします。ベアメタルホストに OpenShift Container Platform をデプロイする場合、プロビジョニングの前後にホストに変更を加える必要がある場合があります。これには、ホストのファームウェアおよび BIOS の詳細の検証が含まれます。Bare Metal Operator (BMO) で使用できる新しいリソースが 2 つあります。

詳細は、ベアメタルの設定を参照してください。

OpenShift Container Platform は、AliCloud Disk の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。このドライバーを管理する AliCloud Disk Driver Operator は一般に利用可能であり、OpenShift Container Platform 4.10 ではデフォルトで有効になっています。

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

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

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

OpenShift Container Platform は、Red Hat Virtualization (RHV) の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。このドライバーを管理する IBM VPC Block Driver Operator は一般に利用可能であり、OpenShift Container Platform 4.10 ではデフォルトで有効になっています。

詳細は、IBM VPC Block CSI Driver Operatorを参照してください。

OpenShift Container Platform は、vSphere の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。この機能は以前は OpenShift Container Platform 4.8 のテクノロジープレビュー機能として導入されましたが、OpenShift Container Platform 4.10 では一般に利用可能となり、デフォルトで有効にされます。

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

vSphere CSI ドライバー Operator のインストールには以下が必要です。

前述の条件が満たされなくても、クラスターはアップグレードされますが、サポートされる vSphere CSI Operator ドライバーを使用するにはこれらの条件を満たすことが推奨されます。

OpenShift Container Platform は、Azure ディスクの Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。この機能は以前は OpenShift Container Platform 4.8 のテクノロジープレビュー機能として導入されましたが、OpenShift Container Platform 4.10 では一般に利用可能となり、デフォルトで有効にされます。

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

OpenShift Container Platform は、AWS Elastic File Storage (EFS) の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。この機能は以前は OpenShift Container Platform 4.9 のテクノロジープレビュー機能として導入されましたが、OpenShift Container Platform 4.10 では一般に利用可能となりました。

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

OpenShift Container Platform 4.8 以降、インツリーボリュームプラグインの同等の Container Storage Interface (CSI) ドライバーへの自動移行がテクノロジープレビュー機能として利用可能になりました。この機能は、Azure File in-tree プラグインの Azure File CSI ドライバーへの自動移行をサポートするようになりました。

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

OpenShift Container Platform 4.8 以降、インツリーボリュームプラグインの同等の Container Storage Interface (CSI) ドライバーへの自動移行がテクノロジープレビュー機能として利用可能になりました。この機能は、vSphere in-tree プラグインの vSphere CSI ドライバーへの自動移行をサポートするようになりました。

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

ストレージボリュームに多数のファイル (およそ 100 万以上) が含まれる場合には、Pod のタイムアウトが生じる可能性があります。

OpenShift Container Platform 4.10 では、fsGroup および fsGroupChangePolicy を使用して、ストレージボリュームの再帰的なパーミッションの変更をスキップする機能が導入されているため、Pod タイムアウトの問題を回避できます。

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

Operator が Operator Lifecycle Manager (OLM) によってインストールされると、そのクラスターサービスバージョン (CSV) の簡単なコピーが Operator が監視するすべての namespace に作成されます。これらの CSV は、コピーされる CSV として知られ、それらは特定の namespace でリソースイベントをアクティブに調整しているコントローラーを特定します。

大規模なクラスターでは、namespace およびインストールされた Operator が数百または数千の場合に、コピーされた CSV は OLM のメモリー使用量、クラスター etcd 制限、およびネットワーク帯域幅などのリソースを有効にしない量を消費する可能性があります。これらの大規模なクラスターをサポートするために、クラスター管理者は、AllNamespaces モードでインストールされる Operator のコピーされた CSV を無効にできます。

詳細は、Operator Lifecycle Manager 機能の設定を参照してください。

特定の依存関係要件を持つ Operator は、複雑な制約または要件式を使用できるようになりました。新しい olm.constraint バンドルプロパティーは、依存関係制約情報を保持します。message フィールドにより、Operator の作成者は特定の制約が使用される理由についてハイレベルな詳細情報を伝えることができます。

詳細は、Operator Lifecycle Manager の依存関係の解決を参照してください。

Operator カタログを含む Operator Lifecycle Manager (OLM) コンポーネントは、Hypershift 管理のコントロールプレーンで完全に実行できるようになりました。この機能により、ワーカーノードのテナントにコストがかかりません。

以前のバージョンでは、デフォルトの Operator カタログは ARM をサポートしませんでした。今回の機能拡張により、Operator Lifecycle Manager (OLM) がデフォルトの Operator カタログを ARM クラスターに追加するようになりました。その結果、OperatorHub には ARM をサポートする Operator がデフォルトでコンテンツが含まれるようになりました。(BZ#1996928)

Operator SDK における標準の Helm ベースの Operator サポートは、Operator の Operator 成熟度モデル で Auto Pilot 機能 (レベル V) に達した Go ベースおよび Ansible ベースの Operator サポートよりも機能が限定されています。

OpenShift Container Platform 4.10 以降、Operator SDK にはハイブリッド Helm Operator が含まれており、Go API 経由で既存の Helm ベースのサポートを強化します。Operator の作成者は Helm チャートで始まる Operator プロジェクトを生成し、Go 言語の Helm リコンサイラーに高度なイベントベースのロジックを追加できます。作成者は Go を使用して、同じプロジェクトに新規 API およびカスタムリソース定義 (CRD) の追加を継続できます。

詳細は、ハイブリッド Helm Operator の Operator SDK チュートリアルを参照してください。

Operator の作成者は Operator SDK で Ansible ベースの Operator サポートを使用し、カスタムメトリックの公開、Kubernetes イベントの送信、および優れたロギングの提供が可能になりました。

詳細は、Ansible ベースの Operator のカスタムメトリックの公開を参照してください。

operator-lib プルーニングユーティリティーを使用すると、Go ベースのオペレーターは、クラスター内にとどまり、リソースを使用できるジョブや Pod などのオブジェクトをクリーンアップできます。このユーティリティーには、囲碁ベースのオペレーター向けの一般的な剪定戦略が含まれています。Operator の作成者は、ユーティリティーを使用してカスタムフックと戦略を作成することもできます。

プルーニングユーティリティーの詳細は、Go ベースの演算子のオブジェクトプルーニングユーティリティーを参照してください。

この機能拡張により、Operator SDK は、Operator Lifecycle Manager (OLM) を使用して切断された環境で機能するバンドルに Operator プロジェクトをパッケージ化できるようになりました。オペレーターの作成者は、make bundleコマンドを実行し、USE_IMAGE_DIGESTS を true に設定して、オペレーターのイメージ参照をタグではなくダイジェストに自動的に更新できます。このコマンドを使用するには、環境変数を使用して、ハードコードされた関連するイメージ参照を置き換える必要があります。

切断された環境用の Operator の開発の詳細には、制限されたネットワーク環境での Operator の有効化を参照してください。

今回の機能拡張により、マシンを Azure Ephemeral OS ディスクにデプロイする Azure で実行されるマシンセットを作成できるようになりました。Azure Ephemeral OS ディスクは、リモートの Azure Storage ではなく、ローカルの VM 容量を使用します。

詳細は、マシンを Ephemeral OS ディスクにデプロイするマシンセット ついて参照してください。

このリリースでは、Machine API を使用して、Microsoft Azure VM の高速ネットワークを有効にできます。アクセラレートネットワークでは、Single Root I/O Virtualization (SR-IOV) を使用して、仮想マシンのスイッチへの直接パスを提供します。

詳細は、Accelerated Networking for Microsoft Azure VMsを参照してください。

今回のリリースにより、高可用性を確保するために、複数のアベイラビリティーゾーンを持たないグローバル Azure リージョンで可用性セットを使用できるようになりました。

Google Cloud Platform (GCP) Compute Engine を使用すると、ユーザーは仮想マシンインスタンスに GPU を追加できます。GPU リソースにアクセスできるワークロードは、この機能を有効にしてコンピュートマシンでより優れたパフォーマンスが得られます。今回のリリースにより、Machine API を使用して、インスタンスに使用するサポートされる GPU を定義できるようになりました。

詳細は、マシンセットの GPU サポートの有効化 について参照してください。

今回の機能拡張により、ClusterAutoscaler リソース定義にノード使用率のしきい値を指定できるようになりました。このしきい値は、不要なノードが削除の対象となっているノードの使用率レベルを表します。

詳細は、Cluster Autoscaler についてを参照してください。

今回の機能拡張により、Machine Config Daemon (MCD) は、ノード起動に加えて、マシン設定で指定されたファイルについてファイルシステム書き込みイベントが発生する場合、またはノードの起動に加えて新規のマシン設定が適用される前に、ノードの設定ドリフトをチェックするようになりました。以前のバージョンでは、MCD はノードの起動時にのみ設定のドリフトの有無を確認していました。この変更は、管理者が問題を修正するまで設定ドリフトによって生じる問題を回避するためにノードの再起動が頻繁に行われないために加えられました。

設定ドリフトは、ノードのディスク上の状態がマシン設定で設定される内容と異なる場合に発生します。Machine Config Operator (MCO) は MCD を使用して設定ドリフトの有無を確認し、検出される場合はノードおよびマシン設定プール (MCP) のパフォーマンスが 低下 します。

設定ドリフトの詳細は、Understanding configuration drift detection を参照してください。

クラスター内の特定ノードで Linux control groups version 2 (cgroups v2) を有効化できるようになりました。cgroups v2 を有効にする OpenShift Container Platform プロセスにより、cgroups バージョン 1 コントローラーおよび階層がすべて無効になります。OpenShift Container Platform cgroups バージョン 2 機能は Developer プレビューとして提供されており、現時点では Red Hat ではサポートされていません。詳細は、Enabling Linux control groups version 2 (cgroups v2)を参照してください。

ノードごとに OpenShift Container Platform ワークロードの swap メモリー使用量を有効にすることができます。詳細は、ノードでの swap メモリー使用の有効化を参照してください。

Node Maintenance Operator (NMO) は、クラスターの残りの部分からノードを切り離し、ノードからすべての Pod をドレイン (解放) します。ノードをメンテナンス状態にすることで、マシンの問題を調査したり、基礎となるマシンで操作を実行したり、ノードに障害が発生する可能性があります。これは NMO のスタンドアロンバージョンです。OpenShift Virtualization をインストールしている場合、バンドルされる NMO を使用する必要があります。

Node Health Check Operator は、これらの新たな拡張機能を提供します。

Poison Pill Operator は NodeDeletion をデフォルトの修復ストラテジーとして使用します。NodeDeletion 修復ストラテジーは node オブジェクトを削除します。

OpenShift Container Platform 4.10 では、Poison Pill Operator は ResourceDeletion という新規の修復ストラテジーを導入しています。ResourceDeletion 修復ストラテジーは、node オブジェクトではなくノードでの Pod および関連付けられたボリュームの割り当てを削除します。このストラテジーは、ワークロードをより迅速に復元するのに役立ちます。

これで、サービスを中断することなく、コントロールプレーンノードをある RHOSP ホストから別のホストに移行できます。

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

OpenShift Container Platform Web コンソールの新規 Metrics Targets ページには、デフォルトの OpenShift Container Platform プロジェクトおよびユーザー定義プロジェクトのターゲットが表示されます。このページを使用すると、現在収集の対象となっているエンドポイントを表示、検索、およびフィルタリングできます。これにより、問題を特定してトラブルシューティングしやすくなります。

今回のリリースにより、すべてのモニタリングコンポーネントが、メトリクス収集にベアラートークンの静的認証ではなく、相互 TLS 認証を使用するように設定されるようになりました。TLS 認証は、Kubernetes API の停止に対してより回復力が高く、Kubernetes API の負荷が軽減されます。

今回のリリースにより、Cluster Monitoring Operator コンポーネントはグローバルな OpenShift Container Platform tlsSecurityProfile 設定を有効にするようになりました。以下のコンポーネントおよびサービスは、TLS セキュリティープロファイルを使用するようになりました。

ユーザー定義モニタリングを有効にしている場合、以下の Pod がプロファイルを使用するようになりました。

今回のリリースにより、ハード非アフィニティールールおよび Pod の Disruption Budget (停止状態の予算) がモニタリングするコンポーネントで、パッチのアップグレード時にダウンタイムを短縮できるようになりました。

ユーザー定義のモニタリングを有効にしている場合、以下のコンポーネントはそれらのルールおよび予算も使用します。

本リリースでは、管理者がユーザー定義プロジェクトのモニタリングのアラートルーティングを有効にできるテクノロジープレビュー機能が導入されました。ユーザーは、ユーザー定義プロジェクトのアラートルーティングを追加し、設定できます。

OpenShift Container Platform ルートからサードパーティーの Alertmanager Web ユーザーインターフェイスへのアクセスが削除されました。

サードパーティーの Grafana Web ユーザーインターフェイスへのアクセスは非推奨となり、今後の OpenShift Container Platform リリースで削除されます。

Special Resource Operator (SRO) は、SRO カスタムリソースおよびオブジェクトの正常性を監視するためのメトリックを公開するようになりました。詳細は、Prometheus Special Resource Operator metrics を参照してください。

Special Resource Operator (SRO) に oc explain を使用すると、SRO カスタムリソース定義 (CRD) のオンラインドキュメントが提供されるようになりました。今回の機能拡張により、CRD フィールドの詳細が改善されました。(BZ#2031875)

Node Tuning Operator (NTO) メトリックが Telemetry に追加されました。Telemetry によって収集されるデータの表示についての手順に従い、Telemetry によって 収集されるすべてのメトリックを表示します。

Node Feature Discovery (NFD) Topology Updater は、ワーカーノードに割り当てられたリソースを調べるデーモンです。これは、ゾーンごとに新規 Pod に割り当てることができるリソースに対応し、ゾーンを Non-Uniform Memory Access (NUMA) ノードにすることができます。詳細は、NFD Topology Updater の使用を参照してください。

OpenShift Container Platform のハイパースレッディング対応の CPU マネージャーポリシーは追加のチューニングなしに利用できるようになりました。クラスター管理者は、必要に応じてこの機能を有効にできます。ハイパースレッドは、ハードウェアによって論理プロセッサーとして抽象化されます。ハイパースレッディングにより、単一の物理プロセッサーが同時に 2 つの負荷スレッド (プロセス) を実行し、プロセッサーリソースを動的に共有できます。

デフォルトの OpenShift Container Platform スケジューラーは、コンピュートノード内の個々の Non-Uniform Memory Access (NUMA) ゾーンを認識しません。これにより、レイテンシーの影響を受けやすいワークロードのスケジューリングが最適化されない可能性があります。NUMA 対応のセカンダリースケジューラーをデプロイする新しい NUMA Resources Operator が利用可能です。NUMA 対応のセカンダリースケジューラーは、クラスター内で使用可能な NUMA ゾーンの全体像に基づいて、ワークロードのスケジューリングを決定します。これにより、レイテンシーの影響を受けやすいワークロードが単一の NUMA ゾーンで処理され、効率とパフォーマンスが最大化されます。

詳細は、About NUMA-aware scheduling を参照してください。

フィルターを使用して SiteConfig CR をカスタマイズし、ゼロタッチプロビジョニング (ZTP) GitOps パイプラインのインストールフェーズで使用する他の CR を含めたり除外したりできるようになりました。詳細は、Filtering custom resources using SiteConfig filters を参照してください。

RAN vDU アプリケーションを実行しているノードでは、以前のバージョンから OpenShift Container Platform 4.10 に更新する場合に、chronyd を無効にする必要があります。chronyd を無効にするには、TunedPerformancePatch.yaml ファイルの .spec.profile.data の下の [service] セクションに以下の行を追加します。TunedPerformancePatch.yaml ファイルは、グループ PolicyGenTemplate CR で参照されます。

[service]
service.chronyd=stop,disable

詳細は、vDU アプリケーションを実行するための推奨クラスター設定 を参照してください。

本リリースでは、テクノロジープレビューフラグ --replica-sets が oc adm prune deployments コマンドに追加されました。デフォルトで、レプリケーションコントローラーのみが oc adm prune deployments コマンドでプルーニングされます。--replica-sets を true に設定すると、レプリカセットもプルーニングプロセスに含まれます。

詳細は、デプロイメントリソースのプルーニングを参照してください。

OpenShift Container Platform 4.10 では、Insights Operator はデフォルトで Red Hat OpenShift Cluster Manager から単純なコンテンツアクセス証明書をインポートするようになりました。

詳細は、Importing simple content access certificates with Insights Operator を参照してください。

Red Hat に送信されるデータ量を減らすために、Insights Operator は特定の条件が満たされる場合にのみ情報を収集します。たとえば、Insights Operator は、Alertmanager がアラート通知の送信に失敗する場合にのみ Alertmanager ログを収集します。

OpenShift Container Platform 4.10 では、Insights Operator は以下の追加情報を収集します。

この追加情報により、Red Hat は OpenShift Container Platform 機能を強化し、Insights Advisor の推奨事項を強化します。

本リリースでは、ユーザーのログイン時に、OpenID Connect プロバイダーから OpenShift Container Platform にグループメンバーシップを同期するサポートが導入されました。これを有効にするには、OpenShift Container Platform OpenID Connect アイデンティティープロバイダー設定で groups 要求を設定します。

詳細は、Sample OpenID Connect CRs を参照してください。

Okta および Ping Identity OpenID Connect (OIDC) プロバイダーは、OpenShift Container Platform でテストされ、サポートされるようになりました。

OIDC プロバイダーの完全リストは、サポートされている OIDC プロバイダーを参照してください。

以前のバージョンでは、レジストリー設定 (oc login または oc image など) を使用する oc コマンドは、Docker 設定の場所から認証情報を取得していました。OpenShift Container Platform 4.10 では、レジストリーエントリーがデフォルトの Docker 設定の場所で見つからない場合、oc コマンドは Podman 設定の場所から認証情報を取得します。場所の優先順位付けのために REGISTRY_AUTH_PREFERENCE 環境変数を使用して docker または podman のいずれかの設定を設定できます。

また、ユーザーは REGISTRY_AUTH_FILE 環境変数を使用するオプションもあります。これは、既存の --registry-config CLI フラグの代わりに機能します。REGISTRY_AUTH_FILE 環境変数も podman と互換性があります。

Cloud Credential Operator (CCO) ユーティリティー ccoctl を使用して、Google Cloud Platform Workload Identity を使用するように CCO を設定できるようになりました。CCO が GCP Workload Identity を使用するように設定されている場合、クラスター内のコンポーネントは、短期的で制限付き権限のセキュリティー認証情報を使用して IAM サービスアカウントになりすますことができます。

詳細は、Using manual mode with GCP Workload Identity を参照してください。