5 minute read

How to perform an OCP4 upgrade from the CLI safe, securely and fully CLI executed?

Let’s take a look!


The OpenShift Container Platform update service is the hosted service that provides over-the-air updates to both OpenShift Container Platform and Red Hat Enterprise Linux CoreOS (RHCOS). It provides a graph, or diagram that contain vertices and the edges that connect them, of component Operators.

The Cluster Version Operator (CVO) in your cluster checks with the OpenShift Container Platform update service to see the valid updates and update paths based on current component versions and information in the graph. When you request an update, the OpenShift Container Platform CVO uses the release image for that update to upgrade your cluster. The release artifacts are hosted in Quay as container images.

Upgrade channels are tied to a minor version of OpenShift Container Platform. For instance, OpenShift Container Platform 4.2 upgrade channels will never include an upgrade to a 4.3 release. This strategy ensures that administrators explicitly decide to upgrade to the next minor version of OpenShift Container Platform.

OpenShift Container Platform 4.2 offers the following upgrade channels:

  • Stable: This channel contains releases as soon as their errata are published, releases are added to the stable channel after a delay of several hours to a day.

  • Fast: This channel is updated with new versions as soon as Red Hat declares the given version as a general availability release.

  • Candidate: Release candidates contain all the features of the product but are not supported. Use release candidate versions to test feature acceptance and assist in qualifying the next version of OpenShift Container Platform.

Planning the upgrade - Graph Upgrade

For take a view in the upgrade plan before to start to upgrade process, there is a useful tool to visualize this path in a SVG format:

curl https://raw.githubusercontent.com/pamoedom/ocp4upc/master/ocp4upc.sh > ocp4-upgrade-checker.sh
chmod +x ocp4-upgrade-checker.sh

Generate the graph for your current OpenShift 4 version.

./ocp4-upgrade-checker.sh 4.2.2
[INFO] Checking prerequisites... [OK]
[INFO] Checking if '4.2.2' (amd64) is a valid release... [OK]
sed: -e expression #1, char 8: unterminated `s' command
sed: -e expression #1, char 8: unterminated `s' command
[INFO] Result exported as 'stable-4.3.svg'
[INFO] Result exported as 'fast-4.3.svg'

Open the graph with an SVG visualizer (e.g. firefox).

firefox stable-4.3.svg

The edges in the graph show which versions you can safely update to, and the vertices are update payloads that specify the intended state of the managed cluster components. For the example graph before, the upgrade will be performed to 4.2.29 and then to 4.3.13.

  • Minor target version: 4.2.29
  • Major target version: 4.3.13

Check your cluster health

Before to start your upgrade, verify that everything is ok in your cluster:

First of all, check that all nodes are in a Ready status.

$ oc get nodes
NAME                     STATUS   ROLES          AGE   VERSION
master0.ocp4.rglab.com   Ready    master         31d   v1.14.6.+7e13ab9a7
master1.ocp4.rglab.com   Ready    master         31d   v1.14.6.+7e13ab9a7
master2.ocp4.rglab.com   Ready    master         31d   v1.14.6.+7e13ab9a7
worker0.ocp4.rglab.com   Ready    infra,worker   31d   v1.14.6.+7e13ab9a7
worker1.ocp4.rglab.com   Ready    infra,worker   31d   v1.14.6.+7e13ab9a7
worker2.ocp4.rglab.com   Ready    infra,worker   31d   v1.14.6.+7e13ab9a7
worker3.ocp4.rglab.com   Ready    worker         9d    v1.14.6.+7e13ab9a7
worker4.ocp4.rglab.com   Ready    worker         9d    v1.14.6.+7e13ab9a7
worker5.ocp4.rglab.com   Ready    worker         9d    v1.14.6.+7e13ab9a7
worker6.ocp4.rglab.com   Ready    worker         9d    v1.14.6.+7e13ab9a7
worker7.ocp4.rglab.com   Ready    worker         9d    v1.14.6.+7e13ab9a7

Verify the current status version is available and there is no upgrade in progress.

$ oc get clusterversion
version   4.2.2    True        False         10d     Cluster version is 4.3.12

Ensure the cluster is healthy and the upgrade can be performed checking that all operators are available, none of them should be degraded.

$ oc get clusteroperators
NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.2.2    True        False         False      31d
cloud-credential                           4.2.2    True        False         False      31d
cluster-autoscaler                         4.2.2    True        False         False      31d
console                                    4.2.2    True        False         False      10d
dns                                        4.2.2    True        False         False      31d
image-registry                             4.2.2    True        False         False      10d
ingress                                    4.2.2    True        False         False      31d
insights                                   4.2.2    True        False         False      31d
kube-apiserver                             4.2.2    True        False         False      31d
kube-controller-manager                    4.2.2    True        False         False      31d
kube-scheduler                             4.2.2    True        False         False      31d
machine-api                                4.2.2    True        False         False      31d
machine-config                             4.2.2    True        False         False      10d
marketplace                                4.2.2    True        False         False      10d
monitoring                                 4.2.2    True        False         False      9h
network                                    4.2.2    True        False         False      31d
node-tuning                                4.2.2    True        False         False      10d
openshift-apiserver                        4.2.2    True        False         False      9h
openshift-controller-manager               4.2.2    True        False         False      31d
openshift-samples                          4.2.2    True        False         False      10d
operator-lifecycle-manager                 4.2.2    True        False         False      31d
operator-lifecycle-manager-catalog         4.2.2    True        False         False      31d
operator-lifecycle-manager-packageserver   4.2.2    True        False         False      10d
service-ca                                 4.2.2    True        False         False      31d
service-catalog-apiserver                  4.2.2    True        False         False      31d
service-catalog-controller-manager         4.2.2    True        False         False      31d
storage                                    4.2.2    True        False         False      10d

Check the latest updates available to the cluster.

$ oc adm upgrade
Cluster version is 4.2.2



Upgrade to latest version in a channel

If the minor target version (4.2.29) is not available, upgrade to the latest available version until it is available.

$ oc adm upgrade --to-latest
Updating to latest version 4.2.14

Monitor the upgrade each 10 seconds until it is 100% complete.

$ watch -n 10 "oc adm upgrade && oc get co && oc get nodes -o wide"
Every 10.0s: oc adm upgrade && oc get co && oc get nodes -o wide

 info: An upgrade is in progress. Working towards 4.2.14: 13% complete

Once the upgrade is completed, check again if the latest updates available contain the minor target version (4.2.29).

$ oc adm upgrade
Cluster version is 4.2.14



Because it does not contain the minor target version, the upgrade must be done to a version that allows an upgrade to the minor target version according to the upgrade plan graph (e.g. 4.2.26).

$ oc adm upgrade --to="4.2.26"
Updating to 4.2.26

Finally, upgrade the cluster to the minor target version.

$ oc adm upgrade --to="4.2.29"
Updating to 4.2.29

Upgrade to next channel version

The clusterversion CR handles the upgrades for a certain channel based on the .spec.channel field.

Update this field to use the stable-4.3 channel.

$ oc patch clusterversion version --type="merge" -p '{"spec":{"channel":"stable-4.3"}}'

Check the updates that are available for this channel.

$ oc adm upgrade
Cluster version is 4.2.29



Upgrade to the major target version.

$ oc adm upgrade --to="4.3.13"
Updating to latest version 4.3.13

And that it’s, after that you have your OCP4 cluster in the latest version available in this moments.

NOTE: Opinions expressed in this blog are my own and do not necessarily reflect that of the company I work for.

Happy OpenShifting!