Supported infrastructure providers

+
Search Tips | Advanced Search

Supported infrastructure providers

With Red Hat OpenShift on IBM Cloud, we can create a cluster from the following infrastructure providers. All the worker nodes in a cluster must be from the same provider. Originally, Red Hat OpenShift on IBM Cloud provisioned your worker nodes in a single provider, classic infrastructure.

Classic: Create the cluster on a classic compute, networking, and storage environment in IBM Cloud infrastructure.
Generation 2 compute: Create the cluster on the next generation of IBM Cloud infrastructure virtual servers, available as of 20 May 2020.

Area Classic VPC

Overview Clusters on classic infrastructure include all of the Red Hat OpenShift on IBM Cloud mature and robust features for compute, networking, and storage. To get started, create a Kubernetes or OpenShift cluster. With VPC, we can create the cluster in the next generation of the IBM Cloud platform, in your Virtual Private Cloud. VPC gives you the security of a private cloud environment with the dynamic scalability of a public cloud, with the ability to deploy the cluster worker nodes as generation 2 compute virtual servers. To get started, try out the VPC Gen 2 compute cluster tutorial.

Doc icons Throughout the documentation, pages and topics might include a note that the content applies only to the classic infrastructure provider. Throughout the documentation, pages and topics might include a note that the content applies only to the VPC infrastructure provider.

Compute and worker node resources Virtual, bare metal, and software-defined storage machines are available for the worker nodes. Your worker node instances reside in your IBM Cloud infrastructure account, but we can manage them through Red Hat OpenShift on IBM Cloud. You own the worker node instances. VPC supports only a select group of virtual machines for the worker nodes. Unlike classic clusters, your VPC cluster worker nodes do not 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.

Security Classic clusters have many built-in security features that help you protect the cluster infrastructure, isolate resources, and ensure security compliance. For more information, see the classic Network Infrastructure documentation. With VPC, the cluster runs in an isolated environment in the public cloud. Network access control lists protect the subnets that provide the floating IPs for the worker nodes. For more information, see the VPC documentation.

High availability For both classic and VPC clusters, the master includes three replicas for high availability. Further, if you create the cluster in a multizone metro, the master replicas are spread across zones and we can also spread your worker pools across zones. For more information, see High availability for Red Hat OpenShift on IBM Cloud. Same as Classic; see High availability for Red Hat OpenShift on IBM Cloud.

Cluster administration Classic clusters support the entire set of v1 API automation, 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, we can choose to remove any attached subnet or storage instances. VPC clusters cannot 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 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, we can also provision the worker nodes on a public VLAN. Communication to the cluster master can be on the public or private service endpoint. For more information, see Understand cluster network basics. Unlike classic infrastructure, the worker nodes of our 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 We can choose to create community Kubernetes or OpenShift clusters to manage your containerized apps. Your app build processes do not differ because of the infrastructure provider, but how you expose the app does, as described in the next App networking entry. We can choose to create community Kubernetes or OpenShift clusters to manage your containerized apps. Your app build processes do not differ because of the infrastructure provider, but how you expose the app does, as described in the next App networking entry.

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, the cluster must have worker nodes on the public VLAN. Then, we can create a NodePort, LoadBalancer (NLB), or Ingress (ALB) service. For more information, see Plan in-cluster and external networking for apps. 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, we can create a Kubernetes LoadBalancer service, which provisions a VPC load balancer and public hostname address for the worker nodes. For more information, see Exposing apps with VPC load balancers.

Storage We can choose from non-persistent and persistent storage solutions such as file, block, object, and software-defined storage. For more information, see Plan highly available persistent storage. For persistent storage, use block. For the number of volumes that can be attached per worker node, see Volume attachment limits. The storage class limits the volume size to 20TB and IOPS capacity to 20,000. For non-persistent storage, secondary storage on the local worker node is not available.

User access To create classic infrastructure clusters, we must set up infrastructure credentials for each region and resource group. To let users manage the cluster, use IBM Cloud IAM platform roles. To grant users access to Kubernetes resources within the cluster, use IBM Cloud IAM service roles, which correspond with Kubernetes RBAC roles. Unlike for classic infrastructure, with VPC, we can use only IBM Cloud IAM access policies to authorize users to create infrastructure, manage the cluster, and access Kubernetes resources. The cluster can be in a different resource group than the VPC.

Integrations We can extend the 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. 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.

Available locations and versions Classic clusters are available worldwide, including all six IBM Cloud multizone metros and 20 single zone locations in more than a dozen countries. VPC clusters are available worldwide in the multizone metros.

Service interface (API, CLI, UI) Classic clusters are fully supported in the Kubernetes Service v1 API , CLI, and console . VPC clusters are supported by the next version (v2) of the IBM Cloud Kubernetes Service API, and we can manage your VPC clusters through the same CLI and console as classic clusters.

Service compliance See the classic section in What standards does the service comply to?. See the VPC section in What standards does the service comply to?.

Service limitations See Service limitations. Feature-specific limitations are documented by section. See Service limitations.

For VPC-specific limitations in Red Hat OpenShift on IBM Cloud, see VPC Gen 2 compute cluster limitations.
For general VPC infrastructure provider limitations, see Known limitations.

Troubleshooting and support Both classic and VPC clusters are supported through the same IBM Cloud Support processes. For cluster issues, check out the Debugging the clusters guide. For questions, try posting in the Slack channel. Both classic and VPC clusters are supported through the same IBM Cloud Support processes. For cluster issues, check out the troubleshooting documentation for VPC-specific topics. For questions, try posting in the Slack channel.

Area	Classic	VPC
Overview	Clusters on classic infrastructure include all of the Red Hat OpenShift on IBM Cloud mature and robust features for compute, networking, and storage. To get started, create a Kubernetes or OpenShift cluster.	With VPC, we can create the cluster in the next generation of the IBM Cloud platform, in your Virtual Private Cloud. VPC gives you the security of a private cloud environment with the dynamic scalability of a public cloud, with the ability to deploy the cluster worker nodes as generation 2 compute virtual servers. To get started, try out the VPC Gen 2 compute cluster tutorial.
Doc icons	Throughout the documentation, pages and topics might include a note that the content applies only to the classic infrastructure provider.	Throughout the documentation, pages and topics might include a note that the content applies only to the VPC infrastructure provider.
Compute and worker node resources	Virtual, bare metal, and software-defined storage machines are available for the worker nodes. Your worker node instances reside in your IBM Cloud infrastructure account, but we can manage them through Red Hat OpenShift on IBM Cloud. You own the worker node instances.	VPC supports only a select group of virtual machines for the worker nodes. Unlike classic clusters, your VPC cluster worker nodes do not 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.
Security	Classic clusters have many built-in security features that help you protect the cluster infrastructure, isolate resources, and ensure security compliance. For more information, see the classic Network Infrastructure documentation.	With VPC, the cluster runs in an isolated environment in the public cloud. Network access control lists protect the subnets that provide the floating IPs for the worker nodes. For more information, see the VPC documentation.
High availability	For both classic and VPC clusters, the master includes three replicas for high availability. Further, if you create the cluster in a multizone metro, the master replicas are spread across zones and we can also spread your worker pools across zones. For more information, see High availability for Red Hat OpenShift on IBM Cloud.	Same as Classic; see High availability for Red Hat OpenShift on IBM Cloud.
Cluster administration	Classic clusters support the entire set of v1 API automation, 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, we can choose to remove any attached subnet or storage instances.	VPC clusters cannot 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	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, we can also provision the worker nodes on a public VLAN. Communication to the cluster master can be on the public or private service endpoint. For more information, see Understand cluster network basics.	Unlike classic infrastructure, the worker nodes of our 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	We can choose to create community Kubernetes or OpenShift clusters to manage your containerized apps. Your app build processes do not differ because of the infrastructure provider, but how you expose the app does, as described in the next App networking entry.	We can choose to create community Kubernetes or OpenShift clusters to manage your containerized apps. Your app build processes do not differ because of the infrastructure provider, but how you expose the app does, as described in the next App networking entry.
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, the cluster must have worker nodes on the public VLAN. Then, we can create a NodePort, LoadBalancer (NLB), or Ingress (ALB) service. For more information, see Plan in-cluster and external networking for apps.	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, we can create a Kubernetes LoadBalancer service, which provisions a VPC load balancer and public hostname address for the worker nodes. For more information, see Exposing apps with VPC load balancers.
Storage	We can choose from non-persistent and persistent storage solutions such as file, block, object, and software-defined storage. For more information, see Plan highly available persistent storage.	For persistent storage, use block. For the number of volumes that can be attached per worker node, see Volume attachment limits. The storage class limits the volume size to 20TB and IOPS capacity to 20,000. For non-persistent storage, secondary storage on the local worker node is not available.
User access	To create classic infrastructure clusters, we must set up infrastructure credentials for each region and resource group. To let users manage the cluster, use IBM Cloud IAM platform roles. To grant users access to Kubernetes resources within the cluster, use IBM Cloud IAM service roles, which correspond with Kubernetes RBAC roles.	Unlike for classic infrastructure, with VPC, we can use only IBM Cloud IAM access policies to authorize users to create infrastructure, manage the cluster, and access Kubernetes resources. The cluster can be in a different resource group than the VPC.
Integrations	We can extend the 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.	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.
Available locations and versions	Classic clusters are available worldwide, including all six IBM Cloud multizone metros and 20 single zone locations in more than a dozen countries.	VPC clusters are available worldwide in the multizone metros.
Service interface (API, CLI, UI)	Classic clusters are fully supported in the Kubernetes Service v1 API , CLI, and console .	VPC clusters are supported by the next version (v2) of the IBM Cloud Kubernetes Service API, and we can manage your VPC clusters through the same CLI and console as classic clusters.
Service compliance	See the classic section in What standards does the service comply to?.	See the VPC section in What standards does the service comply to?.
Service limitations	See Service limitations. Feature-specific limitations are documented by section.	See Service limitations. For VPC-specific limitations in Red Hat OpenShift on IBM Cloud, see VPC Gen 2 compute cluster limitations. For general VPC infrastructure provider limitations, see Known limitations.
Troubleshooting and support	Both classic and VPC clusters are supported through the same IBM Cloud Support processes. For cluster issues, check out the Debugging the clusters guide. For questions, try posting in the Slack channel.	Both classic and VPC clusters are supported through the same IBM Cloud Support processes. For cluster issues, check out the troubleshooting documentation for VPC-specific topics. For questions, try posting in the Slack channel.