Understanding Red Hat OpenShift on IBM Cloud
Learn more about Red Hat® OpenShift® on IBM Cloud®, its capabilities, and the options that are available to you to customize the cluster to your needs.
Red Hat OpenShift on IBM Cloud is a managed offering to create your own Red Hat OpenShift cluster of compute hosts to deploy and manage containerized apps on IBM Cloud. Red Hat OpenShift on IBM Cloud provides intelligent scheduling, self-healing, horizontal scaling, service discovery and load balancing, automated rollouts and rollbacks, and secret and configuration management for your apps. Combined with an intuitive user experience, built-in security and isolation, and advanced tools to secure, manage, and monitor your cluster workloads, you can rapidly deliver highly available and secure containerized apps in the public cloud.
Review frequently asked questions and key technologies that Red Hat OpenShift on IBM Cloud uses.
What is Kubernetes?
Kubernetes is an open source platform for managing containerized workloads and services across multiple hosts, and offers management tools for deploying, automating, monitoring, and scaling containerized apps with minimal to no manual intervention.
The open source project, Kubernetes, combines running a containerized infrastructure with production workloads, open source contributions, and Docker container management tools. The Kubernetes infrastructure provides an isolated and secure app platform for managing containers that is portable, extensible, and self-healing in case of a failover. For more information, see What is Kubernetes?.
Learn more about the key concepts of Kubernetes as illustrated in the following image.
- Account
-
Your account refers to your IBM Cloud account.
- Cluster, worker pool, and worker node
-
A Kubernetes cluster consists of a master and one or more compute hosts that are called worker nodes. Worker nodes are organized into worker pools of the same flavor, or profile of CPU, memory, operating system, attached disks, and other properties. The worker nodes correspond to the Kubernetes
Noderesource, and are managed by a Kubernetes master that centrally controls and monitors all Kubernetes resources in the cluster. So when you deploy the resources for a containerized app, the Kubernetes master decides which worker node to deploy those resources on, accounting for the deployment requirements and available capacity in the cluster. Kubernetes resources include services, deployments, and pods. - Namespace
-
Kubernetes namespaces are a way to divide your cluster resources into separate areas that you can deploy apps and restrict access to, such as if you want to share the cluster with multiple teams. For example, system resources that are configured for you are kept in separate namespaces like
kube-systemoribm-system. If you don't designate a namespace when you create a Kubernetes resource, the resource is automatically created in thedefaultnamespace. - Service
-
A service is a Kubernetes resource that groups a set of pods and provides network connectivity to these pods without exposing the actual private IP address of each pod. You can use a service to make your app available within your cluster or to the public internet.
- Deployment
-
A deployment is a Kubernetes resource where you might specify information about other resources or capabilities that are required to run your app, such as services, persistent storage, or annotations. You document a deployment in a configuration YAML file, and then apply it to the cluster. The Kubernetes master configures the resources and deploys containers into pods on the worker nodes with available capacity.
-
Define update strategies for your app, including the number of pods that you want to add during a rolling update and the number of pods that can be unavailable at a time. When you perform a rolling update, the deployment checks whether the update is working and stops the rollout when failures are detected.
-
A deployment is just one type of workload controller that you can use to manage pods. For help choosing among your options, see What type of Kubernetes objects can I make for my app?. For more information about deployments, see the Kubernetes documentation.
- Pod
-
Every containerized app that is deployed into a cluster is deployed, run, and managed by a Kubernetes resource called a pod. Pods represent small deployable units in a Kubernetes cluster and are used to group the containers that must be treated as a single unit. Usually, each container is deployed in its own pod. However, an app might require a container and other helper containers to be deployed into one pod so that those containers can be addressed by using the same private IP address.
- App
-
An app might refer to a complete app or a component of an app. You might deploy components of an app in separate pods or separate worker nodes. For more information, see Planning app deployments and Developing Kubernetes-native apps.
To dive deeper into Kubernetes, see the Kubernetes documentation.
What are containers?
Containers provide a standard way to package your application's code, configurations, and dependencies into a single unit that can run as a resource-isolated process on a compute server. To run your app on IBM Cloud, you must first containerize your app by creating a container image that you store in a container registry.
Review the following terms to get more familiar with the concepts.
- Container
- A container is an app that is packaged with all its dependencies so that the app can be moved between environments and run without changes. Unlike virtual machines, containers don't virtualize a device, its operating system, and the underlying hardware. Only the app code, run time, system tools, libraries, and settings are packaged inside the container. Containers run as isolated processes on compute hosts and share the host operating system and its hardware resources. This approach makes a container more lightweight, portable, and efficient than a virtual machine.
- Image
- A container image is a package that includes the files, configuration settings, and libraries to run a container. An image is built from a text file called a Dockerfile. Dockerfiles define how to build the image and which artifacts to include in it. The artifacts that are included in a container consist of the app code, configuration settings, and any dependencies.
- Registry
- An image registry is a place to store, retrieve, and share container images. Registries can either be publicly available to anyone or privately available to a small group of users. When it comes to enterprise applications, use a private registry like IBM Cloud to protect your images from being used by unauthorized users.
What is Red Hat OpenShift?
Red Hat OpenShift is a Kubernetes container platform that provides a trusted environment to run enterprise workloads. It extends the Kubernetes platform with built-in software to enhance app lifecycle development, operations, and security. With Red Hat OpenShift, you can consistently deploy your workloads across hybrid cloud providers and environments.
What compute host infrastructure does Red Hat OpenShift on IBM Cloud offer?
With Red Hat® OpenShift® on IBM Cloud®, you can create a cluster by using infrastructure from the following providers. All the worker nodes in a cluster must be from the same provider.
| Component | Description |
|---|---|
| Overview | Create clusters on virtual servers in your own Virtual Private Cloud (VPC). |
| Supported container platforms | Red Hat OpenShift or Kubernetes |
| Compute and worker node resources | Worker nodes are created as virtual machines by using either shared infrastructure or dedicated hosts. Unlike classic clusters, VPC cluster worker nodes on shared hardware don't appear in your infrastructure portal or a separate infrastructure bill. Instead, you manage all maintenance and billing activity for the worker nodes through Red Hat OpenShift on IBM Cloud. Your worker node instances are connected to certain VPC instances that do reside in your infrastructure account, such as the VPC subnet or storage volumes. For dedicated hosts, the dedicated host price covers the vCPU, memory, and any instance storage to be used by any workers placed on the host. Note that all Intel® x86-64 servers have Hyper-Threading enabled by default. For more information, see Intel Hyper-Threading Technology. |
| Security | Clusters on shared hardware run in an isolated environment in the public cloud. Clusters on dedicated hosts do not run in a shared environment, instead only your clusters are present on your hosts. Network access control lists protect the subnets that provide the floating IPs for your worker nodes. |
| High availability | The master includes three replicas for high availability. Further, if you create your cluster in a multizone metro, the master replicas are spread across zones and you can also spread your worker pools across zones. |
| Reservations | Reservations aren't available for VPC. |
| Cluster administration | VPC clusters can't be reloaded or updated. Instead, use the worker replace --update CLI or API operation to replace worker nodes that are outdated or in a troubled state. |
| Cluster networking | Unlike classic infrastructure, the worker nodes of your VPC cluster are attached to VPC subnets and assigned private IP addresses. The worker nodes are not connected to the public network, which instead is accessed through a public gateway, floating IP, or VPN gateway. For more information, see Overview of VPC networking in Red Hat OpenShift on IBM Cloud. |
| Apps and container platform | You can choose to create community Kubernetes or Red Hat OpenShift clusters to manage your containerized apps. Your app build processes don't differ because of the infrastructure provider, but how you expose the app does. |
| App networking | All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range and are routed between worker nodes on the worker node private IP address of the private VPC subnet. To expose the app on the public
network, you can create a Kubernetes LoadBalancer service, which provisions a VPC load balancer and public hostname address for your worker nodes. For more information, see Exposing apps with VPC load balancers. |
| Storage | You can choose from non-persistent and persistent storage solutions such as file, block, object, and software-defined storage. For more information, see Planning highly available persistent storage. |
| User access | You can use IBM Cloud IAM access policies to authorize users to create infrastructure, manage your cluster, and access cluster resources. The cluster can be in a different resource group than the VPC. |
| Integrations | VPC supports a select list of supported IBM Cloud services, add-ons, and third-party integrations. For a list, see Supported IBM Cloud and third-party integrations. |
| Locations and versions | VPC clusters are available worldwide in the multizone location. |
| Service interface | VPC clusters are supported by the next version (v2) of the IBM Cloud Kubernetes Service API, and you can manage your VPC clusters through the same CLI and console
as classic clusters. |
| Service compliance | See the VPC section in What standards does the service comply to?. |
| Service limitations | See Service limitations. For VPC-specific limitations in Red Hat OpenShift on IBM Cloud, see VPC cluster limitations. For general VPC infrastructure provider limitations, see Limitations. |
| Component | Description |
|---|---|
| Overview | Create clusters on your own hardware, IBM Cloud Classic or VPC, or on virtual servers in another cloud provider like AWS or Azure. |
| Supported container platforms | Red Hat OpenShift |
| Compute and worker node resources | Worker nodes can be virtual machines using either shared infrastructure or dedicated hosts, or even bare metal servers. You manage maintenance and billing activity for the worker nodes through your host infrastructure provider whether that is IBM Cloud, your own on-premises hardware, or another cloud provider. You also manage billing through IBM Cloud. For more information about pricing, see What am I charged for when I use IBM Cloud Satellite?. |
| Security | See Security and compliance. |
| High availability | See About high availability and recover. |
| Reservations | Reservations aren't available for Satellite. |
| Cluster administration | See Updating hosts that are assigned as worker nodes. |
| Cluster networking | If you attach IBM Cloud Classic or VPC hosts to your location, refer to those descriptions. |
| Apps and container platform | You can create Red Hat OpenShift clusters to manage your containerized apps. Your app build processes don't differ because of the infrastructure provider, but how you expose the app does. For more information, see Choosing an app exposure service. |
| App networking | All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range by default. You can avoid subnet conflicts with the network that you use to connect to your location by specifying a custom subnet CIDR that provides the private IP addresses for your pods. To expose an app, see Exposing apps in Satellite clusters. |
| Storage | Bring your own storage drivers or deploy one of the supported storage templates. For more information, see Understanding Satellite storage. |
| User access | You can use IBM Cloud IAM access policies to authorize users to create IBM Cloud infrastructure, manage your cluster, and access cluster resources. For more information, see Managing access overview. You can also further control access to your host infrastructure in policies provided by your infrastructure provider. |
| Integrations | For cluster integrations, see Supported IBM Cloud and third-party integrations. For supported Satellite service integrations, see Supported Satellite IBM Cloud services. |
| Locations and versions | Clusters are managed from one of the supported IBM Cloud locations. However, you can deploy worker nodes to your own location, an IBM Cloud data center, or another cloud provider. For more information see Understanding locations and hosts. |
| Service interface | Satellite are supported by the global API [IBM Cloud Kubernetes Service, the Red Hat OpenShift on IBM Cloud CLI and the Satellite CLI. You can also manage your clusters from the console. |
| Service compliance | For clusters, see What standards does the service comply to?. For Satellite, see Security and compliance. |
| Service limitations | See Limitations, default settings, and usage requirements. |
| Component | Description |
|---|---|
| Overview | Create clusters in a classic compute, networking, and storage environment in IBM Cloud infrastructure. |
| Supported container platforms | Red Hat OpenShift or Kubernetes |
| Compute and worker node resources | Virtual, bare metal, and software-defined storage machines are available for your worker nodes. Your worker node instances reside in your IBM Cloud infrastructure account, but you can manage them through Red Hat OpenShift on IBM Cloud. You own the worker node instances. |
| Security | Built-in security features that help you protect your cluster infrastructure, isolate resources, and ensure security compliance. For more information, see the classic Network Infrastructure documentation. |
| High availability | For both classic and VPC clusters, the master includes three replicas for high availability. Further, if you create your cluster in a multizone metro, the master replicas are spread across zones and you can also spread your worker pools across zones. For more information, see High availability for Red Hat OpenShift on IBM Cloud. |
| Reservations | Create a reservation with contracts for 1 or 3 year terms for classic worker nodes to lock in a reduced cost for the life of the contract. Typical savings range between 30-50% compared to regular worker node costs. |
| Cluster administration | Classic clusters support the entire set of v1 API operations, such as resizing worker pools, reloading worker nodes, and updating masters and worker nodes across major, minor, and patch versions. When you delete a cluster,
you can choose to remove any attached subnet or storage instances. |
| Cluster networking | Your worker nodes are provisioned on private VLANs that provide private IP addresses to communicate on the private IBM Cloud infrastructure network. For communication on the public network, you can also provision the worker nodes on a public VLAN. Communication to the cluster master can be on the public or private cloud service endpoint. For more information, see Understanding VPC cluster network basics or Understanding Classic cluster network basics. |
| Apps and container platform | You can choose to create community Kubernetes or Red Hat OpenShift clusters to manage your containerized apps. Your app build processes don't differ because of the infrastructure provider, but how you expose the app does. For more information, see Choosing an app exposure service. |
| App networking | All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range and are routed between worker nodes on the worker node private IP address of the private VLAN. To expose the app on the public network, your cluster must have worker nodes on the public VLAN. Then, you can create a NodePort, LoadBalancer (NLB), or Ingress (ALB) service. For more information, see Planning in-cluster and external networking for apps. |
| Storage | You can choose from non-persistent and persistent storage solutions such as file, block, object, and software-defined storage. For more information, see Planning highly available persistent storage. |
| User access | To create classic infrastructure clusters, you must set up infrastructure credentials for each region and resource group. To let users manage the cluster, use IBM Cloud IAM platform access roles. To grant users access to cluster resources, use IBM Cloud IAM service access roles, which correspond with Kubernetes RBAC roles. |
| Integrations | You can extend your cluster and app capabilities with a variety of IBM Cloud services, add-ons, and third-party integrations. For a list, see Supported IBM Cloud and third-party integrations. |
| Locations and versions | Classic clusters are available worldwide. |
| Service interface | Classic clusters are fully supported in the Kubernetes Service v1 API, CLI,
and console. |
| Service compliance | See the classic section in What standards does the service comply to?. |
| Service limitations | See Service limitations. Feature-specific limitations are documented by section. |
What are the benefits of using the service?
With Red Hat OpenShift on IBM Cloud, your developers have a fast and secure way to containerize and deploy enterprise workloads in Kubernetes clusters. Red Hat OpenShift clusters build on Kubernetes container orchestration that offers consistency and flexibility for your development lifecycle operations.
Your Red Hat OpenShift workloads can scale across IBM’s global footprint of data centers and multizone regions. At the same time, you’re able to uniformly monitor, log, and secure apps. Because IBM manages the service, you can focus on innovating with high-value IBM Cloud services and middleware, such as AI and analytics. You also have access to Red Hat packaged open-source tools, including your favorite app runtimes, frameworks, databases, and more.
Ready to get started? Try out the creating a Red Hat OpenShift on IBM Cloud cluster tutorial.
- Choice of container platform provider
- Deploy clusters with Red Hat OpenShift or community Kubernetes installed as the container platform orchestrator.
- Choose the developer experience that fits your company, or run workloads across both Red Hat OpenShift or community Kubernetes clusters.
- Built-in integrations from the IBM Cloud console to the Kubernetes dashboard or Red Hat OpenShift web console.
- Single view and management experience of all your Red Hat OpenShift or community Kubernetes clusters from IBM Cloud.
- Single-tenant Kubernetes clusters with compute, network, and storage infrastructure isolation
- Create your own customized infrastructure that meets the requirements of your organization.
- Choose between infrastructure providers.
- Provision a dedicated and secured Red Hat OpenShift master, worker nodes, virtual networks, and storage by using the resources provided by IBM Cloud infrastructure.
- Fully managed Kubernetes master that is continuously monitored and updated by IBM to keep your cluster available.
- Option to provision worker nodes as bare metal servers for compute-intensive workloads such as data, GPU, and AI.
- Store persistent data, share data between Kubernetes pods, and restore data when needed with the integrated and secure volume service.
- Benefit from full support for all native Kubernetes APIs.
- Multizone clusters to increase high availability
- Easily manage worker nodes of the same flavor (CPU, memory, virtual or physical) with worker pools.
- Guard against zone failure by spreading nodes evenly across select multizones and by using anti-affinity pod deployments for your apps.
- Decrease your costs by using multizone clusters instead of duplicating the resources in a separate cluster.
- Benefit from automatic load balancing across apps with the multizone load balancer (MZLB) that is set up automatically for you in each zone of the cluster.
- Highly available masters
- Reduce cluster downtime such as during master updates with highly available masters that are provisioned automatically when you create a cluster.
- Spread your masters across zones in a multizone cluster to protect your cluster from zonal failures.
- Image security compliance with Vulnerability Advisor
- Set up your own repo in a secured Docker private image registry where images are stored and shared by all users in the organization.
- Benefit from automatic scanning of images in your private IBM Cloud registry.
- Review recommendations specific to the operating system used in the image to fix potential vulnerabilities.
- Continuous monitoring of the cluster health
- Use the cluster dashboard to quickly see and manage the health of your cluster, worker nodes, and container deployments.
- Find detailed consumption metrics by using IBM Cloud® Monitoring and quickly expand your cluster to meet work loads.
- Review logging information by using IBM® Log Analysis to see detailed cluster activities.
- Secure exposure of apps to the public
- Choose between a public IP address, an IBM provided route, or your own custom domain to access services in your cluster from the internet.
- IBM Cloud service integration
- Add extra capabilities to your app through the integration of IBM Cloud services, such as Watson APIs, Blockchain, data services, or Internet of Things.
Comparison between Red Hat OpenShift and Kubernetes clusters
Both Red Hat OpenShift on IBM Cloud and IBM Cloud Kubernetes Service clusters are production-ready container platforms that are tailored for enterprise workloads. The following table compares and contrasts some common characteristics that can help you choose which container platform is best for your use case.
| Characteristics | Kubernetes clusters | Red Hat OpenShift clusters |
|---|---|---|
| Complete cluster management experience through the IBM Cloud Kubernetes Service automation tools (API, CLI, console) | Yes | Yes |
| Worldwide availability in single and multizones | Yes | Yes |
| Consistent container orchestration across hybrid cloud providers | Yes | Yes |
| Access to IBM Cloud services such as AI | Yes | Yes |
| Software-defined storage Portworx solution available for multizone data use cases | Yes | Yes |
| Create a cluster in an IBM Virtual Private Cloud (VPC) | Yes | Yes |
| Latest Kubernetes distribution | Yes | |
| Scope IBM Cloud IAM access policies to access groups for service access roles that sync to cluster RBAC | Yes | |
| Classic infrastructure cluster on only the private network | Yes | |
| GPU bare metal worker nodes | Yes | Yes |
| Integrated IBM Cloud Paks and middleware | Yes | |
| Built-in container image streams, builds, and tooling (read more) | Yes | |
| Integrated CI/CD with Jenkins | Yes | |
| Stricter app security context set up by default | Yes | |
| Simplified Kubernetes developer experience, with an app console that is suited for beginners | Yes | |
| Supported operating system | Kubernetes version information | Red Hat OpenShift version information |
| Preferred external traffic networking | Ingress | Router |
| Secured routes encrypted with Hyper Protect Crypto Services | Yes |
Comparison between clusters that run in IBM Cloud and standard OCP
Because Red Hat OpenShift on IBM Cloud is a managed service, many of the Red Hat® OpenShift® on IBM Cloud® components and global settings that you manually set up in OpenShift Container Platform are set up for you by default in Red Hat OpenShift on IBM Cloud. Review the following differences between Red Hat OpenShift on IBM Cloud clusters and a standard installation of OpenShift Container Platform on your own infrastructure. You can also review the service architecture for an overview of how Red Hat OpenShift components are set up in the cluster master and worker nodes, or the global settings that you can or can't configure.
| Characteristics | Standard OCP | Red Hat OpenShift on IBM Cloud |
|---|---|---|
| Cluster master (control plane) | You set up control plane components like the API server and etcd on machines that get the master role. You can modify the control plane components, but keep in mind that you are responsible for backing up, restoring, and making
control plane data highly available. |
IBM sets up the master, manages the control plane components, and automatically applies master patch updates for you. The masters are highly available and backed up automatically. |
| Compute machines (worker nodes) | You create your own compatible compute machines, set up compatible network connectivity, SSH into the machines, install OCP, and register the machines as worker nodes in the cluster. Your machines might be installer-provisioned infrastructure (IPI) for a guided setup, or user-provisioned infrastructure (UPI) for more control and subsequent administration on your end. You are responsible for maintaining and updating the worker nodes. You can install updates from the Red Hat OpenShift web console. | You select the flavor of worker nodes that you want to add to your cluster, and IBM automatically connects the worker nodes to the cluster and installs OCP. In this sense, the installation is similar to IPI for you because you don't have to manage all the infrastructure and network settings. IBM also provides patch updates that you can choose to apply to your worker nodes, from the IBM Cloud interface (not the Red Hat OpenShift web console). SSH is disabled for added security. |
| OCP versions and patch updates | You are responsible for updating the underlying infrastructure for the master and worker nodes. You can use the Red Hat OpenShift web console to update OCP versions. | IBM automatically applies updates to the master, and provides version updates and security patch updates for the worker nodes. You choose when to apply these updates to your worker nodes, from the IBM Cloud interface (not the Red Hat OpenShift web console). Supported versions might vary from standard OpenShift Container Platform. |
| Autoscaling compute machines | You can set up a ClusterAutoscaler resource. |
You can set up the cluster autoscaler plug-in. |
| Worker node operating system | CoreOS or RHEL | For a list of supported operating systems by cluster version, see Red Hat OpenShift on IBM Cloud version information. |
| Support | Provided per the terms of your Red Hat subscription or cloud provider. You can use the oc adm must-gather tool to help gather information. |
Provided by IBM Cloud Support. You can use the oc adm must-gather tool, or the Diagnostics and Debug Tool to help gather information. |
| Red Hat OpenShift web console | You set up and can configure or disable the Red Hat OpenShift web console. | The Red Hat OpenShift web console is set up for you. You can't configure or disable the web console. IBM also provides the Red Hat OpenShift clusters console to manage your cluster infrastructure. |
| Authentication | An OAuth server is provided, but you configure the token settings and identity provider to control access to the cluster. You also manage RBAC to control user access within the cluster. | IBM automatically sets up the OAuth server to use IBM Cloud IAM. You can't change the identity provider. IBM Cloud IAM is also set up to automatically sync to RBAC so that you can use IAM to manage access to and within the cluster. |
| Container network for clusters | The cluster network operator sets up the SDN container network interface (CNI) plug-in. You can change the CNI plug-in, configure multiple networks, or attach a hardware network such as single root I/O virtualization (SR-IOV). | Calico is set up for you. You can't change the CNI plug-in, configure multiple networks, or attach a hardware network. |
| Ingress | You can use the Ingress operator to set up one or more HAProxy-based Ingress controllers. You can route traffic to your apps by specifying Route or Ingress resources. |
When you create a cluster, a default Ingress subdomain is set up for you. One HAProxy-based router is set up for each Ingress controller, and one router service is automatically created in each zone that you have worker nodes in. You can
route traffic to your apps by specifying Route or Ingress resources. For more information, see About Ingress in Red Hat OpenShift version 4. |
| Storage | You must set up persistent volumes to be backed up by a storage provider. OpenShift Data Foundation is available. | IBM automatically sets up storage providers such as IBM Cloud File and Block. OpenShift Data Foundation is available. For supported storage options, see Planning highly available persistent storage. |
| Image registry | The cluster is set up with an internal registry to pull images. If your cluster has public network access, you can pull images automatically from Docker Hub. To pull images from other registries, you must set up image pull secrets. You set up the internal registry to back up images to a cloud storage provider. Stored images are not available across clusters. | The internal registry is set up to back up images automatically to a bucket in your IBM Cloud Object Storage instance. Your cluster has image pull secrets automatically set up to pull images from default registries, including IBM Cloud Container Registry. You can also set up the internal registry to work with IBM Cloud Container Registry, which your cluster is also automatically set up to pull images from. For more information, see Setting up an image registry. |
| Operators and OperatorHub | OpenShift Container Platform sets up many operators to manage default components for the cluster. You can also use the OperatorHub to install other operators such as from 3rd-party providers. | IBM sets up many of the same operators as OCP to manage default component for the cluster. However, because IBM manages the master and provides you with IBM Cloud APIs to manage your cloud infrastructure, some operators, such as the machine set operator and other components as noted in this table, are not set up or configurable. You can also use the OperatorHub to install other operators such as from 3rd-party providers. Note that operators that you install or create are not supported by IBM, and might come with their own support terms and pricing. |
| Projects, builds, and apps | OpenShift Container Platform provides tools such as projects, build configurations, and the internal registry that you can use to deploy your apps while following a cloud-native, continuous integration and continuous delivery (CI/CD) methodology. | Red Hat OpenShift on IBM Cloud clusters come with all the same configurable project and build components as OCP clusters. You can also choose to integrate your cluster with IBM Cloud services like Continuous Delivery. |
| Cluster health | You can also set up logging, monitoring, and metering tools by installing and configuring various operators. These solutions are cluster-specific and not highly available unless you back them up. | Your clusters feature one-click integrations with IBM Log Analysis and IBM Cloud Monitoring for enterprise-grade, persistent monitoring and logging solutions across clusters. You can also install the logging and monitoring operators as with standard OCP, but you might have to adjust the configuration settings. For more information, see Logging and monitoring cluster health. |
| Migrating clusters | You can use the cluster migrator operator to migrate clusters from one major version to another. Migration requires separate clusters; you can't update a cluster from one major version to another. Various open source tools might be used, but are not officially supported. | As with standard OpenShift Container Platform, you can't update a cluster from one major version to another. If you use a third-party open source tool such as the cluster migrator operator, the tool is not supported by IBM and might have limitations such as the migration UI being unavailable. |
| Container-native virtualization | You can set up container-native virtualization add-on on bare metal machines, but not on virtual machines. Container-native virtualization is not supported by IBM. If you experience issues, you are responsible for resolving the issues and any impact to your workloads. | |
| Serverless workloads | You can set up Red Hat OpenShift Serverless. | You can also set up Red Hat OpenShift Serverless. |
| Service mesh | You can set up the Red Hat OpenShift Service Mesh. | You can also set up the Red Hat OpenShift Service Mesh, but you must apply a network policy for the service mesh ingress to work. |
| API and CLI tools | OpenShift Container Platform clusters are set up with access to Kubernetes and Red Hat OpenShift API resources. You can also install command line tools such as oc and odo. |
Red Hat OpenShift on IBM Cloud clusters come with the same capabilities to use the Kubernetes and Red Hat OpenShift API and CLI tools. Additionally, you can use the IBM Cloud API and CLI tools to manage your cluster infrastructure and integrate other cloud services with your cluster. |
Moving your workloads to IBM Cloud
You have lots of reasons to move your workloads to IBM Cloud: reducing total cost of ownership, increasing high availability for your apps in a secure and compliant environment, scaling up and down in respond to your user demand, and many more. Red Hat OpenShift on IBM Cloud combines container technology with open source tools, such as Kubernetes so that you can build a cloud-native app that can migrate across different cloud environments, avoiding vendor lock-in.
But how do you get to the cloud? What are your options along the way? And how do you manage your workloads after you get there?
Use this page to learn some strategies for your Kubernetes deployments on Red Hat OpenShift on IBM Cloud. And engage with the team on Slack.
Not on slack yet? Request an invite!
The following table provides some examples of what types of workloads that users typically move to the various types of clouds. You might also choose a hybrid approach where you have clusters that run in both environments.
| Workload | Red Hat OpenShift on IBM Cloud off-prem | on-prem |
|---|---|---|
| DevOps enablement tools | Yes | |
| Developing and testing apps | Yes | |
| Apps that shift dramatically in demand and need to scale rapidly | Yes | |
| Business apps such as CRM, HCM, ERP, and E-commerce | Yes | |
| Collaboration and social tools such as email | Yes | |
| RHEL workloads | Yes | |
| Bare metal | Yes | Yes |
| GPU compute resources | Yes | Yes |
| PCI and HIPAA-compliant workloads | Yes | Yes |
| Legacy apps with platform and infrastructure constraints and dependencies | Yes | |
| Proprietary apps with strict designs, licensing, or heavy regulations | Yes |
- Ready to run workloads off-premises in Red Hat OpenShift on IBM Cloud?
- Great! You're already in the public cloud documentation. Keep reading for more strategy ideas, or hit the ground running by creating a cluster now.
- Want to run workloads in both on-premises and off-premises clouds?
- Explore IBM Cloud Satellite to extend the flexibility and scalability of IBM Cloud into your on-premises, edge, or other cloud provider environments.
What kind of apps can I run? Can I move existing apps, or do I need to develop new apps?
Your containerized app must be able to run on one of the supported operating systems for your cluster version. You also want to consider the statefulness of your app. For more information about the kinds of apps that can run in Red Hat OpenShift on IBM Cloud, see Planning app deployments.
If you already have an app, you can migrate it to Red Hat OpenShift on IBM Cloud. If you want to develop a new app, check out the guidelines for developing stateless, cloud-native apps.
What skills should I have before I move my apps to a cluster?
Red Hat OpenShift is designed to provide capabilities to two main personas, the cluster admin and the app developer. Each persona uses different technical skills to successfully run and deploy apps to a cluster.
- What are a cluster admin's main tasks and technical knowledge?
- As a cluster admin, you are responsible to set up, operate, secure, and manage the IBM Cloud infrastructure of your cluster. Typical tasks include:
- Size the cluster to provide enough capacity for your workloads.
- Design a cluster to meet the high availability, disaster recovery, and compliance standards of your company.
- Secure the cluster by setting up user permissions and limiting actions within the cluster to protect your compute resources, your network, and data.
- Plan and manage network communication between infrastructure components to ensure network security, segmentation, and compliance.
- Plan persistent storage options to meet data residency and data protection requirements.
The cluster admin persona must have a broad knowledge that includes compute, network, storage, security, and compliance. In a typical company, this knowledge is spread across multiple specialists, such as System Engineers, System Administrators, Network Engineers, Network Architects, IT Managers, or Security and Compliance Specialists. Consider assigning the cluster admin role to multiple people in your company so that you have the required knowledge to successfully operate your cluster. For more information, see the Learning path for administrators.
- What are an app developer's main tasks and technical skills?
- As a developer, you design, create, secure, deploy, test, run, and monitor cloud-native, containerized apps in an Red Hat OpenShift cluster. To create and run these apps, you must be familiar with the concept of microservices, the 12-factor app guidelines, Docker and containerization principles, and available Red Hat OpenShift deployment options. For more information, see the Learning path for developers.
Red Hat OpenShift and Red Hat OpenShift on IBM Cloud provide multiple options for how to expose an app and keep an app private, add persistent storage, integrate other services, and how you can secure your workloads and protect sensitive data. Before you move your app to a cluster in Red Hat OpenShift on IBM Cloud, verify that you can run your app as a containerized app on the supported operating system and that Red Hat OpenShift and Red Hat OpenShift on IBM Cloud provide the capabilities that your workload needs.
Related resources
Review how you can learn about Kubernetes concepts and the terminology.
- Familiarize yourself with the product by completing the Creating clusters tutorial.
- Learn how Kubernetes and Red Hat OpenShift on IBM Cloud work together by completing this course.