Recently, our team’s main objective was to expand the functionalities of IBM Cloud Satellite to make it more customizable. As a result of the following implemented features, our users have more options to personalize the configuration of the Satellite locations and clusters, making it more suitable for their setups and solutions.

IBM Cloud Satellite is designed to be consumed within arbitrary data center solutions, so the system-determined purpose for host network interfaces may not be appropriate for the user. That is—considering any bare-metal- or virtual-machine-based Satellite location, users may want individual network interface cards for different purposes to implement traffic segregation requirements.

One of the basic traffic types for a Kubernetes type of workload (such as Red Hat Openshift clusters on Satellite) is the cluster-internal network (or Pod-to-Pod) network. Pod networks are usually realized as overlay networks, which are utilizing one specific network interface on each host. Publicly hosted infrastructures have well-defined (and rigid) defaults for the network interface set of the hosts and how the Pod network is bound to them.

IBM Cloud Satellite now offers a new set of options that lets the user to control how a Pod network will be bound to host network interfaces on each host. The immutable option can be selected upon the creation of each Openshift cluster and for the Satellite location infrastructure, as well.

Given that the IBM Cloud Satellite infrastructure (and the Openshift clusters on it) implements the Pod network with Calico, the new option controls a specific Calico feature.

Similar to the selected interface, the actual Pod and Service subnet may also need to be set to avoid conflicts with existing services in the target data center.

Configure pod network interfaces

To ensure the correct host network interfaces are used for the Pod-to-Pod network, Calico offers an autodetection solution for Kubernetes nodes. To achieve this, several different selection methods are available, including the following:

  • Use the interface, which owns the address assigned to the Kubernetes node (kubernetes-internal-ip)
  • Actively probe the node interfaces to reach a particular IP or domain (can-reach)
  • Regex to include matching interfaces (interface)
  • Regex to exclude matching interfaces (skip-interface)
  • A list of IP ranges in CIDR format to determine valid IP addresses on the node to choose from (cidrs)

When any kind of cluster is created, this autodetection is configured by the deploying process, and before this improvement, it has been set to the “can-reach” method with the “” value. After this implementation, in case of a CoreOS-enabled Satellite configuration, the autodetection method is configurable for the location’s infrastructure and the Openshift clusters in creation time. This feature is only available through the IBM Cloud CLI, and the following methods are supported:

  • Address assigned to Kubernetes node (kubernetes-internal-ip) as a default
  • Address used by the node to reach a particular IP or domain (can-reach)
  • Regex to include matching interfaces (interface)

As it’s been mentioned before, the chosen method should be set through the CLI, using the --pod-network-interface-selection flag, as it is shown below:

ibmcloud oc cluster create satellite --location example-location --name example-cruiser --enable-config-admin --version 4.10.40_openshift --pod-network-interface-selection interface=eth.*

The flag is also available for ibmcloud sat location create. If the --pod-network-interface-selection is left empty for the location creation command, then the “kubernetes-internal-ip” is used for the location, and it will be the default for newly created clusters, as well. If the flag is provided for the location creation, the same setting will be inherited to the location clusters, assuming the data center has homogeneous hosts and network interfaces. Old clusters like 4.8_openshift use the mentioned old default “can-reach” method with “” set to it.

More information about the usage of the flag can be found here and here.  

Configure subnets for Satellite locations

Since the main goal of IBM Cloud Satellite is to let our customers bring their own infrastructure and then make it a managed resource by IBM, the specifics of these systems may vary. 

On any Kubernetes or Openshift cluster, there are two subnets that are treated as cluster-internal, and they should not conflict with other parts of the data center network. These are the Pod and the Service subnets.

As an example, there could be a scenario when a customer’s pre-existing service endpoint IPs or other allocated subnets are present in the data center, and they can’t be modified on their side. Therefore, to be able to use Satellite, the parameters of the IBM services should be set by the user. On the Satellite Openshift clusters, these options has been already available since the beginning, but it was missing from the infrastructure side. Now, you can define these subnets for the infrastructure. This is important when the or the subnets are already used for any purpose in the target infrastructure.

To set the parameters of the Satellite location, the --pod-subnet and --service-subnet flags should be used through the ibmcloud CLI during creation time, as shown in the below example:

ic sat location create --name example-location --managed-from dal --pod-subnet --service-subnet --coreos-enabled

This feature is only available for CoreOS-enabled locations, and there are restrictions for the subnet’s values.

More about these restrictions can be found here.


Our main goal is to deliver a product that satisfies our customer’s needs and expectations. This post introduced features give our users an opportunity to create a more customized environment that will result in a more effortless adaptation of IBM Cloud Satellite.

For more information about the above-mentioned features, please visit our official pages about the Satellite cluster create and Satellite location create.

Contact us

If you have questions, engage our team via Slack by registering here and join the discussion in the #satellite channel on our public IBM Cloud Service Slack.


More from Cloud

Kubernetes version 1.28 now available in IBM Cloud Kubernetes Service

2 min read - We are excited to announce the availability of Kubernetes version 1.28 for your clusters that are running in IBM Cloud Kubernetes Service. This is our 23rd release of Kubernetes. With our Kubernetes service, you can easily upgrade your clusters without the need for deep Kubernetes knowledge. When you deploy new clusters, the default Kubernetes version remains 1.27 (soon to be 1.28); you can also choose to immediately deploy version 1.28. Learn more about deploying clusters here. Kubernetes version 1.28 In…

Temenos brings innovative payments capabilities to IBM Cloud to help banks transform

3 min read - The payments ecosystem is at an inflection point for transformation, and we believe now is the time for change. As banks look to modernize their payments journeys, Temenos Payments Hub has become the first dedicated payments solution to deliver innovative payments capabilities on the IBM Cloud for Financial Services®—an industry-specific platform designed to accelerate financial institutions' digital transformations with security at the forefront. This is the latest initiative in our long history together helping clients transform. With the Temenos Payments…

Foundational models at the edge

7 min read - Foundational models (FMs) are marking the beginning of a new era in machine learning (ML) and artificial intelligence (AI), which is leading to faster development of AI that can be adapted to a wide range of downstream tasks and fine-tuned for an array of applications.  With the increasing importance of processing data where work is being performed, serving AI models at the enterprise edge enables near-real-time predictions, while abiding by data sovereignty and privacy requirements. By combining the IBM watsonx data…

The next wave of payments modernization: Minimizing complexity to elevate customer experience

3 min read - The payments ecosystem is at an inflection point for transformation, especially as we see the rise of disruptive digital entrants who are introducing new payment methods, such as cryptocurrency and central bank digital currencies (CDBC). With more choices for customers, capturing share of wallet is becoming more competitive for traditional banks. This is just one of many examples that show how the payments space has evolved. At the same time, we are increasingly seeing regulators more closely monitor the industry’s…