サービスの制限
Red Hat® OpenShift® on IBM Cloud® と Red Hat OpenShift オープンソース・プロジェクトは、セキュリティー、利便性、および基本的な機能を確保するためのデフォルトのサービス設定と制限を備えています。 いくつかの制限は、特記されている部分で変更できるかもしれない。
Red Hat OpenShift on IBM Cloud の以下のいずれかの制限に達することが予想される場合は、IBM サポートに連絡し、サポート・チケットにクラスター ID、新しいクォータ制限、リージョンを記入してください。
サービスとクォータの制限
使用するインフラストラクチャー・プロバイダーに関係なく、Red Hat OpenShift on IBM Cloud では、サービスに関する以下の制限と上限数がすべてのクラスターに適用されます。 クラシック・クラスターと VPC クラスターの制限も適用されることに留意してください。
ご使用の IBM Cloud アカウントにおけるクラスター関連リソースのクォータ制限を確認するには、ibmcloud oc quota ls コマンドを使用してください。
| カテゴリ | 説明 |
|---|---|
| API レート制限 | 固有の各ソース IP アドレスから、Red Hat OpenShift on IBM Cloud API に対して 10 秒ごとに 200 個の要求。 |
| アプリのデプロイメント | クラスターにデプロイするアプリ、およびクラスターと統合するサービスは、ワーカー・ノードのオペレーティング・システムで実行できるものでなければなりません。 |
| Calico ネットワーク・プラグイン | Calico のプラグイン、コンポーネント、またはデフォルトの Calico 設定の変更はサポートされていません。 例えば、新しい Calico プラグイン・バージョンをデプロイしたり、Calico コンポーネント、デフォルトの IPPool リソース、または Calico ノードのデーモン・セットまたはデプロイメントを変更したりしないでください。 代わりに、Calico の NetworkPolicy または GlobalNetworkPolicy の作成、
Calico MTU の変更、Calico CNI のポート・マップ・プラグインの無効化を、資料の手順に従って行うことができます。 |
| クラスターのクォータ | 1 リージョン、1 インフラストラクチャー・プロバイダーにつき 100 個を超えてはいけません。 ただし、2024 年 1 月 1 日の時点で、割り当て量は 100 に達する前に増分的に増加します。 これより多いリソースが必要な場合は、IBM サポートにお問い合わせください。
サポートケースには、希望するリージョンとインフラストラクチャプロバイダの新しいクォータ制限を含めてください。 割り当て量をリストするには、 ibmcloud quota ls を実行します。 |
| Kubernetes | Kubernetes プロジェクトの制限事項を必ずご確認ください。 |
| KMS プロバイダー | IBM® Key Protect for IBM Cloud® インスタンスへの接続を許可されている IP アドレスをカスタマイズすることはサポートされません。 |
| Red Hat OpenShift | ご使用のバージョンの OpenShift Container Platform の制限を確認してください。 |
| Kubernetes ポッド・ログ | 個々のアプリ・ポッドのログを確認するには、コマンド・ラインを使用して oc logs <pod name> を実行します。 Kubernetes ダッシュボードを使用してポッドのログのストリーミングをしないでください。Kubernetes ダッシュボードへのアクセスが中断される可能性があります。 |
| Monitoring |
|
| オペレーティング・システム | ワーカー・ノードは、サポートされるオペレーティング・システムのいずれかを実行する必要があります。 異なるタイプのオペレーティング・システムを実行するワーカー・ノードを使用してクラスターを作成することはできません。 詳しくは、 Red Hat OpenShift on IBM Cloud バージョン情報 を参照してください。 |
| OperatorHub カタログ | プライベート・クラスターで OperatorHub カタログを使用するには、 OperatorHub および icr.io へのカタログ・ソース・イメージのミラーリングを参照してください。 |
| ポッドのインスタンス | ワーカー・ノードごとに 110 個のポッドを実行できます。 CPU コアを 11 個以上搭載したワーカー・ノードでは、1 コアあたり 10 個のポッドをサポートできますが、ポッド数には 1 ワーカー・ノードあたり最大 250 個という制限があります。 ポッドの数には、ワーカー・ノードで実行される kube-system ポッドと ibm-system ポッドが含まれます。 パフォーマンスを高めるために、コンピュート・コアごとに実行するポッドの数を制限して、ワーカー・ノードを過剰に使用しないようにすることを検討してください。
例えば、b3c.4x16 フレーバーのワーカー・ノードでは、ワーカー・ノードの合計容量の 75% 以下を使用する、コアあたり 10 個のポッドを実行できます。 |
| 非推奨 時刻ベースのワンタイム・パスコード (TOTP) | TOTP を使用するには、 IBM Cloud アカウント全体に対して 多要素認証(MFA)を有効にする 必要があります。 多要素認証 (MFA) がアカウント全体ではなく一部のユーザーに対してのみ有効になっている場合、認証エラーが発生する可能性があります。 |
| ワーカー・ノードのクォータ | 2024年1月1日以前に作成されたアカウントは、最大500ワーカーノード。 その日以降に作成されたアカウントについては、より低いクォータが一定期間続いた後、最大クォータは200となります。 割り当て量は、クラスター インフラストラクチャー・プロバイダー ごとに適用されます。 これより多いリソースが必要な場合は、
IBM サポートにお問い合わせください。 サポートケースには、希望するリージョンとインフラストラクチャプロバイダの新しいクォータ制限を含めてください。 実行されたクォータをリストアップするには、 ibmcloud ks quota ls。 |
| ワーカー・プールのサイズ | クラスタには常に最低2ノードが必要です。 ワーカー・ノードのクォータによって、1 クラスターあたりのワーカー・プール数と 1 ワーカー・プールあたりのワーカー・ノード数は制限されます。 例えば、1 リージョンあたり 500 台というデフォルトのワーカー・ノード・クォータでは、クラスターが 1 つしか存在しないリージョンに、ワーカー・ノード 1 台のワーカー・プールを最大 500 個作成できます。 また、クラスターが 1 つしか存在しないリージョンに、ワーカー・プールを 1 個作成し、ワーカー・ノードを最大 500 台含めることもできます。 |
| Red Hat Enterprise Linux CoreOS ワーカー・ノード | クラスターに追加されるゾーンの最大数は 15 です。 例えば、それぞれが 3 つのゾーンを持つ 4 つの RHCOS ワーカー・プールは、そのクラスターの割り当て量の 12/15 を占めることになります。 |
| ワーカー・ノードの数 | クラスタは最大500ワーカーノードを持つことができます。 |
| Red Hat Enterprise Linux CoreOS ワーカー・ノード | クラスターに追加されるゾーンの最大数は 15 です。 例えば、それぞれが 3 つのゾーンを持つ 4 つの RHCOS ワーカー・プールは、そのクラスターの割り当て量の 12/15 を占めることになります。 |
| クラスター命名 | Ingress のサブドメインと証明書が正しく登録されるようにするには、クラスターの名前の最初の 24 文字が異なっている必要があります。 自動化やテストなどの目的で、7 日以内に最初の 24 文字が 5 回以上同じ名前のクラスターを作成して削除すると、証明書の重複レート制限の暗号化に到達する可能性があります。 |
| リソース・グループ | クラスターは 1 つのリソース・グループにしか作成できず、作成後にリソース・グループを変更することはできません。 誤ったリソース・グループにクラスターを作成した場合、クラスターを削除してから、正しいリソース・グループにクラスターを再作成する必要があります。 また、ibmcloud oc cluster service bind コマンドを使用して IBM Cloud サービスと統合する必要がある場合は、このサービスがクラスターと同じリソース・グループにある必要があります。
IBM Cloud Container Registry のようなリソース・グループを使用しないサービスや、 IBM Cloud Logs のようなサービス・バインディングを必要としないサービスは、クラスタが異なるリソース・グループであっても動作します。 |
Red Hat OpenShift on IBM Cloud クラスターの制限
Red Hat OpenShift クラスターに特有の制限を見直す。 サービスとクラシック・クラスターまたは VPC クラスターの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| クラスターの自動スケーリング | Red Hat OpenShift Administration > Cluster Settings コンソールまたは autoscaling.openshift.io/v1 APIからの ClusterAutoscaler オブジェクトからの Red Hat OpenShift クラスタオートスケーラーはサポートされていません。 代わりに、ibm-iks-cluster-autoscaler Helm プラグインを使用してください。 |
| クラスターの更新 | クラスターの更新には、Red Hat OpenShift on IBM Cloud の API、CLI、またはコンソール・ツールを使用する必要があります。 Red Hat OpenShift Web コンソールなどの OpenShift Container Platform ツールからクラスター・バージョンを更新することはできません。 |
| コンテナー・ログ | Fluentd などのコンテナー・ロギング・オペレーターを使用して ElasticSearch スタックにログを送信する場合は、ibmc-block-gold ストレージ・クラスを使用するようにクラスター・ロギング・デプロイメントを更新する必要があります。 |
| プライベート・クラスター |
インフラストラクチャー・プロバイダーに応じて、プライベート・クラスターのオプションが制限されます。
|
| ロギング | OpenShift Container Platform Elasticsearch、 Fluentd、および Kibana(EFK)スタックをセットアップするには、 「クラスター ロギング オペレーターのインストール」を 参照してください。 |
| サービス・カタログ | サービス・カタログはサポートされていません。 代わりにオペレーターを使用してください。 OperatorHub を使用してサービス・カタログをインストールしないでください。 |
| サービス・メッシュ | Istio マネージド・アドオンはサポートされていません。 代わりに、 Red Hat サービスメッシュ演算子を使用する。 注: ルーターのデフォルトの IBM Cloud 構成ではホスト・ネットワーキングが有効になり、サービス・メッシュ・ネットワーク・ポリシーとの互換性がなくなります。 サービス・メッシュのイングレスを機能させるには、 ネットワーク・ポリシーを適用する。 |
クラシック・クラスターの制限
Red Hat OpenShift on IBM Cloud のクラシック・インフラストラクチャー・クラスターは、以下の制限付きでリリースされます。
コンピュート
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| 予約済みインスタンス | 予約済み容量と予約済みインスタンスはサポートされません。 |
| ワーカー・ノードのフレーバー | ワーカー・ノードは、コンピュート・リソースの一部のフレーバーで利用できる。 |
| ワーカー・ノードのホスト・アクセス | セキュリティーのため、ワーカー・ノードのコンピュート・ホストに SSH で接続することはできません。 |
ネットワーキング
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| Ingress ALB |
|
| ネットワーク・ロード・バランサー (NLB) |
|
| Red Hat OpenShift Web コンソール | パブリックとプライベートのクラウド・サービス・エンドポイントの両方があるクラスターでは、Web コンソールをプライベート・ネットワークで公開することはできません。 プライベートネットワーク上でウェブコンソールを公開したい場合、クラスタはパブリックエンドポイントを有効にすることはできません。 |
| プライベート VLAN のみ | プライベートのネットワーク・ロード・バランサー (NLB) はドメイン・ネーム・サーバー (DNS) に登録できないため、プライベート・ネットワーク・インターフェースのみでクラスターを作成することはできません。 ワーカー・ノードは、パブリック VLAN とプライベート VLAN の両方に接続する必要があります。 それでも、プライベート・サービスを作成してプライベート・ネットワークのみでアプリを公開することは可能です。 |
| サービス・エンドポイント | クラスターの作成時には、パブリックとプライベートの両方のクラウド・サービス・エンドポイントを有効にするか、パブリックのクラウド・サービス・エンドポイントのみを有効にすることができますが、プライベートのクラウド・サービス・エンドポイントのみを有効にすることはできません。 クラスターの作成後にはサービス・エンドポイントを変更することはできません。 |
| strongSwan VPN サービス | strongSwan VPN サービスの考慮事項を参照してください。 |
| サービス IP アドレス | クラスター内の Kubernetes サービスに割り当てることができる IP アドレスは、172.21.0.0/16 の範囲で、1 クラスターあたり 65,000 個です。 |
| VLAN 1 つのあたりのサブネット数 | 各 VLAN のサブネット数の上限は 40 個です。 |
ストレージ
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| ボリュームのインスタンス | アカウントごとに合計 250 個の IBM Cloud インフラストラクチャー・ファイルとブロック・ストレージ・ボリュームを作成できます。 この量を超えてマウントすると、永続ボリュームのプロビジョニング時に out of capacity メッセージが表示されることがあります。 その他のFAQについては、 ファイル および ブロックストレージ のドキュメントを参照してください。 さらにボリュームをマウントする場合は、 IBM サポートにお問い合わせください。 サポート・チケットに、アカウント ID と、必要とするファイル・ストレージまたはブロック・ストレージのボリュームの新しいクォータを記入してください。 |
| Portworx | Portworx の制限を確認してください。 |
| ファイル・ストレージ | IBM Cloud NFS ファイル・ストレージが Linux ユーザー許可を構成する方法によって、ファイル・ストレージの使用時にエラーが発生する場合があります。 その場合、 Red Hat OpenShift セキュリティ・コンテキスト制約を構成するか、別のストレージ・タイプを使用する必要があるかもしれません。 |
ユーザーのアクセス権限
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| IP アドレスのアクセス | IPアドレスによるアクセスを有効にすることで特定のユーザーのアクセスを制限することは、 Red Hat OpenShift on IBM Cloud ではサポートされていません。 ユーザーアクセスを制限したい場合、またはユーザーがアクセスできるサービスやVPCを制限したい場合は、 コンテキストベースの制限 を検討してください。 |
VPC クラスターの制限
Red Hat OpenShift on IBM Cloud の VPC クラスターは、以下の制限付きでリリースされます。 また、基礎的な VPC クォータ、VPC 制限、VPC サービスの制限、通常のサービスの制限がすべて適用されます。
コンピュート
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| 暗号化 | ワーカー・ノードの 2 次ディスクの保存データは、基礎の VPC インフラストラクチャー・プロバイダーによってデフォルトで暗号化されます。 ただし、基礎の仮想サーバー・インスタンスに独自の暗号化を持ち込むことはできません。 |
| Location | VPCクラスタは、 一部のマルチゾーン・リージョンでのみ 利用可能です。 |
| Virtual Private Cloud | 制限と、クォータを参照してください。 |
| ワーカー・ノードのフレーバー | ワーカー・ノードの仮想マシンでは、特定のフレーバーのみを使用できます。 ベアメタル・マシンはサポートされていません。 |
| ワーカー・ノードのホスト・アクセス | セキュリティーのため、ワーカー・ノードのコンピュート・ホストに SSH で接続することはできません。 |
| ワーカー・ノードの更新 | VPCワーカーノードの更新やリロードはできません。 代わりに、ibmcloud oc worker replace コマンドによって、ワーカー・ノードを削除してワーカー・プールのバランスを再調整することができます。 複数のワーカー・ノードを同時に置換すると、それらのノードは 1 つずつではなく、同時に削除されて置換されます。 ワーカー・ノードを置換する前に、ワークロードのスケジュールを変更するための十分な容量がクラスター内にあることを確認してください。 |
ネットワーキング
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| アプリの URL の長さ | DNS 解決は、クラスターの仮想プライベート・エンドポイント (VPE) で管理されます。VPE では URL を最大 130 文字に解決できます。 Ingress のサブドメインや Red Hat OpenShift の経路などの URL を使用してクラスター内のアプリを公開する場合は、URL が 130 文字以下になるようにしてください。 |
| ネットワーク速度 | VPC プロファイルのネットワーク速度は、ワーカー・ノードのインターフェースの速度を表しています。 ワーカーノードで利用可能な最大速度は 25Gbps です。 異なるサブネット上にあるポッド間のトラフィックにはIP in IPカプセル化が必要なため、異なるサブネット上にあるポッド間のデータ転送速度は、コンピュート・プロファイルのネットワーク速度の約半分と遅くなる可能性があります。
クラスターにデプロイするアプリの全体的なネットワーク速度は、ワーカー・ノードのサイズとアプリケーションのアーキテクチャーによって異なります。 |
| NodePort | NodePort を使用してアプリにアクセスできるのは、例えば VPN 接続などを使用して、プライベート VPC ネットワークに接続している場合だけです。 インターネットからアプリにアクセスするには、代わりに VPC ロード・バランサー・サービスまたは Ingress サービスを使用する必要があります。 |
| ポッドのネットワーク | VPC のアクセス制御リスト (ACL) は、サブネットのレベルでクラスターの送受信トラフィックをフィルタリングし、セキュリティー・グループは、ワーカー・ノードのレベルでクラスターの送受信トラフィックをフィルタリングします。 クラスター内部のトラフィックをポッド間のレベルで制御するために、VPC のセキュリティー・グループや ACL を使用することはできません。 代わりに、IP in IP カプセル化を使用するポッド・レベルのネットワーク・トラフィックを制御可能な Calico と Kubernetes のネットワーク・ポリシーを使用してください。 |
| パブリック・ゲートウェイ | パブリック・サービス・エンドポイントが有効な場合、ワーカー・ノードがパブリック・ネットワーク上で通信できるように、各 VPC サブネットにパブリック・ゲートウェイを接続する必要があります。 Red Hat OpenShift のデフォルトのコンポーネント (Web コンソールや OperatorHub など) を使用するには、パブリック・ネットワークへのアクセスが必要です。 |
| サービス・エンドポイント | IBM Cloud のコンソールで VPC クラスターを作成すると、パブリックとプライベートの両方のクラウド・サービス・エンドポイントがクラスターに作成されます。 プライベート・クラウド・サービスのエンドポイントのみが必要な場合は、代わりに CLIで クラスタを作成し、 --disable-public-service-endpoint オプションを含める必要があります。 このオプションを含めると、クラスタはルーターとIngressコントローラーで作成され、デフォルトではプライベートネットワークにのみアプリが公開されます。 後からアプリをパブリック・ネットワークに公開する必要が生じた場合は、パブリックのルーターと Ingress コントローラーを手動で作成する必要があります。 |
| strongSwan VPN サービス | strongSwan サービスはサポートされていません。 オンプレミスのネットワークや別の VPC のリソースにクラスターを接続するには、VPC で VPN を使用する方法を参照してください。 |
| Subnets |
|
| VPC ロード・バランサー | VPC ロード・バランサーの制限を参照してください。 |
ストレージ
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| プロファイル・サイズに対するストレージ・クラス | 詳しくは、 使用可能なボリューム・プロファイル を参照してください。 |
| サポートされるタイプ | IBM Cloud Object Storageと Cloud Databases のみをセットアップできます。 |
| ボリューム接続 | ボリューム接続の制限を参照してください。 |
| Portworx | Portworx の制限を確認してください。 |
| Block Storage for VPC | VPCクラスタのデフォルト・ストレージ・クラスは変更できません。 ただし、 独自のストレージ・クラスを作成 できます。 |
ユーザーのアクセス権限
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| IP アドレスのアクセス | IPアドレスによるアクセスを有効にすることで特定のユーザーのアクセスを制限することは、 Red Hat OpenShift on IBM Cloud ではサポートされていません。 ユーザーアクセスを制限したい場合、またはユーザーがアクセスできるサービスやVPCを制限したい場合は、 コンテキストベースの制限 を検討してください。 |
Satellite クラスターの制限
Red Hat OpenShift on IBM Cloud ロケーションで作成する Satellite クラスターに関する、以下の制限事項を確認してください。 サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| クラスターのアドオン | Red Hat OpenShift クラスター (Satellite ロケーションの) でサポートされないマネージド・アドオン を確認します。 例えば、クラスター自動スケーリング機能や Istio はサポートされません。 |
| ネットワーク | -デフォルトでは、 Satellite クラスターを使用してデプロイされたロード・バランサー・コントローラーは存在しないため、 Kubernetes LoadBalancer サービス はデフォルトではプロビジョンされません。
独自のロード・バランサー・ソリューションをクラスター ( MetalLB など) に統合することができます。 -クラスターのワーカー・ノードを実行するホストは、 ホスト・ネットワーキング およびプロバイダー固有の要件 ( AWS、 Azure、 GCP(G)、 IBM Cloud など) を満たす必要があります (テストおよびデモンストレーションの目的のみ)。 -ワーカー・ノードが異なるポッド間のトラフィックに VXLAN カプセル化が必要であるため、 異なるワーカー・ノード上のポッド間のデータ転送速度は、ホストのネットワーク機能より遅くなる可能性があります。 |
| ワーカー・ノード・ホストのストレージ | ホスト・ストレージおよび接続デバイスを参照してください。 |
| アプリ用ストレージ | デフォルトでは、ストレージ・プロバイダーは Satellite クラスターにインストールされません。 したがって、ストレージ・デバイスによってサポートされる Kubernetes 永続ボリュームにアプリケーション・データを保管するための、事前構成済みの Kubernetes ストレージ・クラスは、デフォルトでクラスターにセットアップされません。 ストレージ・プロバイダーをセットアップする方法については、Satellite ストレージ・テンプレートについてを参照してください。 |
| ワーカー・ノード | ワーカー・ノードは、お客様独自のインフラストラクチャー環境内のホストで実行されます。 ホストは、ホストの要件とプロバイダー固有の要件 (AWS、Azure、
GCP、IBM Cloud (テストおよびデモンストレーションのみ) など) を満たしている必要があります。 ワーカーノードの追加や更新 など、 ホストのインフラストラクチャライフサイクルを管理する 責任があります。 そのため、ibmcloud oc worker add, update, replace, reload コマンドなどのワーカー・ノードの操作はサポートされていません。 |
| ワーカー・プール | resize などの操作を使用するために、ワーカー・プールではホスト・ラベルを使用します。ホスト・ラベルは、Satellite ロケーションにある空きホスト (割り当てられていないホスト) と一致している必要があります。 |
| 単一ノード・クラスター | ワーカー・ノードが 3 台未満のクラスターには、高可用性がありません。 単一ノード・クラスターをプロビジョニングすることで、ワークロードでダウン時間や中断が発生する可能性が高くなり、通常のワーカー・ノードのアップグレードによってワークロードがオフラインになることを受け入れます。 さらに、クラスターが単一ノード・クラスターとしてプロビジョンされている場合、後で標準の高可用性クラスターに変換することはできません。 ノードをさらに追加することはできますが、標準デプロイメントではレプリカ・サイズは増加せず、クラスターは高可用性になりません。 単一ノード・クラスターは、 Red Hat CoreOS(RHCOS)が有効になっている Satellite ロケーションで実行する必要があります。 ロケーション上のコントロール・プレーン・ホスト、および単一ノード・クラスターに割り当てるホストは、RHEL 8 または RHCOS のいずれかのオペレーティング・システムを実行する必要があります。 バージョン 4.11 以降を実行する Satellite クラスターでのみサポートされます。 OpenShift Data Foundation は、単一ノード・クラスターではサポートされません。 Portworx は、単一ノード・クラスターではサポートされていません。 |
Red Hat OpenShift on IBM Cloud でサポートされない機能とオペレーター
以下の機能およびオペレーターは、Red Hat OpenShift on IBM Cloud ではサポートされていません。
Red Hat OpenShift内の MachineConfig ファイルを使用してワーカー・ノードのパフォーマンスを調整する代わりに、 daemonset ファイルを使用してホストを変更できます。 詳しくは、 Calico MTU の変更 または Red Hat CoreOS ワーカー・ノードのパフォーマンスのチューニング を参照してください。
- AMQ Broker
- AMQ Broker LTS
- AMQ Interconnect
- AMQ Online
- AMQ Streams
- Ansible Automation Platform Resource Operator
- API Designer
- Business Automation Operator
- Camel K
- Cost management Operator
- Data Grid Operator
- デバイス・マネージャー
- File Integrity Operator
- Fuse Console
- Fuse Online
- Gatekeeper Operator
- JBoss EAP
- JBoss Web Server
- 論理ボリューム・マネージャー・ストレージ (LVM)
- MachineConfigs
- Metering and Cost Management SaaS Service
- OpenShift Cloud Manager (OCM) SaaS サービス
- OpenShift クラスタワイドプロキシ
- OpenShift Data Foundation: クラスター・アドオン (クラシック・クラスターおよび VPC クラスターの場合)、または Satellite テンプレート ( Satellite クラスターの場合) を介してサポートされます。
- OpenShift Virtualization Operator
- OVS and OVN SDN
- Performance Add-on Operator
- PTP Operator
- Quay Operator
- Red Hat OpenStack プラットフォーム
Kuryr統合 - Red Hat Integration Operator
- Service Registry Operator
- Smart Gateway Operator
- SR-IOV ネットワーク・オペレーター: Satellite クラスターでのみサポートされます。
- Telemeter and Insights Connected Experience
- Windows マシン構成: Windows オペレーティング・システムを使用するワーカー・ノードはサポートされません。
ImageContentSourcePolicyImageDigestMirrorSetおよび はサポートされていません。ImageTagMirrorSet