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:
Resource | API | Notable changes |
---|---|---|
APIService |
apiregistration.k8s.io/v1beta1 |
No |
CertificateSigningRequest |
certificates.k8s.io/v1beta1 |
Yes |
ClusterRole |
rbac.authorization.k8s.io/v1beta1 |
No |
ClusterRoleBinding |
rbac.authorization.k8s.io/v1beta1 |
No |
CSIDriver |
storage.k8s.io/v1beta1 |
No |
CSINode |
storage.k8s.io/v1beta1 |
No |
CustomResourceDefinition |
apiextensions.k8s.io/v1beta1 |
Yes |
Ingress |
extensions/v1beta1 |
Yes |
Ingress |
networking.k8s.io/v1beta1 |
Yes |
IngressClass |
networking.k8s.io/v1beta1 |
No |
Lease |
coordination.k8s.io/v1beta1 |
No |
LocalSubjectAccessReview |
authorization.k8s.io/v1beta1 |
Yes |
MutatingWebhookConfiguration |
admissionregistration.k8s.io/v1beta1 |
Yes |
PriorityClass |
scheduling.k8s.io/v1beta1 |
No |
Role |
rbac.authorization.k8s.io/v1beta1 |
No |
RoleBinding |
rbac.authorization.k8s.io/v1beta1 |
No |
SelfSubjectAccessReview |
authorization.k8s.io/v1beta1 |
Yes |
StorageClass |
storage.k8s.io/v1beta1 |
No |
SubjectAccessReview |
authorization.k8s.io/v1beta1 |
Yes |
TokenReview |
authentication.k8s.io/v1beta1 |
No |
ValidatingWebhookConfiguration |
admissionregistration.k8s.io/v1beta1 |
Yes |
VolumeAttachment |
storage.k8s.io/v1beta1 |
No |
v1beta1
APIs removed from Kubernetes 1.22 TableYou 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: