Preparing to update to OKD 4.13

    A cluster administrator must provide a manual acknowledgment before the cluster can be updated from OKD 4.12 to 4.13. This is to help prevent issues after upgrading to OKD 4.13, 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 OKD 4.12 cluster to 4.13, you must provide the administrator acknowledgment.

    OKD 4.13 uses Kubernetes 1.26, 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 .

    There are several methods to help administrators identify where APIs that will be removed are in use. However, OKD 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.

    • APIRemovedInNextReleaseInUse - for APIs that will be removed in the next OKD release.

    • APIRemovedInNextEUSReleaseInUse - for APIs that will be removed in the next OKD 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.

    Prerequisites

    • You must have access to the cluster as a user with the cluster-admin role.

    Procedure

    You can examine the APIRequestCount resource for a given API version to help identify which workloads are using the API.

    Prerequisites

    • You must have access to the cluster as a user with the cluster-admin role.

    Procedure

    • Run the following command and examine the username and userAgent fields to help identify the workloads that are using the API:

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

      For example:

      1. $ oc get apirequestcounts flowschemas.v1beta1.flowcontrol.apiserver.k8s.io -o yaml

      You can also use -o jsonpath to extract the username and userAgent values from an APIRequestCount resource:

      Example output

      1. VERBS  USERNAME                                                            USERAGENT
      2. get    system:serviceaccount:openshift-cluster-version:default             cluster-version-operator/v0.0.0
      3. watch  system:serviceaccount:openshift-oauth-apiserver:oauth-apiserver-sa  oauth-apiserver/v0.0.0

    For information about how to migrate removed Kubernetes APIs, see the 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 OKD 4.12 to 4.13.

    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. OKD can assist with the evaluation, but cannot identify all possible uses of removed APIs, especially idle workloads or external tools.

    Prerequisites

    • You must have access to the cluster as a user with the role.

    Procedure