IBM Cloud Docs
Limitations, default settings, and usage requirements

Limitations, default settings, and usage requirements

IBM Cloud Satellite® comes with usage requirements, default service settings, and limitations to ensure security, convenience, and basic functionality.

Locations

You can create up to 20 Satellite locations per IBM Cloud multizone metro that the location is managed from.

Name
The Satellite location name must start with a letter, can contain letters, numbers, periods (.), and hyphen (-), and must be 35 characters or fewer. Do not reuse the same name for multiple locations, even if you deleted another location with the same name.
Latency
As you select your infrastructure provider, consider the following latency requirements. Environments that do not meet the latency requirements experience degraded performance.
  • Between IBM Cloud and the location: The hosts that you want to attach to the Satellite location control plane must have a low latency connection of less than or equal to 200 milliseconds (<= 200ms) round trip time (RTT) to the IBM Cloud region that your Satellite location is managed from. As latency increases, you might see impacts to performance, including Satellite Link throughput, Satellite-enabled IBM Cloud service provisioning time, host failure recovery time, and in extreme cases, the availability of resources that run in the Satellite location control plane, such as Red Hat OpenShift cluster masters. For more information, see Testing the latency between IBM Cloud and the Satellite location control plane hosts.
  • Between hosts in your location: Your host infrastructure setup must have a low latency connection of less than or equal to 100 milliseconds (<= 100ms) round trip time (RTT) between the hosts that are used for the Satellite location control plane worker nodes and the hosts that are used for other resources in the location, like clusters or Satellite-enabled IBM Cloud service. For example, in cloud providers such as AWS, this setup typically means that all the hosts in the Satellite location are from the same cloud region, like us-east-1. As latency increases, you might see impacts to performance, including provisioning and recovery times, reduced worker nodes in the cluster, Satellite-enabled IBM Cloud service degradation, and in extreme cases, failures in your cluster applications.

Hosts

See Host requirements.

For cloud provider-specific configurations, see the following topics.

Worker node hosts
Worker nodes in Red Hat OpenShift on IBM Cloud clusters on Classic or VPC infrastructure can't be repurposed for use in Satellite clusters.

Clusters

See Satellite cluster limitations in the Red Hat OpenShift on IBM Cloud documentation. The limitations include information related to the following components.

  • Red Hat OpenShift on IBM Cloud clusters that you create in your Satellite location.
  • Storing data in Kubernetes persistent volumes for apps that run in your clusters.
  • Cluster networking, such as Kubernetes load balancers.
  • Using your hosts as the worker nodes in the cluster.

Connector

Review the following requirements and limitations for Satellite Connector.

Config

Review the following application configuration requirements for Satellite Config.

Satellite Config is not supported on locations that are enabled for Red Hat CoreOS.

Satellite Config access to modify Kubernetes resources within a cluster
By default, Satellite Config is limited to what Kubernetes resources it can read and modify in your clusters. You must grant Satellite Config access in each cluster where you want to use Satellite Config to manage your Kubernetes resources.
Choose from the following options.
  • Opt in to cluster admin access when you create the cluster in the console or CLI with the --enable-admin-agent option. Note that you must perform a one-time oc login in each cluster to synchronize the admin permissions.
  • To opt in after creating a cluster or to scope the access, see Granting Satellite Config access to your clusters.
Satellite Config and IBM Cloud IAM
You cannot scope access policies for Satellite Config resources (configuration, subscription, cluster, or cluster group) to an IBM Cloud resource group. Satellite Config uses the open source Razee project, which authenticates users by using the organization. The organization supports only the account ID, not resource groups.
You cannot scope access policies to particular configuration or subscription resources. When you assign a policy in the IBM Cloud IAM console, leave the Resource field blank for configurations or subscriptions. Instead, you can scope the access policy to a cluster group for more control of how your Satellite Config resources are deployed.
To let users view the Kubernetes resources that run in clusters with Satellite Config, you must assign an access policy with the appropriate role (Administrator, Manager, or Reader) to IBM Cloud Satellite (and not scoped to a particular resource or resource type).
After you enable Satellite Config permissions when you create a Satellite cluster in the console or in the CLI with the --enable-admin-agent option for the ibmcloud oc cluster create satellite command, you must set the context of the cluster to synchronize permissions. You can set the cluster context by launching the Red Hat OpenShift web console or by running the ibmcloud oc cluster config command in the CLI. Note: If you registered a Red Hat OpenShift on IBM Cloud cluster in the public cloud to use with Satellite Config, you do not need to set the cluster context to synchronize permissions.
Configuration files in Satellite Config
  • You can upload only an individual configuration file of Kubernetes resources per release version. You cannot upload a directory or several different configuration files.
  • Configuration files are subject to Kubernetes requirements, such as that the manifest must be expressed in YAML format.

IBM Cloud services

You can have up to 40 instances of a supported IBM Cloud service per Satellite location. For example, you might have a Satellite location that has 40 Red Hat OpenShift on IBM Cloud clusters in it.

Each supported service might have its own limitations to run in Satellite. Check the documentation of the supported service to understand the limitations.