サービスの制限と利用枠
クラスターに適用されるサービスの制限やクォータを確認し、必要に応じて調整可能な制限について理解しましょう。
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 ダッシュボードへのアクセスが中断される可能性があります。 |
| モニター |
|
| オペレーティング・システム | ワーカー・ノードは、サポートされるオペレーティング・システムのいずれかを実行する必要があります。 異なるタイプのオペレーティング・システムを実行するワーカー・ノードを使用してクラスターを作成することはできません。 詳しくは、 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 ワーカー・ノード | クラスタに追加できるゾーンの最大数は12です。 例えば、3つのゾーンを持つ3つのRHCOSワーカープールは、そのクラスタのクォータの9/12を占めます。 |
| ワーカー・ノードの数 | クラスタは最大500ワーカーノードを持つことができます。 |
| クラスター命名 | 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 管理 > クラスタ設定 コンソールからの Red Hat OpenShift クラスタのオートスケーラー、および autoscaling.openshift.io/v1 APIからの ClusterAutoscaler オブジェクトはサポートされていません。 代わりに、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 コンソールをプライベート・ネットワークで公開することはできません。 プライベートネットワーク上でWebコンソールを公開したい場合、クラスターでパブリックエンドポイントが有効になっていてはなりません。 |
| プライベート VLAN のみ | プライベートのネットワーク・ロード・バランサー (NLB) はドメイン・ネーム・サーバー (DNS) に登録できないため、プライベート・ネットワーク・インターフェースのみでクラスターを作成することはできません。 ワーカー・ノードは、パブリック VLAN とプライベート VLAN の両方に接続する必要があります。 それでも、プライベート・サービスを作成してプライベート・ネットワークのみでアプリを公開することは可能です。 |
| サービス・エンドポイント | クラスターの作成時には、パブリックとプライベートの両方のクラウド・サービス・エンドポイントを有効にするか、パブリックのクラウド・サービス・エンドポイントのみを有効にすることができますが、プライベートのクラウド・サービス・エンドポイントのみを有効にすることはできません。 クラスターの作成後にはサービス・エンドポイントを変更することはできません。 |
| 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 サービスの制限、通常のサービスの制限がすべて適用されます。
コンピュート
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| VPCごとのクラスタ | VPCはそれぞれ25クラスタまでに制限されています。 |
| 暗号化 | ワーカー・ノードの 2 次ディスクの保存データは、基礎の VPC インフラストラクチャー・プロバイダーによってデフォルトで暗号化されます。 ただし、基礎の仮想サーバー・インスタンスに独自の暗号化を持ち込むことはできません。 |
| ロケーション | VPCクラスターは、 特定のマルチゾーンリージョン でのみ利用可能です。 |
| Virtual Private Cloud | 制限と、クォータを参照してください。 |
| VPCリソースクォータ | VPCは、 vCPU, メモリ、GPU、インスタンス・ストレージ、および最適化されたインスタンス・ストレージ・リソースのクォータをアカウントごとに管理します。 パブリックインフラ上で仮想サーバーインスタンス（VSI）ワーカーノードをプロビジョニングする場合、これらのリソースは VPC アカウントクォータにカウントされます。 クォータの上限に達すると、ワーカーノードのプロビジョニングは失敗します。 現在のクォータと使用量を表示するには、 VPCリソース・メトリクスの表示を参照してください。 クォータ増量をご希望の場合は、VPCにサポートケースをご請求ください。 詳細については、「 VPC クォータ 」を参照してください。
注 ：このクォータ管理は、現在、パブリックインフラストラクチャ上のVSIワーカーノードにのみ適用されます。専用ホストおよびベアメタルワーカーノードのクォータ管理については、引き続き Red Hat OpenShift on IBM Cloud が担当します。 |
| ワーカー・ノードのフレーバー | ワーカーノードの仮想マシンおよびベアメタルワーカーでは、特定のフレーバーのみが利用可能です。 |
| ワーカー・ノードのホスト・アクセス | セキュリティーのため、ワーカー・ノードのコンピュート・ホストに SSH で接続することはできません。 |
| ワーカー・ノードの更新 | VPC ワーカーの更新処理は、ワーカーの種類によって異なります。 VPC ベアメタル環境をご利用の場合、 ibmcloud oc worker reload コマンドを使用してリロードを実行できます。 VPC 仮想サーバーインスタンスのワーカーについては、 ibmcloud oc worker replace コマンドを使用してください。 複数のワーカー・ノードを同時に置換すると、それらのノードは 1 つずつではなく、同時に削除されて置換されます。
ワーカー・ノードを置換する前に、ワークロードのスケジュールを変更するための十分な容量がクラスター内にあることを確認してください。 |
ネットワーキング
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| アプリの URL の長さ | DNS 解決は、クラスターの仮想プライベート・エンドポイント (VPE) で管理されます。VPE では URL を最大 130 文字に解決できます。 Ingress のサブドメインや Red Hat OpenShift の経路などの URL を使用してクラスター内のアプリを公開する場合は、URL が 130 文字以下になるようにしてください。 |
| ネットワーク速度 | VPC プロファイルのネットワーク速度は、ワーカー・ノードのインターフェースの速度を表しています。 VPCインスタンスで利用可能な帯域幅は、ストレージトラフィックとネットワークトラフィックで共有されます。 デフォルトでは、ストレージの割り当ては最大帯域幅の25%です。 以下の表に示すネットワーク速度は、デフォルトの25%のストレージ帯域幅割り当てを差し引いた後の、単一のネットワークインターフェイスを持つワーカーが利用可能なネットワーク帯域幅です。 |
| 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 コントローラーを手動で作成する必要があります。 |
| Subnets |
|
| VPC ロード・バランサー | VPC ロード・バランサーの制限を参照してください。 |
ストレージ
サービスの制限も適用されることに留意してください。
| カテゴリ | 説明 |
|---|---|
| プロファイル・サイズに対するストレージ・クラス | 詳しくは、 使用可能なボリューム・プロファイル を参照してください。 |
| サポートされるタイプ | IBM Cloud Object Storageと Cloud Databases のみをセットアップできます。 |
| ボリューム接続 | ボリューム接続の制限を参照してください。 |
| Portworx | Portworx の制限を確認してください。 |
| Block Storage for VPC | 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 永続ボリュームにアプリケーション・データを保管するための、事前構成済みの 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 ではサポートされていません。
ワーカーノードのパフォーマンスを /etc/systemd/system/ 内の systemd.conf MachineConfig ファイルで調整する代わりに、 Red Hat OpenShift /etc/systemd/system/ 内の systemd.conf daemonset ファイルでホストを変更できます。
詳細については、 「MTU Calico の変更」 または 「 Red HatCoreOS ワーカーノードのパフォーマンス調整」 を参照してください。
- 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 SDNおよびその他のほとんどのネットワークプラグインはサポートされていません
- Calico すべてのクラスタバージョンでサポートされています。
- OVNは、バージョン 4.20 以降のVPC Red Hat OpenShift クラスターにおいて、RHCOSワーカーノードのみに対応しています。
- 通常のクラスタマスターの更新プロセス以外で、これらのネットワークプラグインを更新または削除しないでください。
- 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