Embrace Red Hat OpenShift’s External Platform for faster onboarding
Here in this blog, we will learn about Embrace Red Hat OpenShift’s External Platform for faster onboarding
When it comes to setting up a Red Hat OpenShift cluster, OpenShift users are spoiled for choice. OpenShift offers integrations to facilitate your installation process whether you choose to install on-premises, in the cloud, or to your own hybrid configuration. With great pleasure, we now introduce the external platform, a new kind of platform that will allow partners to attain different degrees of integration that were not previously achievable in OpenShift.
What is the External Platform?
Deep infrastructure customization is possible with the new OpenShift configuration known as the external platform. The external platform gives partners the option to run their own infrastructure management components, while integrated platforms like AWS, GCP, or OpenStack install components unique to those providers. This indicates that it’s getting simpler to integrate cloud provider components with OpenShift.
In the past, OpenShift required components to be added to the source code and release artifacts in order to implement new platform types. The integration process would have taken a full release cycle or longer to finish under the previous method. The external platform eliminates the need for modifications to the OpenShift source code in this process, and partners maintain ownership of their own release and lifecycle management components. As a result, partners can add infrastructure components using a self-service method offered by the external platform.
How Is Integration Made Easier by External Platform?
OpenShift’s tooling installs infrastructure-related components automatically when it is installed on one of the integrated cloud providers that are included, like Azure, Nutanix, and vSphere. These components, which carry out provider-specific actions to enable specific infrastructure behavior for Kubernetes, can include Cloud Controller Managers, Container Storage Interface drivers, and Machine API providers. By using the external platform, OpenShift is notified that the infrastructure layer components might be changed. As a result, OpenShift needs to adjust the system so that the new components can perform the required functionality.
Given that no infrastructure-related components are installed by default, the external platform cluster and the agnostic platform cluster—also known as none—look similar in some ways. The details make all the difference. OpenShift offers configuration options that let the user tell OpenShift which components to install when installing on an external platform. The cluster then expresses the configuration options as modifications to the internal behaviors of core infrastructure operators. For instance, OpenShift will know to deploy the kubelets with the required flags to communicate with cloud controller managers when you configure an external platform cluster to use them.
Over Oracle Cloud Infrastructure with Red Hat OpenShift
As an illustration of our use of external platforms, consider Oracle Cloud Infrastructure (OCI) and OpenShift enabled. In collaboration with Oracle, we have streamlined the process for our clients to deploy OpenShift on OCI by utilizing an external platform. This solution enables our joint clients to quickly modernize their applications and create best-in-class cloud native solutions.
Turning on cloud native Oracle Cloud Infrastructure storage
You need to understand how container storage interface drivers (CSI) function and how they interact with zonal and regional data on Kubernetes nodes in order to understand how we’ve made it simpler to install OpenShift on OCI using the external platform. Since the 1.13 release, Kubernetes has supported the CSI standard. By making it possible for cloud storage interfaces to be added to most clusters as a “day 2” operation, CSI drivers contributed to the advancement of the Kubernetes user community. This eliminates the need for cloud storage providers to merge code into the Kubernetes core; instead, they can now develop and maintain their own drivers.
To enable appropriate scheduling on infrastructures that use geographical awareness, node and persistent volume resources in Kubernetes operating a CSI driver must be labeled with the zone and region in which they physically exist. Usually, the cloud controller manager (CCM) handles the labeling process. It takes some familiarity with the deployment and the necessary privileges to run the controller so that it can read and modify node objects in order to operate a CCM inside a Kubernetes cluster. An operator oversees CCMs on OpenShift, setting up permissions and keeping an eye out for errors in the controllers that are currently in use.
While CSI drivers can be installed on OpenShift via the operator catalog or user interaction, CCMs are not amenable to this method. Before the system will recognize the CCMs, some modifications have to be made to the core Kubernetes command line flags. OpenShift is instructed by the external platform feature to identify partner CCMs and set up Kubernetes accordingly. Oracle is able to deploy OpenShift on OCI using their own CCM by utilizing the external platform’s CCM feature. This also allows their CSI driver to function properly. As a result, all of the advantages of the native OCI storage are available to clusters that are deployed on OCI using the external platform.
How to Begin Using an External Platform
The steps for installing a cluster on any platform are similar to those for creating a cluster on an external platform. Set up the required infrastructure for OpenShift installation first, following the instructions in the product documentation.
Make sure the installation configuration file is manually created before executing the “openshift-install” command. Once this file has been created, change the following fields to reflect the external platform:
To identify the provider platform, the “platformName” field must contain a string, such as “OCI” for Oracle Cloud Infrastructure.
You must then produce the installation manifests. It is possible to enable or disable support for cloud controller managers by creating these manifests. To generate the manifests, execute the subsequent command:
The “install-config.yaml” file will be used by this command to create the “manifests” and “openshift” directories. The cluster’s configuration data is contained in a file called “cluster-infrastructure-02-config.yml,” which can be found in the “manifests” directory.
You must add the following fields to the “cluster-infrastructure-02-config.yml” file if you intend to run your own CCM:
The following should be entered in the fields if you do not intend to run your own CCM:
You are almost ready to begin the installation after making changes to “cluster-infrastructure-02-config.yml”. Keep in mind that you will also be responsible for overseeing the pods’ deployment within OpenShift if you have chosen to use CCMs. To accomplish this, add a manifest to the “manifests” directory prior to installing the software. You are prepared to begin the installation after you have added any additional manifests that you may require.
By querying the infrastructure configuration object in your new cluster, you can verify that the installation of the external platform was successful.
What Comes Next?
The external platform was first made available in OKD 4.13 and OpenShift 4.13. When the external platform is configured, OpenShift 4.14 adds the ability to add a partner’s cloud controller manager. We will be adding more examples of how to use this new platform type and actively documenting its usage. We will add more CITs (continuous integration tests) to test this kind of platform on a range of infrastructures.
We invite and encourage partners, cloud providers, and platform operators to investigate the possibility of installing OpenShift clusters using infrastructure-aware components without requiring deep integrations through the external platform.
