Azure Red Hat OpenShift FAQ

For pricing information, see Azure Red Hat OpenShift pricing.

For Service Level Agreement (SLA) information, see Service Level Agreements for online services.

For a list of supported regions for Azure Red Hat OpenShift 4.x, see Available regions.

For a list of supported virtual machine sizes for Azure Red Hat OpenShift 4, see Supported resources for Azure Red Hat OpenShift 4.

The actual number of supported pods depends on an application’s memory, CPU, and storage requirements.

Azure Red Hat OpenShift 4.x has a 250 pod-per-node limit and a 60 compute node limit. These limits cap the maximum number of pods supported in a cluster to 250×60 = 15,000. For a private cluster without any public IPs (for example, created by using User Defined Routing (UDR) and running version 4.11 or higher), the limits are 120 compute nodes and 30,000 pods.

No. All nodes in an Azure Red Hat OpenShift cluster must originate in the same Azure region.

Yes. A cluster can be deployed across multiple availability zones automatically if your cluster is deployed to an Azure region that supports availability zones. For more information, see Availability zones.

No. All resources, including the cluster control plane nodes, run in your customer subscription. These types of resources are put in a read-only resource group.

The Azure Managed Application lives in a locked Resource Group with the customer subscription. Customers can view objects in that resource group but not modify them.

Each Azure Red Hat OpenShift cluster is dedicated to a given customer and lives within the customer's subscription.

Yes, ARO allows you to use infrastructure machine sets to create machines that only host infrastructure components, such as the default router, the integrated container registry, and the components for cluster metrics and monitoring. See Deploy infrastructure nodes in an ARO cluster to learn more.

How do I handle cluster upgrades?

For information on upgrades, maintenance, and supported versions, see the support lifecycle guide.

The host operating systems and OpenShift software are updated as Azure Red Hat OpenShift consumes minor release versions and patches from upstream OpenShift Container Platform.

Nodes are rebooted as a part of an upgrade.

Prometheus comes pre-installed and configured for Azure Red Hat OpenShift 4.x clusters. Read more about cluster monitoring.

In Azure Red Hat OpenShift 4.x: Yes.

Logs from underlying VMs are handled by the managed service and aren't exposed to customers.

For Azure Red Hat OpenShift 4.x clusters, the OpenShift web console contains all metrics at the node level. For more information, see the Red Hat documentation on viewing cluster information.

There are by default five fault domains when using Virtual Machine Scale Sets in Azure. Each virtual machine instance in a scale set will get placed into one of these fault domains. This ensures that applications deployed to the compute nodes in a cluster will get placed in separate fault domains.

For more information, see Choosing the right number of fault domains for Virtual Machine Scale Set.

Customers have the ability to get nodes and view labels as the customer-admin. This will provide a way to target any VM in the scale set.

Caution must be used when using specific labels:

• Hostname must not be used. Hostname gets rotated often with upgrades and updates and is guaranteed to change.
• If the customer has a request for specific labels or a deployment strategy, this could be accomplished. However, it would require engineering efforts, and it isn't supported today.

For more information, see Controlling pod placement.

For 4.x clusters, you need to expose a secure registry and configure authentication. For more information, see the following Red Hat documentation:

• Exposing a registry
• Accessing the registry

Moving your ARO cluster between tenants is currently unsupported.

Moving your ARO cluster and its associated resources between subscriptions isn't supported.

Moving or renaming your ARO cluster and its associated resources isn't supported.

In 4.x clusters, you can deploy a cluster into an existing VNet.

Customer and individual project admins can customize cross-namespace networking (including denying it) on a per-project basis using NetworkPolicy objects.

In the subscription that has the virtual network, make sure to register Microsoft.ContainerService provider with the following command: az provider register -n Microsoft.ContainerService --wait

In 4.x clusters, you can specify your own IP ranges.

The Software Defined Network is openshift-ovs-networkpolicy and isn't configurable.

Azure Red Hat OpenShift uses Standard Azure Load Balancer, and it isn't configurable.

Yes. An Azure Red Hat OpenShift administrator can manage users and quotas in addition to accessing all user created projects.

Yes. You can restrict which Microsoft Entra users can sign in to a cluster by configuring the Microsoft Entra Application. For details, see How to: Restrict your app to a set of users.

Yes. Sign in to your cluster as an administrator and execute this command:

oc adm policy \
    remove-cluster-role-from-group self-provisioner \
    system:authenticated:oauth

For more information, see the OpenShift documentation on disabling self-provisioning for your cluster version:

• Disabling self-provisioning in 4.6 clusters

Node access is available through the cluster-admin role. For more information, see Kubernetes RBAC overview.

The cluster-admin role is available. For more information, see Kubernetes RBAC overview.

You configure your own identity provider. For more information, see the Red Hat documentation on configuring identity providers.

By default, data is encrypted at rest. The Azure Storage platform automatically encrypts your data before persisting it, and decrypts the data before retrieval. For more information, see Azure Storage Service Encryption for data at rest.

Storage accounts are set to private access only.

Storage accounts are encrypted (new clusters only). Existing clusters need to be re-created.

Storage accounts are created with general-purpose v2 for new clusters.

General-purpose v2 storage accounts support the latest Azure Storage features and incorporate all the functionality of general-purpose v1 and Blob storage accounts.

Storage accounts access is limited with firewall rules via Azure network security groups (NSGs), which filter network traffic to and from your storage accounts. For more information, see Azure network security groups overview.

Transport Layer Security (TLS) protocol version 1.2 provides secure communications, data privacy, and data integrity.

Data isn't encrypted by default, but you do have the option to enable encryption. For more information, see the guide on encrypting etcd.

Azure Disk (Premium_LRS) is configured as the default storage class. For additional storage providers, and for configuration details (including Azure File), see the Red Hat documentation on persistent storage.

Does ARO store any customer data outside of the cluster's region?

No. All data created in an ARO cluster is maintained within the cluster's region.