$ oc get apirequestcounts
Learn more about administrative tasks that cluster admins must perform to successfully initialize an update, as well as optional guidelines for ensuring a successful update.
OpenShift Container Platform 4.14 uses Kubernetes 1.27, which removed several deprecated APIs.
A cluster administrator must provide a manual acknowledgment before the cluster can be updated from OpenShift Container Platform 4.13 to 4.14. This is to help prevent issues after upgrading to OpenShift Container Platform 4.14, 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 evaluation and migration is complete, the administrator can provide the acknowledgment.
Before you can update your OpenShift Container Platform 4.13 cluster to 4.14, you must provide the administrator acknowledgment.
OpenShift Container Platform 4.14 uses Kubernetes 1.27, which removed the following deprecated APIs. You must migrate manifests and API clients to use the appropriate API version. For more information about migrating removed APIs, see the Kubernetes documentation.
Resource | Removed API | Migrate to |
---|---|---|
|
|
|
There are several methods to help administrators identify where APIs that will be removed are in use. However, OpenShift Container Platform cannot identify all instances, especially workloads that are idle or external tools that are used. It is the responsibility of the administrator to properly evaluate all workloads and other integrations for instances of removed APIs.
Two alerts fire when an API is in use that will be removed in the next release:
APIRemovedInNextReleaseInUse
- for APIs that will be removed in the next OpenShift Container Platform release.
APIRemovedInNextEUSReleaseInUse
- for APIs that will be removed in the next OpenShift Container Platform Extended Update Support (EUS) release.
If either of these alerts are firing in your cluster, review the alerts and take action to clear the alerts by migrating manifests and API clients to use the new API version.
Use the APIRequestCount
API to get more information about which APIs are in use and which workloads are using removed APIs, because the alerts do not provide this information. Additionally, some APIs might not trigger these alerts but are still captured by APIRequestCount
. The alerts are tuned to be less sensitive to avoid alerting fatigue in production systems.
You can use the APIRequestCount
API to track API requests and review whether any of them are using one of the removed APIs.
You must have access to the cluster as a user with the cluster-admin
role.
Run the following command and examine the REMOVEDINRELEASE
column of the output to identify the removed APIs that are currently in use:
$ oc get apirequestcounts
NAME REMOVEDINRELEASE REQUESTSINCURRENTHOUR REQUESTSINLAST24H
...
csistoragecapacities.v1.storage.k8s.io 14 380
csistoragecapacities.v1beta1.storage.k8s.io 1.27 0 16
custompolicydefinitions.v1beta1.capabilities.3scale.net 8 158
customresourcedefinitions.v1.apiextensions.k8s.io 1407 30148
...
You can safely ignore the following entries that appear in the results:
|
You can also use -o jsonpath
to filter the results:
$ oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.metadata.name}{"\n"}{end}'
1.27 csistoragecapacities.v1beta1.storage.k8s.io
1.29 flowschemas.v1beta2.flowcontrol.apiserver.k8s.io
1.29 prioritylevelconfigurations.v1beta2.flowcontrol.apiserver.k8s.io
You can examine the APIRequestCount
resource for a given API version to help identify which workloads are using the API.
You must have access to the cluster as a user with the cluster-admin
role.
Run the following command and examine the username
and userAgent
fields to help identify the workloads that are using the API:
$ oc get apirequestcounts <resource>.<version>.<group> -o yaml
For example:
$ oc get apirequestcounts csistoragecapacities.v1beta1.storage.k8s.io -o yaml
You can also use -o jsonpath
to extract the username
and userAgent
values from an APIRequestCount
resource:
$ oc get apirequestcounts csistoragecapacities.v1beta1.storage.k8s.io \
-o jsonpath='{range .status.currentHour..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \
| sort -k 2 -t, -u | column -t -s, -NVERBS,USERNAME,USERAGENT
VERBS USERNAME USERAGENT
list watch system:kube-controller-manager cluster-policy-controller/v0.0.0
list watch system:kube-controller-manager kube-controller-manager/v1.26.5+0abcdef
list watch system:kube-scheduler kube-scheduler/v1.26.5+0abcdef
For information about how to migrate removed Kubernetes APIs, see the Deprecated API Migration Guide in the Kubernetes documentation.
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 from OpenShift Container Platform 4.13 to 4.14.
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. |
You must have access to the cluster as a user with the cluster-admin
role.
Run the following command to acknowledge that you have completed the evaluation and your cluster is ready for the Kubernetes API removals in OpenShift Container Platform 4.14:
$ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.13-kube-1.27-api-removals-in-4.14":"true"}}' --type=merge
A conditional update is an update target that is available but not recommended due to a known risk that applies to your cluster. The Cluster Version Operator (CVO) periodically queries the OpenShift Update Service (OSUS) for the most recent data about update recommendations, and some potential update targets might have risks associated with them.
The CVO evaluates the conditional risks, and if the risks are not applicable to the cluster, then the target version is available as a recommended update path for the cluster. If the risk is determined to be applicable, or if for some reason CVO cannot evaluate the risk, then the update target is available to the cluster as a conditional update.
When you encounter a conditional update while you are trying to update to a target version, you must assess the risk of updating your cluster to that version. Generally, if you do not have a specific need to update to that target version, it is best to wait for a recommended update path from Red Hat.
However, if you have a strong reason to update to that version, for example, if you need to fix an important CVE, then the benefit of fixing the CVE might outweigh the risk of the update being problematic for your cluster. You can complete the following tasks to determine whether you agree with the Red Hat assessment of the update risk:
Complete extensive testing in a non-production environment to the extent that you are comfortable completing the update in your production environment.
Follow the links provided in the conditional update description, investigate the bug, and determine if it is likely to cause issues for your cluster. If you need help understanding the risk, contact Red Hat Support.