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

OpenShift Container Platform 4.11 では、NVMe デバイスを管理するためのインターフェイスを提供する nvme-cli パッケージが導入されました。

RHCOS は、OpenShift Container Platform 4.11 の x86_64 アーキテクチャーの kdump に対応するようになりました。他のアーキテクチャーでの kdump のサポートは依然としてテクノロジープレビューです。

RHCOS は、テクノロジープレビューとして OpenShift Container Platform 4.11 の arm64 アーキテクチャーの kdump をサポートするようになりました。

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

RHCOS ブートイメージのダウンロード用のリ director ホスト名は rhcos.mirror.openshift.com になりました。ブートイメージへのアクセス権限を付与するようにファイアウォールを設定する必要があります。詳細は、Configuring your firewall for OpenShift Container Platform を参照してください。

OpenShift インストーラー (openshift-install) での Red Hat Enterprise Linux (RHEL) 9 の使用がサポートされるようになりました。

詳細は、お使いのプラットフォームのインストールドキュメントの "Obtaining the installation program" セクションを参照してください。

今回のリリースにより、OpenShift Container Platform を単一ノードにインストールするための最小要件が更新されました。OpenShift Container Platform を単一ノードにインストールする場合は、最低 16 GB の RAM を設定する必要があります。特定のワークロード要件では、追加の RAM が必要になる場合があります。サポート対象プラットフォームの完全なリストは、ベアメタル、vSphere、Red Hat OpenStack Platform (RHOSP)、および Red Hat Virtualization プラットフォームが含まれるように更新されました。いずれの場合も、openshift-installer バイナリーが single-node OpenShift のインストールに使用される際に、install-config.yaml 設定ファイルに platform.none: {} パラメーターを指定する必要があります。

OpenShift Container Platform 4.11 は、ARM アーキテクチャーベースの AWS のユーザーによってプロビジョニングされるインフラストラクチャーおよびベアメタルのインストーラーでプロビジョニングされるインフラストラクチャーでサポートされるようになりました。インスタンスの可用性やインストールに関するドキュメントの詳細は、Supported installation methods for different platforms を参照してください。

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

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

インストールプログラムは、AWS のブートストラップおよびコントロールプレーンホストから、シリアルコンソールログを収集するようになりました。このログデータは標準のブートストラップログバンドルに追加されます。

詳細は、インストールに関する問題のトラブルシューティング を参照してください。

デフォルトでは、インストールプログラムは、Hyper-V 生成バージョン 2 仮想マシン (VM) を使用して Microsoft Azure クラスターをデプロイするようになりました。仮想マシンに選択したインスタンスタイプがバージョン 2 に対応していないことをインストールプログラムが検出すると、デプロイメントにバージョン 1 が使用されます。

OpenShift Container Platform 4.11 以降、インストールプログラムは、4 vCPU および 16 GB の仮想 RAM を持つ AWS および VMware vSphere コンピュートノードをデプロイするようになりました。

OpenShift Container Platform 4.11 では、AWS Secret Commercial Cloud Services (SC2S) リージョンのサポートが追加されました。OpenShift Container Platform クラスターを us-isob-east-1 SC2S リージョンにインストールし、更新できるようになりました。

詳細は、Installing a cluster on AWS into a Secret or Top Secret Region を参照してください。

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

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

OpenShift Container Platform を Azure にインストールする際に、Ultra SSD ストレージを有効にできるようになりました。この機能には、OpenShift Container Platform をインストールする Azure リージョンとゾーンの両方が Ultra ストレージを提供する必要があります。

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

インストーラーでプロビジョニングされる OpenShift Container Platform クラスターを静的 IP アドレスでベアメタルにデプロイし、baremetal ネットワークに DHCP サーバーがない場合、ブートストラップ仮想マシンの静的 IP アドレスとブートストラップ仮想マシンのゲートウェイの静的 IP アドレスを指定する必要があります。OpenShift Container Platform 4.11 は、bootstrapExternalStaticIP および bootstrapExternalStaticGateway 設定を提供します。これらは、デプロイ前に install-config.yaml ファイルで設定できます。これらの設定の導入により、回避手順が置き換えられます。OpenShift Container Platform4.10 リリースの DHCP サーバーを使用せずに、ベアメタルネットワークでブートストラップ VM に IP アドレスを割り当てます。

詳細は、Configuring the install-config.yaml file および Additional install-config parameters を参照してください。

OpenShift Container Platform 4.11 では、Fujitsu ハードウェアを使用して OpenShift Container Platform をベアメタルにインストールする際に、コントロールプレーンノードの BIOS および RAID アレイを設定するサポートが導入されました。OpenShift Container Platform 4.10 では、Fujitsu ハードウェアに BIOS および RAID アレイを設定するとワーカーノードに制限されます。

詳細は、Configuring the BIOS および Configuring the RAID を参照してください。

oc-mirror OpenShift CLI (oc) プラグインを使用して、非接続環境でイメージをミラーリングできます。この機能は以前は OpenShift Container Platform 4.10 でテクノロジープレビューとして提供され、OpenShift Container Platform 4.11 で一般に利用可能になりました。

oc-mirror プラグインの今回のリリースには、以下の新機能が含まれます。

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

OpenShift Container Platform 4.11 では、ユーザー管理のディスク暗号化を使用して、Azure にクラスターをインストールするためのサポートが導入されました。

詳細は、Enabling user-managed encryption for Azure を参照してください。

Azure 上の OpenShift Container Platform 4.11 は、コントロールプレーンとコンピュートノードに Accelerated Networking を提供します。Accelerated Networking は、インストーラーによってプロビジョニングされたインフラストラクチャーインストールでサポートされているインスタンスタイプに対して、デフォルトで有効になっています。

詳細は、Openshift 4 on Azure - accelerated networking を参照してください。

制限された OpenShift Container Platform クラスターを AWS にインストールする際に AWS VPC エンドポイントを設定する必要がなくなりました。VPC エンドポイントの設定はオプションのままですが、VPC エンドポイントのないプロキシーを設定するか、VPC エンドポイントでプロキシーを設定することもできます。

詳細は、Requirements for using your VPC を参照してください。

OpenShift Container Platform 4.11 では、baremetal および marketplace Operator のインストールを無効にすることができます。また、openshift namespace に保存される openshift-samples コンテンツも無効にすることができます。インストール前に baselineCapabilitySet および additionalEnabledCapabilities パラメーターを install-config.yaml 設定ファイルに追加してこれらの機能を無効にすることができます。インストール時にこれらの機能のいずれかを無効にする場合は、クラスターのインストール後にそれらの機能を有効にできます。機能を有効にしたら、再度無効にすることはできません。

詳細は、お使いのプラットフォームのインストールドキュメントのインストール設定パラメーターセクションを参照してください。

OpenShift Container Platform が Azure Marketplace で利用できるようになりました。Azure Marketplace オファリングは、北米および EMEA で OpenShift Container Platform を入手されたお客様にご利用いただけます。

詳細は、Installing OpenShift using Azure Marketplace を参照してください。

OpenShift Container Platform が AWS Marketplace で利用できるようになりました。AWS Marketplace オファリングは、北米で OpenShift Container Platform を入手されたお客様にご利用いただけます。

詳細は、Installing OpenShift using AWS Marketplace を参照してください。

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

上記よりも前のバージョンのコンポーネントは、非推奨になるか、削除されています。廃止されたバージョンも引き続き完全にサポートされていますが、Red Hat では、ESXi 7.0 Update 2 以降および vSphere 7.0 Update 2 まで (バージョン 8 を除く) を使用することを推奨します。vSphere 8 はサポートされていません。

詳細は、Deprecated and removed features を参照してください。

クラスター管理者は、インストールまたはインストール後に、クラスター機能を有効にして 1 つ以上のオプションのコンポーネントを選択または選択解除できます。

詳細は、Cluster capabilities を参照してください。

OpenShift Container Platform 4.11 では、テクノロジープレビューの Azure インストーラーによってプロビジョニングされたインフラストラクチャーを使用して、マルチアーキテクチャーコンピューティングマシンをサポートするクラスターが導入されています。この機能は、2 日目の操作として、マルチアーキテクチャーのインストーラーバイナリーでプロビジョニングされたインストーラーである既存の x86_64 Azure クラスターに arm64 コンピュートノードを追加する機能を提供します。手動で生成された arm64 ブートイメージを使用するカスタム Azure マシンセットを作成することで、クラスターに arm64 コンピュートノードを追加できます。arm64 アーキテクチャー上のコントロールプレーンは現在サポートされていません。詳細は、マルチアーキテクチャークラスターの設定 を参照してください。

今回の更新により、新しい console.openshift.io/use-i18next アノテーションを使用して、ConsolePlugin にローカリゼーションリソースが含まれているかどうかを判断できるようになりました。アノテーションを "true" に設定すると、ダイナミックプラグインにちなんだ i18n namespace からローカライズリソースがロードされます。アノテーションが他の値に設定されているか、ConsolePlugin リソースにない場合、ローカリゼーションリソースは読み込まれません。

詳細は、動的プラグインの概要 を参照してください。

OpenShift Container Platform の Web コンソールがダークモードテーマをサポートするようになりました。User Preferences ページで、お好みのテーマを選択して Web コンソールを表示します。

今回の更新により、Operator Installed Operator ページには、全 namespace の全 Operator が表示されます。プロジェクトセレクター内で選択した namespace のインスタンスのみを引き続き表示できます。オペランドインスタンスを表示する場合、新しい切り替えコントロールにより、すべての namespace または現在の namespace のみのすべてのオペランドインスタンスを表示できます。

今回の更新では、条件付き更新が利用可能な場合、Update cluster モーダルの Select new version ドロップダウンで Include supported but not recommended versions を有効にして、ドロップダウンリストに条件付き更新を入力できます。Supported but not recommended バージョンを選択すると、ドロップダウンメニューの下に、バージョンの潜在的な問題が記載されたアラートが表示されます。

今回の更新により、Pod の Disruption Budget (PDB: 停止状態の予算) のサポートが OpenShift Container Platform Web コンソールに提供されます。Workloads PodDisruptionBudgets から、Pod リソースの PDB を作成できます。可用性要件リストから maxUnavailable と minAvailable を選択し、実行中の Pod の値を設定できます。または、Pod の Disruption Budget (PDB: 停止状態の予算) は、pod controller resources リストおよび 詳細 ページから作成することもできます。たとえば、Workloads Deployments から Add PodDisruptionBudget をクリックします。

詳細は、Pod preemption and other scheduler settings を参照してください。

OpenShift CLI (oc) での Red Hat Enterprise Linux (RHEL) 9 の使用がサポートされるようになりました。

詳細は、Installing the OpenShift CLI を参照してください。

ログインイベントでアノテーションされた OAuth サーバー監査イベントは、監査ログのメタデータレベルでログに記録されるようになりました。ログインイベントには、失敗したログイン試行が含まれます。

詳細は、About audit log policy profiles を参照してください。

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 レベルで高可用性を実現するために使用できます。

詳しくは、Configuring a bond interface from two SR-IOV interfaces を参照してください。

今回の更新により、hostnetwork エンドポイントストラテジーを持つ Ingress コントローラーの新規オプションが導入されました。httpPort、httpsPort、および statsPort バインディングポートを使用して、同じワーカーノードで複数の Ingress コントローラーをホストできるようになりました。

単一設定を同時に、クラスター内の複数のベアメタル、インストーラーでプロビジョニングされるインフラストラクチャーノードに適用できます。単一の設定を複数のノードに適用すると、シングルプロビジョニングプロセスによる設定ミスのリスクが軽減されます。

このメカニズムは、install-config ファイルを使用している場合のみ初期デプロイメントに利用できます。

Ingress コントローラーで AWS Classic Load Balancers (CLB) のアイドル接続タイムアウトを設定できるようになりました。

詳細は、Configuring Classic Load Balancer timeouts を参照してください。

OpenShift Container Platform が HAProxy 2.2.24 に更新されました。

Ingress コントローラーの HAProxy プロセスごとに確立できる同時接続の最大数を 2000 から 2,000,000 までの値に設定できるようになりました。

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

今回の更新により、クラスター管理者はヘルスチェックの間隔を設定して、連続する 2 つのヘルスチェックの間にルーターが待機する時間を定義できるようになりました。この値は、すべてのルートのデフォルトとしてグローバルに適用されます。デフォルト値は 5 秒です。

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

新しい tuning-cni メタプラグインを使用して、特定のインターフェイスのみに適用されるインターフェイスレベルの安全なネットワーク sysctl を設定します。たとえば、tuning-cni プラグインを設定して、特定のネットワークインターフェイスの accept_redirects の動作を変更できます。設定可能なインターフェイス固有の安全な sysclt の完全リストは、ドキュメントを参照してください。

今回の機能拡張により、net.ipv4.ping_group_range および net.ipv4.ip_unprivileged_port_start をサポートするように設定できるシステム全体の安全な sysctl のセットが増えました。

tuning-cni プラグインの設定に関する詳細は、Setting interface level network sysctls を参照してください。

新たにサポートされるインターフェイスレベルのネットワーク安全な sysclt sysclts および更新の詳細は、Using sysctls in containers を参照してください。

高度に規制された環境で作業する場合は、要求をアップストリームリゾルバーに転送する際にドメインネームシステム (DNS) トラフィックのセキュリティーを確保して、追加の DNS トラフィックおよびデータのプライバシーを確保できるようにする必要がある場合があります。クラスター管理者は、転送された DNS クエリーにトランスポート層セキュリティー (TLS) を設定できるようになりました。この機能は DNS Operator にのみ適用され、Machine Config Operator が管理する CoreDNS インスタンスには適用されません。

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

クラスター管理者は、OVN-Kubernetes Container Network Interface (CNI) クラスターネットワークプロバイダーを使用する場合に、Kubernetes サービスオブジェクトで internalTrafficPolicy=Local を設定できます。この機能により、クラスター管理者はトラフィックの発信元の同じノードのエンドポイントにトラフィックをルーティングすることができます。ローカルノードのエンドポイントがない場合、トラフィックはドロップされます。

詳細は、Service Internal Traffic Policy を参照してください。

クラスター管理者は、OpenShift Container Platform Web コンソールまたは CLI を使用して OperatorHub から AWS Load Balancer Operator をインストールできます。AWS Load Balancer Operator はテクノロジープレビュー機能です。

詳細は、Installing AWS Load Balancer Operator を参照してください。

以前のバージョンでは、ルートのサブドメインを指定できず、spec.host フィールドはホスト名を設定する必要がありました。spec.subdomain フィールドを指定し、ルートの spec.host フィールドを省略できるようになりました。ルートを公開するルーターデプロイメントは spec.subdomain 値を使用してホスト名を判別します。

この拡張機能を使用して、ルートがルートを公開する各ルーターデプロイメントによって決定される複数の異なるホスト名を指定できるようにすることで、シャード化を簡素化できます。

OpenShift Container Platform 4.11 では、外部 DNS Operator は AWS Route53、Azure DNS、GCP DNS、および Infoblox in General Availability (GA) ステータスで利用できます。外部 DNS Operator は、GovCloud の BlueCat および AWS Route53 のテクノロジープレビュー (TP) ステータスです。今回の更新により、外部 DNS Operator は以下の拡張機能を提供するようになりました。

TP から GA に移行するようにしてください。OpenShift Container Platform 4.11 の ExternalDNS のアップストリームバージョンは v0.12.0 で、TP の場合は v0.10.2 です。詳細は、About the External DNS Operator を参照してください。

各 NIC チャネルの PtpConfig プロファイルを使用して、デュアルネットワークインターフェイス (NIC) を境界クロックとして設定できるようになりました。

詳細は、Using PTP with dual NIC hardware を参照してください。

新しい PTP イベント API エンドポイント api/cloudNotifications/v1/publishers が利用できるようになりました。このエンドポイントを使用して、クラスターノードの PTP os-clock-sync-state、ptp-clock-class-change、および lock-state の詳細を取得できます。

詳細は、Subscribing DU applications to PTP events REST API reference を参照してください。

SR-IOV のサポートが、Pensando DSC カード で利用できるようになりました。OpenShift SR-IOV はサポートされますが、SR-IOV を使用する際に SR-IOV CNI 設定ファイルを使用して静的な Virtual Function (VF) メディアアクセス制御 (MAC) アドレスを設定する必要があります。

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

ネットワークの CIDR 範囲は、クラスターのインストール後に調整できないことに注意してください。Red Hat では、範囲を判断する際の直接ガイダンスを提供しません。作成された Pod 数について慎重に考慮する必要があるためです。

OVN-Kubernetes クラスターネットワークプロバイダーを使用している場合、クラスターのインストール後に IPsec 暗号化を有効化できるようになりました。IPsec の有効化方法の詳細は、Configuring IPsec encryption を参照してください。

より複雑な設定をサポートするために、追加の MetalLB カスタムリソース定義 (CRD) が追加されました。

以下の CRD が追加されました。

これらの機能強化により、Operator を使用してより複雑な設定を使用できるようになりました。たとえば、機能拡張を使用して、ノードを分離したり、ネットワークをセグメント化したりできます。さらに、FRRouting (FRR) ロギングコンポーネントに追加された機能強化により、生成されたログの詳細を制御できます。

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

route.openshift.io/destination-ca-certificate-secret アノテーションを Ingress オブジェクトで使用して、カスタム証明書 (CA) でルートを定義できるようになりました。

詳細は、Creating a route using the destination CA certificate in the Ingress annotation を参照してください。

OpenShift Container Platform のホスト型コントロールプレーンでは、クラスターを大規模にホストして管理コストの軽減、クラスターデプロイメント時間の最適化、および個別の管理およびワークロードに関する懸念点を実現します。Kubernetes Operator バージョン 2.0 のマルチクラスターエンジンをインストールする場合は、このデプロイメントモデルをテクノロジープレビュー機能として有効にできます。詳細は、Overview of hosted control planes (Technology Preview) を参照してください。

Open Virtual Network (OVN) は、コントロールプレーンとデータストアをクラスターのコントロールプレーンと共にホストするように再設計されました。ホスト型コントロールプレーンでは、OVN は分割されたコントロールプレーンをサポートします。

ユーザーによってプロビジョニングされる ベアメタルインフラストラクチャー 上のクラスターの場合、OVN-Kubernetes クラスターネットワークプロバイダーは IPv4 アドレスと IPv6 アドレスファミリーの両方をサポートします。

RHOSP で実行されるクラスターの場合、Open vSwitch (OVS) ハードウェアオフロードが一般提供されるようになりました。

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

RHOSP で実行されるクラスターの場合、ネットワーク機能の仮想化デプロイメントエクスペリエンスが向上しました。このリリースの変更点は次のとおりです。

これらの変更は、簡素化されたインストール後およびネットワーク設定のドキュメントに反映されています。

Red Hat OpenStack Platform (RHOSP)、VMware vSphere、または oVirt に OpenShift Container Platform インストーラーによってプロビジョニングされたインストールの場合には、keepalived は、デフォルトでマルチキャストではなくユニキャストとして設定されるようになりました。マルチキャストトラフィックを許可する必要はなくなりました。すべてのノードを同時に移行する必要があるため、クラスターのアップグレードが完了してから数分後にユニキャスト移行が行われます。keepalived はユニキャストとマルチキャストを完全に別のものとして扱うため、マルチキャストクラスターとユニキャストクラスターの両方を同時に使用しても問題は発生しません。

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

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

OpenShift Container Platform 4.8 以降、インツリーボリュームプラグインの同等の Container Storage Interface (CSI) ドライバーへの自動移行がテクノロジープレビュー機能として利用可能になりました。Cinder のサポートは OpenShift Container Platform 4.8 のこの機能で提供され、OpenShift Container Platform 4.11 では Cinder の自動移行に対するサポートが一般で利用可能になりました。Cinder の CSI 移行はデフォルトで有効化され、管理者によるアクションは不要になりました。

この機能は in-tree オブジェクトを自動的に対応する CSI 表現に変換するため、ユーザーに対して完全に透過的である必要があります。変換されたオブジェクトはディスクに保存され、ユーザーデータは移行されません。

in-tree ストレージプラグインを参照するストレージクラスは引き続き機能しますが、デフォルトのストレージクラスを CSI ストレージクラスに切り替えることが推奨されます。

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

OpenShift Container Platform 4.8 以降、インツリーボリュームプラグインの同等の Container Storage Interface (CSI) ドライバーへの自動移行がテクノロジープレビュー機能として利用可能になりました。Azure Disk のサポートは OpenShift Container Platform 4.9 のこの機能で提供され、OpenShift Container Platform 4.11 では Azure Disk の自動移行に対するサポートが一般で利用可能になりました。Azure Disk の CSI 移行はデフォルトで有効化され、管理者によるアクションは不要になりました。

この機能は in-tree オブジェクトを自動的に対応する CSI 表現に変換するため、ユーザーに対して完全に透過的である必要があります。変換されたオブジェクトはディスクに保存され、ユーザーデータは移行されません。

in-tree ストレージプラグインを参照するストレージクラスは引き続き機能しますが、デフォルトのストレージクラスを CSI ストレージクラスに切り替えることが推奨されます。

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

OpenShift Container Platform 4.3 以降で、作成済みの Container Storage Interface (CSI) ストレージボリュームの拡張がテクノロジープレビュー機能として利用可能になり、OpenShift Container Platform 4.11 で一般に利用可能になりました。

詳細は、Expanding CSI volumes を参照してください。

OpenShift Container Platform 4.11 では、Container Storage Interface (CSI) の汎用一時ボリュームのサポートが一般で利用可能になりました。汎用一時ボリュームは、永続ボリュームおよび動的プロビジョニングもサポートするすべてのストレージドライバーが提供できる一時ボリュームの一種です。

詳細は、Generic ephemeral volumes を参照してください。

OpenShift Container Platform 4.11 は、以下の制限のある vSphere Container Storage Interface (CSI) Driver Operator のボリュームサイズ変更およびスナップショットをサポートします。

詳細は、CSI drivers supported by OpenShift Container Platform を参照してください。

Image Registry Operator のデフォルト設定は、イメージレジストリー Pod をトポロジーゾーン全体に分散させ、すべての Pod が影響を受ける完全なゾーン障害が発生した場合の復旧時間の遅延を防ぎます。

詳細は、アベイラビリティーゾーン全体での Image Registry Operator のディストリビューション を参照してください。

OpenShift Container Platform 4.11 でサポートされる Red Hat OpenShift Data Foundation レジストリーストレージ。

OpenShift Data Foundation は、以下のような内部イメージレジストリーで使用できる複数のストレージタイプを統合します。

ファイルベースのカタログ形式で OpenShift Container Platform 4.11 リリース用のデフォルトの Red Hat が提供する Operator カタログ。SQLite データベース形式でリリースされた OpenShift Container Platform 4.6 から 4.10。ファイルベースのカタログは、Operator Lifecycle Manager(OLM) のカタログ形式の最新の反復になります。JSON または YAML のプレーンテキストベースファイルであり、以前の SQLite データベース形式の宣言的設定の進化です。クラスター管理者およびユーザーには、新規カタログ形式でのインストールワークフローおよび Operator の消費への変更は表示されません。

詳細は、File-based catalogs を参照してください。

OpenShift Container Platform 4.11 以降、Operator SDK には Java ベースの Operator を開発するためのツールおよびライブラリーが含まれます。Operator 開発者は、Operator SDK での Java プログラミング言語のサポートを利用して、Java ベースの Operator をビルドし、そのライフサイクルを管理できます。

詳細は、Getting started with Operator SDK for Java-based Operators を参照してください。

OpenShift Container Platform 4.11 の時点で、Operator カタログに関して、run bundle コマンドはデフォルトでファイルベースのカタログ形式をサポートします。Operator カタログに関して、非推奨の SQLite データベース形式は引き続きサポートされますが、今後のリリースで削除される予定です。

詳細は、Working with bundle images を参照してください。

Operator の作成者は、Operator SDK で bundle validate コマンドを実行して Operator バンドルのコンテンツおよび形式を検証できます。デフォルトのテストに加え、オプションのバリデーターを実行して、空の CRD 記述やサポートされていない Operator Lifecycle Manager (OLM) リソースなど、バンドル内の問題をテストできます。

詳細は、Validating Operator bundles を参照してください。以前のバージョンの OpenShift Container Platform では、Performance Addon Operator はアプリケーションの自動低レイテンシーパフォーマンスチューニングを提供していました。OpenShift Container Platform 4.11 では、これらの機能は Node Tuning Operator の一部です。Node Tuning Operator は、OpenShift Container Platform 4.11 の標準インストールの一部です。OpenShift Container Platform 4.11 にアップグレードする場合、Node Tuning Operator は起動時に Performance Addon Operator およびすべての関連アーティファクトを削除します。

詳細は、Node Tuning Operator を参照してください。

マシンセットを使用して、Amazon EC2 Instance Metadata Service (IMDS) の特定バージョンを使用するコンピュートマシンを作成できるようになりました。マシンセットは、IMDSv1 と IMDSv2 の両方の使用を許可するコンピュートマシン、または IMDSv2 の使用を必要とするコンピュートマシンを作成することができます。

詳細は、Machine set options for the Amazon EC2 Instance Metadata Service を参照してください。

Ultra ディスクを使用してマシンをデプロイする Azure で実行されるマシンセットを作成できるようになりました。Ultra ディスクをデータディスクとして使用するか、ツリー内または Container Storage Interface (CSI) PVC を使用する永続ボリューム クレーム (PVC) を使用してマシンをデプロイできます。

詳細は、以下のトピックを参照してください。

Google Cloud Platform (GCP) Compute Engine の pd-balanced 永続ディスクタイプをサポートするようになりました。詳細は、Configuring persistent disk types by using machine sets を参照してください。

Nutanix クラスターの新しいプラットフォームのサポートには、Machine API マシンセットを使用してマシンを管理する機能が含まれています。詳細は、Creating a machine set on Nutanix を参照してください。

OpenShift Container Platform 4.11 では、AWS および GCP クラスターのテクノロジープレビューとして、OpenShift Container Platform に統合されたアップストリームの Cluster API を使用してマシンを管理する機能が導入されています。この機能は、Machine API を使用してマシンを管理するための追加または代替の機能になります。詳細は、Managing machines with the Cluster API を参照してください。

Machine Config Operator(MCO) は topology.kubernetes.io/zone ラベルに基づいて、ゾーンによってアルファベット順に影響を受けるノードを更新するようになりました。ゾーンに複数のノードがある場合、最も古いノードが最初に更新されます。ベアメタルデプロイメントなど、ゾーンを使用しないノードの場合、ノードは年齢別にアップグレードされ、最も古いノードが最初に更新されます。以前のバージョンでは、MCO はゾーンまたはノードの経過時間を考慮しませんでした。

詳細については、マシン設定の概要 を参照してください。

MCO が一時停止する Machine Config Pool (MCP) で期限切れの kube-apiserver-to-kubelet-signer CA 証明書の更新を試行した場合に、OpenShift Container Platform Web コンソールのアラート UI でアラートを受信するようになりました。MCP が一時停止されると、MCO は新たにローテーションされた証明書をそれらのノードにプッシュできず、障害が発生する可能性があります。

詳細は、Pausing the machine config pools を参照してください。

OpenShift Container Platform 4.11 では、Puison Pill Operator に代わる Self Node Remediation Operator が導入されました。

Self Node Remediation Operator は以下の拡張機能を提供します。

詳細は、Remediating nodes with the Self Node Remediation Operator を参照してください。

シングルノード OpenShift クラスターにワーカーノードを追加することができるようになりました。これは、リソースに制約のある環境でのデプロイメントや、クラスターに容量を追加する必要があるネットワークエッジでのデプロイメントに役立ちます。

詳細は、Worker nodes for single-node OpenShift clusters を参照してください。

デフォルトで、Descheduler は予測モードで実行されるようになりました。つまり、これは Pod エビクションのみをシミュレートします。Descheduler メトリックを確認し、エビクトされる Pod の詳細を表示できます。

エビクションをシミュレーションせずに Pod をエビクトするには、Descheduler モードを automatic に変更します。

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

本リリースでは、Descheduler について以下のカスタマイズが導入されました。

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

Node Maintenance Operator は、以下の拡張機能を提供します。

詳細は、Using the Node Maintenance Operator to place nodes in maintenance mode を参照してください。

OpenShift Container Platform 4.11 では、RHV API の新しいコネクターが導入されました。これは、クラスター内のすべてのインストールおよび oVirt コンポーネントの自動ログメッセージを追加します。

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

クラスター管理者は、ユーザーワークロードモニタリングのアラートルーティングを有効にし、開発者やその他のユーザーが、ユーザー定義のプロジェクトにカスタムアラートとアラートルーティングを設定できるようになりました。

ユーザー定義のプロジェクトにのみアラートを送信する Alertmanager の独立したインスタンスを有効にするオプションが追加されました。この機能は、デフォルトプラットフォームの Alertmanager インスタンスの負荷を軽減し、ユーザー定義のアラートをデフォルトのプラットフォームアラートからより適切に分離する際に役立ちます。

リモート書き込みエンドポイントにアクセスする際に、AWS Signature Version 4、カスタム Authorization ヘッダー、および OAuth 2.0 の認証方法を使用できるようになりました。このリリース以前は、TLS クライアントと Basic 認証しか使用できませんでした。

OpenShift Container Platform Web コンソールの Observe Metrics ページにある Query Browser には、PromQL クエリーを作成、閲覧、および管理する機能を改善するためのさまざまな拡張機能が追加されています。たとえば、管理者は既存のクエリーを複製し、クエリーの作成および編集時に、オートコンプリートの提案を使用できるようになりました。

単一ノード OpenShift Container Platform デプロイメント上のすべての Cluster Monitoring Operator (CMO) 制御の ServiceMonitors に対して、スクレープ間隔が 2 倍になりました。最大間隔は 2 分になりました。

このリリースでは、管理者が既存のプラットフォームモニタリングメトリクスに基づいて、アラートルールを作成することができるテクノロジープレビュー能が導入されています。この機能により、管理者はより迅速かつ容易に、それぞれの環境に特化した新しいアラートルールを作成することができます。

リモート書き込みストレージに送信されるメトリックに、クラスター ID ラベルを追加できるようになりました。次に、これらのラベルをクエリーし、メトリックのソースクラスターを特定し、そのデータを他のクラスターによって送信される同様のメトリックデータと区別することができます。

Prometheus /federate エンドポイントを使用して、クラスター外のネットワークロケーションからユーザー定義のメトリックをスクレイプできるようになりました。このリリース以前は、フェデレーションエンドポイントにアクセスして、デフォルトのプラットフォームモニタリングでメトリクスをスクレイプすることしかできませんでした。

デフォルトのプラットフォームモニタリング用の enforcedBodySizeLimit config map オプションを設定して、メトリクススクレイピングでボディーサイズ制限を有効化できるようになりました。この設定は、少なくとも 1 つの Prometheus スクレイプターゲットが、設定された enforcedBodySizeLimit より大きいレスポンスボディーで応答したときに、新しい PrometheusScrapeBodySizeLimitHit アラートをトリガーします。この設定により、悪意のあるターゲットが Prometheus コンポーネントとクラスター全体の両方に与える影響を制限できます。

デフォルトのプラットフォームモニタリングとユーザーワークロードモニタリングの両方で、保持されたメトリクスストレージ用に予約された最大ディスク容量を設定できるようになりました。このリリースより前は、これは設定できませんでした。

ユーザー定義のプロジェクトで、Thanos Ruler データの保持期間を設定できるようになりました。このリリースより前は、デフォルト値の 24h を変更できませんでした。

OpenShift Container Platform 4.11 は、さまざまな業界環境の要求を満たすように PerformanceProfile を調整できる Node Tuning Operator のヒントメカニズムもサポートします。このリリースでは、ワークロードのヒントは、highPowerConsumption (消費電力が増加する代わりに非常に低いレイテンシーを実現) および realtime (最適なレイテンシーを優先) で利用できます。これらのヒントの true/false 設定の組み合わせを使用して、アプリケーション固有のワークロードプロファイルと要件を処理できます。

Raft アルゴリズムでは、新しい learner 状態を用いて etcd メンバーのスケーリングが可能です。その結果、クラスタークォーラムの維持、新しいメンバーの追加と削除、learners 昇格は、クラスターの運用を中断することなく行われます。

OpenShift Container Platform 4.11 では、AgentServiceConfig カスタムリソースの一部として imageStorage オプションが導入されています。このオプションは、ユーザーが Image サービスで使用するための Persistent Storage Claim (永続ボリューム要求、PVC) の詳細を指定できるようにすることで、アプリケーションのパフォーマンスが向上します。

ClusterImageSet カスタムリソースの releaseImage パラメーターは、オペレーティングシステムのイメージバージョン ID をサポートするようになりました。検出 ISO は、オペレーティングシステムイメージのバージョンを releaseImage として作成するか、指定したバージョンが利用できない場合は最新バージョンに基づいています。

AgentServiceConfig カスタムリソース (CR) の openshiftVersion パラメーターは、"x.y" (major.minor) または "x.y.z"(major.minor.patch) 形式のいずれかをサポートするようになりました。

OpenShift Container Platform 4.11 では、OpenShift Container Platform Ingress Operator によって管理されるルーターデプロイメントの kubelet の liveness、readiness、および startup プローブのタイムアウト値を設定する機能が導入されました。大きなタイムアウト値を設定する機能を使用すると、短いデフォルトのタイムアウトである 1 秒によって発生する不要な再起動のリスクが軽減されます。

詳細は、Configuring Ingress Controller (router) Liveness, Readiness, and Startup probes を参照してください。

パフォーマンスプロファイルの offlined フィールドに CPU を指定して、Node Tuning Operator による電力消費を減らすことができます。詳細は、Reducing power consumption by taking CPUs offline を参照してください。

OpenShift Container Platform 4.11 では、Node Observability Operator がテクノロジープレビューとして導入されます。

Node Observability Operator は以下の機能を提供します。

詳細は、Requesting CRI-O and Kubelet profiling data using the Node Observability Operator を参照してください。

以前のバージョンの OpenShift Container Platform では、Performance Addon Operator はアプリケーションの自動低レイテンシーパフォーマンスチューニングを提供していました。OpenShift Container Platform 4.11 では、これらの機能は Node Tuning Operator の一部です。Node Tuning Operator は、OpenShift Container Platform 4.11 の標準インストールの一部です。OpenShift Container Platform 4.11 にアップグレードする場合、Node Tuning Operator は起動時に Performance Addon Operator およびすべての関連アーティファクトを削除します。

詳細は、Node Tuning Operator を参照してください。

以前のバージョンの OpenShift Container Platform では、低レイテンシーのチューニングに関するドキュメントに Performance Addon Operator への参照が含まれていました。Node Tuning Operator が低レイテンシーチューニングを提供するようになったため、ドキュメントのタイトルが "Performance Addon Operator for low latency nodes" から "Low latency tuning" に変更され、それに応じてこのドキュメントへの複数の相互参照が更新されました。詳細は、Low latency tuning を参照してください。

スポーククラスターがツリー外ドライバーのサポートを必要とするハブアンドスポークデプロイメントの場合、ハブクラスターにデプロイされた Special Resource Operator (SRO) を使用して、必要なカーネルモジュールの 1 つ以上のマネージドクラスターへのデプロイメントを管理できます。これは Red Hat Advanced Cluster Management (RHACM) を使用し、Node Feature Discovery (NFD) を使用する必要がなくなりました。詳細は、Building and running the simple-kmod SpecialResource for a hub-and-spoke topology を参照してください。

特別なリソースが管理されているクラスターをアップグレードする場合、アップグレード前のカスタムリソースを実行して、カーネルの更新をサポートする新しいドライバーコンテナーが存在することを確認できます。これにより、マネージドの特殊リソースが中断される可能性を回避できます。この機能のドキュメントは現在利用できず、後日リリースされる予定です。

Special Resource Operator (SRO) には、トラブルシューティングのためのより詳細なメッセージを含む一貫したログ出力形式が含まれています。

この更新の前は、SRO は切断された環境でのレジストリーへの接続をサポートしていませんでした。このリリースは、ドライバーコンテナーが OpenShift Container Platform クラスター外のレジストリーでホストされている切断された環境のサポートを提供します。

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

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

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

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

Pod セキュリティーアドミッション が OpenShift Container Platform で有効になりました。

Pod アドミッションは、Pod セキュリティーとセキュリティーコンテキスト制約 (SCC) アドミッションの両方によって実施されます。Pod セキュリティーアドミッションは、privileged 適用と restricted 監査ログと API 警告により、グローバルに実行されます。

コントローラーは、ユーザーが作成した namespace 内のサービスアカウントの SCC 関連のパーミッション を監視し、これらの namespace に Pod セキュリティーアドミッション の warn および audit ラベルを自動的に付けます。

restricted Pod セキュリティープロファイルに従ってワークロード セキュリティーを向上させるために、このリリースでは、新しい Pod セキュリティーアドミッションコントロールに従って Pod セキュリティーを実施する SCC が導入されています。これらの SCC は次のとおりです。

これらは、同様の名前の古い SCC に対応していますが、以下のような拡張機能があります。

OpenShift Container Platform 4.11 では、restricted SCC ではなく、restricted-v2 SCC がデフォルトでユーザーに付与される SCC になりました。新規クラスターでは、restricted-v2 SCC が restricted SCC の代わりに、認証済みのユーザーに使用されます。アクセスが明示的に付与されない限り、restricted SCC は新規クラスターのユーザーが利用できなくなります。OpenShift Container Platform 4.10 以前でインストールされたクラスターでは認証済みのユーザーはすべて、OpenShift Container Platform 4.11 のアップグレード時に restricted SCC を使用します。こうすることで、OpenShift Container Platform のデフォルトのセキュリティーパーミッションを secure-by-default のままにし、アップグレードされたクラスターのパーミッションを以前の状態に保つ一方で、アップストリームの Kubernetes プロジェクトからの Pod セキュリティー受付および Pod セキュリティー基準に合わせます。

ほとんどの namespace の同期を有効にし、すべての namespace の同期を無効にすることができます。

このリリースでは、openshift- が接頭辞として付けられた namespace には、制限付き実施はありません。このような namespace の制限付き実施は、今後のリリースに含まれる予定です。

詳細は、 Understanding and managing pod security admission を参照してください。