Update Openshift 4.x cluster (part 1)
The latest version of the enterprise-ready Kubernetes platform
Openshift 4 is designed to address the complexity of managing container-based application in production system. It is a self-managing platform with automatic software updates and lifecycle management managed by Operator.
It features immutable infrastructure that built on Red Hat Enterprise Linux and Red Hat Enterprise Linux CoreOS for Day 2 Operation.
I have an Openshift 4.1 cluster on hand and today I will feature one of the methods: Over-the-air Updates and explain the pros and cons.
In the web console, user can choose which channel to update under Administration nav section. Initially when this cluster provisioned, it belongs to version 4.1.0 under channel stable-4.1.
My goal is to update from version 4.1 to version 4.2. I thought that I can simply update from channel stable 4.1 to channel stable 4.2, but the truth is:
I need to update from 4.1.0 -> 4.1.15 -> 4.1.25 -> 4.1.27. From version 4.1.27 under channel candidate 4.2, then I am able to choose version 4.2.
Each of the update took between 1 to 2.5 hours, which is considered fast for a cluster update.
Conclusion
The cluster has successfully been updated to version 4.2. Over-the-air Updates provide simplicity, less flexibility and fewer choices for the user.
Nonetheless, Openshift 4 provides multiple great functionalities such as Operator, Service mesh, Serverless functions like KNATIVE and KEDA that enable development and operation in Business.
I believe that more and more companies should adopt Openshift and run it in their production system.
Tips
Bear in mind, some channel may not have the installed version.
If the following error pops up, do not panic. The cluster is still updating and refreshing. Be patient.
User is unable to roll back to previous major version. Attached is the screen after updated to version 4.2, channel for version 4.1 has gone.
