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

今回のリリースでは、以下のコンポーネントおよび概念に関連する拡張機能が追加されました。

1.3.1. Red Hat Enterprise Linux CoreOS (RHCOS)

1.3.1.1. RHCOS は RHEL 9.2 を使用するようになりました

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

1.3.1.1.1. OpenShift Container Platform with RHEL 9.2 へのアップグレードに関する考慮事項

このリリースでは、OpenShift Container Platform 4.13 に RHEL 9.2 ベースの RHCOS が導入されており、アップグレードする前に考慮が必要な点がいくつかあります。

  • RHEL 8.6 と RHEL 9.2 では一部のコンポーネント設定オプションとサービスが変更されている可能性があります。これは、既存のマシン設定ファイルが無効になっている可能性があることを意味します。
  • デフォルトの OpenSSH /etc/ssh/sshd_config サーバー設定ファイルをカスタマイズした場合は、この Red Hat ナレッジベースの記事 に従ってファイルを更新する必要があります。
  • RHEL 6 ベースのイメージコンテナーは RHCOS コンテナーホストではサポートされていませんが、RHEL 8 ワーカーノードではサポートされています。詳細は、Red Hat コンテナー互換性 マトリクスを参照してください。
  • 一部のデバイスドライバーは非推奨になりました。詳細は、RHEL ドキュメント を参照してください。

1.3.1.2. installer-provisioned infrastructure を使用する IBM Power Virtual Server (テクノロジープレビュー)

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

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

1.3.1.3. IBM Z および IBM(R) LinuxONE での IBM Secure Execution

この機能は、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 のインストール を参照してください。

1.3.1.4. Assisted Installer SaaS は、IBM Power、IBM Z、IBM (R) LinuxONE のプラットフォーム統合サポートを提供します。

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 を使用したオンプレミスクラスターのインストール を参照してください。

1.3.1.5. RHCOS に lsof を追加

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

1.3.2. インストールおよび更新

1.3.2.1. VMware vSphere バージョン 8.0 のサポート

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

1.3.2.2. VMware vSphere のリージョンとゾーンの有効化

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

重要

VMware vSphere のリージョンおよびゾーン有効化機能は、クラスター内のデフォルトのストレージドライバーとして vSphere Container Storage Interface (CSI) ドライバーを必要とするため、新しくインストールされたクラスターでのみ使用できます。

以前のリリースからアップグレードされたクラスターは、デフォルトでツリー内 vSphere ドライバーを使用します。そのため、この機能を使用するには、クラスターの CSI 自動移行を有効にする必要があります。その後、アップグレードされたクラスターに対して複数のリージョンとゾーンを設定できます。

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

1.3.2.3. デフォルトの vSphere install-config.yaml ファイルへの変更

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

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

1.3.2.4. 複数の vSphere サブネットをサポートする外部ロードバランサー

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

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

1.3.2.5. VMware vSphere にクラスターをインストール前の仮想マシン暗号化をサポート

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

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

1.3.2.6. 3 ノードクラスターのサポート

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 AWSInstalling a three-node cluster on AzureInstalling a three-node cluster on GCPInstalling a three-node cluster on vSphere を参照してください。

1.3.2.7. IBM Cloud VPC と既存の VPC リソース

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

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

1.3.2.8. GCP が OpenShift Container Platform クラスターをインストールおよび削除するために最低限必要な権限

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

1.3.2.9. Azure のユーザー定義タグ

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

1.3.2.10. GCP 上の OpenShift Container Platform クラスターを共有 Virtual Private Cloud (VPC) にインストール

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

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

1.3.2.11. Shielded VM を使用した GCP へのクラスターのインストール

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

1.3.2.12. Confidential VM を使用した GCP へのクラスターのインストール

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

重要

OpenShift Container Platform 4.13.3 以前のバージョンにおける既知の問題により、Google Cloud Platform (GCP) 上の Confidential 仮想マシンが含まれるクラスターでは、永続ボリュームストレージを使用できません。この問題は OpenShift Container Platform 4.13.4 で解決されています。詳細は、OCPBUGS-11768 を参照してください。

1.3.2.13. AWS 上のクラスターを既存の Virtual Private Cloud (VPC) にインストールするプロセスの改善

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

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

1.3.2.14. OpenShift Container Platform 4.12 から 4.13 へのアップグレードには管理者承認が必要

OpenShift Container Platform 4.14 は Kubernetes 1.27 を使用します。これにより、複数の非推奨 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.13 への更新の準備 を参照してください。

1.3.2.15. Microsoft Azure が OpenShift Container Platform クラスターをインストールおよび削除するために必要な最小限の権限

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

1.3.2.16. シングルアーキテクチャーからマルチアーキテクチャーペイロードへの移行

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

1.3.2.17. vSphere のコントロールプレーン上で実行されるネットワークコンポーネントの設定

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

1.3.2.18. 単一ノードを使用した AWS への OpenShift Container Platform クラスターのインストール

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

1.3.2.19. ユーザーがプロビジョニングしたクラスター内で Bare Metal Operator を使用してベアメタルホストをスケーリング

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

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

注記

Bare Metal Operator では、プロビジョニングネットワークを使用して、user-provisioned infrastructure クラスターをスケーリングすることはできません。このワークフローはプロビジョニングネットワークをサポートしていないため、仮想メディアネットワークの起動をサポートするベアメタルホストドライバー (redfish-virtualmediaidrac-virtualmedia など) のみを使用できます。

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

1.3.2.20. 64-bit ARM での OpenShift Container Platform

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

1.3.2.21. git-lfs パッケージのサポート

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

1.3.2.22. oc-mirror プラグインを使用したローカル OCI Operator カタログの追加機能の一般提供を開始

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

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

  • ターゲットミラーレジストリーからのイメージのプルーニング
  • 前回ツールを実行してから変更された内容のみをミラーリングする増分ミラーリング
  • ターゲットミラーレジストリー内におけるカタログの代替名の namespace 階層
重要
  • OpenShift Container Platform 4.12 のテクノロジープレビュー機能である oc-mirror プラグインの OCI ローカルカタログ機能を使用していた場合、完全に切断されたクラスターにミラーリングするための最初の手順として、oc-mirror プラグインの OCI 機能を使用してローカルにカタログをコピーしてから OCI 形式に変換することができなくなりました。
  • ローカル OCI カタログをミラーリングする場合、ローカル OCI 形式のカタログとともにミラーリングする OpenShift Container Platform リリースまたは追加のイメージをレジストリーからプルする必要があります。OCI カタログを oc-mirror イメージセットファイルと一緒にディスク上でミラーリングすることはできません。
  • --use-oci-feature フラグは非推奨になりました。代わりに --include-local-oci-catalogs フラグを使用して、ローカル OCI カタログのミラーリングを有効にします。

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

1.3.2.23. RHOSP 上での障害ドメインを使用するクラスターのデプロイ (テクノロジープレビュー)

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

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

1.3.2.24. RHOSP 上での、ユーザーが管理するロードバランサーを含むクラスターのデプロイ (テクノロジープレビュー)

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

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

1.3.2.25. Nutanix にクラスターをインストールする際のプロジェクトとカテゴリーの使用

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

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

1.3.2.26. エージェントベースのインストーラーがネットワーク接続チェックを実行

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

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

1.3.3. インストール後の設定

1.3.3.1. マルチアーキテクチャーコンピュートマシンを含む OpenShift Container Platform クラスター

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

1.3.3.2. vSphere 上のクラスターに複数の障害ドメインを指定する

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

詳細は、VSphere 上のクラスターに複数の障害ドメインの指定 を参照してください。

1.3.4. Web コンソール

1.3.4.1. Developer パースペクティブ

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

  • Import from Git フローを使用して、Serverless Function を作成します。
  • Add ページCreate Serverless Function フローを使用して、Serverless Function を作成します。
  • Import from Git ワークフローで、オプションとして Pipeline-as-code を選択します。
  • ユーザーインターフェイスの次の場所でトラフィックを受信している Pod を確認します。

    • Topology ビューのサイドペイン
    • Pod の Details ビュー
    • Pod リストビュー
  • Web Terminal をインスタンス化するときに、タイムアウト期間をカスタマイズするか、独自のイメージを指定します。
  • 管理者は、すべてのユーザーの Developer パースペクティブナビゲーションにデフォルトのリソースが予め固定されるように設定します。
1.3.4.1.1. Pipelines ページを改善

OpenShift Container Platform 4.13 では、Pipelines ページのナビゲーションが以下のとおり改善されました。

  • Pipelines ページに戻っても、前に選択したタブが表示されたままになります。
  • Repository details ページのデフォルトタブは PipelinesRuns になりましたが、Create Git Repository フローに従っている場合、デフォルトタブは Details になります。
1.3.4.1.2. Helm ページの改善

OpenShift Container Platform 4.13 では、Helm ページに次の新機能と更新された機能が追加されました。

  • このページで使用される用語は、Helm チャートのインストールとアンインストールではなく、Helm リリースの作成と削除を意味します。
  • Helm リリースを非同期的に作成および削除でき、アクションの完了を待たずに Web コンソールで次のタスクを実行できます。
  • Helm リリースリストに Status 列が追加されました。

1.3.5. OpenShift CLI (oc)

1.3.5.1. 指定された名前空間で must-gather を実行するための新しいフラグが追加されました

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

詳細は、About the must-gather tool を参照してください。

1.3.5.2. OpenShift CLI (oc) を使用したマニフェストのインポート

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

  • oc import-image
  • oc tag

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

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

1.3.5.3. イメージの os/arch とダイジェストを返す

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

1.3.6. IBM Z and IBM(R) LinuxONE

本リリースでは、IBM Z および IBM® LinuxONE は OpenShift Container Platform 4.13 と互換性があります。インストールは、z/VM または Red Hat Enterprise Linux (RHEL) Kernel-based Virtual Machine (KVM) を使用して実行できます。インストール手順については、以下のドキュメントを参照してください。

重要

コンピュートノードは Red Hat Enterprise Linux CoreOS (RHCOS) を実行する必要があります。

IBM Z および IBM(R) LinuxONE の主な機能拡張

OpenShift Container Platform 4.13 の IBM Z および IBM® LinuxONE リリースでは、OpenShift Container Platform のコンポーネントと概念に、改良点と新機能が追加されました。

このリリースでは、IBM Z および IBM® LinuxONE 上で次の機能がサポートされます。

  • アシステッドインストーラー
  • Cluster Resource Override Operator
  • Egress IP
  • MetalLB Operator
  • Network-Bound Disk Encryption - 外部 Tang サーバー
IBM Secure Execution

OpenShift Container Platform は、IBM Z および IBM® LinuxONE (s390x アーキテクチャー) 上における IBM Secure Execution 用の Red Hat Enterprise Linux CoreOS (RHCOS) ノードの設定をサポートするようになりました。

インストール手順については、以下のドキュメントを参照してください。

1.3.7. IBM Power

このリリースでは、IBM Power は OpenShift Container Platform 4.13 と互換性があります。インストール手順については、以下のドキュメントを参照してください。

重要

コンピュートノードは Red Hat Enterprise Linux CoreOS (RHCOS) を実行する必要があります。

IBM Power の主な機能強化

OpenShift Container Platform 4.13 の IBM Power リリースでは、OpenShift Container Platform のコンポーネントと概念に改良点と新機能が追加されました。

このリリースでは、IBM Power で次の機能がサポートされます。

  • アシステッドインストーラー
  • Cluster Resource Override Operator
  • IBM Power Virtual Server Block CSI Driver Operator (テクノロジープレビュー)
  • Egress IP
  • IBM Power Virtual Server の installer-provisioned infrastructure の有効化 (テクノロジープレビュー)
  • MetalLB Operator
  • Network-Bound Disk Encryption - 外部 Tang サーバー

IBM Power、IBM Z、IBM(R) LinuxONE サポートマトリクス

表1.1 OpenShift Container Platform の機能

機能IBM PowerIBM Z および IBM® LinuxONE

代替の認証プロバイダー

サポート対象

サポート対象

Assisted Installer

サポート対象

サポート対象

ローカルストレージ Operator を使用した自動デバイス検出

サポート対象外

サポート対象

マシンヘルスチェックによる障害のあるマシンの自動修復

サポート対象外

サポート対象外

IBM Cloud 向けクラウドコントローラーマネージャー

サポート対象

サポート対象外

オーバーコミットの制御およびノード上のコンテナーの密度の管理

サポート対象外

サポート対象外

Cron ジョブ

サポート対象

サポート対象

Descheduler

サポート対象

サポート対象

Egress IP

サポート対象

サポート対象

etcd に保存されるデータの暗号化

サポート対象

サポート対象

Helm

サポート対象

サポート対象

Horizontal Pod Autoscaling

サポート対象

サポート対象

IPv6

サポート対象

サポート対象

ユーザー定義プロジェクトのモニタリング

サポート対象

サポート対象

マルチパス化

サポート対象

サポート対象

Network-Bound Disk Encryption - 外部 Tang サーバー

サポート対象

サポート対象

不揮発性メモリーエクスプレスドライブ (NVMe)

サポート対象

サポート対象外

OpenShift CLI (oc) プラグイン

サポート対象

サポート対象

Operator API

サポート対象

サポート対象

OpenShift Virtualization

サポート対象外

サポート対象外

IPsec 暗号化を含む OVN-Kubernetes

サポート対象

サポート対象

PodDisruptionBudget

サポート対象

サポート対象

Precision Time Protocol (PTP) ハードウェア

サポート対象外

サポート対象外

Red Hat OpenShift Local

サポート対象外

サポート対象外

スケジューラーのプロファイル

サポート対象

サポート対象

SCTP (Stream Control Transmission Protocol)

サポート対象

サポート対象

複数ネットワークインターフェイスのサポート

サポート対象

サポート対象

3 ノードクラスターのサポート

サポート対象

サポート対象

Topology Manager

サポート対象

サポート対象外

SCSI ディスク上の z/VM Emulated FBA デバイス

サポート対象外

サポート対象

4k FCP ブロックデバイス

サポート対象

サポート対象

表1.2 永続ストレージのオプション

機能IBM PowerIBM 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]

  1. 永続共有ストレージは、Red Hat OpenShift Data Foundation またはその他のサポートされているストレージプロトコルを使用してプロビジョニングする必要があります。
  2. 共有されていない永続ストレージは、iSCSI、FC、DASD、FCP または EDEV/FBA と共に LSO を使用するなど、ローカルストレージを使用してプロビジョニングする必要があります。

表1.3 Operator

機能IBM PowerIBM Z および IBM® LinuxONE

Cluster Logging Operator

サポート対象

サポート対象

Cluster Resource Override Operator

サポート対象

サポート対象

Compliance Operator

サポート対象

サポート対象

File Integrity Operator

サポート対象

サポート対象

Local Storage Operator

サポート対象

サポート対象

MetalLB Operator

サポート対象

サポート対象

Network Oberservability Operator

サポート対象

サポート対象外

NFD Operator

サポート対象

サポート対象

NMState Operator

サポート対象

サポート対象

OpenShift Elasticsearch Operator

サポート対象

サポート対象

Vertical Pod Autoscaler Operator

サポート対象

サポート対象

表1.4 Multus CNI プラグイン

機能IBM PowerIBM Z および IBM® LinuxONE

ブリッジ

サポート対象

サポート対象

host-device

サポート対象

サポート対象

IPAM

サポート対象

サポート対象

IPVLAN

サポート対象

サポート対象

表1.5 CSI ボリューム

機能IBM PowerIBM Z および IBM® LinuxONE

クローン

サポート対象

サポート対象

拡張

サポート対象

サポート対象

スナップショット

サポート対象

サポート対象

1.3.8. Images

1.3.8.1. イメージストリーム上のマニフェストにリストされたイメージのサポート

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

1.3.9. セキュリティーおよびコンプライアンス

1.3.9.1. AES-GCM 暗号化はサポート対象

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

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

1.3.10. ネットワーク

1.3.10.1. ネットワークメトリクスの強化

1.3.10.1.1. egress_ips_rebalance_total
  • メトリック名: ovnkube_master_egress_ips_rebalance_total
  • ヘルプメッセージ:The total number of times assigned egress IP(s) needed to be moved to a different node.
1.3.10.1.2. egress_ips_node_unreachable_total
  • メトリック名: ovnkube_master_egress_ips_node_unreachable_total
  • ヘルプメッセージ: The total number of times assigned egress IP(s) were unreachable.
1.3.10.1.3. egress_ips_unassign_latency_seconds
  • メトリック名: ovnkube_master_egress_ips_unassign_latency_seconds
  • ヘルプメッセージ: The latency of egress IP unassignment from OVN northbound database.
1.3.10.1.4. interfaces_total
  • メトリック名: ovs_vswitchd_interfaces_total
  • ヘルプメッセージ: The total number of Open vSwitch interface(s) created for pods および Open vSwitch interface until its available.
1.3.10.1.5. interface_up_wait_seconds_total
  • メトリック名: ovs_vswitchd_interface_up_wait_seconds_total
  • ヘルプメッセージ: The total number of seconds that is required to wait for pod. および Open vSwitch interface until its available.
1.3.10.1.6. ovnkube_resource_retry_failures_total
  • メトリック名: ovnkube_resource_retry_failures_total
  • ヘルプメッセージ: The total number of times processing a Kubernetes resource reached the maximum retry limit and was no longer processed.

1.3.10.2. ネットワークアラートの機能強化

  • OVN Kubernetes は、要求を破棄する前に最大 15 回まで要求を再試行します。今回の更新により、この障害が発生した場合、OpenShift Container Platform はクラスター管理者にアラートを出します。各アラートの説明は、コンソールで表示できます。
1.3.10.2.1. NoOvnMasterLeader
  • 概要: ovn-kubernetes マスターリーダーはありません。
  • コンソールでの説明:

    Networking control plane is degraded. Networking configuration updates applied to the cluster will not be implemented while there is no OVN Kubernetes leader. Existing workloads should continue to have connectivity. OVN-Kubernetes control plane is not functional.
1.3.10.2.2. OVNKubernetesNodeOVSOverflowUserspace
  • 概要: OVS vSwitch デーモンは、バッファーオーバーフローが原因でパケットをドロップします。
  • コンソールでの説明:

    Netlink messages dropped by OVS vSwitch daemon due to netlink socket buffer overflow. This will result in packet loss.
1.3.10.2.3. OVNKubernetesNodeOVSOverflowKernel
  • 概要: OVS カーネルモジュールは、バッファーオーバーフローが原因でパケットをドロップします。
  • コンソールでの説明:

    Netlink messages dropped by OVS kernel module due to netlink socket buffer overflow. This will result in packet loss.

1.3.10.3. MetalLB IPAddressPool リソースの IP アドレスを特定の名前空間とサービスに割り当てる

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

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

1.3.10.4. デュアルポート NIC を備えたノードで OpenShift Container Platform インストールをサポート (テクノロジープレビュー)

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

  • エージェントベースのインストーラー
  • installer-provisioned infrastructure のインストール
  • user-provisioned infrastructure のインストール

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

1.3.10.5. BlueField-2 ネットワークデバイスのデータ処理ユニット (DPU) モードからネットワークインターフェイスコントローラー (NIC) モードへの切り替えのサポートが GA になりました

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

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

1.3.10.6. ネットワークカードの MT2892 Family [ConnectX-6 Dx] でハードウェアオフロードの一般提供を開始

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

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

1.3.10.7. OpenShift SDN ネットワークプラグインへの移行

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

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

1.3.10.8. CoreDNS 1.10.1 に更新

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

1.3.10.9. クラスターネットワークの IP アドレス範囲の拡張

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

1.3.10.10. VMware vSphere クラスター上のデュアルスタック IPv4/IPv6

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

1.3.10.11. ベアメタルデュアルスタッククラスター上のプライマリー IP アドレスファミリーとしての IPv6

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

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

1.3.10.12. OVN-Kubernetes がセカンダリーネットワークとして使用可能 (テクノロジープレビュー)

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

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

1.3.10.13. OVN-Kubernetes ネットワークプラグインの egress ファイアウォールにノードセレクターを追加

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

1.3.10.14. RHOSP で実行される Kuryr から OVN-Kubernetes へのクラスター移行手順 (テクノロジープレビュー)

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

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

1.3.10.15. RHOSP 上で実行されるクラスターの egress IP サポートの強化

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

1.3.10.16. SR-IOV (Single Root I/O Virtualization) でサポートされるハードウェア

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

  • Intel E810-XXVDA4T
  • Intel X710 Base T

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

1.3.11. ストレージ

1.3.11.1. KMS での再暗号化における顧客管理型キーの使用をサポート

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

1.3.11.2. 論理ボリュームマネージャー(LVM)ストレージのデュアルスタックサポート

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

1.3.11.3. GitOps ZTP での LVM ストレージのサポート

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

1.3.11.4. 非接続環境での LVM ストレージのサポート

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

1.3.11.5. ユーザー管理型暗号化の一般提供を開始

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

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

1.3.11.6. 正常ではないノードシャットダウン後の CSI ボリュームのデタッチ (テクノロジープレビュー)

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

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

1.3.11.7. VMware vSphere 暗号化サポートの一般提供を開始

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

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

1.3.11.8. 複数のデータセンターに対する VMware vSphere CSI トポロジーのサポートの一般提供を開始

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

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

1.3.11.9. 複数のデフォルトストレージクラスの作成の一般提供を開始

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

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

1.3.11.10. デフォルトストレージクラスの管理の一般提供を開始

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

  • 他の優先ストレージクラスがある場合に、storage operator による最初のデフォルトストレージクラスの作成を阻止します。
  • デフォルトのストレージクラスに名前を付け直すか変更します。
  • 動的プロビジョニングを無効にして静的プロビジョニングを強制します。

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

1.3.11.11. 遡及的なデフォルト StorageClass の割り当て (テクノロジープレビュー)

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

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

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

1.3.11.12. IBM Power Virtual Server Block CSI Driver Operator (テクノロジープレビュー)

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

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

1.3.11.13. CSI インライン一時ボリュームの一般提供を開始

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 インライン一時ボリューム を参照してください。

1.3.11.14. Microsoft Azure File の自動 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 の自動移行 を参照してください。

1.3.11.15. VMware vSphere の自動 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 移行がまだ有効になっていない
  • OpenShift Container Platform が vSphere 7.0u3L+ または 8.0u2+ で実行されていない
  • vSphere in-tree (インツリー)永続ボリューム(PV)が存在する。

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

1.3.11.16. AWS EFS CSI ドライバーのクロスアカウントサポートの一般提供を開始

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

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

1.3.11.17. Kubelet ではなく FSGroup を CSI ドライバーに委譲する機能の一般提供を開始

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

1.3.11.18. NFS をサポートする Azure File の一般提供を開始

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

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

1.3.12. Operator ライフサイクル

1.3.12.1. OpenShift CLI を使用した Operator バージョンの確認

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

oc description コマンド構文の例

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

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

oc get コマンド構文の例

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

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

1.3.12.2. マルチテナントクラスター内の Operator

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

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

1.3.12.3. Colocation of Operators in a namespace

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

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

1.3.12.4. コピーした CSV が無効化されている場合の Web コンソールの動作を更新

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

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

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

1.3.13. Operator の開発

1.3.13.1. サジェストされた namespace テンプレートをデフォルトノードセレクターを使用して設定

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

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

1.3.13.2. Node Tuning Operator

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

1.3.14. マシン API

1.3.14.1. コントロールプレーンマシンセットの追加プラットフォームサポート

  • このリリースでは、コントロールプレーンマシンセットが Google Cloud Platform クラスターでサポートされています。
  • このリリースには、Microsoft Azure クラスター上のコントロールプレーンマシンセットのユーザーエクスペリエンスの強化が含まれています。OpenShift Container Platform バージョン 4.13 と共にインストールまたはアップグレードされた Azure クラスターの場合、コントロールプレーンマシンセットのカスタムリソース (CR) を作成する必要はなくなりました。

    • バージョン 4.13 でインストールされたクラスターには、デフォルトでアクティブなコントロールプレーンマシンセットがあります。
    • バージョン 4.13 にアップグレードされたクラスターの場合、非アクティブな CR がクラスターに対して生成され、CR の値がコントロールプレーンマシンに対して正しいことを確認した後にアクティブ化できます。

詳細は、コントロールプレーンマシンセットオペレーターの概要 を参照してください。

1.3.15. Machine Config Operator

1.3.15.1. Red Hat Enterprise Linux CoreOS (RHCOS) イメージ階層化の一般提供を開始

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

詳細は、Red Hat Enterprise Linux CoreOS (RHCOS) image layering を参照してください。

1.3.15.2. RHCOS へのサードパーティーおよびカスタムコンテンツの追加のサポート

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

詳細は、Red Hat Enterprise Linux CoreOS (RHCOS) image layering を参照してください。

1.3.15.3. core ユーザーパスワード設定のサポート

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

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

1.3.16. ノード

1.3.16.1. タグによるイメージレジストリーリポジトリーのミラーリング

ダイジェスト仕様に加えてイメージタグを使用して、ミラーリングされたレジストリーからイメージをプルできるようになりました。この変更を実現するために、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 参照してください。

1.3.16.2. crun 一般提供

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

1.3.16.3. Linux コントロールグループバージョン 2 (cgroup v2) の一般提供

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

1.3.16.4. Pod Disruption Budget (PDB) の不健全な Pod エビクションポリシー (テクノロジープレビュー)

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

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

警告

クラスターで TechPreviewNoUpgrade 機能セットを有効にすると、元に戻すことができず、マイナーバージョンの更新が妨げられます。本番クラスターでは、この機能セットを有効にしないでください。

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

1.3.16.5. Metal3 修復のサポート

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

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

1.3.17. モニタリング

本リリースのモニタリングスタックには、以下の新機能および変更された機能が含まれています。

1.3.17.1. モニタリングスタックコンポーネントおよび依存関係の更新

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

  • Alertmanager 0.25.0
  • kube-state-metrics 2.8.1
  • node-exporter 1.5.0
  • prom-label-proxy 0.6.0
  • Prometheus 2.42.0
  • prometheus-operator 0.63.0
  • Thanos 0.30.2

1.3.17.2. アラートルールの変更

注記

Red Hat は、記録ルールまたはアラートルールの後方互換性を保証しません。

  • NodeFilesystemAlmostOutOfSpace アラートは、設計上常にいっぱいになっている特定の tmpfs マウントポイントに対して実行されなくなりました。

1.3.17.3. Alertmanager 設定にシークレットを追加する新しいオプション

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

1.3.17.4. node-exporter コレクターを設定するための新しいオプション

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

  • buddyinfo コレクター
  • cpufreq コレクター
  • netclass コレクター
  • netdev コレクター
  • netclass コレクターの netlink バックエンド
  • tcpstat コレクター

1.3.17.6. メトリクスコレクションプロファイルを有効にする新しいオプション (テクノロジープレビュー)

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

1.3.18. Network Observability Operator

Network Observability Operator は、OpenShift Container Platform マイナーバージョンのリリースストリームとは独立して更新をリリースします。更新は、現在サポートされているすべての OpenShift Container Platform 4 バージョンでサポートされている単一のローリングストリームを介して使用できます。Network Observability Operator の新機能、機能拡張、バグ修正に関する情報は、Network Observability リリースノート に記載されています。

1.3.19. スケーラビリティーおよびパフォーマンス

1.3.19.1. NUMA Resources Operator を使用した NUMA 対応のスケジューリングが一般提供されました

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

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

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

  • NUMA リソースレポートの API ポーリングの微調整。
  • ノードトポロジーエクスポータのノードグループレベルでの設定オプション。

詳細は、Scheduling NUMA-aware workloads を参照してください。

1.3.19.2. 3 ノードクラスターと標準クラスターのワークロードパーティション設定のサポート (テクノロジープレビュー)

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

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

1.3.19.3. GitOps ZTP を使用した電源状態の設定

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

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

1.3.19.4. TALM および GitOps ZTP を使用したマネージドクラスター更新用のコンテナーイメージの事前キャッシュ

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

  • 新しいチェック機能では、クラスターを更新する前に、マネージドクラスターホスト上に十分な使用可能ディスク領域があることをが確認されます。コンテナーイメージの事前キャッシュ中に、TALM はホストの使用可能ディスク容量と推定される OpenShift Container Platform イメージのサイズを比較し、ホスト上に十分なディスク容量があることを確認するようになりました。
  • ConfigMap CR の新しい excludePrecachePatterns フィールドが使用可能になり、更新前に TALM がどの事前キャッシュイメージをクラスターホストにダウンロードするかを制御します。

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

1.3.19.5. PTP およびベアメタルイベントの AMQP が HTTP トランスポートに (テクノロジープレビュー)

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

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

1.3.19.6. PTP グランドマスタークロックとして Intel E810 Westport Channel NIC をサポート (テクノロジープレビュー)

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

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

1.3.19.7. GitOps ZTP で crn をマネージドクラスターのデフォルトコンテナーランタイムに設定

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

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

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

1.3.19.8. ドキュメントの強化: etcd の概要を追加

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

1.3.20. Insights Operator

OpenShift Container Platform 4.13 では、Insights Operator が以下の情報を収集するようになりました。

  • openshift_apps_deploymentconfigs_strategy_total メトリクス。このメトリックは、デプロイメントの設定からデプロイメントストラテジー情報を収集します。
  • マシンに障害が発生する理由を特定するための追加のマシンリソース定義。
  • 認証 Operator のパフォーマンスが低下している場合に Insights に通知するためのデフォルトの ingresscontroller.operator.openshift.io リソース。

1.3.21. Hosted Control Plane (テクノロジープレビュー)

1.3.21.1. ドキュメントにホストされたコントロールプレーンのセクションを追加

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

1.3.21.2. ホストされたコントロールプレーンの更新

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

1.3.22. OpenShift Container Platform をシングルノードにインストールするための要件

4.13 は、x86_64 および arm64 CPU アーキテクチャーをサポートするようになりました。