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

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

installer-provisioned infrastructure (IPI) は、OpenShift Container Platform のフルスタックインストールとセットアップを提供します。

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

この機能は、OpenShift Container Platform 4.12 でテクノロジープレビュー機能として導入され、OpenShift Container Platform 4.13 で一般提供が開始されました。IBM Secure Execution は、KVM ゲストのメモリー境界を保護するハードウェア拡張機能です。IBM Secure Execution は、クラスターのワークロードに最高レベルの分離とセキュリティーを提供します。これは、IBM Secure Execution 対応の QCOW2 ブートイメージを使用して有効にすることができます。

IBM Secure Execution を使用するには、ホストマシンのホストキーが必要であり、Ignition 設定ファイルで指定する必要があります。IBM Secure Execution は、LUKS 暗号化を使用してブートボリュームを自動的に暗号化します。

詳細は、IBM Secure Execution を使用した RHCOS のインストール を参照してください。

console.redhat.com の Assisted Installer SaaS は、Assisted Installer ユーザーインターフェイスまたは REST API のいずれかを使用した、IBM Power、IBM Z、IBM® LinuxONE プラットフォームへの OpenShift Container Platform のインストールをサポートします。統合により、ユーザーは単一のインターフェイスからインフラストラクチャーを管理できます。IBM Power、IBM Z、および IBM® LinuxONE と Assisted Installer SaaS の統合を有効にするには、追加でいくつかのインストール手順を実行します。

詳細は、Assisted Installer を使用したオンプレミスクラスターのインストール を参照してください。

OpenShift Container Platform 4.13 には、RHCOS に lsof コマンドが追加されました。

OpenShift Container Platform 4.13 は、VMware vSphere バージョン 8.0 をサポートします。VMware vSphere バージョン 7.0 Update 2 にも引き続き OpenShift Container Platform クラスターをインストールできます。

単一の VMware vCenter で実行される複数の vSphere データセンターまたはリージョンに OpenShift Container Platform クラスターをデプロイできます。各データセンターは、複数のクラスターまたはゾーンを実行できます。この設定により、ハードウェアの障害やネットワークの停止によってクラスターに障害が発生するリスクが軽減されます。

詳細は、「VMware vSphere のリージョンとゾーンの有効化」を参照してください。

vSphere で OpenShift Container Platform のインストールプログラムを実行すると、デフォルトの install-config.yaml ファイルに vcenters および failureDomains フィールドが含まれるようになり、クラスターに複数のデータセンター、リージョン、およびゾーン情報を指定することを選択できるようになりました。VMware vCenter で実行されている単一のデータセンターで設定される vSphere 環境に OpenShift Container Platform クラスターをインストールする場合は、これらのフィールドを空白のままにできます。

詳細は、VMware vCenter のリージョンとゾーンの設定 を参照してください。

OpenShift Container Platform クラスターを、複数のサブネットをサポートする外部ロードバランサーを使用するように設定できます。複数のサブネットを使用する場合は、ロードバランサーターゲットが使用するネットワーク内のすべての IP アドレスを明示的にリストできます。この設定では、ロードバランサーターゲットを再設定せずにネットワーク内でノードを作成および破棄できるため、メンテナンスオーバーヘッドを削減できます。

詳細は、外部ロードバランサーの設定 を参照してください。

OpenShift Container Platform 4.13 では、user-provisioned infrastructure を使用して、VMware vSphere にクラスターをインストールする前に仮想マシンを暗号化できます。

詳細は、仮想マシンの暗号化の要件 を参照してください。

OpenShift Container Platform 4.13 以降、3 ノードクラスターのデプロイは、Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP)、および VMware vSphere でサポートされています。このタイプの OpenShift Container Platform クラスターは、3 つのコントロールプレーンマシンのみから構成され、それがコンピュートマシンとしての役割も果たすため、より小さく、リソース効率の良いクラスターになります。

詳細は、Installing a three-node cluster on AWS､Installing a three-node cluster on Azure､Installing a three-node cluster on GCP､Installing a three-node cluster on vSphere を参照してください。

OpenShift Container Platform クラスターを既存の Virtual Private Cloud (VPC) にデプロイする場合、networkResourceGroupName パラメーターを使用して、これらの既存のリソースを含むリソースグループの名前を指定できるようになりました。この機能強化により、既存の VPC リソースとサブネットを、インストールプログラムがプロビジョニングするクラスターリソースから分離しておくことができます。その後、resourceGroupName パラメーターを使用して、インストーラーによってプロビジョニングされたすべてのクラスターリソースをデプロイするためにインストールプログラムが使用できる既存のリソースグループの名前を指定できます。resourceGroupName が定義されていない場合、クラスターの新しいリソースグループが作成されます。

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

OpenShift Container Platform 4.13 では、事前定義されたロールを使用する代わりに、カスタムロールを定義して、Google Cloud Platform (GCP) が OpenShift Container Platform クラスターをインストールおよび削除するために最低限必要なアクセス許可を含めることができるようになりました。これらの権限は、installer-provisioned infrastructure と user-provisioned infrastructure で利用できます。

OpenShift Container Platform 4.13 では、Azure でタグを設定してリソースをグループ化し、リソースアクセスとコストを管理できます。タグのサポートは、Azure パブリッククラウドで作成されたリソースと、テクノロジープレビュー (TP) としての OpenShift Container Platform 4.13 でのみ使用できます。install-config.yaml ファイルで Azure リソースのタグを定義できるのは、OpenShift Container Platform クラスターの作成時のみです。

OpenShift Container Platform 4.13 では、Google Cloud Platform (GCP) 上の共有 Virtual Private Cloud (VPC) にクラスターをインストールできます。このインストール方法では、VPC を別の GCP プロジェクトと共有するようにクラスターを設定します。共有 VPC を使用すると、組織は複数のプロジェクトから共通 VPC ネットワーク経由でリソースを接続できます。共通 VPC ネットワークでは、内部 IP アドレスを使用することで、組織通信のセキュリティーと効率が向上します。

詳細は、GCP 上のクラスターを共有 VPC にインストール を参照してください。

OpenShift Container Platform 4.13 では、クラスターのインストール時に Shielded VM を使用できます。Shielded VM には、セキュアブート、ファームウェアと整合性の監視、ルートキット検出などの追加のセキュリティー機能があります。詳細は、Shielded VM の有効化 および Google の Shielded VM ドキュメントを参照してください。

OpenShift Container Platform 4.13 では、クラスターのインストール時に Confidential VM を使用できます。Confidential VM は処理中のデータを暗号化します。詳細は、Google のConfidential Computing ドキュメントを参照してください。Confidential VM と Shielded VM を同時に有効にすることができますが、それらは互いに依存していません。

OpenShift Container Platform 4.13 では、AWS VPC を使用するクラスターのインストールプロセスが単純化されました。このリリースでは、AWS Local Zones 用に最適化されたマシンプールである エッジプール も導入されています。

詳細は、AWS Local Zones を使用したクラスターインストール を参照してください。

OpenShift Container Platform 4.16 は Kubernetes 1.29 を使用します。これにより、複数の非推奨 API が削除されました。

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

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

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

OpenShift Container Platform 4.13 では、ビルトインロールを使用する代わりに、カスタムロールを定義して、Microsoft Azure が OpenShift Container Platform クラスターをインストールおよび削除するために最低限必要な権限を含めることができるようになりました。これらの権限は、installer-provisioned infrastructure と user-provisioned infrastructure で利用できます。

OpenShift Container Platform 4.13 では oc adm upgrade --to-multi-arch コマンドが導入され、シングルアーキテクチャーコンピュートマシンを含むクラスターをマルチアーキテクチャーコンピュートマシンを含むクラスターに移行できます。マニフェストにリストされたマルチアーキテクチャーペイロードに更新すると、アーキテクチャーが混在するコンピュートマシンをクラスターに追加できます。

vSphere インストール内のコントロールプレーンノード上で仮想 IP (VIP) アドレスを実行する必要がある場合は、コントロールプレーンノード上で排他的に実行されるように ingressVIP アドレスを設定する必要があります。デフォルトでは、OpenShift Container Platform は、ワーカーマシン設定プールの任意のノードが ingressVIP アドレスをホストすることを許可します。vSphere 環境ではコントロールプレーンノードとは別のサブネットにワーカーノードをデプロイするため、ingressVIP アドレスをコントロールプレーンノードで排他的に実行するように設定すると、ワーカーノードを別のサブネットにデプロイすることに起因する問題の発生を防ぐことができます。詳細は、vSphere のコントロールプレーンで実行されるネットワークコンポーネントの設定 を参照してください。

OpenShift Container Platform 4.13 では、単一ノードを使用してクラスターを Amazon Web Services (AWS) にインストールできます。単一ノードへのインストールでは、ノードのリソース要件が増加します。詳細は、単一ノードへのクラスターのインストール を参照してください。

OpenShift Container Platform 4.13 では、Bare Metal Operator (BMO) およびその他のメタル ³ コンポーネントを使用して、既存の user-provisioned infrastructure クラスター内のベアメタルホストをスケーリングできます。ユーザーがプロビジョニングしたクラスターで Bare Metal Operator を使用すると、ホストの管理とスケーリングを単純化および自動化できます。

BMO を使用すると、BareMetalHost オブジェクトを設定することでホストを追加または削除できます。BareMetalHost オブジェクトインベントリーに既存ホストを externallyProvisioned として登録すると、既存ホストを追跡することもできます。

ユーザーがプロビジョニングしたクラスターを BMO を使用してスケーリングする方法について、詳しくは ユーザーがプロビジョニングしたクラスターの Bare Metal Operator を使用したスケーリング を参照してください。

OpenShift Container Platform 4.13 は、64 ビット ARM アーキテクチャーベースの Azure ユーザープロビジョニングインストールでサポートされるようになりました。Agent ベースのインストールプログラムも、64 ビット ARM システムでサポートされるようになりました。インスタンスの可用性やインストールに関する詳細は、各種プラットフォームのサポートされるインストール方法 を参照してください。

OpenShift Jenkins イメージで git-lfs パッケージがサポートされるようになりました。このパッケージでは、OpenShift Jenkins イメージで 200 メガバイト (MB) を超えるアーティファクトを使用できます。

oc-mirror プラグインを使用して、ディスク上のローカル OCI Operator カタログをミラーレジストリーにミラーリングできるようになりました。これは、OpenShift Container Platform 4.12 でテクノロジープレビュー機能として導入され、OpenShift Container Platform 4.13 で一般提供が開始されました。

このリリースでは、ローカル OCI カタログが含まれる場合に次の機能がサポートされます。

詳細は、ローカル OCI オペレータカタログの追加 を参照してください。

RHOSP 上で、複数の障害ドメインにまたがるクラスターをデプロイできるようになりました。大規模なデプロイメントでは、障害ドメインによって回復力とパフォーマンスが向上します。

詳細は、障害ドメインの RHOSP パラメーター を参照してください。

デフォルトの内部ロードバランサーではなく、ユーザーが管理するロードバランサーを使用して、クラスターを RHOSP にデプロイできるようになりました。

詳細は、ユーザーが管理するロードバランサーを使用した OpenStack 上のクラスターのインストール設定 を参照してください。

OpenShift Container Platform 4.13 では、プロジェクトとカテゴリーを使用して、Nutanix にインストールされたクラスター内のコンピュートプレーン仮想マシンを編成できます。プロジェクトは、権限、ネットワーク、およびその他のパラメーターを管理するためのユーザーロールの論理グループを定義します。カテゴリーを使用すると、共有特性に基づいて仮想マシンのグループにポリシーを適用できます。

詳細は、Nutanix へのクラスターインストール を参照してください。

エージェントベースのインストーラーを使用して OpenShift Container Platform 4.13 をインストールする場合、コンソールアプリケーション (テキストユーザーインターフェイスを使用) はインストールプロセスの初期段階でプルチェックを実行して、現在のホストが設定済みのリリースイメージを取得できることを確認します。コンソールアプリケーションは、ユーザーによるネットワーク設定の直接変更を許可することで、問題のトラブルシューティングをサポートします。

詳細は、現在のインストールホストによるリリースイメージのプルを検証 を参照してください。

マルチアーキテクチャーコンピュートマシンを含む OpenShift Container Platform 4.13 クラスターの一般提供が開始されました。2 日目の操作として、AWS および Azure インストーラーがプロビジョニングしたインフラストラクチャー上に、異なるアーキテクチャーのコンピュートノードを含むクラスターを作成できるようになりました。ベアメタル上でのユーザープロビジョニングインストールはテクノロジープレビュー機能です。マルチアーキテクチャーコンピュートマシンを使用したクラスター作成の詳細は、OpenShift Container Platform クラスターでのマルチアーキテクチャーコンピュートマシンの設定 を参照してください。

管理者は、VMware vSphere インスタンスで実行される OpenShift Container Platform クラスターに複数の障害ドメインを指定できます。これは、主要なコントロールプレーンとワークロード要素をデータセンターのさまざまなハードウェアリソースに分散できることを意味します。さらに、ノード間のデータ転送が複数のネットワークにまたがるように、複数のレイヤー 2 ネットワーク設定を使用するようにクラスターを設定できます。

詳細は、Specifying multiple regions and zones for your cluster on vSphere を参照してください。

このリリースでは、Web コンソールの Developer パースペクティブで次のアクションを実行できるようになりました。

OpenShift Container Platform 4.13 では、--run-namespace フラグが oc adm must-gather コマンドで使用できるようになりました。このフラグを使用して、must-gather ツールを実行する既存の名前空間を指定できます。

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

OpenShift Container Platform 4.13 では、新しい oc コマンドラインインターフェイス (CLI) フラグ --import-mode が以下の oc コマンドに追加されました。

今回の機能強化により、ユーザーは --import-mode フラグを Legacy または PreserveOriginal に設定できます。これにより、oc import-image または oc tag コマンドの実行時にマニフェストリストの単一のサブマニフェストまたはすべてのマニフェストをインポートするオプションがユーザーに提供されます。

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

OpenShift Container Platform 4.13 では、イメージで oc describe を実行すると、各マニフェストの os/arch およびダイジェストが返されるようになりました。

OpenShift Container Platform 4.13 でじゃ、イメージストリーム上のマニフェストにリストされたイメージのサポートが一般提供されるようになりました。

OpenShift Container Platform の etcd 暗号化を有効にする場合に、AES-GCM 暗号化タイプがサポートされるようになりました。AES-GCM 暗号化タイプの暗号化キーは毎週ローテーションされます。

詳細は、サポートされている暗号化タイプ を参照してください。

今回の更新により、MetalLB IPAddressPool リソースからサービス、名前空間、またはその両方に IP アドレスを割り当てることができます。これは、MetalLB が IP アドレスプールから特定のサービスおよび名前空間に IP アドレスを固定する必要があるマルチテナントのベアメタル環境で役立ちます。多くの IP アドレスプールからサービスと名前空間に IP アドレスを割り当てることができます。次に、これらの IP アドレスプールの優先度を定義して、MetalLB が優先度の高い IP アドレスプールから IP アドレスを割り当てるようにすることができます。

IP アドレスプールからサービスおよび名前空間への IP アドレスの割り当ての詳細は、Configuring MetalLB address pools を参照してください。

この更新により、以下の方法を使用して、OpenShift Container Platform クラスターを 2 つの物理機能 (PF) 上の 2 つの仮想機能 (VF) を持つボンディングインターフェイスにデプロイできるようになります。

デュアルポート NIC を備えたノードに OpenShift Container Platform をインストールする方法について、詳しくは SR-IOV デバイスの NIC パーティショニング を参照してください。

このリリースでは、BlueField-2 ネットワークデバイスのデータ処理ユニット (DPU) モードからネットワークインターフェイスコントローラー (NIC) モードへの切り替えが一般的に利用可能になりました。

詳細は、Switching BlueField-2 from DPU to NIC を参照してください。

OpenShift Container Platform 4.13 では、ネットワークカードの MT2892 Family [ConnectX-6 Dx] で OvS ハードウェアオフロードのサポートが追加されました。

詳細は、サポート対象のデバイス を参照してください。

OVN-Kubernetes ネットワークプラグインを使用している場合は、OpenShift SDN ネットワークプラグインに移行できます。

詳細は、OpenShift SDN ネットワークプラグインへの移行を 参照してください。

OpenShift Container Platform 4.13 は CoreDNS を 1.10.1 に更新します。CoreDNS は、元のクライアントクエリーで指定された DNSSEC DO ビットを使用するようになりました。これにより、クライアントが DNSSEC を要求していない場合、DNS 応答の UDP パケットサイズが削減されます。パケットサイズが小さくなると、TCP 接続の再試行が減るため、DNS 切り捨ての可能性と全体的な DNS 帯域幅の両方が減少します。

クラスターへのノードの追加をサポートするために、クラスターネットワークを拡張できます。たとえば、クラスターをデプロイし、クラスターネットワーク範囲として 10.128.0.0/19 を指定し、ホスト接頭辞 23 を指定した場合、16 ノードに制限されます。クラスターの CIDR マスクを /14 に変更することで、これを 510 ノードに拡張できます。詳細は、クラスターネットワーク範囲の設定 を参照してください。

インストーラーがプロビジョンした vSphere クラスターでは、IPv4 をプライマリー IP ファミリーとして、IPv6 をセカンダリーアドレスファミリーとして使用したデュアルスタックネットワークを使用できます。詳細は、ネットワーク設定パラメーター を参照してください。

ベアメタルにクラスターをインストールする際に、IPv6 をデュアルスタッククラスター上のプライマリー IP アドレスファミリーとして設定できます。新しいクラスターのインストール時にこの機能を有効にするには、マシンネットワーク、クラスターネットワーク、サービスネットワーク、API VIP、イングレス VIP の IPv4 アドレスファミリーの前に IPv6 アドレスファミリーを指定します。

詳細は以下を参照してください。

このリリースでは、Red Hat OpenShift Networking OVN-Kubernetes ネットワークプラグインで、Pod のセカンダリーネットワークインターフェイスを設定できます。OVN-Kubernetes は、セカンダリーネットワークとしてレイヤー 2 (switched) トポロジーネットワークをサポートします。これはテクノロジープレビュー機能として利用できます。

セカンダリーネットワークとしての OVN-Kubernetes について、詳しくは OVN-Kubernetes 追加ネットワークの設定 を参照してください。

OpenShift Container Platform 4.13 では、nodeSelector が OVN-Kubernetes ネットワークプラグインの egress ファイアウォールの宛先仕様に追加されました。この機能を使用すると、ユーザーは 1 つまたは複数のノードにラベルを追加でき、選択したノードの IP アドレスが関連するルールに含まれます。詳細は、EgressFirewall の nodeSelector の例 を参照してください。

RHOSP 上で実行され、Kuryr を使用するクラスターを OVN-Kubernetes に移行できるようになりました。

詳細は、Kuryr ネットワークプラグインから OVN-Kubernetes ネットワークプラグインへの移行 を参照してください。

RHOSP 上で実行され、OVN-Kubernetes を使用するクラスターの場合、予約ポートにフローティング IP アドレスを手動で再割り当てを行う必要がなくなりました。予約ポートが 1 つのノードから削除され、別のノードで再作成された場合、再割り当ては自動的に実行されます。

OpenShift Container Platform 4.13 はで、以下の SR-IOV デバイスのサポートが追加されました。

詳細は、サポート対象のデバイス を参照してください。

この更新により、AWS のデフォルトの認証情報要求が変更され、Key Management Service (KMS) での再暗号化に顧客が管理するキーを使用できるようになりました。手動モードを使用するように Cloud Credential Operator (CCO) が設定されているクラスターの場合、管理者は kms:ReEncrypt* 権限をキーポリシーに追加して、これらの変更を手動で適用する必要があります。他の管理者は、この変更による影響を受けません。(OCPBUGS-5410)

OpenShift Container Platform 4.13 では、IPv4 および IPv6 ネットワーク環境のデュアルスタックで LVM ストレージがサポートされます。詳細は、デュアルスタッククラスターネットワークへの変換 を参照してください。

OpenShift Container Platform 4.13 では、GitOps ZTP 経由で論理ボリュームマネージャーストレージ (LVM ストレージ) を追加および設定できます。詳細は、PolicyGenTemplate CR を使用した LVM ストレージの設定 と LVM ストレージ を参照してください。

OpenShift Container Platform 4.13 では、非接続環境に LVM ストレージをインストールできます。詳細は、非接続環境での LVM ストレージのインストール を参照してください。

ユーザー管理型の暗号化機能を使用すると、インストール中に OpenShift Container Platform ノードのルートボリュームを暗号化するキーを指定でき、すべてのマネージドストレージクラスはこれらのキーを使用してプロビジョニングされたストレージボリュームを暗号化できます。これにより、プラットフォームのデフォルトのアカウントキーではなく、選択したキーを使用してストレージボリュームを暗号化できます。

この機能は、次のストレージタイプをサポートします。

Container Storage Interface (CSI) ドライバーは、ノードが正常にシャットダウンしない場合はボリュームを自動的にデタッチできるようになりました。ノードが正常にシャットダウンしなかった場合、ノードに out-of-service テイントを手動で追加し、ノードからボリュームを自動的にデタッチできます。これはテクノロジープレビュー機能としてサポートされています。

詳細は、正常ではないノードシャットダウン後の CSK ボリュームのデタッチ を参照してください。

vSphere 上で実行されている OpenShift Container Platform 上の仮想マシン (VM) と永続ボリューム (PV) を暗号化できます。

詳細は、vSphere 永続ディスクの暗号化 を参照してください。

OpenShift Container Platform 4.12 では、異なるゾーンおよびリージョンに OpenShift Container Platform for vSphere をデプロイする機能が導入されました。この機能を使用することで、複数のコンピュートクラスターにデプロイできるため、単一障害点を回避するのに役立ちます。OpenShift Container Platform 4.13 では、複数のデータセンターにまたがるデプロイと、インストール中またはインストール後に作成された障害ドメインを使用したトポロジーのセットアップに対するサポートが導入されました。

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

OpenShift Container Platform 4.13 では、複数のデフォルトストレージクラスを作成できます。この機能を使用すると、デフォルトとして定義された 2 番目のストレージクラスを作成できるため、デフォルトのストレージクラスを容易に変更できます。その後は、以前のデフォルトストレージクラスからデフォルトステータスを削除するまで、一時的に 2 つのデフォルトストレージクラスが存在することになります。短期間であればデフォルトストレージクラスが複数存在することも許容されますが、最終的に存在するデフォルトストレージクラスは 1 つにする必要があります。

詳細は、デフォルトストレージクラスの変更 および 複数のデフォルトストレージクラス を参照してください。

OpenShift Container Platform 4.13 では、ClusterCSIDriver オブジェクトに spec.storageClassState フィールドが導入されました。これにより、OpenShift Container Platform によって生成されたデフォルトのストレージクラスを管理して、いくつかの目的を達成できます。

詳細は、デフォルトストレージクラスの管理 を参照してください。

以前は、デフォルトのストレージクラスがない場合、デフォルトのストレージクラスを要求した作成済みの永続ボリューム要求 (PVC) は、手動で削除して再作成しない限り、無期限に保留状態のままでした。OpenShift Container Platform は、これらの PVC にデフォルトストレージクラスを遡って割り当てることができるようになり、保留状態のままにはならなくなりました。この機能を有効にすると、デフォルトストレージクラスが作成されるか、いずれかの既存ストレージクラスがデフォルトとして宣言された後、保留されていたこれらの PVC がデフォルトストレージクラスに割り当てられます。

これはテクノロジープレビュー機能としてサポートされています。

詳細は、デフォルトのストレージクラスが存在しない を参照してください。

OpenShift Container Platform は、IBM Power Virtual Server Block Storage の Container Storage Interface (CSI) ドライバーを使用して永続ボリューム (PV) をプロビジョニングできます。

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

Container Storage Interface (CSI) のインライン一時ボリュームは、テクノロジープレビュー機能として OpenShift Container Platform 4.5 に導入されました。これにより、Pod のデプロイ時にインライン一時ボリュームを作成し、Pod の破棄時にインライン一時ボリュームを削除する Pod 仕様を定義できます。現在、この機能は一般提供されています。

この機能は、サポートされている Container Storage Interface (CSI) ドライバーでのみ利用できます。

この機能には、CSI Volume Admission プラグインも含まれており、このプラグインを使用すると、CSI 一時ボリュームをプロビジョニングできる個別の CSI ドライバーの使用を Pod 受け入れ時に制限できるメカニズムを追加できます。管理者またはディストリビューションは、CSIDriver オブジェクトに csi-ephemeral-volume-profile ラベルを追加できます。その後、ラベルは Admission プラグインによって検査され、強制、警告、および監査を決定するために使用されます。

詳細は、CSI インライン一時ボリューム を参照してください。

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

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

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

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

この機能は in-tree オブジェクトを自動的に対応する CSI 表現に変換するため、ユーザーに対して完全に透過的である必要があります。in-tree ストレージプラグインを参照するストレージクラスは引き続き機能しますが、デフォルトのストレージクラスを CSI ストレージクラスに切り替えることが推奨されます。

OpenShift Container Platform 4.8 以降、インツリーボリュームプラグインの同等の Container Storage Interface (CSI) ドライバーへの自動移行がテクノロジープレビュー機能として利用可能になりました。OpenShift Container Platform 4.10 では、この機能で vSphere のサポートが提供されていました。OpenShift Container Platform 4.13 では、vSphere の自動移行に対するサポートが一般提供されています。

OpenShift Container Platform 4.13 以降の新規インストールの場合、自動移行はデフォルトで有効になっています。OpenShift Container Platform 4.12 以前から 4.13 へのアップグレードでは、ユーザーがオプトインした場合に限り vSphere の自動 CSI 移行が発生します。移行をオプトインする前に、提示された影響を慎重に確認してください。

以下の条件が すべて 該当する場合、OpenShift Container Platform 4.12 から 4.13、および 4.13 から 4.14 への更新はブロックされます。

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

クロスアカウントのサポートにより、1 つの Amazon Web Services (AWS) アカウントに OpenShift Container Platform クラスターを配置し、AWS Elastic File System (EFS) Container Storage Interface (CSI) ドライバーを使用して別の AWS アカウントにファイルシステムをマウントできます。

詳細は、AWS EFS CSI クロスアカウントのサポート を参照してください。

この機能により、ボリュームがマウントされている場合に OpenShift Container Platform は Pod の FSGroup を Container Storage Interface (CSI) ドライバーに提供できます。Microsoft Azure File CSI ドライバーはこの機能に依存します。

OpenShift Container Platform 4.13 による、Network File System (NFS) を備えた Azure File Container Storage Interface (CSI) Driver Operator のサポートの一般提供を開始しました。

詳細は、NFS サポート を参照してください。

OpenShift Container Platform 4.13 では、次の OpenShift CLI (oc) コマンドを実行することで、システムにインストールできる Operator のバージョンとチャネルを確認できます。

$ oc describe packagemanifests <operator_name> -n <catalog_namespace>

次のコマンドを実行して、Operator のバージョンとチャネル情報の出力形式を指定できます。

$ oc get packagemanifests <operator_name> -n <catalog_namespace> -o <output_format>

詳細は、特定の Operator バージョンのインストール を参照してください。

Operator Lifecycle Manager (OLM) のデフォルトの動作は、Operator のインストール時に簡素化することを目的としています。ただし、この動作は、特にマルチテナントクラスターでは柔軟性に欠ける場合があります。

次のトピックに、マルチテナントクラスターでの Operator 管理に関するガイダンスと推奨ソリューションが追加されました。

Operator Lifecycle Manager (OLM) は、同じ namespace にインストールされている OLM-managed Operator を処理します。つまり、それらの Subscription リソースは、関連する Operator として同じ namespace に配置されます。それらが実際には関連していなくても、いずれかが更新されると、OLM はバージョンや更新ポリシーなどの状態を考慮します。

次のコピックに、Operator のコロケーションに関するガイダンスと、カスタム namespace を使用する代替手順が追加されました。

OpenShift Container Platform Web コンソールが更新され、コピーされたクラスターサービスバージョン (CSV) がクラスター上で無効になっている場合の Operator 検出が向上しました。

コピーされた CSV がクラスター管理者によって無効にされている場合、実際にはすべての namespace に CSV がコピーされていなくても、openshift namespace からコピーされた CSV を通常ユーザーのすべての namespace に表示するように Web コンソールが変更されます。これにより、通常ユーザーは、namespace でこれらの Operator の詳細を表示したり、グローバルにインストールされた Operator が提供するカスタムリソース (CR) を作成したりできます。

詳細は、コピーした CSV の無効化 を参照してください。

このリリースでは、Operator の作成者は、サジェストされた namespace にデフォルトのノードセレクターを設定できます。ここで、Operator が実行されます。サジェストされた namespace は、ClusterServiceVersion (CSV) に含まれる YAML の namespace マニフェストを使用して作成されます。OperatorHub を使用して Operator をクラスターに追加する場合、Web コンソールはインストールプロセス時にクラスター管理者にサジェストされる namespace を自動設定します。

詳細は、サジェストされた namespace をデフォルトノードセレクターを使用して設定 を参照してください。

Node Tuning Operator (NTO) は、NodeTuning クラスター機能を使用して有効化/無効化できるようになりました。クラスターのインストール時に無効にした場合は、後で再度有効にできます。詳細は、ノードチューニング機能 を参照してください。

詳細は、Control Plane Machine Set Operator のスタートガイド を参照してください。

Red Hat Enterprise Linux CoreOS (RHCOS) イメージ階層化の一般提供が開始されました。この機能を使用すると、ベースイメージに追加のイメージを重ねることで、ベース RHCOS イメージ機能を拡張できます。

詳細は、Red Hat Enterprise Linux CoreOS (RHCOS) イメージの階層化 を参照してください。

Red Hat Enterprise Linux CoreOS (RHCOS) イメージの階層化を使用して、Red Hat Enterprise Linux (RHEL) およびサードパーティーパッケージをクラスターノードに追加できるようになりました。

詳細は、Red Hat Enterprise Linux CoreOS (RHCOS) イメージの階層化 を参照してください。

RHCOS core ユーザーのパスワードを作成できるようになりました。SSH または oc debug node コマンドを使用してノードにアクセスできない場合、このパスワードを使用すると、core ユーザーを使用して、クラウドプロバイダーのシリアルコンソールまたはベアメタルベースボードコントローラーマネージャー (BMC) を介してノードにアクセスできます。

詳細は、Changing the core user password for node access を参照してください。

ダイジェスト仕様に加えてイメージタグを使用して、ミラーリングされたレジストリーからイメージをプルできるようになりました。この変更を実現するために、ImageContentSourcePolicy (ICSP) オブジェクトは非推奨になりました。ImageDigestMirrorSet (IDMS) オブジェクトを使用してダイジェスト仕様を使用してイメージをプルするか、ImageTagMirrorSet (ITMS) オブジェクトを使用してイメージタグを使用してイメージをプルできるようになりました。

ICSP オブジェクトの作成に使用した既存の YAML ファイルがある場合は、oc adm migrate icsp コマンドを使用して、それらのファイルを IDMS YAML ファイルに変換できます。

これらの新しいオブジェクトの詳細は、Configuring image registry repository mirroring を参照してください。

既存の ICSP YAML ファイルを IDMS YAML ファイルに変換する方法の詳細は、Converting ImageContentSourcePolicy (ICSP) files for image registry repository mirroring 参照してください。

crun 低レベルコンテナーランタイムは、OpenShift Container Platform 4.13 で一般提供されるようになりました。GA バージョンには新しい機能はありません。

Linux Control Group バージョン 2 (cgroup v2) が OpenShift Container Platform 4.13 で一般提供されるようになりました。GA バージョンには新しい機能はありません。

このリリースでは、テクノロジープレビュー機能として、Pod Disruption Budget (PDB) に対する不健全な Pod エビクションポリシーを指定できます。これは、ノードドレイン中に誤動作しているアプリケーションを排除するのに役立ちます。

このテクノロジープレビュー機能を使用するには、TechPreviewNoUpgrade 機能セットを有効にする必要があります。

詳細は、異常な Pod のエビクションポリシーの指定 を参照してください。

これまで、Machine Health Checks では自己修復または自己ノード修復プロバイダーの使用が可能でした。このリリースでは、新しい Metal3 修復プロバイダーもベアメタルクラスターでサポートされます。

詳細は、ベアメタルの電源ベースの修復について を参照してください。

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

このリリースでは、コアプラットフォームモニタリングおよびユーザー定義プロジェクトの Alertmanager 設定にシークレットを追加できます。Alertmanager がアラートを送信できるようにレシーバーで認証する必要がある場合は、レシーバーの認証情報を含むシークレットを使用するように Alertmanager を設定できます。

このリリースでは、次の Cluster Monitoring Operator (CMO) config map 設定をカスタマイズできます。次の node-exporter コレクターはオプションとなり、有効または無効にできます。

OpenShift Container Platform Web コンソールで、ノード関連のモニタリングダッシュボードのデータを、ノードのロールに基づきフィルタリングできるようになりました。ワーカーノードなど、特定のロールを持つノードのダッシュボードデータのみを表示したい場合は、この新しいフィルターを使用して、該当するノードロールをすばやく選択できます。

このリリースでは、デフォルトのプラットフォームモニタリングのためのテクノロジープレビュー機能が導入されており、管理者はメトリクスコレクションプロファイルを設定して、デフォルトの量または最小限の量のメトリクスデータを収集できます。最小プロファイルを有効にすると、アラートなどの基本的なモニタリング機能は引き続き動作しますが、Prometheus が必要とする CPU およびメモリーリソースは減少します。

NUMA Resources Operator を使用した NUMA 対応スケジューリングは、OpenShift Container Platform 4.10 でテクノロジープレビューとして以前に導入され、OpenShift Container Platform 4.13 で一般的に利用可能になりました。

NUMA Resources Operator は、クラスター内で使用可能な NUMA ゾーンの全体像に基づいて、ワークロードのスケジューリングを決定する NUMA 対応のセカンダリースケジューラーをデプロイします。この強化された NUMA 対応のスケジューリングにより、レイテンシーの影響を受けやすいワークロードが単一の NUMA ゾーンで処理され、効率とパフォーマンスが最大化されます。

この更新により、次の機能が追加されます。

詳細は、「NUMA 対応ワークロードのスケジューリング」を参照してください。

今回の更新まで、ワークロードパーティション設定はシングルノードの OpenShift クラスターでのみサポートされていました。この更新により、3 ノードのコンパクトクラスターと標準クラスターのワークロードパーティション設定も可能になりました。ワークロードパーティション設定を使用して、OpenShift Container Platform サービス、クラスター管理ワークロード、およびインフラストラクチャー Pod を分離し、予約された CPU セットで実行できます。

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

OpenShift Container Platform 4.12 では、重要なワークロードと重要でないワークロードの電源状態を設定する機能が導入されました。OpenShift Container Platform 4.13 では、GitOps ZTP を使用して電源状態を設定できます。

この機能の詳細は、PolicyGenTemplates CR を使用した電源状態の設定 を参照してください。

このリリースでは、GitOps ZTP で使用する 2 つの新しい Topology Aware Lifecycle Manager (TALM) 機能が追加されました。

詳細は コンテナーイメージの事前キャッシュフィルターの使用 を参照してください。

HTTP は、PTP およびベアメタルイベントインフラストラクチャーのデフォルトトランスポートになりました。AMQ Interconnect は 2024 年 6 月 30 日にライフサイクル終了 (EOL) となります。

詳細は、PTP 高速イベント通知フレームワークについて を参照してください。

PTP Operator を使用して、Intel E810 Westport Channel NIC を PTP グランドマスタークロックとして設定できるようになりました。PTP グランドマスタークロックは、システムクロックとネットワーク時刻の同期に ts2phc (タイムスタンプ 2 物理クロック) を使用します。

詳細は、linuxptp サービスをグランドマスタークロックとして設定する を参照してください。

GitOps ZTP ztp-site-generate コンテナーに、crun をデフォルトのコンテナーランタイムに設定する ContainerRuntimeConfig CR が追加されました。

GitOps ZTP を使用してインストールするクラスターのパフォーマンスを最適化するには、追加の Day 0 installation manifest CR と併せて、シングルノード OpenShift、3 ノード OpenShift、および標準クラスターのコントロールプレーンとワーカーノードに対して crun を有効にします。

詳細は、crun をデフォルトのコンテナーランタイムに設定 を参照してください。

OpenShift Container Platform ドキュメントで、etcd のメリットや仕組みを含めた概要を参照できるようになりました。etcd は、Kubernetes のプライマリーデータストアとして、OpenShift Container Platform でのクラスターの設定と管理に対する信頼性の高いアプローチを etcd Operator を介して提供します。詳細は、etcd の概要 を参照してください。

OpenShift Container Platform のドキュメントに、ホストされたコントロールプレーン専用のセクションが追加されました。ここでは、ホストされたクラスターの設定と管理に関連する機能および情報が記載されています。詳細は、ホストされたコントロールプレーン を参照してください。

OpenShift Container Platform のドキュメントに、ホストされたコントロールプレーンの更新に関する情報が追加されました。ホストされたコントロールプレーンの更新には、ホストされたクラスターとノードプールの更新が含まれます。詳細は、「Hosted Control Plane の更新」を参照してください。