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 there are still a few operations to perform before creating a managed OpenShift cluster.

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

To operate a managed OpenShift cluster from the command-line, you must download and configure the CLI provided by 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 be completed 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.

There are also differences in how the components of a managed OpenShift cluster display 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 compose the cluster by clicking on 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, there are cluster management and application management responsibilities shared between the customer, Red Hat, and the cloud provider.

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

To learn more about the responsibility assignment matrix for ROSA, visit https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.html

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

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://docs.openshift.com/dedicated/osd_architecture/osd_policy/policy-responsibility-matrix.html

The latest OpenShift versions available on each platform service are normally behind the latest Red Hat OpenShift version. This 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, you can schedule upgrades by using the Red Hat OpenShift Cluster Manager. You will 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 are those that use the latest GA version released, or the previous minor. This means that if the current version is 4.10.z, 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.