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

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

このリリースにより、RHCOS を Small Computer Systems Interface (iSCSI) ブートデバイスにインストールできるようになりました。iSCSI のマルチパスもサポートされています。詳細は、iSCSI ブートデバイスへの RHCOS の手動インストール および iBFT を使用した iSCSI ブートデバイスへの RHCOS のインストール を参照してください。

このリリースでは、RHCOS を Intel® VROC RAID デバイスにインストールできるようになりました。Intel® VROC デバイスへの RAID の設定は、Configuring an Intel® Virtual RAID on CPU (VROC) data volume を参照してください。

OpenShift Container Platform 4.16 では、インストールプログラムは Terraform の代わりに Cluster API を使用して、Amazon Web Services へのインストール中にクラスターインフラストラクチャーをプロビジョニングします。この変更の結果、いくつかの追加の権限が必要になります。詳細は、IAM ユーザーに必要な AWS パーミッション を参照し てください。

さらに、コントロールプレーンおよびコンピュートマシンへの SSH アクセスはマシンネットワークに公開されなくなり、コントロールプレーンとコンピュートマシンに関連付けられたセキュリティーグループに制限されます。

OpenShift Container Platform 4.16 では、インストールプログラムは、VMware vSphere へのインストール中にクラスターインフラストラクチャーをプロビジョニングするために、Terraform ではなく Cluster API を使用します。

OpenShift Container Platform 4.16 では、インストールプログラムは、Nutanix へのインストール中にクラスターインフラストラクチャーをプロビジョニングするために、Terraform ではなく Cluster API を使用します。

OpenShift Container Platform 4.16 では、インストールプログラムは、GCP へのインストール中にクラスターインフラストラクチャーをプロビジョニングするために、Terraform ではなく Cluster API を使用します。この機能は、OpenShift Container Platform 4.16 でテクノロジープレビューとして利用できます。テクノロジープレビュー機能を有効にするには、インストール前に install-config.yaml ファイルで featureSet: TechPreviewNoUpgrade パラメーターを設定します。別の方法として、インストールする前に以下のスタンザを install-config.yaml ファイルに追加して、他のテクノロジープレビュー機能なしで Cluster API インストールを有効にすることもできます。

featureSet: CustomNoUpgrade
featureGates:
- ClusterAPIInstall=true

詳細は、任意の設定パラメーター を参照してください。

Ingress 機能は設定可能なクラスター機能となり、Red Hat HyperShift ではオプションになりました。これは設定不可能であり、スタンドアロンの OpenShift Container Platform では常に有効になっています。

このリリースにより、OpenShift Container Platform インストールプログラムは、Alibaba Cloud プラットフォームでの installer-provisioned installation をサポートしなくなりました。現在テクノロジープレビュー機能である Assisted Installer を使用して、Alibaba Cloud にクラスターをインストールできます。詳細は、Alibaba クラウドへのインストール を参照してください。

OpenShift Container Platform 4.16 では、インストール中にクラウドコントローラーマネージャー機能を無効にできます。詳細は、クラウドコントローラーマネージャー機能 を参照してください。

この更新により、FIPS 対応クラスターをインストールする場合、FIPS モードで動作するように設定された RHEL 9 コンピューターからインストールプログラムを実行し、インストールプログラムの FIPS 対応バージョンを使用する必要があります。詳細は、FIPS 暗号のサポート を 参照してください。

OpenShift Container Platform 4.16 では、VMware vSphere クラスターによってプロビジョニングされた仮想マシン (VM) に最大 10 個のタグを追加できます。これらのタグは、クラスターが廃止された際にインストールプログラムが関連する仮想マシンを識別して削除するために使用するクラスター固有の一意のタグに加え、使用されます。

クラスターの作成時に、install-config.yaml ファイルで VMware vSphere 仮想マシンのタグを定義できます。詳細は、インストーラーでプロビジョニングされる VMware vSphere クラスターについての install-config.yaml ファイルの例 を参照してください。

マシンセットを使用して、既存のクラスター上のコンピュートまたはコントロールプレーンマシンのタグを定義できます。詳細は、コンピュート または コントロールプレーン のマシンセットの「マシンセットを使用してマシンにタグを追加する」を参照してください。

OpenShift Container Platform 4.16 は、いくつかの 非推奨の API が削除された Kubernetes 1.29 を使用します。

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

すべての OpenShift Container Platform 4.15 クラスターは、OpenShift Container Platform 4.16 に更新する前に、この管理者の承認が必要です。

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

このリリースにより、クラスターの作成時に --skip-password-print フラグを使用することで、インストール後に kubeadmin パスワードがコンソールに表示されないようにすることができます。パスワードは、auth ディレクトリーで引き続きアクセス可能です。

このリリースにより、OpenShift ベースの Appliance Builder がテクノロジープレビュー機能として利用可能になりました。Appliance Builder を使用すると、自己完結型の OpenShift Container Platform クラスターのインストールが可能になります。つまり、インターネット接続や外部レジストリーに依存しません。これは、Agent-based Installer を含むディスクイメージをビルドするコンテナーベースのユーティリティーであり、これを使用して複数の OpenShift Container Platform クラスターをインストールできます。

詳細は、OpenShift ベースの Appliance Builder ユーザーガイド を参照してください。

このリリースにより、publicIpv4Pool フィールドを使用して Elastic IP アドレス (EIP) を割り当てることで、Amazon Web Services (AWS) にインストールするときに、bring your own public IPv4 addresses (BYOIP) 機能を有効化できるようになりました。BYOIP を有効にするには 必要な権限 が必要です。詳細は、オプションの AWS 設定パラメーター を参照してください。

OpenShift Container Platform 4.16 は、サウジアラビアのダンマーム (me-central2) リージョンと南アフリカのヨハネスブルグ (africa-south1) リージョンの Google Cloud Platform (GCP) にデプロイできます。詳細は、サポートされている GCP リージョン を参照してください。

このリリースにより、GCP にクラスターをインストールするときに、GPU 対応の NVIDIA H100 マシンにコンピュートノードをデプロイできます。詳細については、テスト済みインスタンスタイプ for GCP および Google のドキュメント Accelerator で最適化されたマシンファミリー を参照してください。

このリリースにより、Multiarch Tuning Operator を使用して、マルチアーキテクチャークラスター上のワークロードを管理できます。この Operator は、マルチアーキテクチャークラスター、およびマルチアーキテクチャーコンピュート設定に移行しているシングルアーキテクチャークラスター内の運用エクスペリエンスを強化します。これは、アーキテクチャーを考慮したワークロードスケジューリングをサポートするために、ClusterPodPlacementConfig カスタムリソース (CR) を実装します。

詳細は、Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。

この機能は、64 ビット ARM コントロールプレーンマシンを備えたマルチアーキテクチャークラスターに 64 ビット x86 コンピュートマシンを追加するためのサポートを提供します。このリリースにより、64 ビット ARM コントロールプレーンマシンを使用し、すでに 64 ビット ARM コンピュートマシンが含まれているクラスターに、64 ビット x86 コンピュートマシンを追加できます。

この機能は、multi ペイロードを持つ Agent-based Installer クラスターのインストールをサポートします。multi ペイロードを持つ Agent-based Installer クラスターをインストールした後、異なるアーキテクチャーのコンピュートマシンをクラスターに追加できます。

このリリースにより、Web コンソールでフランス語とスペイン語がサポートされるようになりました。Web コンソールの言語は、User Preferences ページの Language リストから更新できます。

このリリースにより、Web コンソールで Patternfly 4 と React Router 5 が非推奨になりました。すべてのプラグインはできるだけ早く Patternfly 5 および React Router 6 に移行する必要があります。

このリリースでは、Web コンソールの Administrator パースペクティブに次の更新が導入されています。

このリリースでは、Web コンソールの 開発者 パースペクティブに次の更新が導入されています。

OpenShift Container Platform の oc-mirror プラグイン v2 には、Operator イメージやその他の OpenShift Container Platform コンテンツのミラーリングプロセスを改善する新しい機能が含まれています。

以下は、oc-mirror プラグイン v2 の主な機能拡張と機能です。

oc-mirror OpenShift CLI (oc) プラグインは、必要なすべての OpenShift Container Platform コンテンツとその他のイメージをミラーレジストリーにミラーリングするために使用され、切断されたクラスターのメンテナンスを簡素化します。

以前は、oc adm upgrade コマンドがクラスター更新のステータスに関して提供する情報は、限定されていました。このリリースでは、oc adm upgrade status コマンドが追加されました。このコマンドは、oc adm upgrade コマンドからステータス情報を分離し、コントロールプレーンのステータスやワーカーノードの更新など、クラスターの更新に関する特定の情報を提供します。

このリリースにより、短縮名を使用してリソースをクエリーする場合、クラスター内に同じ短縮名を持つカスタムリソース定義 (CRD) が複数存在すると、OpenShift CLI (oc) から警告が返されます。

Warning: short name "ex" could also match lower priority resource examples.test.com

このリリースにより、oc delete コマンドに新しい --interactive フラグが導入されました。--interactive フラグが true に設定されている場合、ユーザーが削除を確認した場合にのみリソースが削除されます。このフラグはテクノロジープレビュー機能として利用できます。

このリリースにより、Microsoft Entra Workload ID を有効にして、既存の Microsoft Azure OpenShift Container Platform クラスターで短期認証情報を使用できるようになりました。この機能は、OpenShift Container Platform バージョン 4.14 および 4.15 でもサポートされるようになりました。詳細は、トークンベースの認証の有効化 を参照してください。

OpenShift Container Platform がサポートされる唯一のネットワークプラグインとして OVN-Kubernetes に移行する一環として、OpenShift Container Platform 4.16 以降では、クラスターが OpenShift SDN ネットワークプラグインを使用する場合、OVN-Kubernetes に移行せずに OpenShift Container Platform の今後のメジャーバージョンにアップグレードすることはできません。OVN-Kubernetes への移行の詳細は、OpenShift SDN ネットワークプラグインからの移行 を参照してください。

アップグレードを試みると、Cluster Network Operator は以下のステータスを報告します。

- lastTransitionTime: "2024-04-11T05:54:37Z"
  message: Cluster is configured with OpenShiftSDN, which is not supported in the
    next version. Please follow the documented steps to migrate from OpenShiftSDN
    to OVN-Kubernetes in order to be able to upgrade. https://docs.openshift.com/container-platform/4.16/networking/ovn_kubernetes_network_provider/migrate-from-openshift-sdn.html
  reason: OpenShiftSDNConfigured
  status: "False"
  type: Upgradeable

デュアル Intel E810 Westport Channel ネットワークインターフェイスコントローラー (NIC) のグランドマスタークロック (T-GM) として linuxptp サービスを設定する機能が、OpenShift Container Platform で一般提供されました。ホストシステムクロックは、Global Navigation Satellite Systems (GNSS) タイムソースに接続された NIC から同期されます。2 つ目の NIC は、GNSS に接続されている NIC によって提供される 1PPS タイミングの出力に同期されます。詳細は、linuxptp サービスをデュアル E810 Westport Channel NIC のグランドマスタークロックとして設定する を参照してください。

linuxptp サービス ptp4l および phc2sys を、デュアル PTP 境界クロック (T-BC) の高可用性 (HA) システムクロックとして設定できます。

詳細は、デュアル NIC Intel E810 PTP 境界クロック用の高可用性システムクロックとして linuxptp を設定する を参照してください。

クラスターコンポーネント間のネットワーク接続を定期的にテストするために、Cluster Network Operator (CNO) は network-check-source デプロイメントと network-check-target デーモンセットを作成します。OpenShift Container Platform 4.16 では、ノードセレクターを設定してノードを設定し、ソース Pod とターゲット Pod を実行してネットワーク接続を確認できます。詳細は、エンドポイントへの接続の確認 を参照してください。

このリリースにより、Microsoft Azure でホストされている OpenShift Container Platform クラスターの NSG で IP アドレスと範囲がより効率的に処理されるようになりました。その結果、allowedSourceRanges フィールドを使用する Microsoft Azure クラスター内のすべての Ingress コントローラーの Classless Inter-Domain Routings (CIDRs) の最大制限が、約 1000 から 4000 CIDR に増加しました。

このリリースにより、OpenShift SDN ネットワークプラグインから OVN-Kubernetes への移行が Nutanix プラットフォームでサポートされるようになりました。詳細は、OVN-Kubernetes ネットワークプラグインへの移行 を参照してください。

このリリースにより、OVN-Kubernetes は新しい DNSNameResolver カスタムリソースを使用して、Egress ファイアウォールルール内の DNS レコードを追跡します。これはテクノロジープレビューとして利用できます。このカスタムリソースは、ワイルドカード DNS 名と通常の DNS 名の両方の使用をサポートし、変更に関連付けられた IP アドレスに関係なく DNS 名にアクセスできるようにします。

詳細は、DNS 解決の改善とワイルドカードドメイン名の解決 を参照してください。

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

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

OpenShift Container Platform 4.16 以降、SR-IOV Network Operator は SriovOperatorConfig カスタムリソース (CR) を自動的に作成しなくなりました。SR-IOV Network Operator の設定 で説明されている手順を使用して、SriovOperatorConfig CR を作成します。

このリリースにより、QinQ support とも呼ばれる 802.1Q-in-802.1Q が導入されました。QinQ は 2 番目の VLAN タグを導入します。ここで、サービスプロバイダーは外部タグを自社用に指定して柔軟性を提供し、内部タグは顧客の VLAN 専用のままになります。パケット内に 2 つの VLAN タグが存在する場合、外側の VLAN タグは 802.1Q または 802.1ad のいずれかになります。内部 VLAN タグは常に 802.1Q である必要があります。

詳細は、SR-IOV 対応ワークロードに対する QinQ サポートの設定 を参照してください。

このリリースにより、ベアメタル、VMware vSphere、Red Hat OpenStack Platform (RHOSP)、Nutanix などのオンプレミスインフラストラクチャー上で OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりにユーザー管理のロードバランサーを使用できるようになりました。この設定では、クラスターの install-config.yaml ファイルで loadBalancer.type: UserManaged を指定する必要があります。

ベアメタルインフラストラクチャーでのこの機能の詳細は、OpenShift インストール環境 のセットアップ の ユーザー管理のロードバランサーのサービス を参照し てください。

このリリースにより、クラスター内に iptables ルールを使用する Pod がある場合、将来的な非推奨を警告する以下のイベントメッセージが表示されます。

This pod appears to have created one or more iptables rules. IPTables is deprecated and will no longer be available in RHEL 10 and later. You should consider migrating to another API such as nftables or eBPF.

詳細は、nftables の使用 を参照してください。サードパーティーのソフトウェアを実行している場合は、ベンダーに問い合わせて、nftables ベースのバージョンがすぐに利用可能になるか確認してください。

このリリースでは、OpenShift Container Platform サービスの Ingress ネットワークフローを表示できます。この情報を使用して、ネットワークの Ingress トラフィックを管理し、ネットワークセキュリティーを向上させることができます。

詳細は、OpenShift Container Platform ネットワークフローマトリックス を参照してください。

このリリースにより、クラスターインフラストラクチャーにパッチを適用することで、既存のデュアルスタック設定のクラスターに API および Ingress サービス用の IPv6 仮想 IP (VIP) を追加できます。

クラスターを OpenShift Container Platform 4.16 にすでにアップグレードしていて、シングルスタッククラスターネットワークをデュアルスタッククラスターネットワークに変換する必要がある場合は、YAML 設定パッチファイルでクラスターに対して以下を指定する必要があります。

詳細は、IPv4/IPv6 デュアルスタックネットワークへの変換 の デュアルスタッククラスターネットワークへの変換 を参照してください。

このリリースにより、Kubernetes に準拠した方法で FRR API のサブセットを公開する Kubernetes ベースの DaemonSet である FRR-K8s が導入されました。クラスター管理者は、FRRConfiguration カスタムリソース (CR) を使用して、MetalLB Operator がバックエンドとして FRR-K8s デーモンセットを使用するように設定できます。これを利用して、ルートの受信などの FRR サービスを操作できます。

詳細は、MetalLB と FRR-K8s のインテグレーションの設定 を参照してください。

このリリースでは、ルート API の .spec.tls.externalCertificate フィールドを利用して、サードパーティーの証明書管理ソリューションで OpenShift Container Platform ルートを設定できるようになりました。これにより、シークレットを介して外部で管理されている TLS 証明書を参照できるようになり、手動による証明書管理が不要になり、プロセスが合理化されます。外部で管理される証明書を使用することで、エラーが削減され、証明書の更新プロセスがスムーズになり、OpenShift ルーターが更新された証明書を迅速に提供できるようになります。詳細は、外部管理証明書を使用したルートの作成 を参照してください。

この機能では、AdminNetworkPolicy (ANP) と BaselineAdminNetworkPolicy (BANP) という 2 つの新しい API が提供されます。namespace が作成される前に、クラスター管理者は ANP と BANP を使用して、クラスター全体にクラスタースコープのネットワークポリシーと保護を適用できます。ANP はクラスタースコープであるため、各 namespace でネットワークポリシーを複製することなく、ネットワークのセキュリティーを大規模に管理できるソリューションを管理者に提供します。

詳細は、IPv4/IPv6 デュアルスタックネットワークへの変換 の デュアルスタッククラスターネットワークへの変換 を参照してください。

以前は、OpenShift SDN から OVN-Kubernetes に移行する場合、利用できるオプションは オフライン 移行方式のみでした。このプロセスにはダウンタイムが含まれており、その間はクラスターにアクセスできませんでした。

このリリースでは、制限付きの ライブ マイグレーションメソッドが導入されています。限定的なライブマイグレーション方式は、OpenShift SDN ネットワークプラグインとそのネットワーク設定、接続、および関連リソースを、サービスを中断することなく OVN-Kubernetes ネットワークプラグインに移行するプロセスです。OpenShift Container Platform で利用できます。Hosted Control Plane デプロイメントタイプでは使用できません。この移行方式は、継続的なサービス可用性を必要とするデプロイメントタイプにとって有用で、以下のような利点があります。

OVN-Kubernetes への移行は、一方向のプロセスとなるよう意図されています。

詳細は、OVN-Kubernetes ネットワークプラグインへの制限付きライブマイグレーションの概要 を参照してください。

以前は、同じ CIDR 範囲を 2 回設定できず、Whereabouts CNI プラグインがこれらの範囲から IP アドレスを個別に割り当てることができませんでした。この制限により、異なるグループが重複している CIDR 範囲を選択する必要があるマルチテナント環境で問題が発生しました。

このリリースでは、Whereabouts CNI プラグインが、network_name パラメーターを含めることで重複する IP アドレス範囲をサポートします。管理者は、network_name パラメーターを使用して、個別の NetworkAttachmentDefinitions 内で同じ CIDR 範囲を複数回設定できます。これにより、各範囲に独立した IP アドレスの割り当てが可能になります。

この機能には、強化された namespace の処理、IPPool カスタムリソース (CR) の適切な namespace への保存、および Multus によって許可された場合の namespace 間のサポートも含まれています。これらの改善により、マルチテナント環境での柔軟性と管理機能が向上します。

この機能の詳細は、Whereabouts を使用した動的 IP アドレス割り当ての設定 を参照してください。

OVN-Kubernetes ネットワークプラグインを使用する場合は、transit、join、および masquerade サブネットを設定できます。transit、join、および masquerade サブネットは、クラスターのインストール中またはインストール後に設定できます。サブネットのデフォルトは以下のとおりです。

これらの設定フィールドの詳細は、Cluster Network Operator 設定オブジェクト を参照してください。既存のクラスターでの transit サブネットと join サブネットの設定に関する詳細は、OVN-Kubernetes 内部 IP アドレスサブネットの設定を参照してください。

Telemetry および Insights Operator は IPsec 接続の Telemetry を収集します。詳細は、Telemetry によって収集されるデータの表示 を参照してください。

Secrets Store CSI Driver Operator を使用して、HashiCorp Vault から OpenShift Container Platform の Container Storage Interface (CSI) ボリュームにシークレットをマウントできるようになりました。Secrets Store CSI Driver Operator は、テクノロジープレビュー機能として利用できます。

利用可能なシークレットストアプロバイダーの完全なリストは、シークレットストアプロバイダー を参照してください。

Secrets Store CSI Driver Operator を使用して HashiCorp Vault からシークレットをマウントする方法の詳細は、HashiCorp Vault からのシークレットのマウント を参照してください。

OpenShift Container Platform 4.16 では、テクノロジープレビュー機能として、Microsoft Azure File Container Storage Interface (CSI) Driver Operator のボリュームのクローン作成機能が導入されています。ボリュームのクローン作成により、既存の永続ボリューム (PV) が複製され、OpenShift Container Platform におけるデータ損失を防ぎます。標準ボリュームを使用する場合と同じように、ボリュームクローンを使用することもできます。

詳細は、Azure File CSI Driver Operator および CSI ボリュームのクローン作成 を参照してください。

Node Expansion Secret 機能を使用すると、ボリュームへのアクセスにノード拡張操作を実行するためのシークレット (たとえば、Storage Area Network (SAN) ファブリックにアクセスするための認証情報) が必要な場合でも、クラスターはマウントされたボリュームのストレージを拡張できます。OpenShift Container Platform 4.16 では、これは一般提供機能としてサポートされています。

VMware vSphere Container Storage Interface (CSI) のスナップショットのデフォルトの最大数は、ボリュームあたり 3 です。OpenShift Container Platform 4.16 では、スナップショットの最大数をボリュームあたり最大 32 に変更できるようになりました。また、vSAN および仮想ボリュームデータストアのスナップショットの最大数を細かく制御することもできます。OpenShift Container Platform 4.16 では、これは一般提供機能としてサポートされています。

詳細は、vSphere のスナップショットの最大数の変更 を参照してください。

OpenShift Container Platform 4.16 では、永続ボリューム (PV) が別のフェーズ (pv.Status.Phase) に移行するたびに更新されるタイムスタンプを持つ新しいパラメーター LastPhaseTransitionTime が導入されました。この機能はテクノロジープレビューのステータスでリリースされています。

OpenShift Container Platform は、Common Internet File System (CIFS) ダイアレクト/Server Message Block (SMB) プロトコル用の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。このドライバーを管理する CIFS/SMB CSI Driver Operator は、テクノロジープレビューのステータスです。

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

OpenShift Container Platform 4.14 では、永続ボリューム (PV) と永続ボリューム要求 (PVC) 用のテクニカルプレビューステータスの新しいアクセスモードである ReadWriteOncePod (RWOP) が導入されました。既存の ReadWriteOnce アクセスモードでは、PV または PVC をシングルノード上の複数の Pod で使用できますが、RWOP はシングルノード上の単一 Pod でのみ使用できます。ドライバーにより有効化されている場合、RWOP は PodSpec またはコンテナーに設定されている SELinux コンテキストマウントを使用します。これにより、ドライバーは正しい SELinux ラベルを使用してボリュームを直接マウントできます。これにより、ボリュームを再帰的に再ラベルする必要がなくなり、Pod の起動が大幅に高速化されます。

OpenShift Container Platform 4.16 では、この機能が一般提供されています。

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

マルチゾーンクラスターでの VMware vSphere Container Storage Interface (CSI) ボリュームのプロビジョニングと使用をサポートするには、デプロイメントが CSI ドライバーによって課される特定の要件に一致している必要があります。これらの要件は 3.1.0 以降に変更されており、OpenShift Container Platform 4.16 は古いタグ付け方法と新しいタグ付け方法の両方を受け入れますが、VMware vSphere は古いタグ付け方法を無効な設定と見なすため、新しいタグ付け方法を使用する必要があります。問題を防ぐために、古いタグ付け方法は使用しないでください。

詳細は、vSphere CSI トポロジーの要件 を参照してください。

この機能は、シックプロビジョニングされたストレージの設定をサポートします。LVMCluster カスタムリソース (CR) で deviceClasses.thinPoolConfig フィールドを除外すると、論理ボリュームはシックプロビジョニングされます。シックプロビジョニングされたストレージを使用する場合、次の制限があります。

LVMCluster CR の設定に関する詳細は、LVMCluster カスタムリソースについて を参照してください。

この更新により、LVMCluster カスタムリソース (CR) で deviceSelector フィールドを設定していない場合に、新しい警告メッセージが表示されるようになります。

LVMCluster CR は、deviceSelector フィールドが設定されているかを示す新しいフィールド deviceDiscoveryPolicy をサポートします。deviceSelector フィールドを設定しない場合、LVM Storage は deviceDiscoveryPolicy フィールドを RuntimeDynamic に自動的に設定します。それ以外の場合、deviceDiscoveryPolicy フィールドは Preconfigured に設定されます。

LMVCluster CR から deviceSelector フィールドを除外することは推奨されません。deviceSelector フィールドを設定しない場合の制限の詳細は、ボリュームグループへのデバイスの追加について を参照してください。

この機能は、暗号化されたデバイスをボリュームグループに追加するためのサポートを提供します。OpenShift Container Platform のインストール中に、クラスターノードでディスク暗号化を有効にすることができます。デバイスを暗号化した後、LVMCluster カスタムリソースの deviceSelector フィールドで LUKS 暗号化デバイスへのパスを指定できます。ディスク暗号化の詳細については、ディスク暗号化 について および ディスク暗号化 と ミラーリングの設定 を参照してください。

ボリュームグループへのデバイスの追加に関する詳細は、ボリュームグループへのデバイスの追加について を参照してください。

Operator Lifecycle Manager (OLM) 1.0 の以前のテクノロジープレビューフェーズでは、Operator Controller コンポーネントによって operator.operators.operatorframework.io として提供される新しい Operator API が導入されました。OpenShift Container Platform 4.16 では、この API の名前は ClusterExtension に変更され、OLM 1.0 のこのテクノロジープレビューフェーズでは clusterextension.olm.operatorframework.io として提供されます。

この API は、ユーザー向け API を単一のオブジェクトに統合することで、registry+v1 バンドル形式を介した Operator を含むインストール済みエクステンションの管理を効率化します。ClusterExtension へ名前を変更することで、以下に対応します。

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

このリリースにより、OLM 1.0 はインストールされたクラスターエクステンションに対して、次のステータス条件メッセージを表示します。

インストールされたクラスター拡張機能のアップグレードエッジを決定する場合、Operator Lifecycle Manager (OLM) 1.0 は、OpenShift Container Platform 4.16 以降、従来の OLM セマンティックをサポートします。このサポートは、replaces、skips、skipRange ディレクティブなど、従来の OLM の動作に従いますが、いくつかの違いがあります。

従来の OLM セマンティックをサポートすることで、OLM 1.0 はカタログからのアップグレードグラフを正確に認識するようになりました。

詳細は、アップグレード制約セマンティクス を参照してください。

このリリースにより、未使用のレンダリングされたマシン設定をガベージコレクションできるようになりました。oc adm prune renderedmachineconfigs コマンドを使用すると、未使用のレンダリングされたマシン設定を表示し、削除するものを決定してから、不要になったレンダリングされたマシン設定を一括削除できます。マシン設定が多すぎると、マシン設定の操作が混乱する可能性があり、ディスク容量やパフォーマンスの問題の原因にもなります。詳細は、未使用のレンダリングされたマシン設定の管理 を参照してください。

デフォルトでは、MachineConfig オブジェクトのパラメーターに特定の変更を加えると、Machine Config Operator (MCO) は、そのマシン設定に関連付けられているノードをドレインして再起動します。ただし、ワークロードの中断をほとんどまたはまったく必要としない Ignition 設定オブジェクトの一連の変更を定義するノード中断ポリシーを MCO namespace に作成できます。詳細は、ノード中断ポリシーを使用してマシン設定の変更による中断を最小限に抑える を参照してください。

Red Hat Enterprise Linux CoreOS (RHCOS) イメージのレイヤー化により、テクノロジープレビュー機能として、カスタムレイヤー化イメージをクラスター内に直接自動的にビルドできるようになりました。以前は、クラスターの外部でカスタムレイヤーイメージをビルドし、そのイメージをクラスターにプルする必要がありました。イメージレイヤー機能を使用して、ベースイメージに追加のイメージをレイヤー化することで、ベース RHCOS イメージの機能を拡張できます。詳細は、RHCOS イメージのレイヤー化 を参照してください。

デフォルトでは、MCO は Red Hat Enterprise Linux CoreOS (RHCOS) ノードを起動するために使用するブートイメージを削除しません。その結果、クラスター内のブートイメージはクラスターとともに更新されません。クラスターを更新するたびにブートイメージも更新するようにクラスターを設定できるようになりました。詳細は、ブートイメージの更新 を参照してください。

このリリースにより、クラスターオートスケーラーは LeastWaste、Priority、および Random エクスパンダーを使用できるようになりました。これらのエクスパンダーを設定して、クラスターをスケーリングするときにマシンセットの選択に影響を与えることができます。詳細は、クラスターオートスケーラーの設定 を参照してください。

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

このリリースでは、コントロールプレーンマシンセットの vSphere 障害ドメインを定義する、以前はテクノロジープレビューだった機能が一般提供されました。詳細は、VMware vSphere のコントロールプレーン設定オプション を参照してください。

Vertical Pod Autoscaler Operator (VPA) は、レコメンダー、アップデーター、アドミッションコントローラーの 3 つのコンポーネントで構成されます。Operator と各コンポーネントには、コントロールプレーンノードの VPA namespace に独自の Pod があります。VPA Operator とコンポーネント Pod をインフラストラクチャーノードまたはワーカーノードに移動できます。詳細は、Vertical Pod Autoscaler Operator コンポーネントの移動 を参照してください。

このリリースにより、oc adm must-gather コマンドによって以下の追加情報が収集されます。

これらの追加は、特定のバージョンの oc の使用から生じる可能性のある問題を特定するのに役立ちます。oc adm must-gather コマンドは、使用されたイメージと、must-gather ログに収集できなかったデータがあるかどうかもリスト表示します。

詳細は、must-gather ツールについて を参照してください。

OpenShift Container Platform 4.16 以降では、ベアメタルノードの BareMetalHost リソースでベースボード管理コントローラー (BMC) アドレスを編集できます。ノードは Provisioned、ExternallyProvisioned、Registering、または Available 状態である必要があります。BareMetalHost リソースの BMC アドレスを編集しても、ノードのプロビジョニングは解除されません。詳細は、BareMetalHost リソースの編集 を参照してください。

OpenShift Container Platform 4.16 以降では、DataImage リソースを使用して、プロビジョニングされたノードに汎用のブータブルでない ISO 仮想メディアイメージをアタッチできます。リソースを適用すると、次回の再起動時にオペレーティングシステムから ISO イメージにアクセスできるようになります。この機能をサポートするために、ノードが Redfish またはそれから派生したドライバーを使用している。ノードが Provisioned または ExternallyProvisioned 状態である。詳細は、ブータブルでない ISO をベアメタルノードにアタッチする を参照してください。

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

Metrics Server コンポーネントが一般提供され、非推奨の Prometheus Adapter の代わりに自動的にインストールされるようになりました。Metrics Server はリソースメトリクスを収集し、他のツールや API が使用できるように metrics.k8s.io Metrics API サービスで公開します。これにより、コアプラットフォーム Prometheus スタックがこの機能の処理から解放されます。詳細は、Cluster Monitoring Operator の config map API 参照のMetricsServerConfig を参照してください。

このリリースでは、openshift-monitoring プロジェクトの Alertmanager API への読み取り専用アクセスを許可する新しい monitoring-alertmanager-view ロールが導入されました。

Vertical Pod Autoscaler (VPA) メトリクスが、kube-state-metrics エージェントを通じて利用可能になりました。VPA メトリクスは、非推奨後にネイティブサポートアップストリームから削除された前と同様の説明形式に従います。

このリリースでは、Prometheus、Alertmanager、Thanos Ruler の前のプロキシーサービスが OAuth から kube-rbac-proxy に更新されました。この変更は、適切なロールとクラスターロールを持たずにこれらの API エンドポイントにアクセスするサービスアカウントとユーザーに影響する可能性があります。

このリリースでは、Prometheus がターゲットをスクレイピングするときに、同じ値であっても重複したサンプルがサイレントに無視されなくなりました。最初のサンプルが受け入れられ、prometheus_target_scrapes_sample_duplicate_timestamp_total カウンターが増加し、これにより、PrometheusDuplicateTimestamps アラートがトリガーされる可能性があります。

このリリースにより、CPU 制限と CPU リクエストの両方を含むワークロードアノテーションを使用してデプロイされたプラットフォーム Pod では、CPU 制限が正確に計算され、特定の Pod の CPU クォータとして適用されます。以前のリリースでは、ワークロードパーティショニングされた Pod に CPU 制限とリクエストの両方が設定されていた場合、それらは Webhook によって無視されていました。Pod はワークロードパーティショニングのメリットを享受できず、特定のコアにロックダウンされませんでした。この更新により、リクエストと制限が Webhook によって正しく解釈されるようになりました。

詳細は、ワークロードのパーティショニング を参照してください。

OpenShift Container Platform 4.16 以降では、パフォーマンスプロファイルが存在する場合でも、すべての新しいデプロイメントで、Control Groups バージョン 2 (cgroup v2) (cgroup2 または cgroupsv2 とも呼ばれる) がデフォルトで有効になっています。

OpenShift Container Platform 4.14 以降、cgroups v2 がデフォルトになりましたが、パフォーマンスプロファイル機能では cgroups v1 を使用する必要がありました。この問題は解決されています。

cgroup v1 は、最初のインストール日が OpenShift Container Platform 4.16 より前のパフォーマンスプロファイルを持つアップグレードされたクラスターで引き続き使用されます。node.config オブジェクトの cgroupMode フィールドを v1 に変更することで、cgroup v1 を現在のバージョンで引き続き使用できます。

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

このリリースにより、etcd のディスククォータを増やすことができます。これはテクノロジープレビューの機能です。詳細は、etcd のデータベースサイズの増加 を参照してください。

このリリースでは、Node Tuning Operator は、予約済みおよび分離されたコア CPU の PerformanceProfile で CPU 周波数の設定をサポートします。これは、特定の周波数を定義するために使用できるオプションの機能です。次に、Node Tuning Operator は Intel ハードウェアの intel_pstate CPUFreq ドライバーを有効にして、これらの周波数を設定します。FlexRAN のようなアプリケーションの周波数については、Intel の推奨事項に従う必要があります。このようなアプリケーションでは、デフォルトの CPU 周波数をデフォルトの実行周波数よりも低い値に設定する必要があります。

以前は、RAN DU プロファイルの場合、PerformanceProfile で realTime ワークロードヒントを true に設定すると、常に intel_pstate が無効になりました。このリリースでは、Node Tuning Operator は TuneD を使用して基盤となる Intel ハードウェアを検出し、プロセッサーの世代に基づいて intel_pstate カーネルパラメーターを適切に設定します。これにより、intel_pstate が realTime および highPowerConsumption ワークロードヒントから切り離されます。intel_pstate は、基盤となるプロセッサーの世代のみに依存するようになりました。

IceLake 以前のプロセッサーの場合、intel_pstate はデフォルトで非アクティブ化されていますが、IceLake 以降の世代のプロセッサーの場合は、intel_pstate は active に設定されています。

PolicyGenerator リソースと Red Hat Advanced Cluster Management (RHACM) を使用して、GitOps ZTP でマネージドクラスターのポリシーをデプロイできるようになりました。PolicyGenerator API は Open Cluster Management 標準の一部であり、PolicyGenTemplate API では不可能なリソースへパッチを適用する一般的な方法を提供します。PolicyGenTemplate リソースを使用してポリシーを管理およびデプロイすることは、今後の OpenShift Container Platform リリースでは非推奨になります。

詳細は、PolicyGenerator リソースを使用したマネージドクラスターポリシーの設定 を参照してください。

このリリースにより、Topology Aware Lifecycle Manager (TALM) は Red Hat Advanced Cluster Management (RHACM) 機能を使用して、マネージドクラスターの inform ポリシーを修復します。この機能拡張により、ポリシーの修復中に Operator が inform ポリシーの enforce コピーを作成する必要がなくなります。この機能拡張により、コピーされたポリシーによるハブクラスターのワークロードも軽減され、マネージドクラスターのポリシーの修復に必要な全体的な時間も短縮されます。

詳細は、マネージドクラスターのポリシーの更新 を参照してください。

このリリースにより、シングルノード OpenShift の GitOps ZTP の高速プロビジョニングを使用することで、クラスターのインストールにかかる時間を短縮できます。高速 ZTP は、ポリシーから派生した Day 2 マニフェストを早い段階で適用することで、インストールを高速化します。

GitOps ZTP の高速プロビジョニングの利点は、デプロイメントの規模に応じて増大します。完全なアクセラレーションは、クラスターの数が多いほど、より大きなメリットをもたらします。クラスターの数が少ない場合、インストール時間の短縮はそれほど大きくありません。

詳細は、GitOps ZTP の高速プロビジョニング を参照してください。

このリリースでは、Lifecycle Agent を使用して、シングルノード OpenShift クラスターの OpenShift Container Platform <4.y> から <4.y+2>、および <4.y.z> から <4.y.z+n> へのイメージベースアップグレードをオーケストレーションできます。Lifecycle Agent は、参加するクラスターの設定に一致する Open Container Initiative (OCI) イメージを生成します。OCI イメージに加えて、イメージベースアップグレードでは、ostree ライブラリーと OADP Operator を使用して、元のプラットフォームバージョンとターゲットプラットフォームバージョン間の移行時にアップグレードとサービスの停止時間を短縮します。

詳細は、シングルノード OpenShift クラスターのイメージベースのアップグレードについて を参照してください。

GitOps ZTP と Red Hat Advanced Cluster Management (RHACM) を使用してデプロイするマネージドシングルノード OpenShift クラスターで IPsec 暗号化を有効化できるようになりました。マネージドクラスターの外部にある Pod と IPsec エンドポイント間の外部トラフィックを暗号化できます。OVN-Kubernetes クラスターネットワーク上のノード間のすべての Pod 間ネットワークトラフィックが、Transport モードの IPsec で暗号化されます。

詳細は、GitOps ZTP および SiteConfig リソースを使用したシングルノード OpenShift クラスターの IPsec 暗号化の設定 を参照してください。

OpenShift Container Platform 4.16 の Hosted Control Plane が AWS プラットフォームで一般提供されました。