In contrast to self-managed OpenShift clusters, managed OpenShift clusters do not require the users to create all the infrastructure components, such as virtual machines, networks, load balancers, and so on. But users still need to perform a few operations before creating a managed OpenShift cluster.

Users interact with each cloud provider by using the web console or a command-line interface (CLI) that is specific to the cloud provider.

To operate a managed OpenShift cluster from the command line, you must download and configure the CLI from the cloud provider. For example, you can use the az CLI to create the necessary cloud components such as resource groups or virtual networks, and then create an ARO cluster. On AWS, you use the aws and rosa CLIs, and the ibmcloud CLI on IBM cloud.

The number of actions to complete before creating a managed OpenShift cluster depends on the cloud provider. For instance, to create an ARO cluster, you must verify the account permissions, verify the resource quotas, register the resource providers, create a resource group, create the virtual network, and finally create the cluster.

On AWS, you must verify the quota for a ROSA cluster, verify the service role for the AWS Elastic Load Balancer (ELB), and finally create the cluster.

Also, the components of a managed OpenShift cluster display differently in the cloud provider portal. For example, on Azure, the components of a cluster are grouped into a resource group. You can access the details of the virtual machines, disks, and other components that comprise the cluster by clicking the corresponding resource group.

On the contrary, on AWS, most objects, relative to a ROSA cluster, use the name of the cluster as a prefix.

In managed OpenShift clusters, cluster management and application management responsibilities are shared between the customer, Red Hat, and the cloud provider.

Generally, customers are responsible for their own data, applications, and developer services. Each cloud provider publishes a detailed shared responsibility matrix by area and task.

Visit https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html-single/introduction_to_rosa/index#rosa-policy-responsibility-matrix to learn more about the responsibility assignment matrix for ROSA.

Visit https://learn.microsoft.com/en-us/azure/openshift/responsibility-matrix to learn more about the responsibility assignment matrix for ARO.

To learn more about the responsibility assignment matrix for Red Hat OpenShift on IBM Cloud, visit https://cloud.ibm.com/docs/openshift?topic=openshift-responsibilities_iks

To learn more about the responsibility assignment matrix for Red Hat OpenShift Dedicated, visit https://access.redhat.com/documentation/en-us/openshift_dedicated/4/html-single/introduction_to_openshift_dedicated/index#policy-responsibility-matrix

The latest available OpenShift versions on each platform service are normally behind the latest Red Hat OpenShift version. This configuration guarantees that the managed OpenShift clusters use a widely tested version of OpenShift in production environments.

Customers are responsible for upgrading the OpenShift version of their managed clusters. The supportability of earlier OpenShift versions depends on the cloud provider. If the managed cluster is registered with Red Hat, then you can schedule upgrades by using the Red Hat OpenShift Cluster Manager. You learn more about how to register your clusters with Red Hat in the section called “ Connect a ROSA Cluster to Red Hat Services ”.

For example, fully supported ARO clusters use the latest released GA version or the previous minor version. If the current version is 4.10.z, then supported clusters must use at least version 4.9.z.

In other cases, such as for ROSA clusters, major versions are fully supported for one year when the next major version is released. Minor versions are fully supported for 14 months following their general availability.

For more information about supportability, visit the following links.