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:
APIService |
apiregistration.k8s.io/v1beta1 |
Do not |
CertificateSigningRequest |
certificates.k8s.io/v1beta1 |
Yes |
ClusterRole |
rbac.authorization.k8s.io/v1beta1 |
Do not |
ClusterRoleBinding |
rbac.authorization.k8s.io/v1beta1 |
Do not |
CSIDriver |
storage.k8s.io/v1beta1 |
Do not |
CSINode |
storage.k8s.io/v1beta1 |
Do not |
CustomResourceDefinition |
apiextensions.k8s.io/v1beta1 |
Yes |
Ingress |
extensions/v1beta1 |
Yes |
Ingress |
networking.k8s.io/v1beta1 |
Yes |
IngressClass |
networking.k8s.io/v1beta1 |
Do not |
Lease |
coordination.k8s.io/v1beta1 |
Do not |
LocalSubjectAccessReview |
authorization.k8s.io/v1beta1 |
Yes |
MutatingWebhookConfiguration |
admissionregistration.k8s.io/v1beta1 |
Yes |
PriorityClass |
scheduling.k8s.io/v1beta1 |
Do not |
Role |
rbac.authorization.k8s.io/v1beta1 |
Do not |
RoleBinding |
rbac.authorization.k8s.io/v1beta1 |
Do not |
SelfSubjectAccessReview |
authorization.k8s.io/v1beta1 |
Yes |
StorageClass |
storage.k8s.io/v1beta1 |
Do not |
SubjectAccessReview |
authorization.k8s.io/v1beta1 |
Yes |
TokenReview |
authentication.k8s.io/v1beta1 |
Do not |
ValidatingWebhookConfiguration |
admissionregistration.k8s.io/v1beta1 |
Yes |
VolumeAttachment |
storage.k8s.io/v1beta1 |
Do 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 administrative → Cluster setup > detail
Click” channel “And update the channel to fast-4.9 or stable-4.9. 
choose Fast 4.9 or Stable-4.9 From the list of available channels. 
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. 
Select the new version of OpenShift 4.9 you want to upgrade to. 
The update process for OpenShift Container Platform 4.9 should begin soon. 
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 . 
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.