1.3. 新機能および機能拡張
今回のリリースでは、以下のコンポーネントおよび概念に関連する拡張機能が追加されました。
1.3.1. Red Hat Enterprise Linux CoreOS (RHCOS)
1.3.1.1. RHCOS が RHEL 9.4 を使用するように
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 リリースです。
1.3.1.2. iSCSI ブートボリュームのサポート
このリリースにより、RHCOS を Small Computer Systems Interface (iSCSI) ブートデバイスにインストールできるようになりました。iSCSI のマルチパスもサポートされています。詳細は、iSCSI ブートデバイスに RHCOS を手動でインストールする および iBFT を使用して iSCSI ブートデバイスに RHCOS をインストールする を参照してください。
1.3.1.3. Intel® Virtual RAID on CPU (VROC) を使用した RAID ストレージのサポート
このリリースでは、RHCOS を Intel® VROC RAID デバイスにインストールできるようになりました。Intel® VROC デバイスへの RAID の設定に関する詳細は、Intel® Virtual RAID on CPU (VROC) データボリュームの設定 を参照してください。
1.3.2. インストールおよび更新
1.3.2.1. AWS インストールで Terraform に代わって Cluster API を使用
OpenShift Container Platform 4.16 では、インストールプログラムは Terraform の代わりに Cluster API を使用して、Amazon Web Services へのインストール中にクラスターインフラストラクチャーをプロビジョニングします。この変更の結果、いくつかの追加の権限が必要になります。詳細は、IAM ユーザーに必要な AWS 権限 を参照してください。
さらに、コントロールプレーンおよびコンピュートマシンへの SSH アクセスはマシンネットワークに公開されなくなり、コントロールプレーンとコンピュートマシンに関連付けられたセキュリティーグループに制限されます。
Cluster API 実装を使用した Amazon Web Services (AWS) のクラスターをシークレットまたはトップシークレットリージョンにインストールすることは、OpenShift Container Platform 4.16 のリリース時点ではテストされていません。このドキュメントは、シークレットリージョンへのインストールがテストされたときに更新されます。Network Load Balancer のシークレットまたはトップシークレットリージョンのセキュリティーグループのサポートには既知の問題があり、インストールが失敗します。詳細は、OCPBUGS-33311 を参照してください。
1.3.2.2. VMware vSphere インストールで Terraform に代わって Cluster API を使用
OpenShift Container Platform 4.16 では、インストールプログラムは、VMware vSphere へのインストール中にクラスターインフラストラクチャーをプロビジョニングするために、Terraform ではなく Cluster API を使用します。
1.3.2.3. Nutanix インストールで Terraform に代わって Cluster API を使用
OpenShift Container Platform 4.16 では、インストールプログラムは、Nutanix へのインストール中にクラスターインフラストラクチャーをプロビジョニングするために、Terraform ではなく Cluster API を使用します。
1.3.2.4. Google Cloud Platform (GCP) インストールで 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
詳細は、オプションの設定パラメーター を参照してください。
1.3.2.5. Assisted Installer (テクノロジープレビュー) を使用した Alibaba Cloud へのインストール
このリリースにより、OpenShift Container Platform インストールプログラムは、Alibaba Cloud プラットフォームでの installer-provisioned installation をサポートしなくなりました。現在テクノロジープレビュー機能である Assisted Installer を使用して、Alibaba Cloud にクラスターをインストールできます。詳細は、Alibaba Cloud へのインストール を参照してください。
1.3.2.6. オプションのクラウドコントローラーマネージャークラスター機能
OpenShift Container Platform 4.16 では、インストール中にクラウドコントローラーマネージャー機能を無効にできます。詳細は、クラウドコントローラーマネージャーの機能 を参照してください。
1.3.2.7. OpenShift Container Platform 4.16 における FIPS インストール要件
この更新により、FIPS 対応クラスターをインストールする場合、FIPS モードで動作するように設定された RHEL 9 コンピューターからインストールプログラムを実行し、インストールプログラムの FIPS 対応バージョンを使用する必要があります。詳細は、FIPS 暗号化のサポート を参照してください。
1.3.2.8. VMware vSphere のオプションの追加タグ
OpenShift Container Platform 4.16 では、VMware vSphere クラスターによってプロビジョニングされた仮想マシン (VM) に最大 10 個のタグを追加できます。これらのタグは、クラスターが廃止された際にインストールプログラムが関連する仮想マシンを識別して削除するために使用するクラスター固有の一意のタグに加え、使用されます。
クラスターの作成時に、install-config.yaml
ファイルで VMware vSphere 仮想マシンのタグを定義できます。詳細は、installer-provisioned VMware vSphere クラスターの install-config.yaml
ファイルのサンプル を参照してください。
マシンセットを使用して、既存のクラスター上のコンピュートまたはコントロールプレーンマシンのタグを定義できます。詳細は、コンピュート または コントロールプレーン のマシンセットの「マシンセットを使用してマシンにタグを追加する」を参照してください。
1.3.2.9. OpenShift Container Platform 4.15 から 4.16 に更新する際に必要な管理者の承認
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 への更新の準備 を参照してください。
1.3.2.10. コンソールに表示されないように kubeadmin パスワードを保護する
このリリースにより、クラスターの作成時に --skip-password-print
フラグを使用することで、インストール後に kubeadmin
パスワードがコンソールに表示されないようにすることができます。パスワードは、auth
ディレクトリーで引き続きアクセス可能です。
1.3.2.11. OpenShift ベースの Appliance Builder (テクノロジープレビュー)
このリリースにより、OpenShift ベースの Appliance Builder がテクノロジープレビュー機能として利用可能になりました。Appliance Builder を使用すると、自己完結型の OpenShift Container Platform クラスターのインストールが可能になります。つまり、インターネット接続や外部レジストリーに依存しません。これは、Agent-based Installer を含むディスクイメージをビルドするコンテナーベースのユーティリティーであり、これを使用して複数の OpenShift Container Platform クラスターをインストールできます。
詳細は、OpenShift ベースの Appliance Builder ユーザーガイド を参照してください。
1.3.2.12. AWS へのインストールでの Bring your own IPv4 (BYOIP) 機能の有効化
このリリースにより、publicIpv4Pool
フィールドを使用して Elastic IP アドレス (EIP) を割り当てることで、Amazon Web Services (AWS) にインストールするときに、bring your own public IPv4 addresses (BYOIP) 機能を有効化できるようになりました。BYOIP を有効にするために 必要な権限 があることを確認する必要があります。詳細は、オプションの AWS 設定パラメーター を参照してください。
1.3.2.13. ダンマーム (サウジアラビア) とヨハネスブルグ (南アフリカ) のリージョンに GCP をデプロイする
OpenShift Container Platform 4.16 は、サウジアラビアのダンマーム (me-central2
) リージョンと南アフリカのヨハネスブルグ (africa-south1
) リージョンの Google Cloud Platform (GCP) にデプロイできます。詳細は、サポートされている GCP リージョン を参照してください。
1.3.2.14. Google Cloud Platform (GCP) 上の NVIDIA H100 インスタンスタイプへのインストール
このリリースにより、GCP にクラスターをインストールするときに、GPU 対応の NVIDIA H100 マシンにコンピュートノードをデプロイできます。詳細は、GCP のテスト済みインスタンスタイプ と、アクセラレーター最適化マシンファミリー に関する Google のドキュメントを参照してください。
1.3.3. インストール後の設定
1.3.3.1. Multiarch Tuning Operator (テクノロジープレビュー) を使用したマルチアーキテクチャークラスター上のワークロードの管理
このリリースにより、Multiarch Tuning Operator を使用して、マルチアーキテクチャークラスター上のワークロードを管理できます。この Operator は、マルチアーキテクチャークラスター、およびマルチアーキテクチャーコンピュート設定に移行しているシングルアーキテクチャークラスター内の運用エクスペリエンスを強化します。これは、アーキテクチャーを考慮したワークロードスケジューリングをサポートするために、ClusterPodPlacementConfig
カスタムリソース (CR) を実装します。
詳細は、Multiarch Tuning Operator を使用してマルチアーキテクチャークラスター上のワークロードを管理する を参照してください。
Multiarch Tuning Operator はテクノロジープレビューのみの機能です。ネットワークシナリオが制限されたクラスターはサポートされません。
1.3.3.2. 64 ビット ARM コントロールプレーンマシンを備えたクラスターに 64 ビット x86 コンピュートマシンを追加するためのサポート
この機能は、64 ビット ARM コントロールプレーンマシンを備えたマルチアーキテクチャークラスターに 64 ビット x86 コンピュートマシンを追加するためのサポートを提供します。このリリースにより、64 ビット ARM コントロールプレーンマシンを使用し、すでに 64 ビット ARM コンピュートマシンが含まれているクラスターに、64 ビット x86 コンピュートマシンを追加できます。
1.3.3.3. 複数のペイロードを持つ Agent-based Installer クラスターのインストールのサポート
この機能は、multi
ペイロードを持つ Agent-based Installer クラスターのインストールをサポートします。multi
ペイロードを持つ Agent-based Installer クラスターをインストールした後、異なるアーキテクチャーのコンピュートマシンをクラスターに追加できます。
1.3.4. Web コンソール
1.3.4.1. フランス語とスペイン語の言語サポート
このリリースにより、Web コンソールでフランス語とスペイン語がサポートされるようになりました。Web コンソールの言語は、User Preferences ページの Language リストから更新できます。
1.3.4.2. Patternfly 4 は 4.16 で非推奨に
このリリースにより、Web コンソールで Patternfly 4 と React Router 5 が非推奨になりました。すべてのプラグインはできるだけ早く Patternfly 5 および React Router 6 に移行する必要があります。
1.3.4.3. 管理者パースペクティブ
このリリースでは、Web コンソールの Administrator パースペクティブに次の更新が導入されています。
-
Google Cloud Platform (GCP) トークン認可、
Auth Token GCP
、およびConfigurable TLS ciphers
フィルターが OperatorHub の インフラストラクチャー機能 フィルターに追加されました。 -
system:admin
ユーザーの偽装に関する情報が記載された新しいクイックスタート (Impersonating the system:admin user) が利用可能です。 - Pod の最後の終了状態を Container list ページと Container details ページで表示できるようになりました。
-
適切な
RoleBinding
を検索しなくても、Groups および Group details ページからImpersonate Group
アクションを利用できるようになりました。 - Getting started セクションの折りたたみと展開が可能です。
1.3.4.3.1. OpenShift Container Platform Web コンソールでのノード CSR 処理
このリリースにより、OpenShift Container Platform Web コンソールはノード証明書署名要求 (CSR) をサポートします。
1.3.4.3.2. クロスストレージクラスのクローンと復元
このリリースにより、クローンまたは復元操作を完了するときに、同じプロバイダーからストレージクラスを選択できるようになりました。この柔軟性により、レプリカ数が異なるストレージクラス間でのシームレスな移行が可能になります。たとえば、レプリカが 3 つのストレージクラスからレプリカが 2/1 のストレージクラスに移動します。
1.3.4.4. Developer パースペクティブ
このリリースでは、Web コンソールの 開発者 パースペクティブに次の更新が導入されています。
- 検索時に、Search ページの Resources リストに新しいセクションが追加され、最近検索した項目が検索された順序で表示されるようになりました。
1.3.4.4.1. コンソール Telemetry
このリリースにより、クラスター Telemetry も有効になっている場合に匿名ユーザー分析が有効になりました。これはほとんどのクラスターのデフォルトであり、Web コンソールの使用方法に関するメトリクスを Red Hat に提供します。クラスター管理者は、各クラスターでこれを更新し、フロントエンド Telemetry をオプトイン、オプトアウト、または無効にすることができます。
1.3.5. OpenShift CLI (oc)
1.3.5.1. oc-mirror プラグイン v2 (テクノロジープレビュー)
OpenShift Container Platform の oc-mirror プラグイン v2 には、Operator イメージやその他の OpenShift Container Platform コンテンツのミラーリングプロセスを改善する新しい機能が含まれています。
以下は、oc-mirror プラグイン v2 の主な機能拡張と機能です。
IDMS および ITMS オブジェクトの自動生成:
oc-mirror プラグイン v2 は、実行ごとに
ImageDigestMirrorSet
(IDMS) およびImageTagMirrorSet
(ITMS) オブジェクトの包括的なリストを自動的に生成します。これらのオブジェクトは、oc-mirror プラグイン v1 で使用されるImageContentSourcePolicy
(ICSP) を置き換わるものです。この機能拡張により、Operator イメージを手動でマージおよびクリーンアップする必要がなくなり、必要なイメージがすべて含まれるようになります。CatalogSource オブジェクト:
CatalogSource オブジェクトの作成では、プラグインが、関連するすべてのカタログインデックスの CatalogSource オブジェクトを生成するようになり、切断されたクラスターへの oc-mirror の出力アーティファクトの適用が強化されました。
検証の改善:
oc-mirror プラグイン v2 は、イメージが以前にミラーリングされたかどうかに関係なく、イメージセット設定で指定された完全なイメージセットがレジストリーにミラーリングされていることを確認します。これにより、ミラーリングは包括的かつ信頼性の高いものとなります。
キャッシュシステム:
新しいキャッシュシステムはメタデータに置き換わり、新しいイメージのみをアーカイブに組み込むことでアーカイブサイズを最小限に抑えます。これによりストレージが最適化され、パフォーマンスが向上します。
日付による選択ミラーリング:
ユーザーはミラーリングの日付に基づいてミラーリングアーカイブを生成できるようになり、新しいイメージを選択的に含めることができるようになりました。
強化されたイメージ削除コントロール:
自動プルーニングに代わって
Delete
機能が導入され、ユーザーはイメージの削除を今まで以上に制御できるようになります。registries.conf
のサポート:oc-mirror プラグイン v2 は、同じキャッシュを使用して複数のエンクレーブへのミラーリングを容易にする
registries.conf
ファイルをサポートしています。これにより、ミラーリングされたイメージを管理する際の柔軟性と効率性が向上します。Operator バージョンのフィルタリング:
ユーザーはバンドル名で Operator バージョンをフィルタリングできるため、ミラーリングプロセスに含まれるバージョンをより正確に制御できます。
oc-mirror v1 と v2 の違い
oc-mirror プラグイン v2 には数多くの機能拡張が加えられていますが、oc-mirror プラグイン v1 の一部の機能は oc-mirror プラグイン v2 にはまだ含まれていません。
- Helm チャート: Helm チャートは oc-mirror プラグイン v2 には存在しません。
-
ImageSetConfig v1alpha2
: API バージョンv1alpha2
は利用できません。ユーザーはv2alpha1
に更新する必要があります。 -
ストレージメタデータ (
storageConfig
): ストレージメタデータは、oc-mirror プラグイン v2ImageSetConfiguration
では使用されません。 -
自動プルーニング: oc-mirror プラグイン v2 の新しい
Delete
機能に置き換えられました。 - リリース署名: リリース署名は、oc-mirror プラグイン v2 では生成されません。
-
一部のコマンド:
init
、list
、describe
コマンドは、oc-mirror プラグイン v2 では使用できません。
oc-mirror プラグイン v2 の使用
oc-mirror プラグイン v2 を使用するには、oc-mirror コマンドラインに --v2
フラグを追加します。
oc-mirror OpenShift CLI (oc
) プラグインは、必要なすべての OpenShift Container Platform コンテンツとその他のイメージをミラーレジストリーにミラーリングするために使用され、切断されたクラスターのメンテナンスを簡素化します。
1.3.5.2. oc adm upgrade status コマンドの導入 (テクノロジープレビュー)
以前は、oc adm upgrade
コマンドがクラスター更新のステータスに関して提供する情報は、限定されていました。このリリースでは、oc adm upgrade status
コマンドが追加されました。このコマンドは、oc adm upgrade
コマンドからステータス情報を分離し、コントロールプレーンのステータスやワーカーノードの更新など、クラスターの更新に関する特定の情報を提供します。
1.3.5.3. リソースの短縮名が重複している場合の警告
このリリースにより、短縮名を使用してリソースをクエリーする場合、クラスター内に同じ短縮名を持つカスタムリソース定義 (CRD) が複数存在すると、OpenShift CLI (oc
) から警告が返されます。
警告例
Warning: short name "ex" could also match lower priority resource examples.test.com
1.3.5.4. リソースを削除するときに確認を要求する新しいフラグ (テクノロジープレビュー)
このリリースにより、oc delete
コマンドに新しい --interactive
フラグが導入されました。--interactive
フラグが true
に設定されている場合、ユーザーが削除を確認した場合にのみリソースが削除されます。このフラグはテクノロジープレビュー機能として利用できます。
1.3.6. IBM Z と IBM LinuxONE
このリリースにより、IBM Z® および IBM® LinuxONE は OpenShift Container Platform 4.16 と互換性を持つようになりました。z/VM、LPAR、または Red Hat Enterprise Linux (RHEL) カーネルベースの仮想マシン (KVM) を使用して、インストールを実行できます。インストール手順は、IBM Z および IBM LinuxONE へのインストールの準備 を参照してください。
コンピュートノードは、Red Hat Enterprise Linux CoreOS (RHCOS) を実行する必要があります。
1.3.6.1. IBM Z および IBM LinuxONE の主な機能拡張
OpenShift Container Platform 4.16 の IBM Z® および IBM® LinuxONE リリースでは、OpenShift Container Platform のコンポーネントと概念に、改良点と新機能が追加されました。
このリリースでは、IBM Z® および IBM® LinuxONE 上で次の機能がサポートされます。
- RHEL KVM の Agent-based Installer ISO ブート
- Ingress Node Firewall Operator
- LPAR 内のマルチアーキテクチャーコンピュートマシン
- z/VM および LPAR のセキュアブート
1.3.7. IBM Power
IBM Power® は OpenShift Container Platform 4.16 と互換性を持つようになりました。インストール手順は、以下のドキュメントを参照してください。
コンピュートノードは、Red Hat Enterprise Linux CoreOS (RHCOS) を実行する必要があります。
1.3.7.1. IBM Power の主な機能拡張
OpenShift Container Platform 4.16 の IBM Power® リリースでは、OpenShift Container Platform コンポーネントに改良点と新機能が追加されました。
このリリースでは、IBM Power® で次の機能がサポートされます。
- CPU マネージャー
- Ingress Node Firewall Operator
1.3.7.2. IBM Power、IBM Z、IBM LinuxONE サポートマトリクス
OpenShift Container Platform 4.14 以降、Extended Update Support (EUS) は IBM Power® および IBM Z® プラットフォームに拡張されています。詳細は、OpenShift EUS の概要 を参照してください。
機能 | IBM Power® | IBM Z® および IBM® LinuxONE |
---|---|---|
代替の認証プロバイダー | サポート対象 | サポート対象 |
Agent-based Installer | サポート対象 | サポート対象 |
Assisted Installer | サポート対象 | サポート対象 |
ローカルストレージ Operator を使用した自動デバイス検出 | サポート対象外 | サポート対象 |
マシンヘルスチェックによる障害のあるマシンの自動修復 | サポート対象外 | サポート対象外 |
IBM Cloud® 向けクラウドコントローラーマネージャー | サポート対象 | サポート対象外 |
オーバーコミットの制御およびノード上のコンテナーの密度の管理 | サポート対象外 | サポート対象外 |
Cron ジョブ | サポート対象 | サポート対象 |
Descheduler | サポート対象 | サポート対象 |
Egress IP | サポート対象 | サポート対象 |
etcd に保存されるデータの暗号化 | サポート対象 | サポート対象 |
FIPS 暗号 | サポート対象 | サポート対象 |
Helm | サポート対象 | サポート対象 |
Horizontal Pod Autoscaling | サポート対象 | サポート対象 |
Hosted Control Plane (テクノロジープレビュー) | サポート対象 | サポート対象 |
IBM Secure Execution | サポート対象外 | サポート対象 |
IBM Power® Virtual Server の installer-provisioned infrastructure の有効化 | サポート対象 | サポート対象外 |
単一ノードへのインストール | サポート対象 | サポート対象 |
IPv6 | サポート対象 | サポート対象 |
ユーザー定義プロジェクトのモニタリング | サポート対象 | サポート対象 |
マルチアーキテクチャーコンピュートノード | サポート対象 | サポート対象 |
マルチアーキテクチャーコントロールプレーン | サポート対象 | サポート対象 |
マルチパス化 | サポート対象 | サポート対象 |
Network-Bound Disk Encryption - 外部 Tang サーバー | サポート対象 | サポート対象 |
不揮発性メモリーエクスプレスドライブ (NVMe) | サポート対象 | サポート対象外 |
Power10 用の nx-gzip (ハードウェアアクセラレーション) | サポート対象 | サポート対象外 |
oc-mirror プラグイン | サポート対象 | サポート対象 |
OpenShift CLI ( | サポート対象 | サポート対象 |
Operator API | サポート対象 | サポート対象 |
OpenShift Virtualization | サポート対象外 | サポート対象外 |
IPsec 暗号化を含む OVN-Kubernetes | サポート対象 | サポート対象 |
PodDisruptionBudget | サポート対象 | サポート対象 |
Precision Time Protocol (PTP) ハードウェア | サポート対象外 | サポート対象外 |
Red Hat OpenShift Local | サポート対象外 | サポート対象外 |
スケジューラーのプロファイル | サポート対象 | サポート対象 |
Secure Boot | サポート対象外 | サポート対象 |
SCTP (Stream Control Transmission Protocol) | サポート対象 | サポート対象 |
複数ネットワークインターフェイスのサポート | サポート対象 | サポート対象 |
IBM Power® 上のさまざまな SMT レベルをサポートする | サポート対象 | サポート対象 |
3 ノードクラスターのサポート | サポート対象 | サポート対象 |
Topology Manager | サポート対象 | サポート対象外 |
SCSI ディスク上の z/VM Emulated FBA デバイス | サポート対象外 | サポート対象 |
4k FCP ブロックデバイス | サポート対象 | サポート対象 |
機能 | IBM Power® | IBM Z® および IBM® LinuxONE |
---|---|---|
iSCSI を使用した永続ストレージ | サポート対象 [1] | サポート対象 [1] [2] |
ローカルボリュームを使用した永続ストレージ (LSO) | サポート対象 [1] | サポート対象 [1] [2] |
hostPath を使用した永続ストレージ | サポート対象 [1] | サポート対象 [1] [2] |
ファイバーチャネルを使用した永続ストレージ | サポート対象 [1] | サポート対象 [1] [2] |
Raw Block を使用した永続ストレージ | サポート対象 [1] | サポート対象 [1] [2] |
EDEV/FBA を使用する永続ストレージ | サポート対象 [1] | サポート対象 [1] [2] |
- 永続共有ストレージは、Red Hat OpenShift Data Foundation またはその他のサポートされているストレージプロトコルを使用してプロビジョニングする必要があります。
- 永続的な非共有ストレージは、iSCSI、FC などのローカルストレージを使用するか、DASD、FCP、または EDEV/FBA での LSO を使用してプロビジョニングする必要があります。
機能 | IBM Power® | IBM Z® および IBM® LinuxONE |
---|---|---|
cert-manager Operator for Red Hat OpenShift | サポート対象 | サポート対象 |
Cluster Logging Operator | サポート対象 | サポート対象 |
Cluster Resource Override Operator | サポート対象 | サポート対象 |
Compliance Operator | サポート対象 | サポート対象 |
Cost Management Metrics Operator | サポート対象 | サポート対象 |
File Integrity Operator | サポート対象 | サポート対象 |
HyperShift Operator | テクノロジープレビュー | テクノロジープレビュー |
IBM Power® Virtual Server Block CSI Driver Operator | サポート対象 | サポート対象外 |
Ingress Node Firewall Operator | サポート対象 | サポート対象 |
Local Storage Operator | サポート対象 | サポート対象 |
MetalLB Operator | サポート対象 | サポート対象 |
Network Observability Operator | サポート対象 | サポート対象 |
NFD Operator | サポート対象 | サポート対象 |
NMState Operator | サポート対象 | サポート対象 |
OpenShift Elasticsearch Operator | サポート対象 | サポート対象 |
Vertical Pod Autoscaler Operator | サポート対象 | サポート対象 |
機能 | IBM Power® | IBM Z® および IBM® LinuxONE |
---|---|---|
ブリッジ | サポート対象 | サポート対象 |
host-device | サポート対象 | サポート対象 |
IPAM | サポート対象 | サポート対象 |
IPVLAN | サポート対象 | サポート対象 |
機能 | IBM Power® | IBM Z® および IBM® LinuxONE |
---|---|---|
クローン | サポート対象 | サポート対象 |
拡張 | サポート対象 | サポート対象 |
スナップショット | サポート対象 | サポート対象 |
1.3.8. 認証および認可
1.3.8.1. 既存のクラスターで Microsoft Entra Workload ID を有効にする
このリリースにより、Microsoft Entra Workload ID を有効にして、既存の Microsoft Azure OpenShift Container Platform クラスターで短期認証情報を使用できるようになりました。この機能は、OpenShift Container Platform バージョン 4.14 および 4.15 でもサポートされるようになりました。詳細は、トークンベースの認証の有効化 を参照してください。
1.3.9. ネットワーク
1.3.9.1. OpenShift SDN ネットワークプラグインが今後のメジャーアップグレードをブロックする
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
1.3.9.2. PTP グランドマスタークロックとしてのデュアル NIC Intel E810 Westport Channel (一般提供)
デュアル 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 のグランドマスタークロックとして設定する を参照してください。
1.3.9.3. 高可用性システムクロックを備えたデュアル NIC Intel E810 PTP 境界クロック (一般提供)
linuxptp
サービス ptp4l
および phc2sys
を、デュアル PTP 境界クロック (T-BC) の高可用性 (HA) システムクロックとして設定できます。
詳細は、デュアル NIC Intel E810 PTP 境界クロック用の高可用性システムクロックとして linuxptp を設定する を参照してください。
1.3.9.4. ネットワーク接続を確認するための Pod 配置の設定
クラスターコンポーネント間のネットワーク接続を定期的にテストするために、Cluster Network Operator (CNO) は network-check-source
デプロイメントと network-check-target
デーモンセットを作成します。OpenShift Container Platform 4.16 では、ノードセレクターを設定してノードを設定し、ソース Pod とターゲット Pod を実行してネットワーク接続を確認できます。詳細は、エンドポイントへの接続の確認 を参照してください。
1.3.9.5. 1 つのネットワークセキュリティーグループ (NSG) ルールに複数の CIDR ブロックを定義する
このリリースにより、Microsoft Azure でホストされている OpenShift Container Platform クラスターの NSG で IP アドレスと範囲がより効率的に処理されるようになりました。その結果、allowedSourceRanges
フィールドを使用する Microsoft Azure クラスター内のすべての Ingress コントローラーの Classless Inter-Domain Routings (CIDRs) の最大制限が、約 1000 から 4000 CIDR に増加しました。
1.3.9.6. OpenShift SDN から Nutanix 上の OVN-Kubernetes への移行
このリリースにより、OpenShift SDN ネットワークプラグインから OVN-Kubernetes への移行が Nutanix プラットフォームでサポートされるようになりました。詳細は、OVN-Kubernetes ネットワークプラグインへの移行 を参照してください。
1.3.9.7. CoreDNS と Egress ファイアウォール間のインテグレーションの改善 (テクノロジープレビュー)
このリリースにより、OVN-Kubernetes は新しい DNSNameResolver
カスタムリソースを使用して、Egress ファイアウォールルール内の DNS レコードを追跡します。これはテクノロジープレビューとして利用できます。このカスタムリソースは、ワイルドカード DNS 名と通常の DNS 名の両方の使用をサポートし、変更に関連付けられた IP アドレスに関係なく DNS 名にアクセスできるようにします。
詳細は、DNS 解決の改善とワイルドカードドメイン名の解決 を参照してください。
1.3.9.8. SR-IOV ネットワークポリシーの更新中の並列ノードドレイン
このリリースにより、ネットワークポリシーの更新中にノードを並行してドレインするように SR-IOV Network Operator を設定できるようになります。ノードを並列にドレインするオプションにより、SR-IOV ネットワーク設定の展開が高速化されます。SriovNetworkPoolConfig
カスタムリソースを使用して、並列ノードドレインを設定し、Operator が並列ドレインできるプール内のノードの最大数を定義できます。
詳細は、SR-IOV ネットワークポリシーの更新中に並列ノードドレインを設定する を参照してください。
1.3.9.9. SR-IOV Network Operator は SriovOperatorConfig CR を自動的に作成しなくなる
OpenShift Container Platform 4.16 以降、SR-IOV Network Operator は SriovOperatorConfig
カスタムリソース (CR) を自動的に作成しなくなりました。SR-IOV Network Operator の設定
で説明されている手順を使用して、SriovOperatorConfig CR を作成します。
1.3.9.10. 二重タグ付きパケット (QinQ) のサポート
このリリースにより、QinQ support とも呼ばれる 802.1Q-in-802.1Q が導入されました。QinQ は 2 番目の VLAN タグを導入します。ここで、サービスプロバイダーは外部タグを自社用に指定して柔軟性を提供し、内部タグは顧客の VLAN 専用のままになります。パケット内に 2 つの VLAN タグが存在する場合、外側の VLAN タグは 802.1Q または 802.1ad のいずれかになります。内部 VLAN タグは常に 802.1Q である必要があります。
詳細は、SR-IOV 対応ワークロードに対する QinQ サポートの設定 を参照してください。
1.3.9.11. オンプレミスインフラストラクチャー用のユーザー管理ロードバランサーの設定
このリリースにより、ベアメタル、VMware vSphere、Red Hat OpenStack Platform (RHOSP)、Nutanix などのオンプレミスインフラストラクチャー上で OpenShift Container Platform クラスターを設定し、デフォルトのロードバランサーの代わりにユーザー管理のロードバランサーを使用できるようになりました。この設定では、クラスターの install-config.yaml
ファイルで loadBalancer.type: UserManaged
を指定する必要があります。
ベアメタルインフラストラクチャーにおけるこの機能の詳細は、OpenShift インストール環境のセットアップ の ユーザー管理ロードバランサーのサービス を参照してください。
1.3.9.12. iptables の検出と警告
このリリースにより、クラスター内に 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
ベースのバージョンがすぐに利用可能になるか確認してください。
1.3.9.13. OpenShift Container Platform サービスの Ingress ネットワークフロー
このリリースでは、OpenShift Container Platform サービスの Ingress ネットワークフローを表示できます。この情報を使用して、ネットワークの Ingress トラフィックを管理し、ネットワークセキュリティーを向上させることができます。
詳細は、OpenShift Container Platform ネットワークフローマトリクス を参照してください。
1.3.9.14. 既存のデュアルスタックネットワークへのパッチ適用
このリリースにより、クラスターインフラストラクチャーにパッチを適用することで、既存のデュアルスタック設定のクラスターに API および Ingress サービス用の IPv6 仮想 IP (VIP) を追加できます。
クラスターを OpenShift Container Platform 4.16 にすでにアップグレードしていて、シングルスタッククラスターネットワークをデュアルスタッククラスターネットワークに変換する必要がある場合は、YAML 設定パッチファイルでクラスターに対して以下を指定する必要があります。
-
最初の
machineNetwork
設定上の API および Ingress サービス用の IPv4 ネットワーク。 -
2 つ目の
machineNetwork
設定上の API および Ingress サービス用の IPv6 ネットワーク。
詳細は、IPv4/IPv6 デュアルスタックネットワークへの変換 の デュアルスタッククラスターネットワークへの変換 を参照してください。
1.3.9.15. MetalLB と FRR-K8s のインテグレーション (テクノロジープレビュー)
このリリースにより、Kubernetes に準拠した方法で FRR
API のサブセットを公開する Kubernetes ベースの DaemonSet
である FRR-K8s
が導入されました。クラスター管理者は、FRRConfiguration
カスタムリソース (CR) を使用して、MetalLB Operator がバックエンドとして FRR-K8s
デーモンセットを使用するように設定できます。これを利用して、ルートの受信などの FRR サービスを操作できます。
詳細は、MetalLB と FRR-K8s のインテグレーションの設定 を参照してください。
1.3.9.16. 外部管理証明書を使用したルートの作成 (テクノロジープレビュー)
このリリースでは、ルート API の .spec.tls.externalCertificate
フィールドを利用して、サードパーティーの証明書管理ソリューションで OpenShift Container Platform ルートを設定できるようになりました。これにより、シークレットを介して外部で管理されている TLS 証明書を参照できるようになり、手動による証明書管理が不要になり、プロセスが合理化されます。外部で管理される証明書を使用することで、エラーが削減され、証明書の更新プロセスがスムーズになり、OpenShift ルーターが更新された証明書を迅速に提供できるようになります。詳細は、外部管理証明書を使用したルートの作成 を参照してください。
1.3.9.17. AdminNetworkPolicy が一般公開される
この機能では、AdminNetworkPolicy
(ANP) と BaselineAdminNetworkPolicy
(BANP) という 2 つの新しい API が提供されます。namespace が作成される前に、クラスター管理者は ANP と BANP を使用して、クラスター全体にクラスタースコープのネットワークポリシーと保護を適用できます。ANP はクラスタースコープであるため、各 namespace でネットワークポリシーを複製することなく、ネットワークのセキュリティーを大規模に管理できるソリューションを管理者に提供します。
詳細は、ネットワークセキュリティー の AdminNetworkPolicy を参照してください。
1.3.9.18. OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーション
以前は、OpenShift SDN から OVN-Kubernetes に移行する場合、利用できるオプションは オフライン 移行方式のみでした。このプロセスにはダウンタイムが含まれており、その間はクラスターにアクセスできませんでした。
このリリースでは、制限付きの ライブ マイグレーションメソッドが導入されています。限定的なライブマイグレーション方式は、OpenShift SDN ネットワークプラグインとそのネットワーク設定、接続、および関連リソースを、サービスを中断することなく OVN-Kubernetes ネットワークプラグインに移行するプロセスです。OpenShift Container Platform で利用できます。Hosted Control Plane デプロイメントタイプでは使用できません。この移行方式は、継続的なサービス可用性を必要とするデプロイメントタイプにとって有用で、以下のような利点があります。
- 継続的なサービスの可用性
- ダウンタイムの最小化
- 自動ノード再起動
- OpenShift SDN ネットワークプラグインから OVN-Kubernetes ネットワークプラグインへのシームレスな移行
OVN-Kubernetes への移行は、一方向のプロセスとなるよう意図されています。
詳細は、OVN-Kubernetes ネットワークプラグインへの制限付きライブマイグレーションの概要 を参照してください。
1.3.9.19. Whereabouts を使用したマルチテナントネットワークの IP 設定の重複
以前は、同じ CIDR 範囲を 2 回設定できず、Whereabouts CNI プラグインがこれらの範囲から IP アドレスを個別に割り当てることができませんでした。この制限により、異なるグループが重複している CIDR 範囲を選択する必要があるマルチテナント環境で問題が発生しました。
このリリースでは、Whereabouts CNI プラグインが、network_name
パラメーターを含めることで重複する IP アドレス範囲をサポートします。管理者は、network_name
パラメーターを使用して、個別の NetworkAttachmentDefinitions
内で同じ CIDR 範囲を複数回設定できます。これにより、各範囲に独立した IP アドレスの割り当てが可能になります。
この機能には、強化された namespace の処理、IPPool
カスタムリソース (CR) の適切な namespace への保存、および Multus によって許可された場合の namespace 間のサポートも含まれています。これらの改善により、マルチテナント環境での柔軟性と管理機能が向上します。
この機能の詳細は、Whereabouts を使用した動的 IP アドレス割り当ての設定 を参照してください。
1.3.9.20. OVN-Kubernetes ネットワークプラグインの内部 IP アドレス範囲の変更のサポート
OVN-Kubernetes ネットワークプラグインを使用する場合は、transit、join、および masquerade サブネットを設定できます。transit、join、および masquerade サブネットは、クラスターのインストール中またはインストール後に設定できます。サブネットのデフォルトは以下のとおりです。
-
transit サブネット:
100.88.0.0/16
およびfd97::/64
-
join サブネット:
100.64.0.0/16
およびfd98::/64
-
masquerade サブネット:
169.254.169.0/29
およびfd69::/125
これらの設定フィールドの詳細は、Cluster Network Operator 設定オブジェクト を参照してください。既存のクラスターでの transit サブネットと join サブネットの設定に関する詳細は、OVN-Kubernetes 内部 IP アドレスサブネットの設定を参照してください。
1.3.9.21. IPsec Telemetry
Telemetry および Insights Operator は IPsec 接続の Telemetry を収集します。詳細は、Telemetry によって収集されるデータの表示 を参照してください。
1.3.10. Storage
1.3.10.1. HashiCorp Vault が Secrets Store CSI Driver Operator で利用可能に (テクノロジープレビュー)
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 からのシークレットのマウント を参照してください。
1.3.10.2. Microsoft Azure File でボリュームのクローン作成がサポートされる (テクノロジープレビュー)
OpenShift Container Platform 4.16 では、テクノロジープレビュー機能として、Microsoft Azure File Container Storage Interface (CSI) Driver Operator のボリュームのクローン作成機能が導入されています。ボリュームのクローン作成により、既存の永続ボリューム (PV) が複製され、OpenShift Container Platform におけるデータ損失を防ぎます。標準ボリュームを使用する場合と同じように、ボリュームクローンを使用することもできます。
詳細は、Azure File CSI Driver Operator および CSI ボリュームのクローン作成 を参照してください。
1.3.10.3. Node Expansion Secret が一般提供へ
Node Expansion Secret 機能を使用すると、ボリュームへのアクセスにノード拡張操作を実行するためのシークレット (たとえば、Storage Area Network (SAN) ファブリックにアクセスするための認証情報) が必要な場合でも、クラスターはマウントされたボリュームのストレージを拡張できます。OpenShift Container Platform 4.16 では、これは一般提供機能としてサポートされています。
1.3.10.4. vSphere CSI のスナップショットの最大数の変更が一般提供へ
VMware vSphere Container Storage Interface (CSI) のスナップショットのデフォルトの最大数は、ボリュームあたり 3 です。OpenShift Container Platform 4.16 では、スナップショットの最大数をボリュームあたり最大 32 に変更できるようになりました。また、vSAN および仮想ボリュームデータストアのスナップショットの最大数を細かく制御することもできます。OpenShift Container Platform 4.16 では、これは一般提供機能としてサポートされています。
詳細は、vSphere のスナップショットの最大数の変更 を参照してください。
1.3.10.5. 永続ボリュームの最終フェーズ遷移時間パラメーター (テクノロジープレビュー)
OpenShift Container Platform 4.16 では、永続ボリューム (PV) が別のフェーズ (pv.Status.Phase
) に移行するたびに更新されるタイムスタンプを持つ新しいパラメーター LastPhaseTransitionTime
が導入されました。この機能はテクノロジープレビューのステータスでリリースされています。
1.3.10.6. CIFS/SMB CSI Driver Operator を使用した永続ストレージ (テクノロジープレビュー)
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 を参照してください。
1.3.10.7. SELinux コンテキストマウントを備えた RWOP が一般提供へ
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 では、この機能が一般提供されています。
詳細は、アクセスモード を参照してください。
1.3.10.8. vSphere CSI Driver 3.1 で CSI トポロジー要件が更新される
マルチゾーンクラスターでの VMware vSphere Container Storage Interface (CSI) ボリュームのプロビジョニングと使用をサポートするには、デプロイメントが CSI ドライバーによって課される特定の要件に一致している必要があります。これらの要件は 3.1.0 以降に変更されており、OpenShift Container Platform 4.16 は古いタグ付け方法と新しいタグ付け方法の両方を受け入れますが、VMware vSphere は古いタグ付け方法を無効な設定と見なすため、新しいタグ付け方法を使用する必要があります。問題を防ぐために、古いタグ付け方法は使用しないでください。
詳細は、vSphere CSI トポロジーの要件 を参照してください。
1.3.10.9. thick-provisioned ストレージ設定のサポート
この機能は、thick-provisioned ストレージの設定をサポートします。LVMCluster
カスタムリソース (CR) で deviceClasses.thinPoolConfig
フィールドを除外すると、論理ボリュームは thick-provisioned となります。thick-provisioned ストレージを使用する場合、次の制限があります。
- ボリュームのクローン作成ではコピーオンライトはサポートされません。
-
VolumeSnapshotClass
はサポートされていません。したがって、CSI スナップショットはサポートされていません。 - オーバープロビジョニングはサポートされていません。その結果、PersistentVolumeClaims (PVC) のプロビジョニングされた容量がボリュームグループからすぐに削減されます。
- シンメトリクスはサポートされていません。thick-provisioned デバイスは、ボリュームグループメトリクスのみをサポートします。
LVMCluster
CR の設定に関する詳細は、LVMCluster カスタムリソースについて を参照してください。
1.3.10.10. LVMCluster カスタムリソースでデバイスセレクターが設定されていない場合の新しい警告メッセージのサポート
この更新により、LVMCluster
カスタムリソース (CR) で deviceSelector
フィールドを設定していない場合に、新しい警告メッセージが表示されるようになります。
LVMCluster
CR は、deviceSelector
フィールドが設定されているかを示す新しいフィールド deviceDiscoveryPolicy
をサポートします。deviceSelector
フィールドを設定しない場合、LVM Storage は deviceDiscoveryPolicy
フィールドを RuntimeDynamic
に自動的に設定します。それ以外の場合、deviceDiscoveryPolicy
フィールドは Preconfigured
に設定されます。
LMVCluster
CR から deviceSelector
フィールドを除外することは推奨されません。deviceSelector
フィールドを設定しない場合の制限の詳細は、ボリュームグループへのデバイスの追加について を参照してください。
1.3.10.11. ボリュームグループへの暗号化デバイスの追加をサポート
この機能は、暗号化されたデバイスをボリュームグループに追加するためのサポートを提供します。OpenShift Container Platform のインストール中に、クラスターノードでディスク暗号化を有効にすることができます。デバイスを暗号化した後、LVMCluster
カスタムリソースの deviceSelector
フィールドで LUKS 暗号化デバイスへのパスを指定できます。ディスク暗号化の詳細は、ディスク暗号化について および ディスク暗号化とミラーリングの設定 を参照してください。
ボリュームグループへのデバイスの追加に関する詳細は、ボリュームグループへのデバイスの追加について を参照してください。
1.3.11. Operator ライフサイクル
1.3.11.1. Operator API の名前が ClusterExtension (テクノロジープレビュー) に変更される
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
へ名前を変更することで、以下に対応します。
- クラスターの機能を拡張する簡素化された機能をより正確に反映します。
- より柔軟なパッケージ形式をより良く表現する
-
Cluster
の接頭辞がClusterExtension
オブジェクトがクラスタースコープであることを明確に示す。これは、Operator が namespace スコープまたはクラスタースコープのいずれかになる可能性がある従来の OLM からの変更です。
詳細は、Operator Controller を参照してください。
OLM 1.0 は依存関係の解決をサポートしていません。拡張機能が他の API またはパッケージへの依存関係を宣言する場合、拡張機能をインストールする前に、その依存関係がクラスター上に存在している必要があります。
現在、OLM 1.0 は次の基準を満たす拡張機能のインストールをサポートしています。
-
拡張機能では
AllNamespaces
インストールモードを使用する必要があります。 - 拡張機能では Webhook を使用しないでください。
Webhook を使用するクラスター拡張機能、または単一または指定された namespace のセットを対象とするクラスター拡張機能はインストールできません。
1.3.11.2. Operator Lifecycle Manager (OLM) 1.0 (テクノロジープレビュー) のクラスターエクステンションのステータス条件メッセージと非推奨通知が改善される
このリリースにより、OLM 1.0 はインストールされたクラスターエクステンションに対して、次のステータス条件メッセージを表示します。
- 特定のバンドル名
- インストール済みバージョン
- 健全性レポートの改善
- パッケージ、チャネル、バンドルの非推奨通知
1.3.11.3. OLM 1.0 でのレガシー OLM アップグレードエッジのサポート (テクノロジープレビュー)
インストールされたクラスター拡張機能のアップグレードエッジを決定する場合、Operator Lifecycle Manager (OLM) 1.0 は、OpenShift Container Platform 4.16 以降、従来の OLM セマンティックをサポートします。このサポートは、replaces
、skips
、skipRange
ディレクティブなど、従来の OLM の動作に従いますが、いくつかの違いがあります。
従来の OLM セマンティックをサポートすることで、OLM 1.0 はカタログからのアップグレードグラフを正確に認識するようになりました。
セマンティックバージョン (semver) のアップグレード制約のサポートは OpenShift Container Platform 4.15 で導入されましたが、このテクノロジープレビューフェーズでは従来の OLM セマンティクスを優先するため 4.16 では無効になっています。
詳細は、アップグレード制約セマンティクス を参照してください。
1.3.12. ビルド
1.3.12.1. 認証されていないユーザーが system:webhook ロールバインディングから削除される
このリリースにより、認証されていないユーザーは system:webhook
ロールバインディングにアクセスできなくなります。OpenShift Container Platform 4.16 より前では、認証されていないユーザーが system:webhook
ロールバインディングにアクセスできました。認証されていないユーザーのアクセスを変更することで、セキュリティーの層が追加されます。ユーザーは必要な場合にのみ、これを有効にする必要があります。この変更は新しいクラスターに対するものであり、以前のクラスターには影響しません。
認証されていないユーザーに特定の namespace の system:webhook
ロールバインディングを許可することが推奨されるユースケースがあります。system:webhook
クラスターロールを使用すると、ユーザーは GitHub、GitLab、Bitbucket などの OpenShift Container Platform 認証メカニズムを使用しない外部システムからビルドをトリガーできます。クラスター管理者は、このユースケースを容易にするために、認証されていないユーザーに system:webhook
ロールバインディングへのアクセスを許可できます。
認証されていないアクセスを変更するときは、常に組織のセキュリティー標準に準拠していることを確認してください。
認証されていないユーザーに、特定の namespace の system:webhook
ロールバインディングへのアクセスを許可するには、認証されていないユーザーを system:webhook ロールバインディングに追加する を参照してください。
1.3.13. Machine Config Operator
1.3.13.1. 未使用のレンダリングされたマシン設定のガベージコレクション
このリリースにより、未使用のレンダリングされたマシン設定をガベージコレクションできるようになりました。oc adm prune renderedmachineconfigs
コマンドを使用すると、未使用のレンダリングされたマシン設定を表示し、削除するものを決定してから、不要になったレンダリングされたマシン設定を一括削除できます。マシン設定が多すぎると、マシン設定の操作が混乱する可能性があり、ディスク容量やパフォーマンスの問題の原因にもなります。詳細は、未使用のレンダリングされたマシン設定の管理 を参照してください。
1.3.13.2. ノード中断ポリシー (テクノロジープレビュー)
デフォルトでは、MachineConfig
オブジェクトのパラメーターに特定の変更を加えると、Machine Config Operator (MCO) は、そのマシン設定に関連付けられているノードをドレインして再起動します。ただし、ワークロードの中断をほとんどまたはまったく必要としない Ignition 設定オブジェクトの一連の変更を定義するノード中断ポリシーを MCO namespace に作成できます。詳細は、ノード中断ポリシーを使用してマシン設定の変更による中断を最小限に抑える を参照してください。
1.3.13.3. クラスター上の RHCOS イメージのレイヤー化 (テクノロジープレビュー)
Red Hat Enterprise Linux CoreOS (RHCOS) イメージのレイヤー化により、テクノロジープレビュー機能として、カスタムレイヤー化イメージをクラスター内に直接自動的にビルドできるようになりました。以前は、クラスターの外部でカスタムレイヤーイメージをビルドし、そのイメージをクラスターにプルする必要がありました。イメージレイヤー機能を使用して、ベースイメージに追加のイメージをレイヤー化することで、ベース RHCOS イメージの機能を拡張できます。詳細は、RHCOS イメージのレイヤー化 を参照してください。
1.3.13.4. ブートイメージの更新 (テクノロジープレビュー)
デフォルトでは、MCO は Red Hat Enterprise Linux CoreOS (RHCOS) ノードを起動するために使用するブートイメージを削除しません。その結果、クラスター内のブートイメージはクラスターとともに更新されません。クラスターを更新するたびにブートイメージも更新するようにクラスターを設定できるようになりました。詳細は、ブートイメージの更新 を参照してください。
1.3.14. マシン管理
1.3.14.1. クラスターオートスケーラーのエクスパンダーの設定
このリリースにより、クラスターオートスケーラーは LeastWaste
、Priority
、および Random
エクスパンダーを使用できるようになりました。これらのエクスパンダーを設定して、クラスターをスケーリングするときにマシンセットの選択に影響を与えることができます。詳細は、クラスターオートスケーラーの設定 を参照してください。
1.3.14.2. VMware vSphere の Cluster API を使用したマシンの管理 (テクノロジープレビュー)
このリリースにより、VMware vSphere クラスターのテクノロジープレビューとして、OpenShift Container Platform に統合されたアップストリーム Cluster API を使用してマシンを管理する機能が導入されました。この機能は、Machine API を使用してマシンを管理するための追加または代替の機能になります。詳細は、Cluster API について を参照してください。
1.3.14.3. コントロールプレーンマシンセットの vSphere 障害ドメインの定義
このリリースでは、コントロールプレーンマシンセットの vSphere 障害ドメインを定義する、以前はテクノロジープレビューだった機能が一般提供されました。詳細は、VMware vSphere のコントロールプレーン設定オプション を参照してください。
1.3.15. ノード
1.3.15.1. Vertical Pod Autoscaler Operator Pod の移動
Vertical Pod Autoscaler Operator (VPA) は、レコメンダー、アップデーター、アドミッションコントローラーの 3 つのコンポーネントで構成されます。Operator と各コンポーネントには、コントロールプレーンノードの VPA namespace に独自の Pod があります。VPA Operator とコンポーネント Pod をインフラストラクチャーノードまたはワーカーノードに移動できます。詳細は、Vertical Pod Autoscaler Operator コンポーネントの移動 を参照してください。
1.3.15.2. must-gather によって収集された追加情報
このリリースにより、oc adm must-gather
コマンドによって以下の追加情報が収集されます。
-
OpenShift CLI (
oc
) バイナリーバージョン - must-gather ログ
これらの追加は、特定のバージョンの oc
の使用から生じる可能性のある問題を特定するのに役立ちます。oc adm must-gather
コマンドは、使用されたイメージと、must-gather ログに収集できなかったデータがあるかどうかもリスト表示します。
詳細は、must-gather ツールについて を参照してください。
1.3.15.3. BareMetalHost リソースの編集
OpenShift Container Platform 4.16 以降では、ベアメタルノードの BareMetalHost
リソースでベースボード管理コントローラー (BMC) アドレスを編集できます。ノードは Provisioned
、ExternallyProvisioned
、Registering
、または Available
状態である必要があります。BareMetalHost
リソースの BMC アドレスを編集しても、ノードのプロビジョニングは解除されません。詳細は、BareMetalHost リソースの編集 を参照してください。
1.3.15.4. ブータブルでない ISO のアタッチ
OpenShift Container Platform 4.16 以降では、DataImage
リソースを使用して、プロビジョニングされたノードに汎用のブータブルでない ISO 仮想メディアイメージをアタッチできます。リソースを適用すると、次回の再起動時にオペレーティングシステムから ISO イメージにアクセスできるようになります。この機能をサポートするために、ノードが Redfish またはそれから派生したドライバーを使用している。ノードが Provisioned
または ExternallyProvisioned
状態である。詳細は、ブータブルでない ISO をベアメタルノードにアタッチする を参照してください。
1.3.16. モニタリング
このリリースのクラスター内モニタリングスタックには、以下の新機能および修正された機能が含まれます。
1.3.16.1. モニタリングスタックコンポーネントおよび依存関係の更新
このリリースには、クラスター内モニタリングスタックコンポーネントと依存関係に関する以下のバージョン更新が含まれています。
- kube-state-metrics が 2.12.0 へ
- Metrics Server が 0.7.1 へ
- node-exporter が 1.8.0 へ
- Prometheus が 2.52.0 へ
- Prometheus Operator が 0.73.2 へ
- Thanos が 0.35.0 へ
1.3.16.2. アラートルールの変更
Red Hat は、記録ルールまたはアラートルールの後方互換性を保証しません。
-
Cluster Monitoring Operator 設定が非推奨のフィールドを使用する際に監視するための
ClusterMonitoringOperatorDeprecatedConfig
アラートを追加しました。 -
Prometheus Operator がオブジェクトステータスの更新に失敗した際に監視するための
PrometheusOperatorStatusUpdateErrors
アラートを追加しました。
1.3.16.3. Metrics API の一般提供 (GA) にアクセスするための Metrics Server コンポーネント (テクノロジープレビュー)
Metrics Server コンポーネントが一般提供され、非推奨の Prometheus Adapter の代わりに自動的にインストールされるようになりました。Metrics Server はリソースメトリクスを収集し、他のツールや API が使用できるように metrics.k8s.io
Metrics API サービスで公開します。これにより、コアプラットフォーム Prometheus スタックがこの機能の処理から解放されます。詳細は、Cluster Monitoring Operator の config map API 参照のMetricsServerConfig を参照してください。
1.3.16.4. Alertmanager API への読み取り専用アクセスを許可する新しいモニタリングロール
このリリースでは、openshift-monitoring
プロジェクトの Alertmanager API への読み取り専用アクセスを許可する新しい monitoring-alertmanager-view
ロールが導入されました。
1.3.16.5. VPA メトリクスが kube-state-metrics エージェントで利用可能に
Vertical Pod Autoscaler (VPA) メトリクスが、kube-state-metrics
エージェントを通じて利用可能になりました。VPA メトリクスは、非推奨後にネイティブサポートアップストリームから削除された前と同様の説明形式に従います。
1.3.16.6. コンポーネントを監視するためのプロキシーサービスの変更
このリリースでは、Prometheus、Alertmanager、Thanos Ruler の前のプロキシーサービスが OAuth から kube-rbac-proxy
に更新されました。この変更は、適切なロールとクラスターロールを持たずにこれらの API エンドポイントにアクセスするサービスアカウントとユーザーに影響する可能性があります。
1.3.16.7. Prometheus が重複サンプルを処理する方法の変更
このリリースでは、Prometheus がターゲットをスクレイピングするときに、同じ値であっても重複したサンプルがサイレントに無視されなくなりました。最初のサンプルが受け入れられ、prometheus_target_scrapes_sample_duplicate_timestamp_total
カウンターが増加し、これにより、PrometheusDuplicateTimestamps
アラートがトリガーされる可能性があります。
1.3.17. Network Observability Operator
Network Observability Operator は、OpenShift Container Platform マイナーバージョンのリリースストリームとは独立して更新をリリースします。更新は、現在サポートされているすべての OpenShift Container Platform 4 バージョンでサポートされている単一のローリングストリームを介して使用できます。Network Observability Operator の新機能、機能拡張、バグ修正に関する情報は、Network Observability リリースノート を参照してください。
1.3.18. スケーラビリティーおよびパフォーマンス
1.3.18.1. ワークロードパーティショニングの強化
このリリースにより、CPU 制限と CPU リクエストの両方を含むワークロードアノテーションを使用してデプロイされたプラットフォーム Pod では、CPU 制限が正確に計算され、特定の Pod の CPU クォータとして適用されます。以前のリリースでは、ワークロードパーティショニングされた Pod に CPU 制限とリクエストの両方が設定されていた場合、それらは Webhook によって無視されていました。Pod はワークロードパーティショニングのメリットを享受できず、特定のコアにロックダウンされませんでした。この更新により、リクエストと制限が Webhook によって正しく解釈されるようになりました。
CPU 制限の値がアノテーション内のリクエストの値と異なる場合、CPU 制限はリクエストと同じものと見なされることが想定されています。
詳細は、ワークロードのパーティショニング を参照してください。
1.3.18.2. Linux Control Groups バージョン 2 がパフォーマンスプロファイル機能でサポートされるようになる
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 バージョンの設定 を参照してください。
1.3.18.3. etcd データベースのサイズを増やすためのサポート (テクノロジープレビュー)
このリリースにより、etcd のディスククォータを増やすことができます。これはテクノロジープレビューの機能です。詳細は、etcd のデータベースサイズの増加 を参照してください。
1.3.18.4. 予約コア周波数のチューニング
このリリースでは、Node Tuning Operator は、予約済みおよび分離されたコア CPU の PerformanceProfile
で CPU 周波数の設定をサポートします。これは、特定の周波数を定義するために使用できるオプションの機能です。次に、Node Tuning Operator は Intel ハードウェアの intel_pstate
CPUFreq ドライバーを有効にして、これらの周波数を設定します。FlexRAN のようなアプリケーションの周波数については、Intel の推奨事項に従う必要があります。このようなアプリケーションでは、デフォルトの CPU 周波数をデフォルトの実行周波数よりも低い値に設定する必要があります。
1.3.18.5. Node Tuning Operator intel_pstate ドライバーのデフォルト設定
以前は、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
に設定されています。
1.3.19. エッジコンピューティング
1.3.19.1. RHACM PolicyGenerator リソースを使用して GitOps ZTP クラスターポリシーを管理する (テクノロジープレビュー)
PolicyGenerator
リソースと Red Hat Advanced Cluster Management (RHACM) を使用して、GitOps ZTP でマネージドクラスターのポリシーをデプロイできるようになりました。PolicyGenerator
API は Open Cluster Management 標準の一部であり、PolicyGenTemplate
API では不可能なリソースへパッチを適用する一般的な方法を提供します。PolicyGenTemplate
リソースを使用してポリシーを管理およびデプロイすることは、今後の OpenShift Container Platform リリースでは非推奨になります。
詳細は、PolicyGenerator リソースを使用したマネージドクラスターポリシーの設定 を参照してください。
PolicyGenerator
API は現在、アイテムのリストを含むカスタム Kubernetes リソースとのパッチのマージをサポートしていません。たとえば、PtpConfig
CR の場合などです。
1.3.19.2. TALM ポリシーの修正
このリリースにより、Topology Aware Lifecycle Manager (TALM) は Red Hat Advanced Cluster Management (RHACM) 機能を使用して、マネージドクラスターの inform
ポリシーを修復します。この機能拡張により、ポリシーの修復中に Operator が inform
ポリシーの enforce
コピーを作成する必要がなくなります。この機能拡張により、コピーされたポリシーによるハブクラスターのワークロードも軽減され、マネージドクラスターのポリシーの修復に必要な全体的な時間も短縮されます。
詳細は、マネージドクラスターのポリシーの更新 を参照してください。
1.3.19.3. GitOps ZTP の高速プロビジョニング (テクノロジープレビュー)
このリリースにより、シングルノード OpenShift の GitOps ZTP の高速プロビジョニングを使用することで、クラスターのインストールにかかる時間を短縮できます。高速 ZTP は、ポリシーから派生した Day 2 マニフェストを早い段階で適用することで、インストールを高速化します。
GitOps ZTP の高速プロビジョニングの利点は、デプロイメントの規模に応じて増大します。完全なアクセラレーションは、クラスターの数が多いほど、より大きなメリットをもたらします。クラスターの数が少ない場合、インストール時間の短縮はそれほど大きくありません。
詳細は、GitOps ZTP の高速プロビジョニング を参照してください。
1.3.19.4. Lifecycle Agent を使用したシングルノード OpenShift クラスターのイメージベースアップグレード
このリリースでは、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 クラスターのイメージベースのアップグレードについて を参照してください。
1.3.19.5. GitOps ZTP と RHACM を使用してマネージドクラスターに IPsec 暗号化をデプロイする
GitOps ZTP と Red Hat Advanced Cluster Management (RHACM) を使用してデプロイするマネージドシングルノード OpenShift クラスターで IPsec 暗号化を有効化できるようになりました。マネージドクラスターの外部にある Pod と IPsec エンドポイント間の外部トラフィックを暗号化できます。OVN-Kubernetes クラスターネットワーク上のノード間のすべての Pod 間ネットワークトラフィックが、Transport モードの IPsec で暗号化されます。
詳細は、GitOps ZTP および SiteConfig リソースを使用したシングルノード OpenShift クラスターの IPsec 暗号化の設定 を参照してください。
1.3.20. Hosted Control Plane
1.3.20.1. Hosted Control Plane は Amazon Web Services (AWS) で一般公開されています
OpenShift Container Platform 4.16 の Hosted Control Plane が AWS プラットフォームで一般提供されました。
1.3.21. セキュリティー
新しい署名者認証局 (CA) である openshift-etcd
が、証明書の署名用として利用できるようになりました。この CA は、既存の CA とのトラストバンドルに含まれています。2 つの CA シークレット (etcd-signer
および etcd-metric-signer
) もローテーションに使用できます。このリリース以降、すべての証明書は実証済みのライブラリーに移行します。この変更により、cluster-etcd-operator
によって管理されていなかったすべての証明書の自動ローテーションが可能になります。すべてのノードベースの証明書は現在の更新プロセスを続行します。