IBM Cloud Docs
Locations

Locations

You can deploy Red Hat® OpenShift® on IBM Cloud® clusters worldwide. When you create a cluster, its resources remain in the location that you deploy the cluster to. To work with your cluster, you can access the service via a global API endpoint.

Red Hat OpenShift on IBM Cloud locations
Figure 1. Red Hat OpenShift on IBM Cloud locations

This image is an artistic representation and does not reflect actual political or geographic boundaries.

Red Hat OpenShift on IBM Cloud locations

IBM Cloud resources are organized into a hierarchy of geographic locations. Red Hat OpenShift on IBM Cloud is available in a subset of these locations, including worldwide multizone regions and single zone regions. Other IBM Cloud services might be available globally or within a specific location.

ibmcloud oc locations

How locations are organized

The following image is used as an example to explain how Red Hat OpenShift on IBM Cloud locations are organized. For more information, see Locations for resource deployment.

Organization of Red Hat OpenShift on IBM Cloud locations
Figure 1. Organization of Red Hat OpenShift on IBM Cloud locations

Organization of Red Hat OpenShift on IBM Cloud locations.
Type Example Description
Geography North America (na) An organizational grouping that is based on geographic continents.
Country Canada (ca) The location's country within the geography.
Metro For example, Dallas (dal). The name of a city where 1 or more data centers are located. A metro might have a multizone region, such as Dallas, or might have a single zone region, such as Milan. If you create a cluster in a multizone region, the Kubernetes master and worker nodes can be spread across zones for high availability.
Data center (zone) Dallas 12 (dal12) A physical location of the compute, network, and storage infrastructure and related cooling and power that host cloud services and applications. In a region, clusters can be spread across data centers, or zones, in an multizone architecture for high availability. Zones are isolated from each other, which ensures no shared single point of failure.

Classic multizone regions

If you create a classic cluster in a multizone region, the replicas of your highly available Kubernetes master are automatically spread across the data centers (zones). You have the option to spread your worker nodes across zones to protect your apps from a zone failure. To determine whether a location has a multizone region, your can run ibmcloud oc locations and look for the value in the Multizone Metro column.

Available multizone metro locations for classic clusters in Red Hat OpenShift on IBM Cloud.
Geography Country Metro Region Zones
Asia Pacific Australia Sydney au-syd syd01, syd04, syd05
Asia Pacific Japan Osaka jp-osa osa21, osa22, osa23
Asia Pacific Japan Tokyo jp-tok tok02, tok04, tok05
Europe Germany Frankfurt de-fra fra02, fra04, fra05
Europe United Kingdom London uk-lon lon02, lon04, lon05, lon06
North America United States Dallas us-dal dal10, dal12, dal13
North America United States Washington DC us-wdc wdc04, wdc06, wdc07

Classic single zone regions

If you create a classic cluster in a single zone region, you can create multiple worker nodes but you can't spread them across data centers (zones). The highly available master includes three replicas on separate hosts, but is not spread across zones.

Classic single zone clusters are managed from the regional endpoint located in the nearest region that supports classic multizone, such as mon01 to us-east or sao01 to us-south.

Available single zone data center locations for classic clusters in Red Hat OpenShift on IBM Cloud.
Geography Country Metro Region Zone Managed from region
Asia Pacific India Chennai in-che che01 AP North (ap-north, jp-tok)
Asia Pacific Singapore Singapore sng-mtr sng01 AP North (ap-north, jp-tok)
Europe France Paris fr-par par01 EU Central (eu-central, eu-de)
Europe Italy Milan it-mil mil01 EU Central (eu-central, eu-de)
Europe Netherlands Amsterdam nl-ams ams03 EU Central (eu-central, eu-de)
North America Canada Montreal ca-mon mon01 US East (us-east)
North America Canada Toronto ca-tor tor01 US East (us-east)
North America United States San Jose us-sjc sjc03, sjc04 US South (us-south)
South America Brazil Sao Paulo br-sao sao01 US South (us-south)

VPC multizone regions

VPC resources are provisioned in a region, which is a separate group of zones within a metro. The zones are mapped to separate data centers to ensure that resources are distributed evenly across zones in a multizone architecture. In the API and CLI, zones use the regional zone name in the API and command line (us-south-1), but in the console, zones use by the data center location (Dallas 1). For the data center code that the VPC zone and location corresponds to, such as us-south-1 and DAL10, see Multizone regions.

Available multizone metro locations for VPC clusters in Red Hat OpenShift on IBM Cloud.
Geography Country Metro Region Zones
Asia Pacific Australia Sydney au-syd au-syd-1, au-syd-2, au-syd-3
Asia Pacific Japan Osaka jp-osa jp-osa-1, jp-osa-2, jp-osa-3
Asia Pacific Japan Tokyo jp-tok jp-tok-1, jp-tok-2, jp-tok-3
Europe Germany Frankfurt eu-de eu-de-1, eu-de-2, eu-de-3
Europe Spain Madrid eu-es eu-es-1, eu-es-2, eu-es-3
Europe United Kingdom London eu-gb eu-gb-1, eu-gb-2, eu-gb-3
North America Canada Toronto ca-tor ca-tor-1, ca-tor-2, ca-tor-3
North America United States Dallas us-south us-south-1, us-south-2, us-south-3
North America United States Washington DC us-east us-east-1, us-east-2, us-east-3
South America Brazil São Paulo br-sao br-sao-1, br-sao-2, br-sao-3

These regions are available as multizone regions for clusters on VPC infrastructure only.

Resources in a single zone cluster

In a single zone cluster, your cluster's resources remain in the data center (zone) in which the cluster is deployed, but management operations might be routed through a regional endpoint.

Your cluster's resources, including the master and worker nodes, are in the same zone that you deployed the cluster to. When you initiate local container orchestration actions, such as oc commands, the information is exchanged between your master and worker nodes within the same zone.

If you set up other cluster resources, such as storage, networking, compute, or apps running in pods, the resources and their data remain in the zone that you deployed your cluster to.

When you initiate cluster management actions, such as running ibmcloud oc commands, basic information about the cluster such as name, ID, user, the command is routed through a regional endpoint and the global endpoint.

Resources in a multizone cluster

In a multizone cluster, your cluster's resources are spread across multiple zones for higher availability.

Worker nodes are spread across multiple zones in the metro location to provide more availability for your cluster. The Kubernetes master replicas are also spread across zones. When you initiate local container orchestration actions, such as oc commands, the information is exchanged between your master and worker nodes through the global endpoint.

Other cluster resources, such as storage, networking, compute, or apps running in pods, vary in how they deploy to the zones in your multizone cluster. For more information, review these topics:

When you initiate cluster management actions, such as running ibmcloud oc commands, basic information about the cluster, such as name, ID, user, the command is routed through the global endpoint.

Satellite regions

To see a list of the supported Managed from regions for Satellite clusters, Supported Satellite locations.

Accessing the global endpoint

You can organize your resources across IBM Cloud services by using IBM Cloud locations (formerly called regions). For example, you can deploy an app to a cluster by using a private Docker image that is stored in your IBM Cloud Container Registry of the same location. To access these resources, you can use the global endpoints and filter by location.

Logging in to IBM Cloud

When you log in to the IBM Cloud (ibmcloud) command line, you are prompted to select a region. However, this region does not affect the Red Hat OpenShift on IBM Cloud plug-in (ibmcloud oc) endpoint, which still uses the global endpoint. Note that you do still need to target the resource group that your cluster is in if it is not in the default resource group.

To log in to the IBM Cloud global API endpoint and target the resource group that your cluster is in:

ibmcloud login -a https://cloud.ibm.com -g <nondefault_resource_group_name>

Logging in to Red Hat OpenShift on IBM Cloud

When you log in to IBM Cloud, you can access the Kubernetes Service. To help you get started, check out the following resources for using the Red Hat OpenShift on IBM Cloud CLI and API.

Install the IBM Cloud CLI Access your Red Hat OpenShift cluster.

When you use the new global functionality in the Red Hat OpenShift on IBM Cloud CLI, consider the following changes from the legacy region-based functionality.

  • Listing resources:

    • When you list resources, such as with the ibmcloud oc cluster ls, ibmcloud oc subnets, or ibmcloud oc zone ls commands, resources in all locations are returned. To filter resources by a specific location, certain commands include a --location option. For example, if you filter clusters for the wdc metro, multizone clusters in that metro and single-zone clusters in data centers (zones) within that metro are returned. If you filter clusters for the wdc06 data center (zone), multizone clusters that have a worker node in that zone and single-zone clusters in that zone are returned. ibmcloud oc cluster ls -l dal.

    • Other commands don't return resources in all locations. To run credential set/unset/get, api-key reset, and vlan spanning get commands, you must specify a region in the --region.

  • Working with resources:

    • When you use the global endpoint, you can work with resources that you have access permissions to in any location, even if you target one region and the resource that you want to work with is in another region.
    • If you have clusters with the same name in different regions, use the cluster ID when you run commands or set a region with the ibmcloud oc init command and use the cluster name when you run commands.
  • Legacy functionality:

    • If you need to list and work with resources from one region only, you can use the ibmcloud oc init command to target a regional endpoint instead of the global endpoint. Example to target the US South regional endpoint:
      ibmcloud oc init --host https://us-south.containers.cloud.ibm.com
      
    • To use the global functionality, you can use the ibmcloud oc init command again to target the global endpoint. Example to target the global endpoint again:
      ibmcloud oc init --host https://containers.cloud.ibm.com
      

Red Hat OpenShift on IBM Cloud API:

To interact with the global Red Hat OpenShift on IBM Cloud API, enter the command type and append global/v1/command to the endpoint.

Example of GET /clusters global API:

GET https://containers.cloud.ibm.com/global/v1/clusters

If you need to specify a region in an API call, remove the /global parameter from the path and pass the region name in the X-Region header. To list available regions, review the Previous region column in the Red Hat OpenShift on IBM Cloud locations table.