Learn how to – How To Upgrade From OpenShift 4.8 To 4.9

Learn how to – How To Upgrade From OpenShift 4.8 To 4.9.

Red Hat OpenShift Container Platform is a powerful platform created to provide IT organizations and developers with a hybrid cloud application platform. With this secure and scalable platform, you’re able deploy containerized applications with minimal configuration and management overhead. In this article we look at how you can perform an upgrade from OpenShift 4.8 To OpenShift 4.9.

The OpenShift Container Platform 4.9 is supported on Red Hat Enterprise Linux CoreOS (RHCOS) 4.9, as well as on Red Hat Enterprise Linux (RHEL) 8.4 and 7.9. Red Hat recommends you run RHCOS machines on the the control plane nodes, and either RHCOS or RHEL 8.4+/7.9 on the compute machines.

The Kubernetes version used in OpenShift Container Platform 4.9 is 1.22. In Kubernetes 1.22, a significant number of deprecated v1beta1 APIs were removed. There was a requirement introduced in OpenShift Container Platform 4.8.14 that requires an administrator to provide a manual acknowledgment before being able to upgrade the Cluster from OpenShift Container Platform 4.8 to 4.9. This helps to prevent issues after an upgrade to OpenShift Container Platform 4.9, where removed APIs are still in use by workloads and components in the Cluster.

Removed Kubernetes APIs in OpenShift 4.9

The following is a list of deprecated v1beta1 APIs in OpenShift Container Platform 4.9 which uses Kubernetes 1.22:

You are required to migrate manifests and API clients to use the v1 API version. More information on deprecated APIs migration can be found in the Official Kubernetes documentation.

1) Evaluate OpenShift 4.8 Cluster for removed APIs

It is a responsibility of Kubernetes/OpenShift Administrator to properly evaluate all Workloads and other integrations to identify where APIs removed in Kubernetes 1.22 are in use.

Ensure you’re on OpenShift Cluster 4.8 before trying to perform an upgrade to 4.9. The following commands helps you identify OCP release

$ oc get clusterversions.config.openshift.io
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.8.15    True        False         5h45m   Cluster version is 4.8.15

You can then use the APIRequestCount API to track API requests – if any of the requests is using one of the removed APIs.

The following command can be use to identify APIs that will be removed in a future release but are currently in use. Focus on the REMOVEDINRELEASE output column.

$ oc get apirequestcounts
NAME                            REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
ingresses.v1beta1.extensions    1.22               2                       364

The results can be filtered further by using -o jsonpath option:

oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"t"}{.metadata.name}{"n"}{end}'

Example output:

$ oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"t"}{.metadata.name}{"n"}{end}'
1.22	ingresses.v1beta1.extensions

With API identified, you can examine the APIRequestCount resource for a given API version to help identify which workloads are using the API.

oc get apirequestcounts <resource>.<version>.<group> -o yaml

Example for the ingresses.v1beta1.extensions API:

$ oc get apirequestcounts  ingresses.v1beta1.extensions
NAME                           REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
ingresses.v1beta1.extensions   1.22               3                       365

Migrate instances of removed APIs

You can get more information on migrating removed Kubernetes APIs, see the Deprecated API Migration Guide in the Kubernetes documentation.

2) Acknowledge Upgrade to OpenShift Container Platform 4.9

After the evaluation and migration of removed Kubernetes APIs to v1 is complete, as an OpenShift Administrator you can provide the acknowledgment required to proceed.

WARNING: It is a sole responsibility of administrator to ensure all uses of removed APIs is resolved and necessary migrations performed before providing this administrator acknowledgment.

Run the following command to acknowledge that you have completed the evaluation and cluster can be upgraded to OpenShift Container Platform 4.9:

oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.8-kube-1.22-api-removals-in-4.9":"true"}}' --type=merge

Expected command output:

configmap/admin-acks patched

3) Begin Upgrade from OpenShift 4.8 To 4.9

Login to OpenShift Web Console and navigate to Administration → Cluster Settings > Details

Click on “Channel” and update channel to fast-4.9 or stable-4.9.

Select fast-4.9 orstable-4.9 from the list of available channels.

Channel can also be changed from the command line with below command syntax:

oc adm upgrade channel clusterversion version --type json -p '[{"op": "add", "path": "/spec/channel", "value": "<channel>”}]'

Where <channel> is replaced with either;

• stable-4.9
• fast-4.9
• candidate-4.9

New cluster updates should be visible now. Use the “Update” link to initiate upgrade from OpenShift 4.8 to OpenShift 4.9.

Select the new version of OpenShift 4.9 that you’ll be upgrading to.

The update process to OpenShift Container Platform 4.9 should begin shortly.

You can also check upgrade status from CLI:

$ oc get clusterversions.config.openshift.io
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.8.15    True        True          2m26s   Working towards 4.9.0: 71 of 735 done (9% complete)

Output once all the upgrades are completed. You now have OpenShift cluster version 4.9.

List all the available MachineHealthCheck to ensure everything is in healthy state.

$ oc get machinehealthcheck -n openshift-machine-api
NAME                              MAXUNHEALTHY   EXPECTEDMACHINES   CURRENTHEALTHY
machine-api-termination-handler   100%

Check cluster components:

$ oc get cs
W1110 20:39:28.838732 2592723 warnings.go:70] v1 ComponentStatus is deprecated in v1.19+
NAME                 STATUS    MESSAGE                         ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-3               Healthy   {"health":"true","reason":""}
etcd-1               Healthy   {"health":"true","reason":""}
etcd-0               Healthy   {"health":"true","reason":""}
etcd-2               Healthy   {"health":"true","reason":""}

List all cluster operators and review current versions.

$ oc get co
NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.9.5     True        False         False      32h
baremetal                                  4.9.5     True        False         False      84d
cloud-controller-manager                   4.9.5     True        False         False      20d
cloud-credential                           4.9.5     True        False         False      84d
cluster-autoscaler                         4.9.5     True        False         False      84d
config-operator                            4.9.5     True        False         False      84d
console                                    4.9.5     True        False         False      37d
csi-snapshot-controller                    4.9.5     True        False         False      84d
dns                                        4.9.5     True        False         False      84d
etcd                                       4.9.5     True        False         False      84d
image-registry                             4.9.5     True        False         False      84d
ingress                                    4.9.5     True        False         False      84d
insights                                   4.9.5     True        False         False      84d
kube-apiserver                             4.9.5     True        False         False      84d
kube-controller-manager                    4.9.5     True        False         False      84d
kube-scheduler                             4.9.5     True        False         False      84d
kube-storage-version-migrator              4.9.5     True        False         False      8d
machine-api                                4.9.5     True        False         False      84d
machine-approver                           4.9.5     True        False         False      84d
machine-config                             4.9.5     True        False         False      8d
marketplace                                4.9.5     True        False         False      84d
monitoring                                 4.9.5     True        False         False      20d
network                                    4.9.5     True        False         False      84d
node-tuning                                4.9.5     True        False         False      8d
openshift-apiserver                        4.9.5     True        False         False      20d
openshift-controller-manager               4.9.5     True        False         False      7d8h
openshift-samples                          4.9.5     True        False         False      8d
operator-lifecycle-manager                 4.9.5     True        False         False      84d
operator-lifecycle-manager-catalog         4.9.5     True        False         False      84d
operator-lifecycle-manager-packageserver   4.9.5     True        False         False      20d
service-ca                                 4.9.5     True        False         False      84d
storage                                    4.9.5     True        False         False      84d

Check if all nodes are available and in healthy state.

$ oc get nodes

Conclusion

In this blog post we’ve be able to perform an upgrade of OpenShift from version 4.8 to 4.9. Ensure all Operators previously installed through Operator Lifecycle Manager (OLM) are updated to their latest version in their latest channel as selected during upgrade. Also ensure that all machine config pools (MCPs) are running and not paused. For any issues experienced during upgrade you can reach out to us through our comments section.

Other guides on OpenShift:

• Use Let’s Encrypt SSL Certificates on OpenShift 4.x Ingress / Routes
• How To Install Jenkins Server on Kubernetes | OpenShift
• Install Local OpenShift Cluster using CRC