Whether you’ve already chosen OpenShift as your potential Kubernetes platform or you’ve only seen it in industry announcements, the best way to know if it’s for you is to try it out by deploying a full cluster. If you’re a developer, however, this may be overkill. For basic validation, you can use CRC (Code Ready Containers), which is a single-node version that can be integrated into your local workflow.
When deploying a full cluster with an offering as complicated as OpenShift, there are several things that you need to take into consideration. First and foremost, though, you have to understand what OpenShift is and what it does.
Red Hat OpenShift Container Platform is the leading enterprise Kubernetes distribution.
That’s because it has been a part of the Kubernetes open source community from its inception, and it has built on Kubernetes by bundling all of the components that an enterprise needs to get started with containerized applications. The OpenShift distribution starts with pure upstream Kubernetes and integrates additional open source projects into a supported platform. These products provide hundreds of additional function points including enhanced RBAC, Single Sign-on, CI/CD pipelines, a private registry, and a web console. The goal of OpenShift is to offer a consistently managed and provisioned platform that provides developers with the same experience no matter which type of infrastructure they use. This allows for seamless migration and growth from private clouds to hybrid and multi-cloud infrastructures.
Which Type of Installer? (IPI vs. UPI)
OpenShift 4 has two types of installers, but each does not work with every type of infrastructure. This may seem like it complicates things, but the goal is to provide the most flexibility to customers while simplifying the actual installation. This is a significant improvement over OpenShift 3, which had an Ansible-based installer that worked on every supported platform, but needed hundreds of flags to get it going.
In order to install OpenShift, you’ll need to choose between an Installer-Provisioned Infrastructure (or IPI) and a User-Provisioned Infrastructure (or UPI).
The IPI option installs OpenShift in a very opinionated way. It creates and configures all components of the underpinning infrastructure from the virtual network to the load-balancers.
The UPI option is used in two situations: the first is when the opinionated configuration doesn’t support an internal requirement (such as the need to reuse an existing virtual network). The second is when your chosen platform doesn’t have all of the options that are needed to fully deploy OpenShift. This is the case mainly with on-premises deployments in which VMware and Bare Metal do not have load-balancers or DNS servers to be configured.
Using an IPI installer on a cloud platform is by far the easiest way to get started.
Pick Your Base Infrastructure
Now that you understand the different types of installers, you can pick your base infrastructure.
There are supported IPI installers for:
- AWS
- Azure
- GCP
- OpenStack
There are supported UPI installers for:
- AWS
- Azure
- GCP
- KVM
- VMware
- Bare metal
Configure the Prerequisites and Run the Installer
Both IPI and UPI installers have prerequisites that need to be met before any installation can take place. For an IPI installer, this usually means creating the service account and assigning the correct roles so that it has access to do everything required to complete the installation.
For a UPI installer, there will be additional steps outlined in the documentation; these can be anything from installing the OS to setting DNS and load-balancer requirements. The UPI installer does not have much tolerance for misconfigurations. As a handy tip, you should make sure that all systems have hostnames assigned to their IP addresses and the time is synced (Etcd will work much better this way).
Once you’ve finished this step, download the openshift-installer for your infrastructure of choice, perform any additional configurations specified in the official documentation, and run the installer.
You will have a cluster up and running in about 45 minutes.
Day Two Operations and Next Steps
OpenShift has enough functionality built in that most enterprises will be able to begin working with containerized applications as soon their cluster is up and running. However, OpenShift does not provide industry-leading solutions for every aspect of running in production. For example, the open source products that enable out-of-the-box monitoring and reporting have limitations when it comes to alerting, scalability, and creating a holistic view across all aspects of the platform. Red Hat relies on partners like Broadcom to provide best-of-breed solutions to fill these gaps. AIOps from Broadcom enables better deep-dive analysis, a holistic view across multiple clusters, and machine learning capabilities to discover trends before they become problems.
To learn more about how Broadcom is positioned to monitor OpenShift, check out the partner brief: Broadcom Improves the Performance of OpenShift Applications.
