What’s New in OpenShift: a Comparison Between V3 and V4

We thought it’d be useful to highlight the most interesting new features available in a v4 cluster. If you’re already a customer, we’ll highlight the differences from v3 also.

We’ve been offering UKCloud for OpenShift as a managed service for around 3 years now, going back to early releases of version 3, when Red Hat first moved their container platform to be based on Kubernetes. We’ve recently been preparing to upgrade our customers (and our internal teams) to the latest major release of OpenShift, v4.x. This is a major milestone in OpenShift releases due to some significant changes in the architecture, deployment process and the approach to cluster operations.

It’s our intention to explore some of those changes in more detail and what this means for our workloads in future, although many of the feature changes are covered elsewhere in blog posts and videos by Red Hat themselves. For now, we thought it’d be useful to cover at a high level some of the changes we’ve been particularly interested in and the implications for our customers.

In this blog, we’ll highlight the most interesting new features available in a v4 cluster. For existing OpenShift customers, we’ll also highlight the differences from v3.

Infrastructure and operations

Operating system integration – Tight coupling of the OS and cluster versions. In v3.x of OpenShift we used the Red Hat Atomic OS, which is essentially an immutable Red Hat installation with minimal tooling installed that provides an ideal platform for container-based workloads. This still needed to be patched and managed separately to the cluster. In v4, the OS of choice will be Red Hat CoreOS, which has many similarities with Atomic in that it’s immutable and geared towards containers, however it’s tightly coupled with the cluster and all configuration of the host OS is managed through the cluster including the version of RHCOS that it runs. This removes the overhead of separate management of the underlying hosts, and enables cluster administrators to configure the host OS if required using a resource type called MachineConfigs in the cluster.

Cluster scaling – As a result of the OS integration mentioned above, the deployment and scaling of the nodes in the cluster can now be managed entirely from within the cluster. This involves creation of a machineset that represents the cluster nodes, and scaling the machineset in the same way an application might be scaled in the cluster. When the machineset gets scaled, the cluster makes API calls to the appropriate cloud provider and deploys the instances as required, booting them with the configuration that the cluster holds for the OS.

We’ve simplified this here to describe it at high level, but the detail of how to make it work is more complex. We’ll look to explore this further in a future blog post on the UKCloud Community. The key message here is that the cluster can be configured to scale out its own infrastructure which is a massive step forward compared to the v3 approach of adding machines and running Ansible from outside the cluster. It’s much, much faster as well!



Operators – much (if not all) of the cluster configuration is now held within the cluster and managed with cluster operators. These are effectively running at all times, ensuring that the configuration they expect to be applied to the cluster is there. This means that configuring almost any aspect of the cluster involves reconfiguring some configmap or secret with the cluster and waiting for the effects to be applied by the appropriate operator.

Operators themselves are relatively recent, but the hugely significant change to Kubernetes is the deployment approach. It’s worth looking into them further as they enable all kinds of configuration and application deployment and management and roll in much of the day-to-day operational management, even patching/upgrade of what’s been deployed within their scope. For more information on what an Operator is and how it’s used, take a look at this Knowledge Base article from Red Hat: https://docs.openshift.com/container-platform/4.3/operators/olm-what-operators-are.html

User experience

The most visible change for users is the new web interface, which is divided into two sections: Developer and Administrator.