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 “www.ibm.com” 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 “ibm.com” 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 172.20.0.0/16 or the 172.16.0.0/16 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 172.16.0.0/16 --service-subnet 172.23.0.0/16 --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.

Conclusion

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.