1.3. 新機能および機能拡張
今回のリリースでは、以下のコンポーネントおよび概念に関連する拡張機能が追加されました。
1.3.1. 認証および認可
1.3.1.1. OIDC にバインドされたサービスアカウントの署名者キーのローテーション
このリリースでは、Cloud Credential Operator (CCO) ユーティリティー (ccoctl
) を使用して、以下のクラウドプロバイダーにインストールされているクラスターの OpenID Connect (OIDC) のバインドされたサービスアカウント署名者キーをローテーションできます。
1.3.2. バックアップおよび復元
1.3.2.1. クラスターを最大 90 日間ハイバネート状態にする
このリリースにより、OpenShift Container Platform クラスターを最大 90 日間ハイバネート状態にし、クラスターが正常に回復することを期待できるようになりました。このリリースより前は、最大 30 日間ハイバネートすることしかできませんでした。
詳細は、OpenShift Container Platform クラスターのハイバーネート を参照してください。
1.3.2.2. etcd のバックアップと復元に関するドキュメントの強化
etcd 障害復旧ドキュメントが更新され、簡素化されました。通常の障害復旧の場合も、以前のバックアップを使用したクラスターの完全復元の場合も、より迅速にクラスターを復旧できるようになりました。
復元手順の多くのステップを完了できる 2 つのスクリプト (quorum-restore.sh
と cluster-restore.sh
) が導入されました。
さらに、正常なノードが少なくとも 1 つ存在する場合にクラスターをより迅速に復元するための手順が追加されました。残存ノードのいずれかが特定の基準を満たしている場合は、それを使用して復元を実行できます。
詳細は、障害復旧について を参照してください。
1.3.3. エッジコンピューティング
1.3.3.1. クラスターのインストール後 1 年間以内のシングルノード OpenShift クラスターのシャットダウンと再起動
このリリースでは、クラスターをインストールしてから最大 1 年間は、シングルノード OpenShift クラスターをシャットダウンして再起動できます。クラスターのシャットダウン中に証明書の有効期限が切れた場合は、クラスターの再起動時に証明書署名要求 (CSR) を承認する必要があります。
この更新前は、シングルノード OpenShift クラスターをシャットダウンして再起動できるのは、クラスターのインストール後 120 日間でした。
シャットダウンする前に、シングルノード OpenShift クラスターからすべてのワークロード Pod を退避させてください。
詳細は、クラスターのグレースフルシャットダウン を参照してください。
1.3.4. 拡張機能 (OLM v1)
1.3.4.1. Operator Lifecycle Manager (OLM) v1 (一般提供)
Operator Lifecycle Manager (OLM) は、最初のリリースから OpenShift Container Platform 4 に含まれており、Operator として実行されるソリューションや高度なワークロードの実質的なエコシステムの実現と発展に貢献してきました。
OpenShift Container Platform 4.18 では、OpenShift Container Platform での Operator 管理方法を改善するために設計された次世代 Operator Lifecycle Manager である OLM v1 が一般提供 (GA) 機能として導入されました。
OpenShift Container Platform 4.18 で OLM v1 の一般提供が開始されたことに伴い、OpenShift Container Platform 4 のリリース以降に含まれる既存の OLM バージョンは OLM (Classic) と呼ばれるようになりました。
これまではテクノロジープレビュー機能としてのみ利用可能でしたが、OLM v1 の更新されたフレームワークでは、Operator 管理の簡素化、セキュリティーの強化、信頼性の向上により、OLM (Classic) の一部であった多くの概念が進化しています。
- OpenShift Container Platform 4.18 以降では、OLM (Classic) とともに OLM v1 がデフォルトで有効になっています。OLM v1 は、OpenShift Container Platform のインストール前に管理者がオプションで無効にできる クラスター機能 です。
- OLM (Classic) は、OpenShift Container Platform 4 のライフサイクル全体で引き続きフルサポートが提供されます。
- API の単純化
OLM v1 では、新しいユーザーフレンドリーな API である
ClusterExtension
オブジェクト を使用することで、Operator 管理が単純化されています。Operator をクラスターの不可欠な拡張機能として管理することにより、OLM v1 はカスタムリソース定義 (CRD) の特別なライフサイクル要件に対応します。この設計は Kubernetes の原則とより密接に連携し、カスタムコントローラーと CRD で構成される Operator をクラスター全体のシングルトンとして扱います。OpenShift Container Platform では、OpenShift Container Platform 4.18 の OLM v1 においてデフォルトで有効になっているデフォルトの Red Hat Operator カタログ を通じて、最新の Operator パッケージ、パッチ、および更新に引き続きアクセスできます。OLM v1 では、クラスターに
ClusterExtension
API オブジェクトを作成して適用することで、Operator パッケージをインストールできます。ClusterExtension
オブジェクトを操作することで、Operator パッケージのライフサイクルを管理し、そのステータスを迅速に把握し、問題のトラブルシューティングを行えます。- 合理化された宣言的ワークフロー
- 単純化された API を活用することで、目的の Operator の状態を宣言的に定義して、Git や Zero Touch Provisioning などのツールとの統合時に OLM v1 がそれらの状態を自動的に維持するようにできます。これにより、人的エラーが最小限に抑えられ、より幅広いユースケースに対応できます。
- 継続的な調整とオプションのロールバックによる中断のない運用
OLM v1 は、継続的な調整を通じて信頼性を高めます。OLM v1 は、1 回の試行に頼るのではなく、問題が解決するまで自動的に再試行して Operator のインストールと更新の失敗をプロアクティブに解決します。これにより、
InstallPlan
API オブジェクトの削除など、これまで必要だった手動のステップが不要になり、コンテナーイメージの欠落やカタログの問題など、クラスター外の問題の解決が大幅に単純化されます。さらに、OLM v1 ではオプションのロールバックが提供されており、潜在的なリスクを慎重に評価した後、特定の条件下で Operator バージョンの更新を元に戻すことが可能です。
- デプロイメント更新の詳細な制御
詳細な更新制御により、特定の Operator バージョンを選択したり、許容されるバージョン範囲を定義したりできます。たとえば、ステージ環境で Operator のバージョン
1.2.3
をテストして承認した場合、最新バージョンが実稼働環境で同様に動作することを期待する代わりに、バージョンを固定できます。希望するバージョンとして1.2.3
を指定すると、それが安全で予測可能な更新を行うためにデプロイされる正確なバージョンになります。また、自動 z-stream 更新では、手動による介入のない自動セキュリティー修正を適用することで、シームレスでセキュアなエクスペリエンスが提供され、運用の中断が最小限に抑えられます。
- ユーザー提供のサービスアカウントによるセキュリティー強化
-
OLM v1 はセキュリティーを優先しており、権限要件を最小限に抑え、アクセスをより強力に制御します。Operator ライフサイクル運用のためのユーザー提供
ServiceAccount
オブジェクト を使用することで、OLM v1 アクセスは必要な権限のみに制限され、コントロールプレーンの攻撃対象領域が大幅に削減され、全体的なセキュリティーが向上します。このように、OLM v1 は、侵害の影響を最小限に抑えるために最小権限モデルを採用しています。
1.3.4.2. OLM v1 でサポートされる拡張機能
現在、Operator Lifecycle Manager (OLM) v1 は、次のすべての条件を満たすクラスター拡張機能のインストールをサポートしています。
-
拡張機能では、OLM (Classic) で導入された
registry+v1
バンドル形式を使用する必要があります。 -
拡張機能は、
AllNamespaces
インストールモードによるインストールをサポートする必要があります。 - 拡張機能は Webhook を使用してはなりません。
拡張機能は、次に示すいずれかのファイルベースのカタログプロパティーを使用して依存関係を宣言してはなりません。
-
olm.gvk.required
-
olm.package.required
-
olm.constraint
-
OLM v1 は、インストールする拡張機能がこれらの制約を満たしているかどうかを確認します。インストールする拡張機能がこれらの制約を満たしていない場合、クラスター拡張機能の条件にエラーメッセージが出力されます。
1.3.4.3. OLM v1 での非接続環境のサポート
特にミッションクリティカルな実稼働ワークロードのために、インターネット非接続環境でクラスターを実行することで高いセキュリティーを優先するクラスター管理者をサポートするために、OLM v1 は OpenShift Container Platform 4.18 以降で非接続環境をサポートします。
OpenShift CLI の oc-mirror プラグイン (oc
) を使用して、クラスターに必要なイメージを完全または部分的な非接続環境のミラーレジストリーにミラーリングした後、oc-mirror プラグイン v1 または v2 のいずれかによって生成されたリソースセットを利用することで、OLM v1 はこれらの環境で適切に機能できます。
詳細は、OLM v1 での非接続環境のサポート を参照してください。
1.3.4.4. OLM v1 のカタログ選択の改善
このリリースでは、クラスター拡張機能のインストール時または更新時に、次のアクションを実行してカタログコンテンツの選択を制御できます。
- カタログを選択するためのラベルを指定します
- match 式を使用してカタログ全体をフィルタリングします
- カタログの優先順位を設定します
詳細は、カタログコンテンツの解決 を参照してください。
1.3.4.5. プロキシー環境と信頼済み CA 証明書の基本的なサポート
このリリースでは、Operator Controller と catalogd がプロキシー環境で実行できるようになり、信頼済み CA 証明書の基本的なサポートが含まれるようになりました。
1.3.4.6. OpenShift Container Platform バージョンとの互換性
クラスター管理者は、OpenShift Container Platform クラスターを次のマイナーバージョンに更新する前に、インストールされているすべての Operator がクラスターの次のマイナーバージョン (4.y+1) と互換性のあるバンドルバージョンに更新されていることを確認する必要があります。
OpenShift Container Platform 4.18 以降、OLM v1 は Operator のクラスターサービスバージョン (CSV) で olm.maxOpenShiftVersion
アノテーションをサポートします。これは、OLM (Classic) の動作と同じように、インストールされた Operator を互換性のあるバージョンに更新する前に管理者がクラスターを更新することを防ぎます。
詳細は、OpenShift Container Platform バージョンとの互換性 を参照してください。
1.3.4.7. 拡張機能リソースへのユーザーアクセス
クラスター拡張機能がインストールされ、Operator Lifecycle Manager (OLM) v1 によって管理されるようになると、多くの場合、拡張機能はクラスター上で新しい API リソースを公開する CustomResourceDefinition
オブジェクト (CRD) を提供できるようになります。通常、クラスター管理者はデフォルトでこれらのリソースへの完全な管理アクセス権を持ちますが、クラスター管理者以外のユーザー、つまり 通常のユーザー は十分な権限を持たない可能性があります。
OLM v1 では、インストールされた拡張機能が提供する API を通常のユーザーが操作できるように、ロールベースのアクセス制御 (RBAC) を自動的に設定または管理することはありません。クラスター管理者は、このようなユーザー向けにカスタムリソース (CR) を作成、表示、または編集するために必要な RBAC ポリシーを定義する必要があります。
詳細は、拡張機能リソースへのユーザーアクセス を参照してください。
1.3.4.8. OLM v1 の sigstore 署名を使用したコンテナーイメージのランタイム検証 (テクノロジープレビュー)
OpenShift Container Platform 4.18 以降では、コンテナーイメージの sigstore 署名のランタイム検証を処理するための OLM v1 サポートがテクノロジープレビュー (TP) 機能として利用可能になっています。
1.3.4.9. OLM v1 の既知の問題
Operator Lifecycle Manager (OLM) v1 は、OLM (Classic) で導入された OperatorConditions
API をサポートしていません。
拡張機能が OperatorConditions
API のみに依存して更新を管理している場合、拡張機能が正しくインストールされない可能性があります。この API に依存する拡張機能のほとんどは起動時に失敗しますが、一部は調整中に失敗する可能性があります。
回避策として、拡張機能を特定のバージョンに固定できます。拡張機能を更新する場合は、拡張機能のドキュメントを参照して、いつ拡張機能を新しいバージョンに固定すれば安全か確認してください。
1.3.4.10. SiteConfig v1 が非推奨に
SiteConfig v1 は、OpenShift Container Platform 4.18 以降で非推奨になります。ClusterInstance
カスタムリソースを使用する SiteConfig Operator を通じて、同等の改良された機能が利用できるようになりました。詳細は、Red Hat ナレッジベースの Procedure to transition from SiteConfig CRs to the ClusterInstance API を参照してください。
SiteConfig Operator の詳細は、SiteConfig を参照してください。
1.3.5. Hosted Control Plane
Hosted Control Plane のリリースは OpenShift Container Platform と同期しないため、独立したリリースノートがあります。詳細は、Hosted Control Plane リリースノート を参照してください。
1.3.6. IBM Power
OpenShift Container Platform 4.18 の IBM Power® リリースでは、OpenShift Container Platform コンポーネントに改良点と新機能が追加されました。
このリリースでは、IBM Power で次の機能がサポートされます。
- PowerVS Installer Provisioned Infrastructure デプロイメントへの 4 つの新しいデータセンターの追加
-
OpenShift CLI (
oc
) を使用したオンプレミスクラスターへのコンピュートノードの追加
1.3.7. IBM Z と IBM LinuxONE
このリリースにより、IBM Z® および IBM® LinuxONE は OpenShift Container Platform 4.18 と互換性を持つようになりました。z/VM、LPAR、または Red Hat Enterprise Linux (RHEL) カーネルベースの仮想マシン (KVM) を使用して、インストールを実行できます。インストール手順については、インストール方法 を参照してください。
コンピュートノードは、Red Hat Enterprise Linux CoreOS (RHCOS) を実行する必要があります。
IBM Z および IBM LinuxONE の主な機能拡張
OpenShift Container Platform 4.18 の IBM Z® および IBM® LinuxONE リリースでは、OpenShift Container Platform のコンポーネントと概念に、改良点と新機能が追加されました。
このリリースでは、IBM Z® および IBM® LinuxONE 上で次の機能がサポートされます。
-
OpenShift CLI (
oc
) を使用したオンプレミスクラスターへのコンピュートノードの追加
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 |
---|---|---|
OpenShift CLI ( | サポート対象 | サポート対象 |
代替の認証プロバイダー | サポート対象 | サポート対象 |
Agent-based Installer | サポート対象 | サポート対象 |
Assisted Installer | サポート対象 | サポート対象 |
ローカルストレージ Operator を使用した自動デバイス検出 | サポート対象外 | サポート対象 |
マシンヘルスチェックによる障害のあるマシンの自動修復 | サポート対象外 | サポート対象外 |
IBM Cloud® 向けクラウドコントローラーマネージャー | サポート対象 | サポート対象外 |
オーバーコミットの制御およびノード上のコンテナーの密度の管理 | サポート対象外 | サポート対象外 |
CPU マネージャー | サポート対象 | サポート対象 |
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. Insights Operator
1.3.8.1. Insights Runtime Extractor (テクノロジープレビュー)
このリリースでは、ワークロードデータを収集する Insights Runtime Extractor 機能が Insights Operator に導入されました。これにより、Red Hat がお客様のコンテナーのワークロードをより的確に把握できるようになります。テクノロジープレビューとして提供される Insights Runtime Extractor 機能は、ランタイムワークロードデータを収集し、Red Hat に送信します。Red Hat は、OpenShift Container Platform コンテナーの使用方法を推進および最適化するお客様の投資判断に役立つ分析情報を入手するために、収集したランタイムワークロードデータを使用します。詳細は、フィーチャーゲートを使用した機能の有効化 を参照してください。
1.3.8.2. Rapid Recommendations
このリリースでは、Insights Operator が収集するデータを決定するルールをリモートで設定するための Rapid Recommendations メカニズムが強化されました。
Rapid Recommendations 機能はバージョンに依存せず、既存の条件付きデータ収集メカニズムに基づいてビルドされます。
Insights Operator は、console.redhat.com で実行されているセキュアなリモートエンドポイントサービスに接続し、Red Hat がフィルタリングおよび収集するコンテナーログメッセージを決定するルールが含まれる定義を取得します。
条件付きデータ収集の定義は、pod.yml
設定ファイルの conditionalGathererEndpoint
属性を通じて設定されます。
conditionalGathererEndpoint: https://console.redhat.com/api/gathering/v2/%s/gathering_rules
conditionalGathererEndpoint: https://console.redhat.com/api/gathering/v2/%s/gathering_rules
以前のイテレーションでは、Insights Operator が収集するデータを決定するルールはハードコードされており、対応する OpenShift Container Platform バージョンに関連付けられていました。
事前設定済みのエンドポイント URL に、OpenShift Container Platform のターゲットバージョンを定義するためのプレースホルダー (%s
) が追加されました。
1.3.8.3. 収集されるデータの増加と推奨事項の追加
Insights Operator は、以下の状況を検出するために、さらに多くのデータを収集するようになりました。このデータを他のアプリケーションで使用して、OpenShift Container Platform のデプロイメントをプロアクティブに管理するための修復推奨事項を生成できます。
-
nmstate.io/v1
API グループからリソースを収集します。
-
clusterrole.rbac.authorization.k8s.io/v1
インスタンスからデータを収集します。
1.3.9. インストールおよび更新
1.3.9.1. Cluster API Provider IBM Cloud の新バージョン
インストールプログラムでは、Transit Gateway の修正が含まれる新しいバージョンの Cluster API Provider IBM Cloud プロバイダーが使用されるようになりました。IBM Cloud の Transit Gateway のコストを考慮して、OpenShift Container Platform クラスターの作成時に OpenShift Container Platform を使用して Transit Gateway を作成できるようになりました。詳細は、(OCPBUGS-37588) および (OCPBUGS-41938) を参照してください。
1.3.9.2. クラスターのインストール中に ovn-kubernetes
join サブネットを設定する
このリリースにより、クラスターのインストール時に ovn-kubernetes
によって内部で使用される IPv4 join サブネットを設定できるようになりました。install-config.yaml
ファイルで internalJoinSubnet
パラメーターを設定し、クラスターを既存の Virtual Private Cloud (VPC) にデプロイできます。
詳細は、ネットワーク設定パラメーター を参照してください。
1.3.9.3. oc adm upgrade recommend コマンドの導入 (テクノロジープレビュー)
クラスターの更新時に、oc adm upgrade
コマンドは次の利用可能なバージョンのリストを返します。4.18 oc
クライアントバイナリーを使用している限り、更新を開始する前に、oc adm upgrade recommend
コマンドを使用して提案を絞り込み、新しいターゲットリリースを推奨することができます。この機能は、更新サービスに接続されている OpenShift Container Platform バージョン 4.16 以降のクラスターで利用できます。
詳細は、CLI を使用したクラスター更新 を参照してください。
機能 | 4.16 | 4.17 | 4.18 |
---|---|---|---|
| テクノロジープレビュー | テクノロジープレビュー | テクノロジープレビュー |
| 利用不可 | 利用不可 | テクノロジープレビュー |
1.3.9.4. Amazon Web Services (AWS) 上の Nutanix Cloud Clusters (NC2) と Microsoft Azure 上の NC2 のサポート。
このリリースでは、AWS の Nutanix Cloud クラスター (NC2)、Azure の NC2 に OpenShift Container Platform をインストールできます。
詳細は、インフラストラクチャーの要件 を参照してください。
1.3.9.5. C4 および C4A マシンシリーズを使用した Google Cloud Platform へのクラスターのインストール
このリリースでは、コンピュートまたはコントロールプレーンマシン用の C4 および C4A マシンシリーズを使用して、GCP にクラスターをデプロイできます。これらのマシンでサポートされるディスクタイプは hyperdisk-balanced
です。Hyperdisk ストレージを必要とするインスタンスタイプを使用する場合は、クラスター内のすべてのノードが Hyperdisk ストレージをサポートする必要があり、Hyperdisk ストレージを使用するようにデフォルトのストレージクラスを変更する必要があります。
マシンタイプの設定に関する詳細は、GCP のインストール設定パラメーター、C4 machine series (Compute Engine ドキュメント)、および C4A machine series (Compute Engine ドキュメント) を参照してください。
1.3.9.6. Google Cloud Platform にクラスターをインストールするときに、独自のプライベートホストゾーンを提供する
このリリースでは、GCP 上のクラスターを共有 VPC にインストールするときに、独自のプライベートホストゾーンを提供できます。その場合、Bring Your Own (BYO) ゾーンの要件として、そのゾーンは <cluster_name>.<base_domain>.
などの DNS 名を使用し、ゾーンをクラスターの VPC ネットワークにバインドする必要があります。
詳細は、GCP 上のクラスターを共有 VPC にインストールするための前提条件 および Deployment Manager テンプレートを使用して GCP の共有 VPC にクラスターをインストールするための前提条件 を参照してください。
1.3.9.7. 事前にロードされた RHCOS イメージオブジェクトを使用して Nutanix にクラスターをインストールする
このリリースでは、プライベートクラウドまたはパブリッククラウドから名前付きの事前ロードされた RHCOS イメージオブジェクトを使用して、Nutanix にクラスターをインストールできます。OpenShift Container Platform クラスターごとに RHCOS イメージオブジェクトを作成してアップロードする代わりに、install-config.yaml
ファイルで preloadedOSImageName
パラメーターを使用できます。
詳細は、追加の Nutanix 設定パラメーター を参照してください。
1.3.9.8. RHOSP 上のシングルスタック IPv6 クラスター
RHOSP にシングルスタック IPv6 クラスターをデプロイできるようになりました。
OpenShift Container Platform クラスターをデプロイする前に、RHOSP を設定する必要があります。詳細は、シングルスタック IPv6 ネットワークを使用したクラスターの設定 を参照してください。
1.3.9.9. 複数のサブネットを持つ Nutanix にクラスターをインストールする
このリリースでは、OpenShift Container Platform クラスターをデプロイする Prism Element に対して、複数のサブネットを持つ Nutanix クラスターをインストールできます。
詳細は、障害ドメインの設定 および 追加の Nutanix 設定パラメーター を参照してください。
既存の Nutanix クラスターの場合、コンピュート または コントロールプレーン のマシンセットを使用して複数のサブネットを追加できます。
1.3.9.10. 複数のネットワークインターフェイスコントローラーを備えた VMware vSphere へのクラスターのインストール (テクノロジープレビュー)
このリリースでは、ノードに複数のネットワークインターフェイスコントローラー (NIC) を備えた VMware vSphere クラスターをインストールできます。
詳細は、複数の NIC の設定 を参照してください。
既存の vSphere クラスターの場合、コンピュートマシンセット を使用して複数のサブネットを追加できます。
1.3.9.11. Agent-based Installer を使用して 4 ノードおよび 5 ノードのコントロールプレーンを設定する
このリリースでは、Agent-based Installer を使用していれば、4 ノードまたは 5 ノードのコントロールプレーンをインストールできるようにクラスターを設定できるようになりました。この機能は、install-config.yaml
ファイルで controlPlane.replicas
パラメーターを 4
または 5
に設定することで有効になります。
詳細は、Agent-based Installer の オプションの設定パラメーター を参照してください。
1.3.9.12. Agent-based Installer で最小限の ISO イメージをサポート
このリリースでは、Agent-based Installer は、すべてのサポート対象プラットフォームで最小限の ISO イメージの作成をサポートします。以前は、最小限の ISO イメージは external
プラットフォームでのみサポートされていました。
この機能は、agent-config.yaml
ファイルの minimalISO
パラメーターを使用して有効にできます。
詳細は、Agent-based Installer の オプションの設定パラメーター を参照してください。
1.3.9.13. Agent-based Installer の Internet Small Computer System Interface (iSCSI) ブートサポート
このリリースでは、Agent-based Installer は、iSCSI ターゲットから OpenShift Container Platform クラスターを起動するために使用できるアセットの作成をサポートします。
詳細は、iSCSI ブート用のインストールアセットの準備 を参照してください。
1.3.10. Machine Config Operator
1.3.10.1. GA にプロモートされた AWS クラスターのブートイメージの更新
ブートイメージの更新が、Amazon Web Services (AWS) クラスターで GA にプロモートされました。詳細は、ブートイメージの更新 を参照してください。
1.3.10.2. マシン設定ノード情報の拡張 (テクノロジープレビュー)
マシン設定ノードのカスタムリソースは、ノードへのマシン設定の更新の進行状況を監視するために使用できます。このカスタムリソースに、更新に関する詳細情報が表示されるようになりました。oc get machineconfignodes
コマンドの出力で、以下の状態やその他の状態が報告されるようになりました。これらのステータスを使用して更新を追跡したり、更新中にエラーが発生した場合にノードのトラブルシューティングを行ったりできます。
- 各ノードがスケジューリング対象から除外された、または復帰したかどうか
- 各ノードがドレインされたどうか
- 各ノードが再起動したどうか
- ノードで CRI-O がリロードされたかどうか
- ノードのオペレーティングシステムとノードファイルが更新されたかどうか
1.3.10.3. クラスター上のレイヤリング変更 (テクノロジープレビュー)
クラスター上のレイヤリング機能にいくつかの重要な変更があります。
-
MachineConfig
オブジェクトを使用して、クラスター上のカスタムレイヤードイメージに拡張機能をインストールできるようになりました。 -
MachineOSConfig
オブジェクト内の Containerfile を更新すると、ビルドの実行がトリガーされるようになりました。 -
MachineOSConfig
オブジェクトからラベルを削除することで、クラスター上のカスタムレイヤーイメージをベースイメージに戻せるようになりました。 -
Machine Config Operator の
must-gather
に、MachineOSConfig
およびMachineOSBuild
オブジェクトのデータが含まれるようになりました。
クラスター上のレイヤリングの詳細は、クラスター上でのレイヤー化を使用してカスタムレイヤーイメージを適用する を参照してください。
1.3.11. マシン管理
1.3.11.1. Microsoft Azure の Cluster API を使用したマシン管理 (テクノロジープレビュー)
このリリースにより、Microsoft Azure クラスターのテクノロジープレビューとして、OpenShift Container Platform に統合されたアップストリーム Cluster API を使用してマシンを管理する機能が導入されました。この機能は、Machine API を使用してマシンを管理するための追加または代替の機能になります。詳細は、Cluster API について を参照してください。
1.3.12. 管理コンソール
1.3.12.1. クラスター監視を有効にするチェックボックスがデフォルトでオンに設定
この更新により、OpenShift Lightspeed Operator のインストール時に、クラスター監視を有効にするためのチェックボックスがデフォルトでオンに設定されるようになりました。(OCPBUGS-42381)
1.3.13. モニタリング
このリリースのクラスター内モニタリングスタックには、以下の新機能および修正された機能が含まれます。
1.3.13.1. モニタリングスタックコンポーネントおよび依存関係の更新
このリリースには、クラスター内モニタリングスタックコンポーネントと依存関係に関する以下のバージョン更新が含まれています。
- Metrics Server が 0.7.2 へ
- Prometheus 2.55.1 への更新
- Prometheus Operator 0.78.1 への更新
- Thanos 0.36.1 への更新
1.3.13.2. ユーザーワークロードモニタリング Prometheus のスクレイピングと評価の間隔を追加
この更新により、ユーザーのワークロードを監視するために、Prometheus の連続スクレイピングの間隔とルール評価の間隔を設定できるようになりました。
1.3.13.3. モニタリング config map のモニタリング設定の早期検証を追加
この更新では、cluster-monitoring-config
および user-workload-monitoring-config
config map のモニタリング設定の変更に対する早期検証が導入され、フィードバックループが短縮され、ユーザーエクスペリエンスが向上します。
1.3.13.4. Alertmanager コンテナーにプロキシー環境変数を追加
この更新により、Alertmanager はプロキシー環境変数を使用するようになります。したがって、クラスター全体の HTTP プロキシーを設定した場合は、アラートレシーバーまたは Alertmanager のグローバル設定レベルで proxy_from_environment
パラメーターを true
に設定することで、プロキシーを有効にできます。
1.3.13.5. プロジェクト間のユーザーワークロードアラートと記録ルールを追加
この更新により、複数のプロジェクトに対して同時にクエリーを実行するユーザーワークロードアラートおよび記録ルールを作成できるようになります。
1.3.13.6. クラスターメトリクスと RHOSO メトリクスの相関関係
Red Hat OpenStack Services on OpenShift (RHOSO) で実行されるクラスターの可観測性メトリクスを相関させることができるようになりました。両方の環境からメトリクスを収集することで、インフラストラクチャーレイヤーとアプリケーションレイヤー全体の問題を監視およびトラブルシューティングできます。
詳細は、RHOSO で実行されるクラスターのモニタリング を参照してください。
1.3.14. Network Observability Operator
Network Observability Operator は、OpenShift Container Platform マイナーバージョンのリリースストリームとは独立して更新をリリースします。更新は、現在サポートされているすべての OpenShift Container Platform 4 バージョンでサポートされている単一のローリングストリームを介して使用できます。Network Observability Operator の新機能、機能拡張、バグ修正に関する情報は、Network Observability リリースノート を参照してください。
1.3.15. ネットワーク
1.3.15.1. GNSS をソースとするグランドマスタークロックのホールドオーバー
このリリースでは、ソースとして Global Navigation Satellite System (GNSS) を使用して、グランドマスター (T-GM) クロックのホールドオーバー動作を設定できます。ホールドオーバーにより、GNSS ソースが利用できない場合でも T-GM クロックは同期パフォーマンスを維持できます。この期間中、T-GM クロックは内部オシレーターとホールドオーバーパラメーターに依存してタイミングの中断を削減します。
PTPConfig
カスタムリソース (CR) で次のホールドオーバーパラメーターを設定することにより、ホールドオーバー動作を定義できます。
-
MaxInSpecOffset
-
LocalHoldoverTimeout
-
LocalMaxHoldoverOffSet
詳細は、GNSS をソースとするグランドマスタークロックのホールドオーバー を参照してください。
1.3.15.2. IPVLAN および Bond CNI のマルチネットワークポリシー設定をサポート
このリリースでは、次のネットワークタイプに対してマルチネットワークポリシーを設定できます。
- IPVLAN (IP 仮想ローカルエリアネットワーク)
- SR-IOV 上のボンディング Container Network Interface (CNI)
詳細は、マルチネットワークポリシーの設定 を参照してください。
1.3.15.3. ホワイトリストおよびブラックリストアノテーションの用語を更新
ip_whitelist
アノテーションおよび ip_blacklist
アノテーションの用語が、それぞれ ip_allowlist
および ip_denylist
に更新されました。現在、OpenShift Container Platform は、ip_whitelist
および ip_blacklist
アノテーションを引き続きサポートしています。ただし、これらのアノテーションは今後のリリースで削除される予定です。
1.3.15.4. CLI を使用して OVS サンプリングで OVN-Kubernetes ネットワークトラフィックを確認する
OVN-Kubernetes ネットワークトラフィックは、CLI を介した次のネットワーク API の OVS サンプリングで表示できます。
-
NetworkPolicy
-
AdminNetworkPolicy
-
BaselineNetworkPolicy
-
UserDefinedNetwork
分離 -
EgressFirewall
- マルチキャスト ACL。
CLI を使用して OVS サンプリングで OVN-Kubernetes ネットワークトラフィックを確認することは、パケットのトレースに役立つことを目的としています。これは、Network Observability Operator のインストール時にも使用できます。
詳細は、CLI を使用して OVS サンプリングで OVN-Kubernetes ネットワークトラフィックを確認する を参照してください。
1.3.15.5. ユーザー定義のネットワークセグメンテーション (一般提供)
OpenShift Container Platform 4.18 では、ユーザー定義のネットワークセグメンテーションが一般利用可能になりました。ユーザー定義ネットワーク (UDN) では、管理者が、namespace がスコープ指定された UserDefinedNetwork とクラスターがスコープ指定された ClusterUserDefinedNetwork カスタムリソースを使用してカスタムネットワークトポロジーを定義できるようにすることで、ネットワークセグメンテーション機能を強化しました。
管理者は、UDN を使用して、強化された分離機能、ワークロードの IP アドレス管理機能、および高度なネットワーク機能を備えた、カスタマイズしたネットワークトポロジーを作成できます。レイヤー 2 とレイヤー 3 の両方のトポロジータイプをサポートするユーザー定義のネットワークセグメンテーションにより、幅広いネットワークアーキテクチャーとトポロジーが可能になり、ネットワークの柔軟性、セキュリティー、パフォーマンスが向上します。サポートされている機能の詳細は、UDN サポートマトリックス を参照してください。
UDN のユースケースとしては、仮想マシン (仮想マシン) に静的 IP アドレスの有効期間を割り当てる場合や、レイヤー 2 のプライマリー Pod ネットワークを提供してユーザーがノード間で仮想マシンをライブマイグレーションできるようにする場合などがあります。これらの機能はすべて OpenShift Virtualization に完全に装備されています。ユーザーは UDN を使用して、より強力なネイティブマルチテナント環境を作成し、デフォルトでオープンになっているオーバーレイ Kubernetes ネットワークを保護できます。詳細は、ユーザー定義ネットワークについて を参照してください。
1.3.15.6. Dynamic Configuration Manager は、デフォルトで有効になっています (テクノロジープレビュー)
Ingress Controller の Dynamic Configuration Manager を使用すると、メモリーフットプリントを削減できます。Dynamic Configuration Manager は、動的 API 経由でエンドポイントの変更を伝播します。このプロセスにより、基礎となるルーターはリロードなしで変更 (スケールアップおよびスケールダウン) に適応できます。
Dynamic Configuration Manager を使用するには、次のコマンドを実行して TechPreviewNoUpgrade
機能セットを有効にします。
oc patch featuregates cluster -p '{"spec": {"featureSet": "TechPreviewNoUpgrade"}}' --type=merge
$ oc patch featuregates cluster -p '{"spec": {"featureSet": "TechPreviewNoUpgrade"}}' --type=merge
1.3.15.7. ネットワークフローマトリックスの追加環境
このリリースにより、以下の環境で OpenShift Container Platform サービスへの Ingress フローのネットワーク情報を表示できるようになりました。
- ベアメタル上の OpenShift Container Platform
- ベアメタル上のシングルノード OpenShift
- Amazon Web Services (AWS) 上の OpenShift Container Platform
- AWS 上のシングルノード OpenShift
詳細は、OpenShift Container Platform ネットワークフローマトリックス を参照してください。
1.3.15.8. Border Gateway Protocol の MetalLB 更新
このリリースでは、MetalLB に Border Gateway Protocol (BGP) ピアカスタムリソース用の新しいフィールドが含まれています。dynamicASN
フィールドを使用して、BGP セッションのリモートエンドに使用する自律システム番号 (ASN) を検出できます。これは、spec.peerASN
フィールドに ASN を明示的に設定する代わりに使用できます。
1.3.15.9. SR-IOV 用の RDMA サブシステムの設定
このリリースでは、Single Root I/O Virtualization (SR-IOV) で Remote Direct Memory Access (RDMA) Container Network Interface (CNI) を設定して、コンテナー間の高パフォーマンスで低遅延の通信を実現できます。RDMA と SR-IOV を組み合わせると、Data Plane Development Kit (DPDK) アプリケーション内で使用するために Mellanox Ethernet デバイスのハードウェアカウンターを公開するメカニズムが提供されます。
1.3.15.10. Mellanox カードのセキュアブート対応環境で SR-IOV Network Operator の設定をサポート
このリリースでは、システムでセキュアブートが有効になっている場合に、Single Root I/O Virtualization (SR-IOV) Network Operator を設定できます。SR-IOV Operator は、最初に Mellanox デバイスのファームウェアを手動で設定した後に設定されます。セキュアブートを有効にすると、システムの回復力が強化され、コンピューターの全体的なセキュリティーに対する重要な防御層が提供されます。
詳細は、セキュアブートが有効な場合における Mellanox カードでの SR-IOV Network Operator の設定 を参照してください。
1.3.15.11. Ingress コントローラーでの事前作成済み RHOSP Floating IP アドレスのサポート
このリリースでは、RHOSP で実行されているクラスターの Ingress コントローラーで、事前に作成された Floating IP アドレスを指定できるようになりました。
詳細は、Ingress コントローラーでの Floating IP アドレスの指定 を参照してください。
1.3.15.12. SR-IOV Network Operator サポートの拡張
SR-IOV Network Operator は、Intel NetSec アクセラレーターカードと Marvell Octeon 10 DPU をサポートするようになりました。(OCPBUGS-43451)
1.3.15.13. Linux ブリッジインターフェイスを OVS のデフォルトポート接続として使用する
OVN-Kubernetes プラグインは、Open vSwitch (OVS) のデフォルトポート接続として Linux ブリッジインターフェイスを使用できるようになりました。これは、SmartNIC などのネットワークインターフェイスコントローラーが、基盤となるネットワークとホストをブリッジできるようになったことを意味します。(OCPBUGS-39226)
1.3.15.14. 問題のネットワーク重複メトリクスを公開する Cluster Network Operator
制限付きライブマイグレーションメソッドを開始し、ネットワークの重複に関する問題が存在する場合、Cluster Network Operator (CNO) は、その問題のネットワーク重複メトリクスを公開できるようになりました。これは、openshift_network_operator_live_migration_blocked
メトリクスに新しい NetworkOverlap
ラベルが含まれるようになったために可能になりました。(OCPBUGS-39096)
1.3.15.15. ネットワークアタッチメントが動的な再設定をサポート
以前は、NetworkAttachmentDefinition
CR はイミュータブルでした。このリリースでは、既存の NetworkAttachmentDefinition
CR を編集できます。編集がサポートされていることにより、ネットワークインターフェイスの MTU の調整など、基盤となるネットワークインフラストラクチャーの変更に簡単に対応できます。
同じネットワーク name
と type: ovn-k8s-cni-overlay
を参照する各 NetworkAttachmentDefinition
CR の設定が同期されていることを確認する必要があります。これらの値が同期している場合にのみ、ネットワークアタッチメントの更新は成功します。設定が同期されていない場合、OpenShift Container Platform がどの NetworkAttachmentDefinition
CR を設定に使用するかが確定されないため、動作は未定義になります。
ネットワークの変更を Pod で有効にするには、ネットワークアタッチメント定義を使用するワークロードを再起動する必要があります。
1.3.16. Nodes
1.3.16.1. crun がデフォルトのコンテナーランタイムに
crun は、OpenShift Container Platform で作成された新しいコンテナーのデフォルトのコンテナーランタイムになりました。runC ランタイムは引き続きサポートされており、必要に応じてデフォルトのランタイムを runC に変更できます。crun の詳細は、コンテナーエンジンとコンテナーランタイムについて を参照してください。デフォルトを runC に変更する方法については、CRI-O パラメーターを編集するための ContainerRuntimeConfig CR の作成 を参照してください。
OpenShift Container Platform 4.17.z から OpenShift Container Platform 4.18 に更新しても、コンテナーのランタイムは変更されません。
1.3.16.2. sigstore のサポート (テクノロジープレビュー)
sigstore プロジェクトはテクノロジープレビューとして提供されており、これを OpenShift Container Platform でサプライチェーンのセキュリティー向上のために使用できます。クラスター全体のレベル、または特定の namespace に対して署名ポリシーを作成できます。詳細は、sigstore を使用したセキュアな署名管理 を参照してください。
1.3.16.3. ノード追加プロセスの拡張
OpenShift Container Platform 4.17 で導入された オンプレミスクラスターにワーカーノードを追加する プロセスが拡張されました。このリリースでは、ISO イメージファイルの代わりに Preboot Execution Environment (PXE) アセットを生成できるようになりました。また、ノード作成プロセスが失敗したかどうかにかかわらず、レポートが生成されるように設定することもできます。
1.3.16.4. Node Tuning Operator がカーネル引数を適切に選択
Node Tuning Operator が、Intel および AMD CPU のカーネル引数と管理オプションを適切に選択できるようになりました。(OCPBUGS-43664)
1.3.16.5. デフォルトのコンテナーランタイムが適切に設定されない場合がある
クラスター Node Tuning Operator によって設定されるデフォルトのコンテナーランタイムは、必ずクラスターから継承され、Operator によりハードコードされることはありません。このリリースから、デフォルト値は crun
になります。(OCPBUGS-45450)
1.3.17. OpenShift CLI (oc)
1.3.17.1. oc-mirror プラグイン v2 (一般提供)
oc-mirror プラグイン v2 が一般公開されました。これを使用するには、oc-mirror コマンドを実行するときに --v2
フラグを追加します。--v2
フラグが設定されていない場合に実行される以前のバージョン (oc-mirror プラグイン v1) は非推奨になりました。継続的なサポートと改善のために、oc-mirror プラグイン v2 に移行することが推奨されます。
詳細は、oc-mirror プラグイン v2 を使用した非接続インストールのイメージのミラーリング を参照してください。
oc-mirror プラグイン v2 は、Helm チャートのミラーリングをサポートするようになりました。また、oc-mirror プラグイン v2 は、HTTP/S
プロキシーが有効になっている環境でも使用できるようになりました。これにより、エンタープライズセットアップとの幅広い互換性が確保されます。
oc-mirror プラグイン v2 では、Operator カタログの v1 後方互換フィルタリングが導入され、フィルタリングされたカタログが生成されます。この機能により、クラスター管理者は、元のカタログの完全なリストではなく、ミラーリングされた Operator のみを表示できます。
1.3.18. Operator ライフサイクル
1.3.18.1. Operator Lifecycle Manager の既存バージョンの呼称を OLM (Classic) に変更
OpenShift Container Platform 4.18 以降で Operator Lifecycle Manager (OLM) v1 が一般提供 (GA) 機能としてリリースされるため、OpenShift Container Platform 4 以降に含まれている OLM の既存バージョンは OLM (Classic) と呼ばれるようになりました。
OLM (Classic) は引き続きデフォルトで有効になっており、OpenShift Container Platform 4 のライフサイクル全体を通して完全にサポートされます。
OLM v1 の GA リリースの詳細は、拡張機能 (OLM v1) リリースノートセクションを参照してください。OLM v1 に重点を置いた完全なドキュメントについては、拡張機能 ガイドを参照してください。
OLM (Classic) に重点を置いた完全なドキュメントについては、引き続き Operator ガイドを参照してください。
1.3.19. Oracle(R) Cloud Infrastructure (OCI)
1.3.19.1. Oracle (R) Cloud Infrastructure (OCI) でのベアメタルサポート
Oracle® Cloud Infrastructure (OCI) 上の OpenShift Container Platform クラスターのインストールが、ベアメタルマシンでサポートされるようになりました。Assisted Installer または Agent-based Installer を使用して、OCI にベアメタルクラスターをインストールできます。OCI にベアメタルクラスターをインストールするには、次のいずれかのインストールオプションを選択します。
1.3.20. インストール後の設定
1.3.20.1. Amazon Web Services で x86 コントロールプレーンを arm64 アーキテクチャーに移行する
このリリースでは、Amazon Web Services (AWS) 上のクラスター内のコントロールプレーンを x86
から arm64
アーキテクチャーに移行できます。詳細は、Amazon Web Services で x86 コントロールプレーンを arm64 アーキテクチャーに移行する を参照してください。
1.3.20.2. イメージストリームのインポートモードの動作設定 (テクノロジープレビュー)
この機能では、image.config.openshift.io/cluster
リソースに新しいフィールド imageStreamImportMode
が導入されます。imageStreamImportMode
フィールドは、イメージストリームのインポートモードの動作を制御します。imageStreamImportMode
フィールドを、次のいずれかの値に設定できます。
-
レガシー
-
PreserveOriginal
詳細は、イメージコントローラーの設定パラメーター を参照してください。
imageStreamImportMode
機能を有効にするには、FeatureGate
カスタムリソース (CR) で TechPreviewNoUpgrade
機能セットを有効にする必要があります。詳細は、フィーチャーゲートについて を参照してください。
1.3.21. Red Hat Enterprise Linux CoreOS (RHCOS)
1.3.21.1. RHCOS が RHEL 9.4 を使用
RHCOS は、OpenShift Container Platform 4.18 で Red Hat Enterprise Linux (RHEL) 9.4 パッケージを使用します。これらのパッケージにより、OpenShift Container Platform インスタンスが最新の修正、機能、機能拡張、ハードウェアサポート、およびドライバーの更新を確実に受け取ることができます。
1.3.22. レジストリー
読み取り専用レジストリーの強化
以前のバージョンの OpenShift Container Platform では、読み取り専用としてマウントされたストレージは、ストレージエラーに関する特定のメトリクスや情報を返しませんでした。これにより、ストレージバックエンドが読み取り専用であった場合に、レジストリーがサイレントな失敗となる可能性がありました。このリリースでは、バックエンドが読み取り専用に設定されている場合にストレージ情報を返すために、次のアラートが追加されました。
アラート名 | メッセージ |
---|---|
| イメージレジストリーストレージは読み取り専用で、イメージはストレージにコミットされません。 |
| イメージレジストリーストレージディスクが満杯になり、イメージはストレージにコミットされません。 |
1.3.23. スケーラビリティーおよびパフォーマンス
1.3.23.1. cluster-compare プラグインを使用したクラスター検証
cluster-compare
プラグインは、クラスター設定とターゲット設定を比較する OpenShift CLI (oc
) プラグインです。このプラグインは、設定可能な検証ルールとテンプレートを使用して、設定の差異を報告する一方で、想定内の差異は除外します。
たとえばプラグインは、オプションのコンポーネントやハードウェア固有のフィールドなど、想定内の違いを無視する一方で、フィールドの値の不一致、リソースの欠落、バージョンの不一致など、想定外の違いを強調できます。このように比較することで、ターゲット設定でクラスターコンプライアンスを簡単に評価できます。
cluster-compare
プラグインは、開発、実稼働、およびサポートのシナリオで使用できます。
cluster-compare
プラグインの詳細は、cluster-compare プラグインの概要 を参照してください。
1.3.23.2. Node Tuning Operator: チューニング更新の延期
このリリースでは、Node Tuning Operator にチューニング更新の延期に対するサポートが導入されました。管理者はこの機能を使用して、メンテナンス期間中に更新を適用するようにスケジュールできます。
詳細は、チューニング変更適用の延期 を参照してください。
1.3.23.3. NUMA Resources Operator でデフォルトの SELinux ポリシーを使用
このリリースでは、NUMA Resources Operator は、ターゲットノードへの Operator コンポーネントのインストールを有効にするカスタム SELinux ポリシーを作成しなくなりました。代わりに、Operator は組み込みのコンテナー SELinux ポリシーを使用します。この変更により、以前はインストール中にカスタム SELinux ポリシーを適用する際に必要であった追加のノードの再起動が不要になります。
既存の NUMA 対応スケジューラー設定を持つクラスターでは、OpenShift Container Platform 4.18 にアップグレードすると、設定済みの各ノードで追加の再起動が必要になる可能性があります。このシナリオでアップグレードを管理して中断を制限する方法の詳細は、Red Hat ナレッジベースの記事 Managing an upgrade to OpenShift Container Platform 4.18 or later for a cluster with an existing NUMA-aware scheduler configuration を参照してください。
1.3.23.4. Node Tuning Operator プラットフォーム検出
このリリースでは、パフォーマンスプロファイルを適用すると、Node Tuning Operator がプラットフォームを検出し、それに応じてカーネル引数やその他のプラットフォーム固有のオプションを設定します。このリリースでは、次のプラットフォームを検出するためのサポートが追加されました。
- AMD64
- AArch64
- Intel 64
1.3.23.5. AMD EPYC Zen 4 CPU を搭載したワーカーノードのサポート
このリリースでは、PerformanceProfile
カスタムリソース (CR) を使用して、AMD EPYC Zen 4 CPU (Genoa および Bergamo など) を搭載したマシンでワーカーノードを設定できます。これらの CPU は、単一の NUMA ドメイン (NPS=1) で設定されている場合に完全にサポートされます。
Pod ごとの電源管理機能は、AMD EPYC Zen 4 CPU では機能しません。
1.3.24. ストレージ
1.3.24.1. LVMCluster カスタムリソースの作成後のオーバープロビジョニング比率の更新
以前は、LVMCluster
カスタムリソース (CR) の thinPoolConfig.overprovisionRatio
フィールドは、LVMCluster
CR の作成中にのみ設定できました。このリリースにより、LVMCluster
CR の作成後にも thinPoolConfig.overprovisionRatio
フィールドを更新できるようになりました。
1.3.24.2. シンプールのメタデータサイズ設定のサポート
この機能により、LVMCluster
カスタムリソース (CR) に次の新しいオプションフィールドが提供されます。
-
thinPoolConfig.metadataSizeCalculationPolicy
: 基になるボリュームグループのメタデータサイズを計算するポリシーを指定します。このフィールドは、Static
またはHost
のいずれかに設定できます。デフォルトでは、このフィールドはHost
に設定されています。 -
thinPoolConfig.metadataSize
: シンプールのメタデータサイズを指定します。MetadataSizeCalculationPolicy
フィールドがStatic
に設定されている場合にのみ、このフィールドを設定できます。
詳細は、LVMCluster カスタムリソースについて を参照してください。
1.3.24.3. 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 は、OpenShift Container Platform 4.16 でテクノロジープレビューステータスで導入されました。OpenShift Container Platform 4.18 では、一般提供が開始されました。
詳細は、CIFS/SMB CSI Driver Operator を参照してください。
1.3.24.4. Secret Store CSI Driver Operator の一般提供開始
Secrets Store Container Storage Interface (CSI) Driver Operator である secrets-store.csi.k8s.io
を使用すると、OpenShift Container Platform がエンタープライズグレードの外部シークレットストアに保存されている複数のシークレット、キー、証明書をインラインの一時ボリュームとして Pod にマウントできます。Secrets Store CSI Driver Operator は、gRPC を使用してプロバイダーと通信し、指定された外部シークレットストアからマウントコンテンツを取得します。ボリュームがアタッチされると、その中のデータがコンテナーのファイルシステムにマウントされます。Secrets Store CSI Driver Operator は、OpenShift Container Platform 4.14 でテクノロジープレビュー機能として利用可能でした。OpenShift Container Platform 4.18 では、この機能の一般提供が開始されました。
Secrets Store CSI Driver の詳細は、Secrets Store CSI Driver Operator を参照してください。
Secrets Store CSI Driver Operator を使用して外部シークレットストアから CSI ボリュームにシークレットをマウントする方法については、外部シークレットストアを使用した機密データの Pod への提供 を参照してください。
1.3.24.5. 永続ボリュームの最終フェーズ遷移時間パラメーターの一般提供開始
OpenShift Container Platform 4.16 では、永続ボリューム (PV) が別のフェーズ (pv.Status.Phase
) に移行するたびに更新されるタイムスタンプを持つ新しいパラメーター LastPhaseTransitionTime
が導入されました。OpenShift Container Platform 4.18 では、この機能の一般提供が開始されました。
永続ボリュームの最終フェーズ遷移時間パラメーターの使用に関する詳細は、最終フェーズ遷移時間 を参照してください。
1.3.24.6. vSphere CSI の複数の vCenter に対するサポートの一般提供開始
OpenShift Container Platform 4.17 では、テクノロジープレビュー機能として、複数の vSphere クラスター (vCenter) をまたいで OpenShift Container Platform をデプロイする機能が導入されました。OpenShift Container Platform 4.18 では、複数の vCenter に対するサポートが一般提供されるようになりました。
詳細は、vSphere CSI の複数の vCenter サポート および vSphere のインストール設定パラメーター を参照してください。
1.3.24.7. 永続ボリュームの回収ポリシーを常に適用 (テクニカルプレビュー)
OpenShift Container Platform 4.18 より前は、永続ボリューム (PV) 回収ポリシーが常に適用されるとは限りませんでした。
バインドされた PV と永続ボリューム要求 (PVC) のペアの場合、PV 削除回収ポリシーが適用されるかどうは PV-PVC の削除順序によって決まります。PV を削除する前に PVC が削除された場合、PV は回収ポリシーを適用していました。しかし、PVC を削除する前に PV が削除された場合、回収ポリシーは適用されませんでした。この動作では、外部インフラストラクチャー内の関連付けられたストレージ資産は削除されませんでした。
OpenShift Container Platform 4.18 では、PV 回収ポリシーが常に一貫して適用されます。この機能はテクニカルプレビューです。
詳細は、永続ボリュームの回収ポリシー を参照してください。
1.3.24.8. LSO の LV または LVS を簡単に削除できる機能の改良と一般提供
OpenShift Container Platform 4.18 では、Local Storage Operator (LSO) のローカルボリューム (LV) とローカルボリュームセット (LVS) を削除する機能が向上し、アーティファクトが自動的に削除され、必要とする手順数が削減されます。
詳細は、ローカルボリュームまたはローカルボリュームセットの削除 を参照してください。
1.3.24.9. CSI ボリュームグループスナップショット (テクノロジープレビュー)
OpenShift Container Platform 4.18 では、テクノロジープレビュー機能として Container Storage Interface (CSI) ボリュームグループスナップショットが導入されています。この機能は CSI ドライバーによってサポートされている必要があります。CSI ボリュームグループスナップショットは、ラベルセレクターを使用して、スナップショット用に複数の永続ボリューム要求 (PVC) をグループ化します。ボリュームグループスナップショットは、同じ時点で取得された複数のボリュームからのコピーを表します。これは、複数のボリュームが含まれるアプリケーションに役立ちます。
OpenShift Data Foundation は、ボリュームグループのスナップショットをサポートしています。
CSI ボリュームグループスナップショットの詳細は、CSI ボリュームグループスナップショット を参照してください。
1.3.24.10. GCP PD CSI ドライバーにおけるベアメタル用 C3 インスタンスタイプのサポートと、N4 マシンシリーズの一般提供開始
Google Cloud Platform Persistent Disk (GCP PD) Container Storage Interface (CSI) ドライバーは、ベアメタルおよび N4 マシンシリーズの C3 インスタンスタイプをサポートしています。C3 インスタンスタイプと N4 マシンシリーズは、ハイパーディスクバランスディスクをサポートします。
さらに、大規模ストレージ向けにハイパーディスクストレージプールがサポートされています。ハイパーディスクストレージプールは、購入した容量、スループット、および IOPS のコレクションであり、必要に応じてアプリケーションにプロビジョニングできます。
OpenShift Container Platform 4.18 では、この機能の一般提供が開始されました。
詳細は、ベアメタルおよび N4 マシンシリーズの C3 インスタンスタイプ を参照してください。
1.3.24.11. OpenStack Manila 拡張永続ボリュームの一般提供開始
OpenShift Container Platform 4.18 では、OpenStack Manila は Container Storage Interface (CSI) 永続ボリューム (PV) の拡張をサポートしています。この機能は一般提供されています。
詳細は、永続ボリュームの拡張 および OpenShift Container Platform がサポートする CSI ドライバー を参照してください。
1.3.24.12. ワークロードアイデンティティーをサポートする GCP Filestore の一般提供開始
OpenShift Container Platform 4.18 では、Google Compute Platform (GCP) Filestore Container Storage Interface (CSI) ストレージが Workload Identity をサポートしています。これにより、ユーザーはサービスアカウントキーの代わりにフェデレーションアイデンティティーを使用して Google Cloud リソースにアクセスできます。OpenShift Container Platform 4.18 では、この機能の一般提供が開始されました。
詳細は、Google Compute Platform Filestore CSI Driver Operator を参照してください。
1.3.25. Web コンソール
1.3.25.1. 管理者パースペクティブ
このリリースでは、Web コンソールの Administrator パースペクティブに次の更新が導入されています。
- Overview ページの Getting started resources カードを非表示にして、ダッシュボードを最大限に活用できる新しい設定。
-
CronJob の List と Details ページに Start Job オプションが追加されました。これにより、
oc
CLI を使用せずに、Web コンソールで個々の CronJob を手動で直接開始できるようになりました。 - masthead の Import YAML ボタンは、Quick Create ボタンになりました。これは、YAML、Git からのインポート、またはコンテナーイメージの使用によってワークロードを迅速にデプロイメントするために使用できます。
- チャットボットのサンプルを使用して、独自の生成 AI チャットボットを構築できます。生成 AI チャットボットのサンプルは Helm を使用してデプロイされ、完全な CI/CD パイプラインが含まれています。このサンプルは、CPU のないクラスターでも実行できます。
- OpenShift Lightspeed を使用して YAML をコンソールにインポートできます。
1.3.25.1.1. コンテンツセキュリティーポリシー (CSP)
このリリースでは、コンソールのコンテンツセキュリティーポリシー (CSP) がレポート専用モードでデプロイされます。CSP 違反はブラウザーのコンソールに記録されますが、関連する CSP ディレクティブは適用されません。動的プラグインの作成者は、独自のポリシーを追加できます。
さらに、セキュリティーポリシーに違反するプラグインを報告することもできます。管理者は、これらのポリシーに違反するプラグインを無効にできます。CSP 違反はブラウザーのコンソールに記録されますが、関連する CSP ディレクティブは適用されません。この機能は feature-gate
の背後にあるため、手動で有効にする必要があります。
詳細は、コンテンツセキュリティーポリシー (CSP) および Web コンソールを使用した機能セットの有効化 を参照してください。
1.3.25.2. Developer パースペクティブ
このリリースでは、Web コンソールの 開発者 パースペクティブに次の更新が導入されています。
- OpenShift Container Platform ツールキット、Quarkus ツールと JBoss EAP、および Visual Studio Code と IntelliJ 用の Language Server Protocol Plugin が追加されました。
- 以前は、Monaco エディターでライトモードからダークモードに切り替えても、コンソールはダークモードのままでした。この更新により、Monaco コードエディターは選択したテーマに一致するようになります。