---
name: openshift-limitations
title: Service limitations and quotas
description: Review the service limitations and quotas that apply to clusters, and learn which limits can be adjusted when needed.
last-updated: 2026-08-03
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/openshift?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Service limitations and quotas
{: #limitations}

Review the service limitations and quotas that apply to clusters, and learn which limits can be adjusted when needed.
{: shortdesc}


If you anticipate reaching any of the following Red Hat OpenShift on IBM Cloud limitations, [contact IBM Support](https://cloud.ibm.com/docs/openshift?topic=openshift-get-help&format=markdown) and provide the cluster ID, the new quota limit, and the region in your support ticket.
{: tip}

## Service and quota limitations
{: #tech_limits}

Red Hat OpenShift on IBM Cloud comes with the following service limitations and quotas that apply to all clusters, independent of what infrastructure provider you plan to use. Keep in mind that the [classic](#classic_limits) and [VPC](#ks_vpc_gen2_limits) cluster limitations also apply.
{: shortdesc}

To view quota limits on cluster-related resources in your IBM Cloud account, use the `ibmcloud oc quota ls` command.
{: tip}

| Category | Description |
| -------- | ----------- |
| API rate limits | 200 requests per 10 seconds to the Red Hat OpenShift on IBM Cloud API from each unique source IP address. |
| App deployment | The apps that you deploy to and services that you integrate with your cluster must be able to run on the operating system of the worker nodes. |
| Calico network plug-in | Changing the Calico plug-in, components, or default Calico settings is not supported. For example, don't deploy a new Calico plug-in version, or modify the daemon sets or deployments for the Calico components, default `IPPool` resources, or Calico nodes. Instead, you can follow the documentation to [create a Calico `NetworkPolicy` or `GlobalNetworkPolicy`](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policies&format=markdown), to [change the Calico MTU](https://cloud.ibm.com/docs/openshift?topic=openshift-kernel&format=markdown#calico-mtu), or to [disable the port map plug-in for the Calico CNI](https://cloud.ibm.com/docs/openshift?topic=openshift-kernel&format=markdown#calico-portmap). |
| Cluster quota | You can't exceed 100 clusters per region and per [infrastructure provider](https://cloud.ibm.com/docs/openshift?topic=openshift-overview&format=markdown#what-compute-infra-is-offered). However, as of 01 January 2024, quotas are increased incrementally before reaching 100. If you need more of the resource, [contact IBM Support](https://cloud.ibm.com/docs/support?topic=support-using-avatar&format=markdown). In the support case, include the new quota limit for the region and infrastructure provider that you want.. To list quotas, run `ibmcloud quota ls`. |
| Kubernetes | Make sure to review the [Kubernetes project limitations](https://kubernetes.io/docs/setup/best-practices/cluster-large/){: external}. |
| KMS provider | Customizing the IP addresses that are allowed to connect to your IBM® Key Protect for IBM Cloud® instance is not supported.|
| Red Hat OpenShift | Make sure to review the [OpenShift Container Platform limitations](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/scalability_and_performance/planning-your-environment-according-to-object-maximums){: external} for your version.|
| Kubernetes pod logs | To check the logs for individual app pods, you can use the command line to run `oc logs <pod name>`. Do not use the Kubernetes dashboard to stream logs for your pods, which might cause a disruption in your access to the Kubernetes dashboard. |
| Monitoring |  - Because IBM manages your cluster master, event alerting for the master is disabled. IBM monitors your cluster master and fixes issues as they are detected. For this reason, in the Administrator perspective of the Red Hat OpenShift, you might see a `Not available` message for the control plane status. \n - The built-in Prometheus alert manager includes two rules that display as active alerts in a `FIRING` state: `KubeControllerManagerDown` and `KubeSchedulerDown`. These components are part of the IBM-managed cluster master, so you can ignore these alerts. |
| Operating system | Worker nodes must run one of the supported operating systems. You can't create a cluster with worker nodes that run different types of operating systems. For more information, see the [Red Hat OpenShift on IBM Cloud version information](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions&format=markdown). |
| OperatorHub catalog | To use the OperatorHub catalog in private clusters see [Disabling OperatorHub and mirroring catalog source images to `icr.io`](https://cloud.ibm.com/docs/openshift?topic=openshift-operators&format=markdown#mirror-operatorhub). |
| Pod instances | You can run 110 pods per worker node. If you have worker nodes with 11 CPU cores or more, you can support 10 pods per core, up to a limit of 250 pods per worker node. The number of pods includes `kube-system` and `ibm-system` pods that run on the worker node. For improved performance, consider limiting the number of pods that you run per compute core so that you don't overuse the worker node. For example, on a worker node with a `b3c.4x16` flavor, you might run 10 pods per core that use no more than 75% of the worker node total capacity. |
| [Deprecated]{: tag-red} Time-based one-time passcode (TOTP) | To use [TOTP](https://cloud.ibm.com/docs/iam?topic=iam-legacy-mfa&format=markdown#account-based), make sure that you [enable multifactor authentication (MFA)](https://cloud.ibm.com/docs/iam?topic=iam-enablemfa&format=markdown) for your entire IBM Cloud account. If MFA is enabled only for some users but not at the account level, authentication errors might occur.  |
| Worker node quota | A maximum 500 worker nodes for any accounts created before 01 January 2024. For accounts created on or after that date, the maximum quota is 200 after a period of lower quotas. Quotas apply per cluster [infrastructure provider](https://cloud.ibm.com/docs/openshift?topic=openshift-overview&format=markdown#what-compute-infra-is-offered). If you need more of the resource, [contact IBM Support](https://cloud.ibm.com/docs/support?topic=support-using-avatar&format=markdown). In the support case, include the new quota limit for the region and infrastructure provider that you want.. To list quotas run, `ibmcloud ks quota ls`. |
| Worker pool size | You must always have a minimum of 2 nodes in your cluster. Because of the worker node quota, you are limited in the number of worker pools per cluster and number of worker nodes per worker pool. For example, with the default worker node quota of 500 per region, you might have up to 500 worker pools of 1 worker node each in a region with only 1 cluster. Or, you might have 1 worker pool with up to 500 worker nodes in a region with only 1 cluster. |
| Red Hat Enterprise Linux CoreOS worker nodes | The maximum amount of zones added to a cluster is 12. For example, 3 RHCOS worker pools with 3 zones each will account for 9/12 of the quota for that cluster. |
| Number of worker nodes | Clusters can have a maximum of 500 worker nodes. |
| Cluster naming | To ensure that the Ingress subdomain and certificate are correctly registered, the first 24 characters of the clusters' names must be different. If you create and delete clusters with the same name or names that have the same first 24 characters 5 times or more within 7 days, such as for automation or testing purposes, you might reach the [Let's Encrypt Duplicate Certificate rate limit](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_rate_limit&format=markdown). |
| Resource groups | A cluster can be created in only one resource group that you can't change afterward. If you create a cluster in the wrong resource group, you must delete the cluster and re-create it in the correct resource group. Furthermore, if you need to use the `ibmcloud oc cluster service bind` command to [integrate with an IBM Cloud service](https://cloud.ibm.com/docs/openshift?topic=openshift-service-binding&format=markdown#bind-services), that service must be in the same resource group as the cluster. Services that don't use resource groups like IBM Cloud Container Registry or that don't need service binding like IBM Cloud Logs work even if the cluster is in a different resource group. |
{: caption="Red Hat OpenShift on IBM Cloud limitations"}





### Red Hat OpenShift on IBM Cloud cluster limitations
{: #ocp4_limitations}

Review limitations that are specific to Red Hat OpenShift clusters. Keep in mind that the [service](#tech_limits) and [classic cluster](#classic_limits) or [VPC cluster](#ks_vpc_gen2_limits) limitations also apply.
{: shortdesc}

| Category | Description |
| -------- | ----------- |
| Cluster autoscaling | The Red Hat OpenShift cluster autoscaler from the Red Hat OpenShift **Administration > Cluster Settings** console or `ClusterAutoscaler` object from the `autoscaling.openshift.io/v1` API is not supported. Instead, use the [`ibm-iks-cluster-autoscaler` Helm plug-in](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-install-addon&format=markdown). |
| Cluster updates | You must [update your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-update&format=markdown) by using the Red Hat OpenShift on IBM Cloud API, CLI, or console tools. You can't update your cluster version from OpenShift Container Platform tools such as the Red Hat OpenShift web console. |
| Container logs | If you use a container logging operator such as Fluentd to send logs to an ElasticSearch stack, you must [update the cluster logging deployment to use the `ibmc-block-gold` storage class](https://cloud.ibm.com/docs/openshift?topic=openshift-health&format=markdown#oc_logging_operator). |
| Private clusters | Depending on the infrastructure provider, your options for private clusters are limited. \n - **VPC**: When you create your VPC cluster in the IBM Cloud console, your cluster has both a public and a private cloud service endpoint. If you want only a private cloud service endpoint, you must create the cluster [in the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-create-vpc-gen2&interface=cli&format=markdown) instead, and include the `--disable-public-service-endpoint` option. If you include this option, your cluster is created with routers and Ingress controllers that expose your apps on the private network only by default. If you later want to expose apps to a public network, you must manually create public routers and Ingress controllers. \n - **Classic**: You can enable the public and private cloud service endpoint or the public cloud service endpoint only, but you can't enable the private cloud service endpoint only. After cluster creation, you can't later change the service endpoints.  |
| Logging | To set up an [OpenShift Container Platform Elasticsearch, Fluentd, and Kibana (EFK) stack](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/logging/index){: external}, see [installing the cluster logging operator](https://cloud.ibm.com/docs/openshift?topic=openshift-health&format=markdown#oc_logging_operator).|
| Service catalog | The service catalog is not supported. Use [Operators](https://cloud.ibm.com/docs/openshift?topic=openshift-operators&format=markdown#operators_4) instead. Do not use the OperatorHub to install the service catalog. |
| Service mesh | The Istio managed add-on is not supported. Instead, use the [Red Hat service mesh operator](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/service_mesh/index){: external}. **Note**: The default IBM Cloud configuration of the routers enables host networking, which is not compatible with the service mesh network policy. For the service mesh ingress to work, [apply a network policy](https://gist.githubusercontent.com/kitch/39c504a2ed9e381c2aadea436d5b52e4/raw/d8efa69f41d41425b16bb363a881a98d40d3708c/mesh-policy.yaml){: external}.|
{: caption="OpenShift Container Platform cluster limitations"}




## Classic cluster limitations
{: #classic_limits}

Classic infrastructure clusters in Red Hat OpenShift on IBM Cloud are released with the following limitations.
{: shortdesc}

### Compute
{: #classic_compute_limit}

Keep in mind that the [service](#tech_limits) limitations also apply.

| Category | Description |
| -------- | ----------- |
| Reserved instances | [Reserved capacity and reserved instances](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-provisioning-reserved-capacity-and-instances&format=markdown) are not supported. |
| Worker node flavors | Worker nodes are available in select flavors of compute resources. |
| Worker node host access | For security, you can't SSH into the worker node compute host. |
{: caption="Classic cluster compute limitations"}

### Networking
{: #classic_networking_limit}

Keep in mind that the [service](#tech_limits) limitations also apply.

| Category | Description |
| -------- | ----------- |
| Ingress ALBs |  \n - The Ingress application load balancer (ALB) can process 32,768 connections per second. If your Ingress traffic exceeds this number,  [scale up the number of ALB replicas](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotations&format=markdown) in your cluster to handle the increased workload. \n - ALBs that run the [Red Hat OpenShift on IBM Cloud custom Ingress image](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about&format=markdown) only: HTTP/2 is not supported. \n - ALBs that run the [Red Hat OpenShift on IBM Cloud custom Ingress image] (/docs/containers?topic=containers-managed-ingress-about) only: The names of the `ClusterIP` services that expose your apps must be unique across all namespaces in your cluster.  |
| Network load balancers (NLB)| - You can't create version 2.0 network load balancers (NLB 2.0) to expose your apps. \n - You can't create subdomains for private NLBs. \n - You can register up to 128 subdomains. This limit can be lifted on request by opening a [support case](https://cloud.ibm.com/docs/openshift?topic=openshift-get-help&format=markdown).  | 
| Red Hat OpenShift web console | The web console cannot be exposed on the private network on clusters that have both public and private endpoints. If you want to expose the web console on the private network, your cluster cannot have a public endpoint enabled.  | 
| Private VLANs only | Private network load balancers (NLBs) can't be registered with the domain name server (DNS), so the cluster can't be created with only a private network interface. Worker nodes must be connected to both public and private VLANs. You can still create a private service to expose your apps on only the private network. |
| Service endpoints | When you create a cluster, you can enable the public and private cloud service endpoint or the public cloud service endpoint only, but you can't enable the private cloud service endpoint only. After cluster creation, you can't later change the service endpoints. | 
| Subnets per VLAN | Each VLAN has a limit of 40 subnets. |
{: caption="Classic cluster networking limitations"}

### Storage
{: #classic_storage_limit}

Keep in mind that the [service](#tech_limits) limitations also apply.

| Category | Description |
| -------- | ----------- |
| Volume instances | You can have a total of 250 IBM Cloud infrastructure file and block storage volumes per account. If you mount more than this amount, you might see an `out of capacity` message when you provision persistent volumes. For more FAQ, see the [file](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-file-storage-faqs&format=markdown#provision) and [block](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-block-storage-faqs&format=markdown#authlimit) storage docs. If you want to mount more volumes, [contact IBM Support](https://cloud.ibm.com/docs/openshift?topic=openshift-get-help&format=markdown). In your support ticket, include your account ID and the new file or block storage volume quota that you want.  |
| Portworx | Review the [Portworx limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_plan&format=markdown#portworx_limitations). |
| File storage | Because of the way that IBM Cloud NFS file storage configures Linux user permissions, you might encounter errors when you use file storage. If so, you might need to configure [Red Hat OpenShift Security Context Constraints](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/authentication_and_authorization/managing-pod-security-policies){: external} or use a different storage type. |
{: caption="Classic cluster storage limitations"}

## Classic user access
{: #classic_access_limit}

Keep in mind that the [service](#tech_limits) limitations also apply.

| Category | Description |
| -------- | ----------- |
| IP address access | Restricting access for specific users by enabling IP address access is not supported by Red Hat OpenShift on IBM Cloud. If you want to restrict user access or restrict which services and VPCs a user can access, consider [context-based restriction](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr-tutorial&format=markdown).  |
{: caption="Classic cluster user access limitations"}



## VPC cluster limitations
{: #ks_vpc_gen2_limits}

VPC clusters in Red Hat OpenShift on IBM Cloud are released with the following limitations. Additionally, all the underlying [VPC quotas, VPC limits](https://cloud.ibm.com/docs/vpc?topic=vpc-quotas&format=markdown), [VPC service limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-limitations&format=markdown), and [regular service limitations](#tech_limits) apply.
{: shortdesc}

### Compute
{: #vpc_gen2_compute_limit}

Keep in mind that the [service](#tech_limits) limitations also apply.

| Category | Description |
| -------- | ----------- |
| Clusters per VPC | VPCs are limited to 25 clusters each. |
| Encryption | The secondary disks of your worker nodes are encrypted at rest by default by the [underlying VPC infrastructure provider](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-about&format=markdown#vpc-storage-encryption). However, you can't [bring your own encryption to the underlying virtual server instances](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-byok-encryption&interface=ui&format=markdown). |
| Location | VPC clusters are available only in [select multizone regions](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zones&format=markdown#zones-vpc). |
| Virtual Private Cloud | See [Limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-limitations&format=markdown) and [Quotas](https://cloud.ibm.com/docs/vpc?topic=vpc-quotas&format=markdown). |
| VPC resource quotas | VPC manages quotas for vCPU, memory, GPU, instance storage, and optimized instance storage resources on a per-account basis. When you provision virtual server instance (VSI) worker nodes on public infrastructure, these resources count against your VPC account quotas. If you reach a quota limit, worker node provisioning fails. To view your current quotas and usage, see [Viewing VPC resource metrics](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-quota-metrics&format=markdown){: external}. To request a quota increase, open a support case with VPC. For more information, see [VPC quotas](https://cloud.ibm.com/docs/vpc?topic=vpc-quotas&format=markdown){: external}. \n \n **Note**: This quota management currently applies only to VSI worker nodes on public infrastructure. Red Hat OpenShift on IBM Cloud continues to manage quotas for dedicated host and bare metal worker nodes. |
| Worker node flavors | Only certain flavors are available for worker node virtual machines and bare metal workers. |
| Worker node host access | For security, you can't SSH into the worker node compute host. |
| Worker node updates | VPC worker update actions depend on the worker type. For VPC bare metal workers, you can use the `ibmcloud oc worker reload` command to apply a reload. For VPC virtual server instance workers, use the `ibmcloud oc worker replace` command. If you replace multiple worker nodes at the same time, they are deleted and replaced concurrently, not one by one. Make sure that you have enough capacity in your cluster to reschedule your workloads before you replace worker nodes. |
{: caption="VPC cluster compute limitations"}


### Networking
{: #vpc_gen2_networking_limit}

Keep in mind that the [service](#tech_limits) limitations also apply.

| Category | Description |
| -------- | ----------- |
| App URL length | DNS resolution is managed by the cluster's [virtual private endpoint (VPE)](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnets&format=markdown#vpc_basics_vpe), which can resolve URLs up to 130 characters. If you expose apps in your cluster with URLs, such as the Ingress subdomain or Red Hat OpenShift routes, ensure that the URLs are 130 characters or fewer. |
| Network speeds | [VPC profile network speeds](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles&format=markdown) refer to the speeds of the worker node interfaces. The bandwidth available for VPC instances is shared between storage and network traffic. By default, the storage allocation is 25% of maximum bandwidth. Network speed, as shown in the tables below, is the network bandwidth available to a worker with a single network interface after deducting the default 25% storage bandwidth allocation. |
| NodePort | You can access an app through a NodePort only if you are connected to your private VPC network, such as through a VPN connection. To access an app from the internet, you must use a VPC load balancer or Ingress service instead. |
| Pod network | VPC access control lists (ACLs) filter incoming and outgoing traffic for your cluster at the subnet level, and security groups filter incoming and outgoing traffic for your cluster at the worker nodes level. To control traffic within the cluster at the pod-to-pod level, you can't use VPC security groups or ACLs. Instead, use [Calico](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policies&format=markdown) and [Kubernetes network policies](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-kube-policies&format=markdown), which can control the pod-level network traffic that uses IP in IP encapsulation. |
| Public gateway | If the public service endpoint is enabled, you must attach a public gateway to each VPC subnet so that your worker nodes can communicate on the public network. Default Red Hat OpenShift components, such as the web console and OperatorHub, require public network access.|
| Service endpoints | When you create your VPC cluster in the IBM Cloud console, your cluster has both a public and a private cloud service endpoint. If you want only a private cloud service endpoint, you must create the cluster [in the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-create-vpc-gen2&interface=cli&format=markdown) instead, and include the `--disable-public-service-endpoint` option. If you include this option, your cluster is created with routers and Ingress controllers that expose your apps on the private network only by default. If you later want to expose apps to a public network, you must manually create public routers and Ingress controllers.|
| Subnets |  \n - See [VPC networking limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnets&format=markdown#vpc_basics_limitations). \n - Do not delete the subnets that you attach to your cluster during cluster creation or when you add worker nodes in a zone. If you delete a VPC subnet that your cluster used, any load balancers that use IP addresses from the subnet might experience issues, and you might be unable to create new load balancers.  |
| VPC load balancer | See [VPC load balancer limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-vpclb-about&format=markdown#vpclb_limit). |
{: caption="VPC cluster networking limitations"}

### Storage
{: #vpc_gen2_storage_limit}

Keep in mind that the [service](#tech_limits) limitations also apply.

| Category | Description |
| -------- | ----------- |
| Storage class for profile sizes | For more information, see [available volume profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-profiles&format=markdown). |
| Supported types | You can set up IBM Cloud Object Storage and Cloud Databases only. |
| Volume attachments | See [Volume attachment limits](https://cloud.ibm.com/docs/vpc?topic=vpc-attaching-block-storage&format=markdown#vol-attach-limits).|
| Portworx | Review the [Portworx limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_plan&format=markdown#portworx_limitations). |
| Block Storage for VPC | The default storage class in VPC clusters cannot be changed. However, you can [create your own storage class](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-block&format=markdown#vpc-customize-storage-class). |
{: caption="VPC cluster storage limitations"}

## VPC user access
{: #vpc_access_limit}

Keep in mind that the [service](#tech_limits) limitations also apply.

| Category | Description |
| -------- | ----------- |
| IP address access | Restricting access for specific users by enabling IP address access is not supported by Red Hat OpenShift on IBM Cloud. If you want to restrict user access or restrict which services and VPCs a user can access, consider [context-based restriction](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr-tutorial&format=markdown).  |
{: caption="VPC cluster user access limitations"}



## Satellite cluster limitations
{: #satellite_limits}

Review the following limitations for [Red Hat OpenShift on IBM Cloud clusters that you create in a Satellite location](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-clusters&format=markdown). Keep in mind that the [service](#tech_limits) limitations also apply.
{: shortdesc}

| Category | Description |
| -------- | ----------- |
| Cluster add-ons | Review the [unsupported managed add-ons for Red Hat OpenShift clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-managed-addons&format=markdown#addons-satellite) in a Satellite location. For example, the cluster autoscaler and Istio are not supported. |
| Network |  \n - By default, there is no load balancer controller deployed with Satellite clusters and therefore, [Kubernetes LoadBalancer services](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/){: external} are not provision by default. You can integrate your own load balancer solution into clusters, such as [MetalLB](https://cloud.ibm.com/docs/openshift?topic=openshift-sat-expose-apps&format=markdown#sat-expose-metallb). \n - The hosts that run the worker nodes for your cluster must meet the [host networking](https://cloud.ibm.com/docs/satellite?topic=satellite-reqs-host-network&format=markdown) and provider-specific requirements, such as for [AWS](https://cloud.ibm.com/docs/satellite?topic=satellite-aws&format=markdown), [Azure](https://cloud.ibm.com/docs/satellite?topic=satellite-azure&format=markdown), [GCP](https://cloud.ibm.com/docs/satellite?topic=satellite-gcp&format=markdown), and [IBM Cloud](https://cloud.ibm.com/docs/satellite?topic=satellite-ibm&format=markdown) (testing and demonstration purposes only). \n - Because VXLAN encapsulation is required for traffic between pods that are on different worker nodes, data transfer speeds between pods on different worker nodes might be slower than the network capability of the hosts. |
| Storage for worker node hosts | See [Host storage and attached devices](https://cloud.ibm.com/docs/satellite?topic=satellite-reqs-host-storage&format=markdown). |
| Storage for apps | No storage provider is installed in your Satellite clusters by default. Therefore, no pre-configured Kubernetes storage classes are set up by default in your clusters to store your application data in a Kubernetes persistent volume that is backed by storage device. For options to set up a storage provider, see [Understanding Satellite storage templates](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-template-ov&format=markdown). |
| Worker nodes | Worker nodes run on hosts in your own infrastructure environments. The hosts must meet [host](https://cloud.ibm.com/docs/satellite?topic=satellite-host-reqs&format=markdown) and provider-specific requirements, such as for [AWS](https://cloud.ibm.com/docs/satellite?topic=satellite-aws&format=markdown), [Azure](https://cloud.ibm.com/docs/satellite?topic=satellite-azure&format=markdown), [GCP](https://cloud.ibm.com/docs/satellite?topic=satellite-gcp&format=markdown), and [IBM Cloud](https://cloud.ibm.com/docs/satellite?topic=satellite-ibm&format=markdown) (testing and demonstration purposes only). You are responsible for [managing the infrastructure lifecycle of your hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-host-update-location&format=markdown), including adding and [updating worker nodes](https://cloud.ibm.com/docs/satellite?topic=satellite-host-update-workers&format=markdown). As such, worker node operations like `ibmcloud oc worker add, update, replace, reload` commands are not supported. |
| Worker pools | To use operations like `resize`, your worker pool uses [host labels](https://cloud.ibm.com/docs/satellite?topic=satellite-host-autoassign-ov&format=markdown) that must match available (unassigned) hosts in the Satellite location. |
| Single node clusters | Any cluster with fewer than three worker nodes lacks high availability. By provisioning a single-node cluster, you accept that you are more likely to experience downtime and disruptions in your workload, and that regular worker node upgrades result in your workload going offline. Additionally, if a cluster is provisioned as a single-node cluster, it cannot later be converted to a standard, highly available cluster. You can add more nodes, but standard deployments do not increase in replica size and the cluster does not become highly available. Single node clusters must run on a Satellite location with [Red Hat CoreOS (RHCOS) enabled](https://cloud.ibm.com/docs/satellite?topic=satellite-locations&format=markdown#verify-coreos-location). Control plane hosts on your location and the host you assign to your single-node cluster must run either the RHEL 8 or RHCOS operating systems. Only supported for Satellite clusters that run version 4.11 or later. OpenShift Data Foundation is not supported on single-node clusters. Portworx is not supported on single-node clusters.
{: caption="Satellite cluster limitations"}


## Unsupported features and operators in Red Hat OpenShift on IBM Cloud
{: #not-supported-features-table}

The following features and operators are not supported in Red Hat OpenShift on IBM Cloud.

Instead of tuning worker node performance with `MachineConfig` files in Red Hat OpenShift, you can modify the host with a `daemonset` file. For more information, see [Changing the Calico MTU](https://cloud.ibm.com/docs/openshift?topic=openshift-kernel&format=markdown#calico-mtu) or [Tuning performance for Red Hat CoreOS worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-rhcos-performance&format=markdown).
{: note}

* 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
* Device Manager
* File Integrity Operator
* Fuse Console
* Fuse Online
* Gatekeeper Operator
* JBoss EAP
* JBoss Web Server
* Logical volume manager storage (LVM)
* MachineConfigs
* Metering and Cost Management SaaS Service
* OpenShift Cloud Manager (OCM) SaaS Service
* OpenShift Cluster-Wide Proxy
* OpenShift Data Foundation: Supported through the [cluster add-on](https://cloud.ibm.com/docs/openshift?topic=openshift-ocs-storage-prep&format=markdown) for Classic and VPC clusters or through the Satellite [template](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-template-ov&format=markdown) for Satellite clusters.
* OpenShift SDN and most other network plugins are not supported
   * Calico is supported on all cluster versions.
   * OVN is supported for VPC Red Hat OpenShift clusters at version 4.20 and later with RHCOS worker nodes only.
   * Do not update or remove these network plugins outside of the normal cluster master update process.
* Performance Add-on Operator
* PTP Operator
* Quay Operator
* Red Hat OpenStack Platform `Kuryr` Integration
* Red Hat Integration Operator
* Service Registry Operator
* Smart Gateway Operator
* SR-IOV Network Operator: Supported in Satellite clusters only.
* Telemeter and Insights Connected Experience
* Windows Machine Config: Worker nodes with Windows operating systems are not supported.
* `ImageContentSourcePolicy`, `ImageDigestMirrorSet`, and `ImageTagMirrorSet` are not supported.