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.

An existing cluster that uses a service principal can't be migrated to use a managed identity. You need to create a new cluster that uses a managed identity on an Azure Red Hat OpenShift cluster. For more information, see Create an Azure Red Hat OpenShift cluster with managed identities (preview).

For a list of supported virtual machine sizes for Azure Red Hat OpenShift 4, see Azure Red Hat OpenShift 4.0 support policy.

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 250 compute node limit. These limits cap the maximum number of pods supported in a cluster to 250×250 = 62,500. These limits are the same for clusters created using User Defined Routing (UDR) and running version 4.11 or higher.

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, Azure Red Hat OpenShift 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. For more information, see Deploy infrastructure nodes in an Azure Red Hat OpenShift cluster.

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 preinstalled and configured for Azure Red Hat OpenShift 4.x clusters. Read more about cluster monitoring.

Yes, you can use Prometheus in Azure Red Hat OpenShift 4.x.

Logs from underlying virtual machines 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 is placed into one of these fault domains. This process ensures that applications deployed to the compute nodes in a cluster are 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 ability provides a way to target any virtual machine 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 cluster between tenants is currently unsupported.

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

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

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

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 Restrict a Microsoft Entra 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 can enable encryption. For more information, see the guide on encrypting etcd.

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

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

Related content

• Azure Red Hat OpenShift 4.0 support policy
• Support lifecycle for Azure Red Hat OpenShift 4