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

coreos-installer プログラムでインストールされるノードは、以前は /boot/ignition/config.ign ファイルにインストール Ignition 設定を保持していました。OpenShift Container Platform 4.9 のインストールイメージから、このファイルはノードのプロビジョニング時に削除されます。この変更は、以前の OpenShift Container Platform バージョンにインストールされたクラスターには影響を与えません。以前のブートイメージを使用するためです。

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

OpenShift Container Platform 4.9 では、ユーザーによってプロビジョニングされるインフラストラクチャーを使用して Azure Stack Hub にクラスターをインストールするためのサポートが導入されました。

デプロイメントプロセスを支援する Red Hat 提供の Azure Resource Manager (ARM) テンプレートのサンプルを組み込むか、または独自のテンプレートを作成することができます。他の方法を使用して必要なリソースを作成することもできます。ARM テンプレートはサンプルとしてのみ提供されます。

詳細は、Installing a cluster on Azure Stack Hub using ARM templates を参照してください。

アップグレードプロセスで、クラスター内のノードが一時的に利用できなくなる可能性があります。ワーカーノードの場合、マシンのヘルスチェックにより、このようなノードは正常ではないと識別され、それらが再起動される場合があります。このようなノードの再起動を回避するために、OpenShift Container Platform 4.9 では cluster.x-k8s.io/paused="" アノテーションが導入され、クラスターの更新前に MachineHealthCheck リソースを一時停止できます。

詳細は、Pausing a MachineHealthCheck resource を参照してください。

Microsoft Azure の OpenShift Container Platform インストールプログラムは、マシン CIDR 内に可能な限り大きなサブネットを作成するようになりました。これにより、クラスターがマシン CIDR のサイズを、クラスター内のノード数に対応するように設定できます。

OpenShift Container Platform 4.9 では、中国の AWS リージョンのサポートが導入されました。cn-north-1 (Beijing) および cn-northwest-1(Ningxia) リージョンに OpenShift Container Platform クラスターをインストールし、更新できるようになりました。

詳細は、Installing a cluster on AWS China を参照してください。

OpenShift Container Platform 4.9 では、baremetal ネットワークで仮想メディアを使用して、provisioning ネットワークを使用してデプロイされるインストーラーでプロビジョニングされるクラスターを拡張することができます。ProvisioningNetwork 設定が Managed に設定されている場合、この機能を使用できます。この機能を使用するには、provisioning カスタムリソース (CR) で virtualMediaViaExternalNetwork 設定を true に設定する必要があります。また、API VIP アドレスを使用するようにマシンセットを編集する必要もあります。詳細は、Preparing to deploy with Virtual Media on the baremetal network を参照してください。

OpenShift Container Platform 4.9 は Kubernetes 1.22 を使用します。これにより、非推奨となった v1beta1 APIs が大幅に 削除されました。

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

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

詳細は、Preparing to update to OpenShift Container Platform 4.9 を参照してください。

OpenShift Container Platform 4.9 では、PCI パススルー に依存する Red Hat OpenStack Platform (RHOSP) デプロイメントへのインストールがサポートされるようになりました。

OpenShift Container Platform 4.9 は etcd 3.5 をサポートします。クラスターをアップグレードする前に、有効な etcd バックアップが存在することを確認します。etcd バックアップは、アップグレードの失敗が発生した場合に、クラスターを復元できることを保証します。OpenShift Container Platform 4.9 では、etcd のアップグレードは自動的に行われます。クラスターのバージョン 4.9 への移行状態によっては、etcd バックアップが利用可能である可能性があります。ただし、クラスターのアップグレードを開始する前に、バックアップが存在することを確認することが推奨されます。

OpenShift Container Platform 4.9 では、インストーラーでプロビジョニングされるインフラストラクチャーを使用して IBM Cloud® にクラスターをインストールするためのサポートが導入されました。手順は、以下の相違点で、ベアメタルのインストーラーでプロビジョニングされるインフラストラクチャーとほぼ同じです。

詳細は、Deploying installer-provisioned clusters on IBM Cloud を参照してください。

OpenShift Container Platform 4.9 は、インストーラーでプロビジョニングされるクラスターを Fujitsu ハードウェアにデプロイし、Fujite 統合 Remote Management Controller (iRMC) を使用する場合はワーカーノードの BIOS 設定サポートを追加します。詳細は、Configuring BIOS for worker node を参照してください。

今回の更新により、管理者は Node ページからノードログにアクセスできるようになりました。ノードのログを確認するには、Logs タブをクリックして個別のログファイルとジャーナルログユニットを切り替えます。

クラスターダッシュボードの Cluster utilization カードで、ノードタイプでフィルターできるようになりました。追加のノードタイプは作成時に一覧に表示されます。

今回の更新で、デフォルトのプロジェクト、パースペクティブ、トポロジービューなどの設定をカスタマイズするための User Preferences ページが追加されました。

今回の更新により、Web コンソールのマストヘッドで、Projects ドロップダウンから default projects を非表示にできるようになりました。検索およびフィルターの前に、default projects を表示に切り替えることができます。

今回の更新により、Web コンソールにユーザー設定を追加できるようになりました。ユーザーは、デフォルトのパースペクティブ、プロジェクト、トポロジー、およびその他の設定を選択できます。

OpenShift Container Platform の監査ロギングレベルをきめ細かく制御できるようになりました。カスタムルールを使用して、異なるグループに異なる監査ポリシープロファイル (Default、WriteRequestBodies、AllRequestBodies、または None) を指定することができます。

詳細は、Configuring the audit log policy with custom rules を参照してください。

None 監査ポリシープロファイルを使用して OpenShift Container Platform の監査ロギングを無効にできるようになりました。

詳細は、Disabling audit logging を参照してください。

内部 OAuth サーバーの URL をカスタマイズすることができるようになりました。詳細は、Customizing the internal OAuth server URL を参照してください。

OpenShift Container Platform 4.9 では、NBDE を設定したシステムのメンテナンスを継続的に行う手順が追加されました。NBDE を使用すると、マシンの再起動時にパスワードを手動で入力しなくても、物理マシンおよび仮想マシン上のハードドライブのルートボリュームを暗号化できます。詳細は、About disk encryption technology を参照してください。

OpenShift Container Platform 4.9 では、etcd 証明書は自動的にローテーションされ、システムによって管理されます。

Kubernetes API サーバー TLS セキュリティープロファイル設定も etcd で適用されるようになりました。

OpenShift Container Platform 4.9 では、PTP に以下の更新が導入されました。

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

PTP イベントの高速イベント通知がベアメタルクラスターで利用可能になりました。PTP Operator は、設定されたすべての PTP 対応ネットワークインターフェイスのイベント通知を生成します。イベントは、同じノードで実行されているアプリケーションの REST API を介して利用できます。高速イベント通知は、AMQ Interconnect Operator によって提供される Advanced Message Queuing Protocol(AMQP) メッセージバスによって転送されます。

詳細は、About PTP and clock synchronization error events を参照してください。

OVN-Kubernetes の egress IP 機能は、namespace に複数の egress IP アドレスが割り当てられている場合、その指定された namespace のノード全体にほぼ均等にネットワークトラフィックを分散するようになりました。それぞれの IP アドレスは異なるノードに存在する必要があります。詳細は、OVN-Kubernetes の Configuring egress IPs for a project を参照してください。

コンテナー化された Data Plane Development Kit(DPDK) が OpenShift Container Platform 4.9 で一般提供されるようになりました。詳細は、Using virtual functions (VFs) with DPDK and RDMA modes を参照してください。

SR-IOV は、Intel および Mellanox NIC 上の Fast Datapath DPDK アプリケーションで使用する vhost-net をサポートするようになりました。この機能は、SriovNetworkNodePolicy リソースを設定して有効にできます。詳細は、SR-IOV network node configuration object を参照してください。

単一ノードクラスターは、SR-IOV ハードウェアおよび SR-IOV Network Operator をサポートします。SR-IOV ネットワークデバイスを設定すると、単一ノードが再起動するので、Operator の disableDrain フィールドを設定する必要があることに注意してください。詳細は、Configuring the SR-IOV Network Operator を参照してください。

OpenShift Container Platform 4.9 では、追加の Broadcom および Intel ハードウェアへのサポートが追加されました。

詳細は、supported devices を参照してください。

本リリースでは、MetalLB Operator が導入されました。MetalLB Operator のインストールおよび設定後に、MetalLB をデプロイして、ベアメタルクラスターのサービス用のネイティブロードバランサー実装を提供できます。ベアメタルのような他のオンプレミスインフラストラクチャーにもメリットがあります。

Operator はカスタムリソース AddressPool を導入します。MetalLB がサービスに割り当てることのできる IP アドレス範囲のアドレスプールを設定します。LoadBalancer タイプのサービスを追加する場合、MetalLB はプールから IP アドレスを割り当てます。

本リリースでは、Red Hat はレイヤー 2 モードでの MetalLB の使用のみをサポートします。

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

CNI VRF プラグインは以前は OpenShift Container Platform 4.7 のテクノロジープレビュー機能として導入されましたが、OpenShift Container Platform 4.9 では一般に利用可能となりました。

詳細は、Assigning a secondary network to a VRF を参照してください。

このリリースでは、Ingress Controller の tuningOptions パラメーター用に、6 つのタイムアウト設定が導入されています。

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

spec.clientTLS を設定することにより、相互 TLS(mTLS) 認証を有効にするように Ingress コントローラーを設定できるようになりました。clientTLS フィールドは、クライアント証明書を検証するための Ingress コントローラーの設定を指定します。

詳細は、Configuring Mutual TLS Authentication を参照してください。

クラスター管理者は、503、404、または両方のエラーページのカスタム HTTP エラーコード応答ページを指定できます。

詳細は、Customizing HAProxy error code response pages を参照してください。

OpenShift Container Platform 4.9 では、インストーラーでプロビジョニングされたクラスターの provisioningNetworkInterface 設定はオプションになります。provisioningNetworkInterface 設定は、provisioning ネットワークに使用される NIC 名を識別します。OpenShift Container Platform 4.9 では、install-config.yml ファイルの bootMACAddress を代わりに指定できます。これにより、Ironic は provisioning ネットワークに接続されている NIC の IP アドレスを識別し、これにバインドできます。プロビジョニングカスタムリソースの provisioningInterface 設定を省略して、プロビジョニングカスタムリソースが代わりに bootMACAddress 設定を使用するようにすることもできます。

OpenShift Container Platform 4.9 では、DNS Operator managementState を変更できるようになりました。DNS Operator の managementState は、デフォルトで Managed に設定されます。これは、DNS Operator がそのリソースをアクティブに管理していることを意味します。これを Unmanaged に変更できます。つまり、DNS Operator がそのリソースを管理していないことを意味します。

以下は、DNS Operator managementState を変更するためのユースケースです。

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

RHOSP で実行されるクラスターの場合、クラウドプロバイダーのオプションとして、負荷分散用に Octavia を設定できるようになりました。

詳細は、Setting cloud provider options を参照してください。

今回のリリースにより、HAProxy に TLS 1.3 および Modern プロファイルの Ingress Controller のサポートが追加されました。

詳細は、Ingress Controller TLS security profiles を参照してください。

クラスター管理者は、route.openshift.io/RequiredRouteAnnotations と呼ばれるルーターのアドミッションプラグインを追加して、ドメインごとに HTTP Strict Transport Security(HSTS) 検証を設定できます。クラスター管理者がこのプラグインを設定して HSTS を適用する場合、新しく作成されたルートは、準拠する HSTS ポリシーで設定する必要があります。これは、ingresses.config.openshift.io/cluster と呼ばれるクラスター Ingress 設定のグローバル設定に対して検証されます。

詳細は、HTTP Strict Transport Security を参照してください。

OpenShift Container Platform 4.9 では、logEmptyRequests および HTTPEmptyRequestsPolicy フィールドを設定して、Ingress コントローラーが空の要求をログに記録または無視するように設定できます。

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

cluster-admin ロールで Web コンソールにログインすると、コンソールのフォームからクラスター内の任意の namespace に新しいネットワークポリシーを作成できるようになりました。以前のバージョンでは、これは YAML で直接実行することしかできませんでした。

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

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

OpenShift Container Platform は、Azure Stack Hub Storage の CSI Driver を使用して PV をプロビジョニングできます。Azure Stack ポートフォリオの一部である Azure Stack Hub を使用すると、オンプレミス環境でアプリケーションを実行し、データセンターで Azure サービスを配信できます。このドライバーを管理する Azure Stack Hub CSI Driver Operator は 4.9 用となり、一般提供されます。

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

OpenShift Container Platform は、AWS Elastic File Service (EFS) の CSI Driver を使用して PV をプロビジョニングできます。このドライバーを管理する AWS EFS CSI Driver Operator はテクノロジープレビュー機能としてご利用いただけます。

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

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

詳細は、CSI Automatic Migration を参照してください。

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

詳細は、CSI Automatic Migration を参照してください。

vSphere CSI Operator Driver ストレージクラスが vSphere のストレージポリシーを使用するようになりました。OpenShift Container Platform は、クラウド設定で設定されるデータストアをターゲットにするストレージポリシーを自動的に作成します。

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

OpenShift Container Platform 4.9 は、ローカルストレージ Operator の以下の新規メトリクスを提供します。

詳細は、Persistent storage using local volumes を参照してください。

OpenShift Container Platform 4.9 は、oVirt CSI ドライバーにサイズ変更機能を追加します。これにより、ユーザーは既存の永続ボリューム要求 (PVC) のサイズを増やすことができます。この機能の前に、ユーザーはサイズが増加する新規 PVC を作成し、すべてのコンテンツを古い永続ボリューム (PV) から新規 PV に移動させる必要がありました。これにより、データが失われる可能性があります。ユーザーは既存の PVC を編集し、oVirt CSI ドライバーは基礎となる oVirt ディスクのサイズを調整できるようになりました。

OpenShift Container Platform 4.9 では、統合イメージレジストリーは、ユーザーによってプロビジョニングされるインフラストラクチャーを使用して Microsoft Azure Stack Hub にインストールされたクラスターに Azure Blob Storage を使用します。

詳細は、Installing a cluster on Azure Stack Hub using ARM templates を参照してください。

OpenShift Container Platform 4.9 以降、Operator Lifecycle Manager(OLM) は Kubernetes 1.22 をサポートします。その結果、多数の v1beta1 API が削除され v1 に更新されています。削除された v1beta1 API に依存する Operator は OpenShift Container Platform 4.9 では実行されません。クラスター管理者は、クラスターを OpenShift Container Platform 4.9 にアップグレードする前に、latest チャネルに インストールされた Operator をアップグレードする 必要があります。

ファイルベースのカタログは、Operator Lifecycle Manager(OLM) のカタログ形式の最新の反復になります。この形式は、プレーンテキストベース (JSON または YAML) であり、以前の形式の宣言的な設定の進化であり現在は非推奨の SQLite データベース形式 であり、完全な下位互換性があります。この形式の目標は、Operator のカタログ編集、設定可能性、および拡張性を有効にすることです。

ファイルベースのカタログ仕様の詳細は、Operator Framework packaging format を参照してください。

opm CLI を使用して、ファイルベースのカタログを作成する方法については、Managing custom catalogs を参照してください。

Operator Lifecycle Manager(OLM) が Single Node OpenShift(SNO) クラスターで利用でき、セルフサービスの Operator のインストールが可能になりました。

管理者は、このような問題を正常にデバッグするために、さまざまな低レベル API 間の相互作用プロセスや Operator Lifecycle Manager(OLM)Pod ログへのアクセスを理解する必要がないため、OpenShift Container Platform4.9 では、OLM に以下の拡張機能を導入し、よりわかりやすいエラーレポートとメッセージを管理者に提供します。

クラスターのアップグレードにより、Operator のインストールがサポートされていない状態になったり、更新パスが継続されなかったりする可能性を回避するために、クラスターのアップグレードの一環として、Operator カタログのインデックスイメージのバージョンを自動的に変更するように有効化することができます。

olm.catalogImageTemplate アノテーションをカタログイメージ名に設定し、イメージタグのテンプレートを作成する際に、1 つ以上の Kubernetes クラスターバージョン変数を使用します。

詳細は、Image template for custom catalog sources を参照してください。

OpenShift Container Platform クラスターは、複数のノードを使用する高可用性 (HA) モード、または単一ノードを使用する非 HA モードで設定できます。Single Node OpenShift(SNO) とも呼ばれる単一ノードクラスターには、より慎重なリソース制約がある可能性があります。したがって、単一ノードクラスターにインストールされた Operator がそれに応じて調整でき、正常に実行できることが重要です。

OpenShift Container Platform で提供されるクラスター高可用性モード API にアクセスすることにより、Operator の作成者は、Operator SDK を使用して、Operator がクラスターのインフラストラクチャートポロジー (HA モードまたは非 HA モード) を検出できるようにすることができます。カスタム Operator ロジックは、検出されたクラスタートポロジーを使用して、Operator およびそれが管理するオペランドまたはワークロードの両方のリソース要件を、トポロジーに最も適したプロファイルに自動的に切り替えるように開発することができます。

詳細は、High-availability or single node cluster detection and support を参照してください。

Operator の作成者は、ネットワークプロキシーをサポートする Operator を開発できるようになりました。プロキシーをサポートする Operator は環境変数の Operator デプロイメントを検査し、必要なオペランドに変数を渡します。クラスター管理者は、Operator Lifecycle Manager (OLM) によって処理される環境変数のプロキシーサポートを設定します。詳細は、Go、Ansible、および Helm を使用して Operator を開発するための Operator SDK チュートリアルを参照してください。

bundle validate サブコマンドを使用して、テストの Operator Framework スイートを使用して Kubernetes 1.22 から削除された API のバンドルマニフェストを確認することができます。

以下に例を示します。

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

バンドルマニフェストに Kubernetes 1.22 から削除された API が含まれる場合は、このコマンドに警告メッセージが表示されます。警告メッセージは、移行する必要がある API および Kubernetes API 移行ガイドへのリンクを示します。

詳細は、table of beta APIs removed from Kubernetes 1.22 および Operator SDK CLI reference を参照してください。

本リリースでは、イメージレジストリー設定でレジストリーソースとしてワイルドカードドメインを使用するサポートが導入されました。*.example.com などのワイルドカードドメインを使用して、各サブドメインを手動で入力しなくても、複数のサブドメインからイメージをプッシュおよびプルするようにクラスターを設定できます。詳細は、Image controller configuration parameters を参照してください。

OpenShift Container Platform 4.9 以降、コンピュートマシンに Red Hat Enterprise Linux(RHEL)8.4 を使用できるようになりました。以前は、RHEL 8 はコンピュートマシン用にはサポートされませんでした。

RHEL 7 コンピュートマシンを RHEL 8 にアップグレードすることはできません。新しい RHEL 8 ホストをデプロイする必要があり、古い RHEL 7 ホストを削除する必要があります。

スケジューラープロファイルを使用した Pod のスケジューリングが一般提供されました。これは、スケジューラーポリシーを設定する代わりに実行されます。以下のスケジューラープロファイルを利用できます。

詳細は、Scheduling pods using a scheduler profile を参照してください。

以下の Descheduler プロファイルが利用可能になりました。

LifecycleAndUtilization プロファイルの Pod ライフタイム値をカスタマイズすることもできます。

詳細は、Evicting pods using the descheduler を参照してください。

Pod がプライベートレジストリーからイメージをプルできるように docker/config.json ファイルを設定する場合、同じレジストリー内の特定のリポジトリーを一覧表示できるようになりました。各リポジトリーには、そのレジストリーパスに固有の認証情報が含まれています。以前は、特定のレジストリーから 1 つのリポジトリーしかリストできませんでした。特定の namespace でレジストリーを定義することもできるようになります。

ノード関連のメトリックスとアラートが強化され、ノードの安定性がいつ損なわれたかを早期に示すことができます。

Poison Pill Operator は、ウォッチドッグデバイスを使用して強化された修復を提供するようになりました。詳細については、ウォッチドッグデバイスについて を参照してください。

Node Health Check Operator を使用して NodeHealthCheck コントローラーをデプロイできます。コントローラーは、正常ではないノードを識別し、Poison PillOperator を使用して、正常ではないノードを修正します。

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

サードパーティーの Prometheus UI へのリンクは、OpenShift Container Platform Web コンソールの Observe → Metrics ページから削除されます。Prometheus UI へのルートへは、openshift-monitoring プロジェクトの Networking → Routes ページに移動し、Administrator パースペクティブの Web コンソールで引き続きアクセスすることができます。

デフォルトの Grafana ダッシュボードを実行すると、ユーザーのワークロードからリソースを取得できるため、Grafana ダッシュボードのデプロイメントを無効にできます。

Special Resource Operator(SRO) を使用して、既存の OpenShift Container Platform クラスターでのカーネルモジュールとドライバーのデプロイメントを管理できるようになりました。これは現在、テクノロジープレビュー機能です。

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

Performance Addon Operator によって設定される kubelet サブコンポーネントである Memory Manager は、以下の Topology Manager ポリシーのいずれかで設定されたノードで実行されているすべての Pod に対してデフォルトで有効にされるようになりました。

OpenShift Container Platform 4.9 では、システムレイテンシーを測定するための 2 つのツールが追加されました。

詳細は、Running the latency tests を参照してください。

OpenShift Container Platform 4.9 の クラスターの最大値 に関するガイダンスが更新されました。

ご使用の環境のクラスター制限を見積もるには、OpenShift Container Platform Limit Calculator を使用できます。

OpenShift Container Platform 4.9 は、ゼロタッチプロビジョニング (ZTP) をサポートします。これにより、リモートサイトでのベアメタル機器の宣言的な設定で新しいエッジサイトをプロビジョニングすることができます。ZTP は、インフラストラクチャーのデプロイメントに GitOps デプロイメントセットを使用します。GitOps は、YAML ファイルや他の定義パターンなどの Git リポジトリーに保存される宣言型仕様を使用してこれらのタスクを実行します。これは、インフラストラクチャーをデプロイするためのフレームワークを提供します。宣言型の出力は、マルチサイトのデプロイメントに Open Cluster Manager (OCM) によって使用されます。詳細は、Provisioning edge sites at scale を参照してください。

OpenShift Container Platform 4.9 では、Insights Operator は Red Hat OpenShift Cluster Manager から RHEL Simple Content Access(SCA) 証明書をインポートすることができます。

詳細は、Importing RHEL Simple Content Access certificates with Insights Operator を参照してください。

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

この追加情報により、Red Hat は Insights Advisor の改善された修復手順を提供できます。

今回のリリースにより、Microsoft Azure Stack Hub へのインストールは、Cloud Credential Operator(CCO) を手動モードに設定して実行できます。

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