Kubernetes 1.22 版本将删除的 API 和特性:这里是你需要知道的

来源: 投稿
作者: CNCF
2021-07-16

随着 Kubernetes API 的发展,API 会周期性地重新组织或升级。当 API 演进时,它们所取代的旧 API 将被弃用,并最终被移除。请参阅Kubernetes API removals[1]阅读更多关于 Kubernetes 移除 API 的政策。

我们想确保你知道一些即将的删除。这些是测试版(beta)的 API,你可以在当前受支持的 Kubernetes 版本中使用,它们已经被弃用了。所有这些删除的原因是它们已经被一个更新的、稳定的(“GA”)API 所取代。

Kubernetes 1.22 将于 2021 年 8 月发布,它将移除一些已经弃用的 API。Kubernetes 1.22 发布信息[2]详细介绍了 v1.22 的发布时间表。

Kubernetes v1.22 移除的 API

v1.22 版本将停止提供下面列出的 API 版本。这些都是 beta 版本的 API,之前为了支持更新和更稳定的 API 版本而被弃用。

  • Beta versions of the ValidatingWebhookConfiguration and MutatingWebhookConfiguration API (the admissionregistration.k8s.io/v1beta1 API versions)

  • The beta CustomResourceDefinition API (apiextensions.k8s.io/v1beta1)

  • The beta APIService API (apiregistration.k8s.io/v1beta1)

  • The beta TokenReview API (authentication.k8s.io/v1beta1)

  • Beta API versions of SubjectAccessReview, LocalSubjectAccessReview, SelfSubjectAccessReview (API versions from authorization.k8s.io/v1beta1)

  • The beta CertificateSigningRequest API (certificates.k8s.io/v1beta1)

  • The beta Lease API (coordination.k8s.io/v1beta1)

  • All beta Ingress APIs (the extensions/v1beta1 and networking.k8s.io/v1beta1 API versions)

Kubernetes 文档涵盖了这些1.22 版本中删除的 API[3],并解释了这些 API 在 beta 和稳定版本之间是如何变化的。

要做什么

我们将浏览每一种受这些删除影响的资源,并解释你需要采取的步骤。

Ingress

迁移至使用 networking.k8s.io/v1 Ingress API,从 v1.19 开始可用。相关的 API IngressClass 是为了补充 Ingress 概念而设计的,允许你在一个集群中配置多种 Ingress。如果你目前正在使用已弃用的 kubernetes.io/ingress.class 注释,请计划改用.spec.ingressClassName 字段。

在任何运行 Kubernetes v1.19 或更高版本的集群上,你都可以使用 v1 API 来检索或更新现有的 Ingress 对象,即使它们是使用较旧的 API 版本创建的。

当你将一个 Ingress 转换为 v1 API 时,你应该检查该 Ingress 中的每个规则。较老版本的 Ingress 使用遗留的 ImplementationSpecific 路径类型。切换路径匹配 Prefix 或 Exact,而不是 ImplementationSpecific。迁移到这些替代路径类型的好处之一是,在不同的 Ingress 类之间迁移变得更加容易。

除了作为客户端升级自己对 Ingress API 的使用之外,还要确保你使用的每个 Ingress 控制器都与 v1 Ingress API 兼容。阅读Ingress 先决条件[4]了解更多关于 Ingress 和 Ingress 控制器的上下文。

ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration

迁移以使用 admissionregistration.k8s.io/v1 API 的 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration,从 v1.16 开始提供。你可以使用 v1 API 来检索或更新现有对象,即使它们是使用较旧的 API 版本创建的。

CustomResourceDefinition

迁移以使用 CustomResourceDefinition apiextensions.k8s.io/v1 API,从 v1.16 开始可用。你可以使用 v1 API 来检索或更新现有对象,即使它们是使用较旧的 API 版本创建的。如果你在集群中定义了任何自定义资源,那么在升级之后这些资源仍然会被使用。

如果你正在使用外部 CustomResourceDefinitions,则可以使用 kubectl convert 将现有清单转换为使用较新的 API。因为在 beta 版和稳定版 CustomResourceDefinitions 之间存在一些功能差异,所以我们的建议是对每一个进行测试,以确保它在升级后按照你期望的方式工作。

APIService

迁移到使用 apiregistration.k8s.io/v1 APIService API,从 v1.10 开始可用。你可以使用 v1 API 来检索或更新现有对象,即使它们是使用较旧的 API 版本创建的。如果你已经有了使用 APIService 对象的 API 聚合,那么这个聚合在升级之后将继续工作。

TokenReview

迁移以使用 authentication.k8s.io/v1 TokenReview API,从 v1.10 开始可用。除了通过 HTTP 提供这个 API 之外,Kubernetes API 服务器也使用相同的格式将 TokenReviews 发送到 webhook。v1.22 版本继续使用 v1beta1 API 发送 TokenReviews 给 webhook。关于切换到稳定 API 的一些具体技巧,请参阅展望未来。

SubjectAccessReview、SelfSubjectAccessReview 和 LocalSubjectAccessReview

迁移以使用 authorization.k8s.io/v1 版本的 API,从 v1.6 开始提供。

CertificateSigningRequest

迁移到使用 certificates.k8s.io/v1 CertificateSigningRequest API,从 v1.19 开始可用。你可以使用 v1 API 来检索或更新现有对象,即使它们是使用较旧的 API 版本创建的。现有颁发的证书在升级时保留其有效性。

Lease

迁移以使用 coordination.k8s.io/v1 Lease API,从 v1.14 开始可用。你可以使用 v1 API 来检索或更新现有对象,即使它们是使用较旧的 API 版本创建的。

kubectl convert

kubectl 有一个插件,提供 kubectl convert 子命令。这是一个官方插件,你可以下载作为 Kubernetes 的一部分。有关更多细节,请参阅Download Kubernetes[5]。

你可以使用 kubectl convert 来更新清单文件,以使用不同的 API 版本。例如,如果你在源代码控制中有一个使用 beta Ingress API 的清单,你可以 check out 这个定义,并运行 kubectl convert -f --output-version / 。你可以使用 kubectl convert 命令自动转换现有清单。

例如,将旧的 Ingress 定义转换为 networking.k8s.io/v1,可以运行:

kubectl convert -f ./legacy-ingress.yaml --output-version networking.k8s.io/v1

自动转换使用了一种类似于 Kubernetes 控制平面更新对象的技术,这些对象最初是使用旧 API 版本创建的。因为这是一个机械转换,你可能需要进去改变清单来调整默认值等等。

为升级进行排练

如果你管理集群的 API 服务器组件,那么你可以在升级到 Kubernetes v1.22 之前尝试删除这些 API。

为此,将以下内容添加到 kube-apiserver 命令行参数中:

--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1=false,apiregistration.k8s.io/v1beta1=false,authentication.k8s.io/v1beta1=false,authorization.k9s.io/v1=false,certificates.k8s.io/v1beta=false,coordination.k8s.io/v1beta1=false,extensions/v1beta1/ingresses=false,networking.k8s.io/v1beta1=false

(作为一个副作用,这也关闭了 EndpointSlice 的 v1beta1——在测试时要注意。)

一旦你将集群中的所有 kube-apiserver 切换为使用该设置,这些 beta API 就会被删除。你可以测试 API 客户端(kubectl,部署工具,自定义控制器等)是否仍然按照你期望的方式工作,如果你需要,你可以恢复,而不必计划一个更具破坏性的降级。

给软件作者的建议

也许你读这篇文章是因为你是一个插件或其他集成 Kubernetes 组件的开发者?

如果你开发了 Ingress 控制器,webhook 验证器,API 聚合,或任何其他依赖于这些废弃 API 的工具,你应该已经开始转换你的软件了。

你可以使用预演中的升级技巧来运行你自己的只使用新 API 的 Kubernetes 集群,并确保你的代码工作正常。对于你的文档,请确保读者了解 Kubernetes v1.22 升级应该采取的任何步骤。

在可能的情况下,尽早帮助你的用户采用新的 API——也许是在测试环境中——这样他们就可以就任何问题向你提供反馈。

在 Kubernetes v1.25 中还会有更多的弃用之处,所以也计划将其囊括在内。

Kubernetes API 的移除

以下是 Kubernetes 为什么删除一些 API 的背景信息,以及 Kubernetes 对稳定 API 的承诺。

Kubernetes 对其特性遵循一个已定义的弃用策略[6],包括 Kubernetes API。该策略允许替换 Kubernetes 的稳定(“GA”)API。重要的是,这个策略意味着只有当一个稳定的 API 有新的稳定版本可用时,才会弃用该 API。

这种稳定性保证很重要:如果你使用的是稳定的 Kubernetes API,就不会有新版本的发布迫使你切换到 alpha 或 beta 特性。

早期阶段是不同的。Alpha 特性还在测试中,可能不完整。alpha 特性在默认情况下几乎总是禁用的。Kubernetes 发布的版本可以并且确实删除了 alpha 版本中那些没有发挥作用的特性。

alpha 后面是 beta。这些特性通常是默认启用的;如果测试成功,该特性可以逐步趋于稳定。如果没有,可能需要重新设计。

去年,Kubernetes 正式对已经进入测试阶段的 API采取[7]了一项政策:

对于 Kubernetes REST API 来说,当一个新特性的 API 达到测试版时,就开始倒计时了。beta 质量的 API 现在有三个版本:

  • 到达 GA,弃用测试版,或者

  • 拥有一个新的测试版(并弃用之前的测试版)。

在写那篇文章的时候,Kubernetes 发布三次大约相当于 9 个日历月。同月晚些时候,Kubernetes 采用了新的发布节奏,即每日历年发布 3 个版本,所以现在的倒计时时间大约是 12 个日历月。

不管 API 的删除是因为测试版特性已经趋于稳定,还是因为该 API 没有被证明是成功的,Kubernetes 将继续通过遵循其弃用策略并确保迁移选项被记录下来来删除 API。

展望未来

如果你使用 webhook 认证检查,有一个相关的设置。将来的 Kubernetes 版本将使用默认将 TokenReview 对象发送到 authentication.k8s.io/v1 API。目前,默认是发送 authentication.k8s.io/v1beta1 TokenReviews 到 webhooks,这仍然是 Kubernetes v1.22 版本的默认方式。不过,如果你想,现在可以切换到稳定的 API:在 kube-apiserver 的命令行选项中添加--authentication-token-webhook-version=v1,并检查用于身份验证的 webhook 是否仍按你期望的方式工作。

一旦你满意了,你就可以在控制平面上设置--authentication-token-webhook-version=v1 选项。

计划于明年发布的 v1.25 版本将停止提供几个 Kubernetes API 的 beta 版本,这些 API 目前已经稳定了一段时间。相同的 v1.25 版本将删除 PodSecurityPolicy,它已被弃用,不会升级到稳定状态。有关更多信息,请参阅PodSecurityPolicy Deprecation: Past, Present, and Future[8]。

Kubernetes 1.25 计划移除的 API[9]的官方列表如下:

  • The beta CronJob API (batch/v1beta1)

  • The beta EndpointSlice API (networking.k8s.io/v1beta1)

  • The beta PodDisruptionBudget API (policy/v1beta1)

  • The beta PodSecurityPolicy API (policy/v1beta1)

想了解更多吗?

Kubernetes 发布说明中宣布了弃用的内容。你可以在1.19[10]、1.20[11]和1.21[12]的发布说明中看到弃用声明。

有关弃用和移除过程的信息,请查看 Kubernetes 官方弃用策略[13]文档。

参考资料

[1] Kubernetes API removals: https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/#kubernetes-api-removals

[2] Kubernetes 1.22 发布信息: https://www.kubernetes.dev/resources/release/

[3] 1.22 版本中删除的 API: 这些

[4] Ingress 先决条件: https://kubernetes.io/docs/concepts/services-networking/ingress/#prerequisites

[5] Download Kubernetes: https://kubernetes.io/releases/download/

[6] 弃用策略: https://kubernetes.io/docs/reference/using-api/deprecation-policy/

[7] 采取: https://kubernetes.io/blog/2020/08/21/moving-forward-from-beta/#avoiding-permanent-beta

[8] PodSecurityPolicy Deprecation: Past, Present, and Future: https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/

[9] 1.25 计划移除的 API: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-25

[10] 1.19: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md#deprecations

[11] 1.20: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation

[12] 1.21: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md#deprecation

[13] 弃用策略: https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api

展开阅读全文
2 收藏
分享
加载中
更多评论
0 评论
2 收藏
分享
返回顶部
顶部