How to upgrade from OpenShift 4.8 to 4.9

Red Hat OpenShift Container Platform is a powerful platform designed to provide IT organizations and developers with a hybrid cloud application platform. With this secure and scalable platform, you can deploy containerized applications with minimal configuration and management overhead. In this article, we will learn how to perform the upgrade from OpenShift 4.8 to OpenShift 4.9.

Red Hat Enterprise Linux CoreOS (RHCOS) 4.9 and Red Hat Enterprise Linux (RHEL) 8.4 and 7.9 support OpenShift Container Platform 4.9. Red Hat recommends that you run the RHCOS machine on the control plane node, and run RHCOS or RHEL 8.4+/7.9 on the computer.

The Kubernetes version used in OpenShift Container Platform 4.9 is 1.22. In Kubernetes 1.22, a large number of deprecated v1beta1 APIs have been removed. A requirement was introduced in OpenShift Container Platform 4.8.14, requiring the administrator to provide Manual confirmation Before being able to upgrade the cluster from OpenShift Container Platform 4.8 to 4.9. This helps prevent problems after upgrading to OpenShift Container Platform 4.9, when workloads and components in the cluster are still using the removed API.

The Kubernetes API was removed in OpenShift 4.9

Below is the deprecated list v1beta1 API in OpenShift Container Platform 4.9 using Kubernetes 1.22:

Significant changes to ResourceAPI
APIServiceapiregistration.k8s.io/v1beta1Do not
CertificateSigningRequestcertificates.k8s.io/v1beta1Yes
ClusterRolerbac.authorization.k8s.io/v1beta1Do not
ClusterRoleBindingrbac.authorization.k8s.io/v1beta1Do not
CSIDriverstorage.k8s.io/v1beta1Do not
CSINodestorage.k8s.io/v1beta1Do not
CustomResourceDefinitionapiextensions.k8s.io/v1beta1Yes
Ingressextensions/v1beta1Yes
Ingressnetworking.k8s.io/v1beta1Yes
IngressClassnetworking.k8s.io/v1beta1Do not
Leasecoordination.k8s.io/v1beta1Do not
LocalSubjectAccessReviewauthorization.k8s.io/v1beta1Yes
MutatingWebhookConfigurationadmissionregistration.k8s.io/v1beta1Yes
PriorityClassscheduling.k8s.io/v1beta1Do not
Rolerbac.authorization.k8s.io/v1beta1Do not
RoleBindingrbac.authorization.k8s.io/v1beta1Do not
SelfSubjectAccessReviewauthorization.k8s.io/v1beta1Yes
StorageClassstorage.k8s.io/v1beta1Do not
SubjectAccessReviewauthorization.k8s.io/v1beta1Yes
TokenReviewauthentication.k8s.io/v1beta1Do not
ValidatingWebhookConfigurationadmissionregistration.k8s.io/v1beta1Yes
VolumeAttachmentstorage.k8s.io/v1beta1Do not

v1beta1 API deleted from Kubernetes 1.22 table

You need to migrate the manifest and API client to use v1 API version.For more information on migration of deprecated APIs, see Kubernetes official documentation.

1) Evaluate the OpenShift 4.8 cluster against the deleted API

It is the responsibility of Kubernetes/OpenShift administrators to properly evaluate all workloads and other integrations to determine where to use the API removed in Kubernetes 1.22.

Before attempting to upgrade to 4.9, make sure you are using OpenShift Cluster 4.8.The following commands can help you identify the OCP version

$ 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

Then you can use APIRequestCount API Track API requests-if any request is using one of the deleted APIs.

The following commands can be used to identify APIs that will be removed in a future version but are currently in use.focus on REMOVEDINRELEASE Output column.

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

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

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

Sample output:

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

After the API is identified, you can check the APIRequestCount resource for a given API version to help determine which workloads are using the API.

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

Example ingresses.v1beta1.extensions Application program interface:

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

Migrate instances where APIs have been removed

You can get more information about migrating the deleted Kubernetes API, see Deprecated API migration guide In the Kubernetes documentation.

2) Confirm the upgrade to OpenShift Container Platform 4.9

After the removed Kubernetes API evaluation and migration to v1 are completed, as an OpenShift administrator, you can provide the confirmation needed to continue.

Warning: It is the administrator’s responsibility to ensure that all uses of the deleted API are resolved and perform the necessary migration before providing this Administrator confirm.

Run the following command to confirm that you have completed the assessment and the 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) Start to upgrade from OpenShift 4.8 to 4.9

Log in to the OpenShift web console and navigate to administrativeCluster setup > detail

Click”channel“And update the channel to fast-4.9 or stable-4.9.Upgrade openshift 4.8 to 4.9 02

choose Fast 4.9 orStable-4.9 From the list of available channels.Upgrade openshift 4.8 to 4.9 03

You can also change the channel from the command line using the following command syntax:

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

Where <channel> Is replaced by one of them;

  • Stable-4.9
  • Fast 4.9
  • Candidate-4.9

You should now see the new cluster update. use”renew“Link to initiate the upgrade from OpenShift 4.8 to OpenShift 4.9.Upgrade openshift 4.8 to 4.9 04Upgrade openshift 4.8 to 4.9 05

Select the new version of OpenShift 4.9 you want to upgrade to.Upgrade openshift 4.8 to 4.9 06

The update process for OpenShift Container Platform 4.9 should begin soon.Upgrade openshift 4.8 to 4.9 07

You can also check the upgrade status from the 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 after all upgrades are completed.You now have an OpenShift cluster version 4.9.Upgrade openshift 4.8 to 4.9 08

List all available Machine health check To make sure everything is in a healthy state.

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

Check the 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 view the current version.

$ 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 whether all nodes are available and in a healthy state.

$ oc get nodes

in conclusion

In this blog post, we have been able to upgrade OpenShift from version 4.8 to version 4.9. Ensure that all operators previously installed via Operator Lifecycle Manager (OLM) are updated to the latest version in the latest channel selected during the upgrade. Also make sure that all machine configuration pools (MCPs) are running and not suspended. For any problems encountered during the upgrade process, you can contact us through our comment section.