Preparing to upgrade to OpenShift Container Platform 4.9

Updated -

This article is part of series covering API removals and deprecations. See Navigating Kubernetes API deprecations and removals for more information on evaluating API usage and migrating away from these APIs.

OpenShift Container Platform 4.9 uses Kubernetes 1.22, which removed a significant number of deprecated v1beta1 APIs.

OpenShift Container Platform 4.8.14 introduced a requirement that an administrator must provide a manual acknowledgment before the cluster can be upgraded from OpenShift Container Platform 4.8 to 4.9. This is to help prevent issues after upgrading to OpenShift Container Platform 4.9, where APIs that have been removed are still in use by workloads, tools, or other components running on or interacting with the cluster. Administrators must evaluate their cluster for any APIs in use that will be removed and migrate the affected components to use the appropriate new API version. After this is done, the administrator can provide the administrator acknowledgment.

All clusters require this administrator acknowledgment before they can be upgraded to OpenShift Container Platform 4.9.

Removed Kubernetes APIs

Kubernetes 1.22 removed the following deprecated v1beta1 APIs. If your cluster, or any idle workloads or tools use any of these APIs, you must migrate them to the appropriate new version before upgrading to OpenShift Container Platform 4.9.

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
SelfSubjectRulesReview 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

Providing the administrator acknowledgement

IMPORTANT: See Navigating Kubernetes API deprecations and removals for information on evaluating API usage and migrating away from these removed APIs.

After you have evaluated your cluster for any removed APIs and have migrated any removed APIs, you can acknowledge that your cluster is ready to upgrade to OpenShift Container Platform 4.9.

Note: This method of acknowledgement does not apply to OpenShift Dedicated (OSD) or Red Hat OpenShift Service on AWS (ROSA). Please refer to the relevant KCS for OSD and for ROSA.

WARNING: Be aware that all responsibility falls on the administrator to ensure that all uses of removed APIs have been resolved and migrated as necessary before providing this administrator acknowledgment. OpenShift Container Platform can assist with the evaluation, but cannot identify all possible uses of removed APIs, especially idle workloads or external tools.

To acknowledge that you have completed the evaluation and your cluster is ready to upgrade to OpenShift Container Platform 4.9, run the following command:

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

Note: You must have access to the cluster as a user with the cluster-admin role in order to run this command.

Your cluster is now ready to be upgraded to OpenShift Container Platform 4.9.

9 Comments

Had a look at this after upgrading to 4.8 and in all but a few cases they are used by openshift-<something> and in one case kube-controller-manager. So regarding this "WARNING", why am I expected to take responsibility to ensure that the usage of these removed APIs have been resolved for cluster specific functionality? I would be nice if Red Hat can state that they will take care of their stuff and not have me to acknowledge that and subsequently assume responsibility.

Thanks for the feedback.

The counters currently look back over the past 24hrs which would include data before the upgrade had completed. We'll look at improving this such that the counters are reset when the 4.8 upgrade completes. If after 24hrs the counters are still showing activity can you please file a case and attach a must-gather so that we can look into the specifics of why your cluster is triggering these counters?

We'll look at improving this such that the counters are reset when the 4.8 upgrade completes.

is this already implemented/active in 4.8.z?

For the ingress controller you get false positives for the kube-controller-manager. You can safely ignore them as it is auditing the API. This is stated in the release notes, but it wasn't included in this kb article.

Edit - I went back and looked closely and it is stated in this KB article.

I installed a new version of openshift 4.8 and it looks like OLM is using customresourcedefinitions.v1beta1.apiextensions.k8s.io . Should I ignore it and provide the administrator acknowledgement?

oc get apirequestcounts -o jsonpath='{range ..username}{$}{"\n"}{end}' customresourcedefinitions.v1beta1.apiextensions.k8s.io

system:serviceaccount:openshift-operator-lifecycle-manager:olm-operator-serviceaccount

The get apirequestcounts query may give false positive in case of middleware applications. For example, AMQ Streams uses deprecated APIs when available, in order to minimize the risk surface, and switches to the new APIs when required. In general, the fact that some old API is still used, does not mean that the new one is not supported. In case of positives, these must be always checked with support.

Hi, is the list of Removed Kubernetes APIs complete and kept up to date?

The list of removed APIs in this article is for OCP 4.9 (based on Kubernetes 1.22), and they were marked as deprecated several releases in advance.

For deprecated/removed APIs in future OCP/Kubernetes releases, you can check the Deprecated API Migration Guide.

See Navigating Kubernetes API deprecations and removals for updates beyond OCP 4.9.