Big Shift

Homogeneous Platform

Particular importance is paid to a homogeneous platform; each step has a Red Hat tool, so you don't have any additional manual work above the initial installation. Red Hat distinguishes between installer-based setups and user-based setups.

The installer approach is far more automated and currently only covers one special case. If you want to run OpenShift in AWS, you can use the Red Hat OpenShift Cluster Manager [2] and roll out OpenShift directly to AWS. This option is convenient because the Cluster Manager only needs valid AWS credentials. The rest is fully automated – including high availability and other essential details.

Unfortunately, Red Hat does not offer similar convenience on other cloud platforms, such as Microsoft Azure and the Google Kubernetes Engine (GKE). GKE should be available from OpenShift 4.2 or, in the case of OpenStack, OpenShift 4.3.

The user-provisioned approach is less automatic. To begin, you download an installation program that currently supports macOS and Linux and create a bootstrap node, which in turn becomes the nucleus of the future OpenShift installation.

Whether it is bare metal, a VM in Azure, or a KVM VM on a private OpenStack installation is irrelevant from OpenShift's point of view; the installation routine works without problems on all these platforms.

A new OpenStack tool, Ignition, runs on the OpenShift installation control plane servers and allows the installation of new systems. Ignition is one of the tools that comes directly from CoreOS. I will look more at the components inherited from CoreOS later.

RHEL or CoreOS?

When rolling out a new OpenShift environment, you encounter one of the central changes in v4.1 for the first time. No, that's not a typo: OpenShift 4.0 never officially existed. What Red Hat currently markets as OpenShift 4 has been version number 4.1 from the outset. Whatever the numbering scheme, RHEL CoreOS first appeared on the scene in series 4. In fact, Red Hat bought CoreOS in early 2018. Now it becomes clear why: In OpenShift, CoreOS is now considered the first choice of operating system on the cloud node.

Red Hat explicitly points out that you can also use RHEL – as long as it is RHEL 7. OpenShift does not yet know how to handle RHEL 8. However, a setup with RHEL at its heart does not make much sense. The purpose of containers is to keep the main system as clean as possible. Clean in this context also means maintenance free, and a system that runs nothing but a kernel, a few basic libraries, and a container run time is far easier to maintain than a full-blown RHEL.

The CoreOS developers thus established their distribution as a lightweight container operating system without any bells and whistles. By first purchasing CoreOS and now establishing it as the preferred system for nodes in OpenShift, Red Hat is continuing along this path.

Another practical effect is that Kubelet, a part of CoreOS, is rolled out in the basic installation, and Kubelet is precisely the service that turns any Linux system into a Kubernetes node with the ability to start containers.

Even More CoreOS

Red Hat has adopted not only the CoreOS distribution, but the company itself. CoreOS also had some other components in the pipeline, which are now also consistently finding their way into OpenShift. Tectonic, for example, was the management layer developed by CoreOS for Kubernetes, which in OpenShift 4 replaces some of Red Hat's in-house offerings. The OpenShift Cluster Manager mentioned earlier is a Tectonic component.

Another example of substitutions is Quay, the container registry developed for CoreOS, which is now used in the new OpenShift version and replaces another Red Hat development (the old registry). The reason for the recent Red Hat shopping spree is now evident: The Kubernetes implementation of earlier OpenShift versions and the old registry had apparently been identified as weak points.

The CoreOS purchase added more powerful components that will successively replace the old products. Although it probably won't affect your work as an admin, it will lead to more stability and performance behind the scenes.

Together with CoreOS, OpenShift also gets a new rollout mechanism for updating the installation nodes. In future, you will be able to manage the nodes by using OpenShift just like the containers belonging to your own virtual environment, made possible by over-the-air updates. OpenShift uses rpm-ostree to apply changes to the systems atomically and automatically (Figure 2).

Figure 2: The OpenShift developers promise over-the-air updates in version 4. OpenShift inherits most of the functionality from CoreOS, but integrates it into the GUI. ©Red Hat