OpenShift 3.x has been around for a long while and it does pretty much everything you need to run your applications. But if you are still using it today, there is a good chance that some of the advanced features released in later versions are not available to you.
OpenShift Container Platform 3.x is no longer supported as of May 31, 2020, and OpenShift Container Platform 4.x will be the latest supported version. Red Hat charges quite a fee for Extended Life Cycle Support (ELS) on OCP 3.x which consists of limited continued support and updates from Red Hat. This means that if you are still using OpenShift 3.x, then you are going to have trouble keeping up with security patches and bug fixes as they become available over time only for OCP 4.x without subscribing for the costly ELS!
OpenShift 4.x is a major overhaul that brings many new features and improvements over its predecessor, such as:
Improved Kubernetes integration: With OpenShift 4.x comes improved Kubernetes support with an integrated agent running in each pod that allows users to manage their clusters directly through the web console (instead of having to SSH into them). This means less time spent managing clusters and more focus on developing applications or building infrastructure components instead!
Improved CI/CD capabilities: If you have used Gitlab CI/CD before then this feature should be familiar – it gives developers access directly from their workstation via webhooks when projects are deployed or updated with new versions so they can see exactly what happened during deployment without having any knowledge about how such actions occur within OpenShift itself.
In this post, we have discussed in detail, the reasons why you should consider upgrading from 3.x to 4.x right away.
Version Support: v3.x is out of support as of May 31, 2020, which means you can still use OpenShift 3.x, but it is no longer being supported by Red Hat. OpenShift 4.x is the latest supported version of OpenShift, and as such 3.x can face many challenges due to bugs and the version is outdated, but in 4.x, continuous bug fixes and enhancements will be available.
Patching: If you are still using OpenShift 3.x, your containerized applications are likely exposed to a plethora of security vulnerabilities, since they would not be receiving any new patches. The first two versions of OpenShift 3.x were vulnerable to a remote code execution vulnerability that allowed an attacker to hijack the execution flow of an application and take over its control.
OpenShift 4.x has been patched for this issue, but it works only if you are running a Kubernetes cluster with version 1.7 or later installed on top of Kubernetes 1.6 or later (Kubernetes-v1).High ELS fee: OpenShift 3.x has been around for a while and Red Hat is still charging quite a hefty fee for Extended Life Cycle Support (ELS). ELS is what you pay if your OpenShift 3 cluster needs maintenance or upgrades after its initial release. You can easily bypass this fee by upgrading to 4.x.
Ease of installation: In OpenShift 3.x, you prepare your Red Hat Enterprise Linux (RHEL) hosts, set all of the configurations values your clusters need and finally run an Ansible playbook to install and set up your clusters. In OpenShift Container Platform 4.x, you use the specific OpenShift installation program to create a minimum set of resources that are required for each cluster. Once the cluster is up and running, you can use Operators to configure your cluster further and install new services as needed.
Operator Framework: OpenShift 4.x introduces a new Operator Framework that simplifies the deployment of containerized applications and automates operational tasks, improving cluster availability while reducing operational costs and complexity. You can now deploy your application in any environment supported by OpenShift 4.x using the same process as you would using OpenShift 3.x:
- Create a new project (or select an existing one) with a single command
- Go through the steps in their UI to add it to your cluster YOU
Click here for OpenShift 30-Day Free Trial Support
OS integration: In v3.x of OpenShift we had the Red Hat Atomic OS, which was essentially an immutable Red Hat installation with very minimal tooling installed, that provided an ideal platform for container-centric workloads. This still needed separate patching and management. In v4.x, the OS of choice is Red Hat CoreOS, which has quite a few similarities with Atomic in that it is immutable and geared towards containers, however it is tightly coupled with the cluster and all configurations of the host OS is managed through the clusters including the version of RHCOS that it is running. This removes the overhead of separately managing the underlying hosts and enables the cluster administrators to configure the host OS as required using a resource type called MachineConfigs in the cluster.
Cluster scaling: As a result of the OS integration mentioned in point 6, the deployment and scaling of the nodes in the clusters can be managed entirely from within the cluster in v4.x. This involves creating a machine set that represents the cluster nodes and scaling the machine set in a similar way as a cluster application. When the machine set gets scaled, the cluster can make API calls to the appropriate cloud providers and deploy the instances as required, booting them with the required configuration the cluster holds for the OS. From a high-level view, the key takeaway here is that the clusters can be configured to scale out their own infrastructures which is a massive step forward compared to the 3.x approach of adding machines and running Ansible from outside the clusters. It is much faster as well.
Operators: Most of the cluster configuration in v4.x is held within the clusters and managed with cluster operators. These effectively run continuously, ensuring that the configuration they expect to be applied to the cluster is there. This means that configuring almost any aspect of the clusters involves reconfiguring some config map or secret with the clusters and waiting for the effects to be applied by the appropriate operators. The operators themselves are quite recent, but the hugely significant change to Kubernetes is the deployment approach they bring. They enable all kinds of configurations and application deployments and management and are involved in much of the day-to-day operational management, even patching/upgrading what has been deployed within their scope.
User experience: The most visible change for end users is the new web interface in v4.x, which is divided into two sections nowadays, Developer and Administrator.
The former is for developers to manage their own apps and containers while the latter is where you can manage all users and groups, deploy apps, scale your stack using PostgreSQL or Redis databases (among others), monitor its performance through metrics collection as well as create custom reports based on those metrics data points collected by your application(s).
Additionally, there’s also a new feature called “deploy” which allows you to push code changes directly from GitHub without having to build them first—and all this without needing any special permissions on your server!
- Ease of containerization:3.x is deployed on top of RHEL OS, while 4.x is deployed on top of RHCOS which is specially designed for containerized applications.
BONUS:
Ease of degradation: In OpenShift Container Platform 3.x, you upgrade your cluster by running Ansible playbooks but in OpenShift Container Platform 4.x, the clusters manage their own updates, including updates to RHEL CoreOS (RHCOS) on cluster nodes.
Storage: Red Hat OpenShift Container Storage 3 is available for use with the OpenShift Container Platform 3.x, which uses Red Hat Gluster Storage as the backing storage. On the other hand, Red Hat OpenShift Container Storage 4 is available for use with OpenShift Container Platform 4, which uses Red Hat CEPH Storage as the backing storage.
User authentication: In OpenShift Container Platform 3.x, it was possible for an unauthenticated user to access the discovery endpoints. In 4.x unauthenticated access to the discovery endpoints is not allowed. If you do need to allow unauthenticated access, you can configure the RBAC settings as required.
Pods: You need to spin pods for monitoring, logging and CI/CD Pipeline in OpenShift 3.x but in 4.x, in-built operators for monitoring, logging and CI/CD Pipeline make pods unnecessary.
On top of all of the above, OpenShift 3.x does not have to enable technology like Machine Learning, Cloud-Native apps and Containers as a Service (CaaS), all of which, are available in 4.x. In fact, there are over 1,000 Compose files available for deployment in the Red Hat Marketplace ready to be used with OpenShift 4.x.
So, if you are still using OCP 3.x and have not upgraded yet, then it’s definitely high time to do it!
This article was originally published on our company blog.
Top comments (2)
Great points! The improved Kubernetes integration and enhanced CI/CD capabilities in OpenShift 4.x are compelling reasons to upgrade halloween squishmallows 2024. Thanks for the detailed breakdown.
Upgrading to OpenShift 4.x is crucial for continued support and access to the latest features and security updates. Staying on 3.x could mean missing out on important improvements and facing higher costs for extended support click.