Setting up a distributed hybrid cloud at the edge

To create new end-to-end edge computing solutions, you need to have a managed cloud-native infrastructure and be able to deploy and run apps consistently across a distributed cloud environment. Edge applications need to be deployed and run-on various edge nodes and need to be able to interface with multiple cloud environments.

IBM Cloud Satellite is a distributed cloud offering that enables you to consume cloud services anywhere you need them and to deploy, manage, and control workloads across on-premises environments, edge computing environments, and public cloud environments from any cloud vendor. IBM Cloud Satellite delivers cloud services, APIs, access policies, logging, and monitoring across all locations.

In Part 1 of this edge computing series, we described the key layers of an edge computing architecture including the device layer, network layer, and edge layer. In Part 2, we explored the application layer and device layer and discussed the tools that are needed to implement those two layers. In Part 3, we covered the network layer which the applications that are deployed in the other layers use to connect to backend systems and other applications that are deployed at the edge.

In these previous articles in this edge computing series, we assumed that a cloud-native infrastructure was already available to deploy an end-to-end edge computing solution. In this article, part 4, we explain how to deploy the cloud-native infrastructure that is needed for an end-to-end edge computing solution to a set of bare-metal servers at the edge. We provide the steps to use IBM Cloud Satellite to deploy this cloud-native infrastructure, including creating a new satellite location, setting up the satellite control plan, and instantiating a satellite edge cluster on a bare metal server. Then, after the infrastructure setup is completed, we will show you how to deploy edge applications by using IBM Cloud Satellite.

In this article, we show how to use IBM Cloud Satellite to provision managed OpenShift clusters on an Edge Bare Metal server to implement the use case that we described in Part 2. The implementation that we described in part 2 assumed the existence of an edge cluster, but in this article we explain how to use Satellite to provision the edge cluster. As a brief overview, this use case involves:

• Creating a machine learning visual inspection model by using tools like IBM Maximo Visual Inspection.
• These containerized models are made available as edge services on IBM Edge Application Manager.
• The IBM Cloud Satellite service is used to provision a managed Red Hat OpenShift Kubernetes Service (ROKS) cluster on a multi-access edge compute (MEC) bare metal server.
• IBM Edge Application Manager deploys the object detection model to the edge device (a smart camera on a MacBook or Jetson TX2) and deploys a Maximo Visual Inspection model (namely a hard hat detection model) to the edge cluster.
• The object detection model that is running on the edge device will start the live video stream to the MEC edge server as soon as it detects a person. The hard hat detection model running on the edge cluster will generate an alert on a custom UI if it doesn’t detect a hard hat.

Setting up the cloud-native infrastructure using IBM Cloud Satellite

In this article, we will discuss the steps to deploy the cloud-native infrastructure on the edge server. We'll discuss creating a new satellite location using the IBM Cloud Satellite service and then setting up the Satellite control plane in the location. After the Satellite control plane is set up, we will describe how to instantiate a Satellite edge cluster on the bare metal edge server.

Create a new satellite location in IBM Cloud Satellite

An IBM Cloud Satellite location represents a data center that can have any kind of infrastructure resources installed to start running IBM Cloud services on that infrastructure. Each enterprise can create multiple satellite locations, such as creating a location for each of the data centers in different parts of the world.

Each location has a local control plane where IBM Cloud Satellite manages all provisioned services and communicates back to the central Satellite control plane. The location control plane runs resources that are managed by Satellite to help manage the hosts, clusters, and other resources attached to the location. Each satellite location includes these key features:

• Satellite links provide secure network connections and help in auditing these network connections in the location.
• Satellite Config helps in deploying, managing, and controlling your apps and policies across clusters in the location.

A satellite location starts with infrastructure that runs somewhere outside IBM Cloud, such as on another cloud provider or on-premises. In our use case, our infrastructure provides the basis for the hosts and zones that builds out the satellite location. On-premises VMs and bare metal servers are used as infrastructure to the satellite location.

Follow the instructions in the IBM Cloud Satellite docs to create a satellite location from the console.

Set up the satellite control plane

After we set up the satellite location, we need to attach the hosts (the VMs or bare metal servers) that can act as the control plane and worker nodes to the Satellite location and our edge clusters.

The host systems must meet certain requirements as covered in the IBM Cloud Satellite docs. Additionally, there are a few host network requirements.

After you understand the host requirements, you can set up the control plane for your satellite location by following the steps in the IBM Cloud Satellite docs. We need to have at least 3 VMs to act as a Satellite location’s control plane nodes and ensure that they match these host requirements. You can follow the instructions in the IBM Cloud Satellite docs to add the hosts to your satellite location. If your hosts are replacing existing hosts, then you might have multiple hosts with the same machine-id. Generally, cloned VMs have the same machine-ids. We need to make sure to change the machine-ids before we attach the nodes to the satellite location to ensure that the network identities are unique. If you run into issues with your hosts not attaching, refer to the troubleshooting information in the IBM Cloud Satellite docs.

After the three hosts are attached to a Satellite location, we assign them to the different zones to set up the satellite control plane. See the following image that describes the architecture for our use case. After the Satellite control plane is set up, we’ll add the bare metal server to the Satellite location and instantiate the ROKS cluster on it.

Instantiate the Satellite edge cluster

In part 2 of our edge computing series, we assumed that a Red Hat OpenShift cluster existed at the edge. In this article, we describe how you can use IBM Cloud Satellite to provision managed OpenShift clusters on a bare metal server on the edge.

Now that we set up the Satellite control plane, we can provision Red Hat OpenShift Kubernetes Service (ROKS) clusters by attaching additional hosts to the satellite location. We attach our own bare metal server to the satellite location and use it as the infrastructure to provision these edge clusters. Our Satellite control plane will act as primary nodes and configure the worker nodes of ROKS clusters on the bare metal server.

Once the cluster is created, the Satellite control plane will automatically assign the nodes that match compute requirements as worker nodes to the ROKS edge cluster. The Satellite control plane will provision the worker nodes on the bare metal server and then set up the ROKS edge cluster.

This cloud-native environment was set up using the IBM Cloud Satellite UI, but it can also be implemented using APIs. There are API endpoints for IBM Cloud Satellite that can be used to perform various functions on IBM Cloud Satellite.

Deploy applications to the edge cluster using Satellite Config

After we provision the ROKS cluster, the applications and models need to be deployed on this bare metal edge server as required by the use case. These applications can be deployed on to the edge server by using either IBM Edge Application Manager or IBM Cloud Satellite Config. We described how to deploy an application using IBM Edge Application Manager in part 2 of this edge computing series. In this article, we describe how to deploy applications to edge clusters using Satellite Config.

The high-level process flow for deploying applications using IBM Cloud Satellite involves creating a satellite configuration, then creating a cluster group, and then finally creating a subscription.

1. Create a Satellite configuration.

   A Satellite configuration lets us upload or create Kubernetes resource YAML file versions that can then be deployed to a group of Red Hat OpenShift on IBM Cloud clusters.

   In our use case, we have a satellite configuration setup to deploy the custom UI and models. In this scenario, a Satellite configuration named edge-config was created that helps deploy the custom UI on the ROKS edge cluster.

   

2. Add a version to the configuration.

   A version represents a Kubernetes resource YAML file that you uploaded or manually created for a Satellite configuration. You can include any Kubernetes resource in your version and upload as many versions to a configuration as you like.

   In this step, we’ll create a version in the configuration called edge-ui-version that describes the UI application yaml file to be deployed on the ROKS cluster. This version (yaml file) is added to the satellite configuration edge-config.

   

3. Create a cluster group.

   A cluster group specifies a set of Red Hat OpenShift on IBM Cloud clusters that are registered with the Satellite Config component and that are included in a Satellite configuration. Cluster groups are used to group clusters together to be able to deploy the versions. We created a cluster group called edge-ui-clustergroup.

   

4. Add the satellite cluster to the cluster group.

   Red Hat OpenShift on IBM Cloud clusters that run in your location are automatically registered and can be added to a cluster group. Clusters that run in IBM Cloud must be manually registered with the Satellite Config component before you can add them to a cluster group.

   

5. Create a subscription.

   A Satellite subscription is created for a Satellite configuration and specifies which version of the Kubernetes resource that you uploaded is deployed to one or more cluster groups.

   The Satellite subscription ties it all together and deploys the applications including our custom UI and models on to the ROKS edge cluster. The subscription edge-ui created in the configuration edge-config deploys the version edge-ui-version to all the clusters in the cluster group edge-ui-clustergroup.

   

6. Review the subscription status.

   The subscription will deploy the applications specified in the YAML file of the version to the assigned clusters. The status of this deployment is displayed in the Rollout Status tab on the subscription page.

Similarly, all the other applications that are needed to realize this use case are deployed using these same steps using Satellite Config. We use Satellite Config to set up the environment and deploy the application layer.

Conclusion

In this article, we explained how to use IBM Cloud Satellite to set up a Red Hat OpenShift cluster on a bare metal edge server. These steps include creating a satellite location, followed by setting up of the control plane, and then creating the ROKS edge cluster. By using IBM Cloud Satellite to provision OpenShift clusters, you have a single management and operations experience, irrespective of the location of the edge server. We also covered deploying applications on the edge server using Satellite config.

With the four articles in this edge computing series, you should be able to start with a bare metal server, create an OpenShift cluster, provision the network layer, and deploy the applications of the application layer on to edge devices and edge servers.