浏览 Kubernetes API 弃用和删除
免责声明:这里包含的到外部网站的链接仅供方便之用。红帽没有审查链接,也不对内容或其可用性负责。包含到外部网站的任何链接并不意味着红帽认可网站或其实体、产品或服务。您同意红帽对由于您使用(或依赖)外部网站或内容而导致的任何损失或费用不承担任何责任。
Kubernetes 遵循一种非常严格的 API 版本策略,导致在多个版本中发生了大量 v1beta1 和 v2beta1 API 的 API 弃用。根据 策略,API Beta 版本在弃用后必须支持 9 个月或 3 个版本(以较长者为准),此时可以删除它们。
已删除的 API 仍在由运行在集群上或与集群交互的工作负载、工具或其他组件使用的地方将开始失败。因此,用户/管理员必须针对任何正在使用的将被删除的 API 评估其集群,并迁移受影响的组件,以使用适当的新 API 版本。
完成后,管理员可以提供管理员确认,并在发生 API 删除的情况下继续进行更新。
使用已删除的 API 迁移应用程序
有关从已删除的 Kubernetes API 迁移的更多信息,请参阅以下内容:
- Red Hat OpenShift Container Platform 4.9 API 删除
- Kubernetes 文档中的 用于 Kube 1.22 (OCP 4.9)的已弃用 API 迁移指南,和 OpenShift 合作伙伴博客中的 Kubernetes 1.22 中将影响您的 Operator 的 API 弃用。
- Red Hat OpenShift Container Platform 4.10 - 无 Kubernetes API 删除
- Red Hat OpenShift Container Platform 4.11 - 无 Kubernetes API 删除
- Red Hat OpenShift Container Platform 4.12 API 删除
- Red Hat OpenShift Container Platform 4.13 API 删除
- Red Hat OpenShift Container Platform 4.14 API 删除
- Red Hat OpenShift Container Platform 4.15 - 无 Kubernetes API 删除
- Red Hat OpenShift Container Platform 4.16 API 删除
- Red Hat OpenShift Container Platform 4.17 - 无 Kubernetes API 删除
- Red Hat OpenShift Container Platform 4.18 - 无 Kubernetes API 删除
评估集群的已删除的 API
有多种方法可帮助管理员确定将被移除的 API 在哪里在使用。但是,OpenShift Container Platform 无法识别所有实例,特别是空闲的工作负载或在使用的外部工具。正确评估已删除 API 实例的所有工作负载和其他集成是管理员的责任。
检查警报,以识别是否在使用将被删除的 API
OpenShift Container Platform 在下一个发行版本中提供了两个在使用将被删除的 API 时触发的警报:
APIRemovedInNextReleaseInUse
- 对于在下一个 OpenShift Container Platform 发行版本中将被删除的 API。APIRemovedInNextEUSReleaseInUse
- 对于在下一个 OpenShift Container Platform Extended Update Support(EUS)发行版本中将被删除的 API。
如果其中任何一个警报在集群中被触发,请查看警报,并通过迁移清单和 API 客户端以使用新的 API 版本来采取措施清除警报。
这些警报旨在全面监控集群,不会提供帮助确定哪些工作负载在使用将被删除的 API 的信息。另外,这些警报被调整为不会过于敏感,以避免在生产系统上出现警报疲劳。您可以使用 APIRequestCount
API 来获取有关哪些 API 在使用的更多信息,以及哪些工作负载在使用将要删除的 API。另外,一些 API 可能不会触发上述警报,但仍然可能会被 APIRequestCount
捕获。
使用 APIRequestCount
识别是否在使用将被删除的 API
您可以使用 APIRequestCount
API 跟踪 API 请求,并检查它们中的任何一个是否在使用一个已删除的 API。
重要:在以前的 OCP 4.8 版本中有一个影响
APIRequestCount
(BZ 2021629) 的 bug,已在 OCP 4.8.25 中由 RHBA-2021:5209 修复了。建议您在检查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) 的 bug,已在 OCP 4.8.25 中由 RHBA-2021:5209 修复了。建议您在检查APIRequestCount
之前升级到较新的 OCP 4.8.z 版本。备注:您必须有以带有
cluster-admin
角色的用户身份访问集群的权限,以便使用APIRequestCount
API。
运行以下命令并检查 username
和 userAgent
字段,以帮助识别在使用 API 的工作负载:
$ oc get apirequestcounts <resource>.<version>.<group> -o yaml
例如:
$ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io -o yaml
您还可以使用 -o jsonpath
从 APIRequestCount
资源中提取 username
和 userAgent
的值:
$ oc get apirequestcounts ingresses.v1beta1.networking.k8s.io \
-o jsonpath='{range .status.last24h..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \
| sort -u | column -t -s ","
注: 使用每个已弃用的仍被使用的 API 的名称更改命令中的
ingresses.v1beta1.networking.k8s.io
。
注: 以上命令显示所选 API 在最后 24 小时内是否被使用了。如果在某些应用程序中进行了更改/升级以使用较新的 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)。- 在 4.10 中
system:serviceaccount:openshift-ovn-kubernetes:ovn-kubernetes-controller
可能显示在使用endpointslices.v1beta1.discovery.k8s.io
,而这个 API 已在 4.12 中被删除。这不是问题,因为在 4.11 中 OVN-Kubernetes 切换到 v1 endpointslices API ,并且从 4.10 到 4.12 的 EUS 升级必须使其控制平面穿过 4.11 。- 在 4.10 中
system:serviceaccount:openshift-network-operator
可能显示在使用poddisruptionbudgets.v1beta1.policy
,而这个 API 已在 4.12 中被删除。这不是一个问题,因为在4.11 中 cluster-network-operator 切换到 v1 poddisruptionbudgets API ,并且从 4.10 到 4.12 的 EUS 升级必须使其控制平面穿过 4.11 。system:serviceaccount:openshift-monitoring:kube-state-metrics
可能显示在使用horizontalpodautoscalers.v2beta2.autoscaling
。这可以被安全地忽略,因为根据 OCPBUGS-4112 解决方案,所有 4.12 版本都已切换到 v2 API。- 当尝试升级到 4.12 时,
system:serviceaccount:prod-rhsso:rhsso-operator
可能会显示在使用poddisruptionbudgets.v1beta1.policy
。如果 RHSSO 版本是最新的,则这可以被安全地忽略,如 Red Hat Single Sign-On (RH SSO) Operator 在使用已弃用的 'poddisruptionbudgets.v1beta1.policy' API 中所述。- 当尝试升级到 4.13 时,
system:serviceaccount:openshift-kube-storage-version-migrator
可能会显示在使用flowschemas.v1beta1.flowcontrol.apiserver.k8s.io
。这可以被安全地忽略,因为它是用来在 etcd 中迁移旧版本的服务战虎。提了一个 BUG ,要求在从 OCP 4.12 升级到 OCP 4.13 时删除 openshift-kube-storage-version-migrator flowschemas APIs 。
Comments