Translated message

A translation of this page exists in English.

浏览 Kubernetes API 弃用和删除

已更新 -

免责声明：此处包含的外部网站链接仅供参考。红帽没有审阅链接的内容，并不对其内容负责。包含任何指向外部网站的链接并不表示红帽认可该网站或其实体、产品或服务。您同意，红帽不承担由于您使用（或依赖）外部网站或内容而导致的任何损失或费用的责任。

Kubernetes 遵循相当严格的 API 版本控制政策；导致多个版本中出现了 v1beta1 和 v2beta1 API 的大量 API 弃用。根据政策，Beta API 版本必须在弃用后支持 9 个月或 3 个版本（以较长者为准），此时可以将其删除。

已删除的 API 仍在被集群上运行或与集群交互的工作负载、工具或其他组件使用的地方将开始出现故障。因此，用户/管理员必须评估其集群中正在使用的任何将被删除的 API，并迁移受影响的组件以使用适当的新 API 版本，这一点非常重要。

完成此操作后，管理员可以提供管理员确认并继续进行 API 删除的更新。

使用已删除的 API 迁移应用程序

有关从已删除的 Kubernetes API 进行迁移的更多信息，请参阅以下内容：

为删除的 API 评估集群

有多种方法可帮助管理员确定将使用移除的 API 的位置。但是，OpenShift Container Platform 无法识别所有实例，尤其是使用闲置或外部工具的工作负载。管理员负责针对已删除 API 实例正确评估所有工作负载和其他集成。

检查警报以确定将被删除的 API 的使用情况

OpenShift Container Platform 提供了两个在使用 API 时触发的警报，这些警报将在下一版本中删除：

  • APIRemovedInNextReleaseInUse - 用于将在下一个 OpenShift Container Platform 版本中删除的 API。
  • APIRemovedInNextEUSReleaseInUse - 用于将在下一个 OpenShift Container Platform 扩展更新支持 (EUS) 版本中删除的 API。

如果其中任何一个警报在集群中触发，请查看警报并采取措施通过迁移清单和 API 客户端以使用新的 API 版本来清除警报。

这些警报旨在对集群进行整体监控，但不会提供有助于确定哪些工作负载正在使用将被删除的 API 的信息。此外，这些警报被调整为不过分敏感，以避免对生产系统造成警报疲劳。您可以使用APIRequestCount API 获取有关哪些 API 正在使用以及哪些工作负载正在使用将被删除的 API 的更多信息。此外，某些 API 可能不会触发上述警报，但仍可能被APIRequestCount捕获。

使用APIRequestCount来识别将被删除的 API 的使用情况

您可以使用APIRequestCount API 跟踪 API 请求并检查其中是否有任何请求正在使用已删除的 API 之一。

重要提示：之前的 OCP 4.8 版本中存在一个影响APIRequestCount ( BZ 2021629 ) 的错误，该错误已通过勘误表 RHBA-2021:5209在 OCP 4.8.25 中修复。建议在检查APIRequestCount之前升级到较新的 OCP 4.8.z 版本。

注意：您必须以具有cluster-admin角色的用户身份访问集群才能使用APIRequestCount API。

运行以下命令并检查输出的REMOVEDINRELEASE列，以确定将在未来版本中删除但当前正在使用的 API：

$ oc get apirequestcounts

输出示例：

NAME                                        REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
cloudcredentials.v1.operator.openshift.io                      32                      111
ingresses.v1.networking.k8s.io                                 28                      110
ingresses.v1beta1.extensions                1.22               16                      66
ingresses.v1beta1.networking.k8s.io         1.22               0                       1
installplans.v1alpha1.operators.coreos.com                     93                      167
...

您还可以使用-o jsonpath来过滤结果：

$ oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.status.requestCount}{"\t"}{.metadata.name}{"\n"}{end}'

输出示例：

1.22    11      certificatesigningrequests.v1beta1.certificates.k8s.io
1.22    356     ingresses.v1beta1.extensions
1.22    0       ingresses.v1beta1.networking.k8s.io

使用APIRequestCount确定哪些工作负载正在使用将被删除的 API

您可以检查给定 API 版本的APIRequestCount资源，以帮助确定哪些工作负载正在使用该 API。

重要提示：之前的 OCP 4.8 版本中存在一个影响APIRequestCount ( BZ 2021629 ) 的错误，该错误已通过勘误表 RHBA-2021:5209在 OCP 4.8.25 中修复。建议在检查APIRequestCount之前升级到较新的 OCP 4.8.z 版本。

注意：您必须以具有cluster-admin角色的用户身份访问集群才能使用APIRequestCount API。

运行以下命令并检查用户名和userAgent字段以帮助识别正在使用 API 的工作负载：

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

例如：

$ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io -o yaml

您还可以使用-o jsonpath从APIRequestCount资源中提取用户名和userAgent值：

$ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io \
-o jsonpath='{range .status.last24h..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \
| sort -k 2 -t, -u | column -t -s ","

注意：将命令中的ingresses.v1beta1.networking.k8s.io更改为仍使用的每个已弃用 API 的名称。
注意：以上命令显示过去 24 小时内是否使用过所选 API。如果在某些应用程序中进行了更改/升级以使用较新的 API，则可以将last24h更改为currentHour以查看过去一小时内是否仍在使用该 API。

输出示例：

VERBS  USERNAME                        USERAGENT
watch  bob                             oc/v4.8.11
watch  system:kube-controller-manager  cluster-policy-controller/v0.0.0

重要提示：您可以安全地忽略结果中出现的以下条目：

  • system:serviceaccount:kube-system:generic-garbage-collector和system:serviceaccount:kube-system:namespace-controller用户可能会出现在结果中，因为他们遍历所有已注册的 API 来搜索要删除的资源。
  • system:kube-controller-manager和system:cluster-policy-controller用户可能会出现在结果中，因为他们在执行各种策略的同时遍历所有资源。
  • 如果集群中安装了 OpenShift GitOps，则为 system:serviceaccount:openshift-gitops:openshift-gitops-argocd-application-controller用户（请参阅KCS 6635361了解更多信息）。
  • 如果集群中安装了 OpenShift Pipelines，则openshift-pipelines-operator userAgent （请参阅KCS 6821411了解更多信息）。
  • 在 OSD 和 ROSA 集群中，或者如果集群中安装了 Velero，则system:serviceaccount:openshift-velero:velero和system:serviceaccount:openshift-oadp:velero用户（请参阅KCS 6351332了解更多信息）。
  • system:serviceaccount:openshift-ovn-kubernetes:ovn-kubernetes-controller在 4.10 中可能显示为使用endpointslices.v1beta1.discovery.k8s.io ，而该 API 在 4.12 中已被删除。这不是问题，因为OVN-Kubernetes 在 4.11 中切换到 v1 endpointslices API ，并且 EUS 从 4.10 升级到 4.12 必须使其控制平面遍历 4.11。
  • system:serviceaccount:openshift-network-operator在 4.10 中可能显示为使用poddisruptionbudgets.v1beta1.policy ，而该 API 在 4.12 中已被删除。这不是问题，因为cluster-network-operator 在 4.11 中切换到 v1 poddisruptionbudgets API ，并且 EUS 从 4.10 升级到 4.12 必须使其控制平面遍历 4.11。
  • system:serviceaccount:openshift-monitoring:kube-state-metrics可能显示为使用horizontalpodautoscalers.v2beta2.autoscaling 。这可以安全地忽略，因为所有 4.12 版本都根据OCPBUGS-4112的解决方案切换到 v2 API。
  • 尝试升级到 4.12 时，使用poddisruptionbudgets.v1beta1.policy时可能会出现system:serviceaccount:prod-rhsso:rhsso-operator 。如果 RHSSO 版本是最新的，则可以安全地忽略此问题，如Red Hat Single Sign-On (RH SSO) Operator is using deprecated 'poddisruptionbudgets.v1beta1.policy' API中所述。

Comments