Kubernetes v1.22有哪些变化：众多 API 和功能被移除

随着 Kubernetes API 的发展，API 会定期重组或升级。当 API 发展时，它们替换的旧 API 将被弃用，并最终被删除。请参阅下文了解有关 Kubernetes 删除 API 政策的更多信息。

我们希望确保你了解一些即将进行的移除。这些是你可以在当前受支持的 Kubernetes 版本中使用的 beta API，但它们已被弃用。所有这些删除的原因是它们已被更新的、稳定的（“GA”）API 取代。

Kubernetes 1.22 将于 2021 年 8 月发布，它将删除许多已弃用的 API。Kubernetes 1.22 Release Information 包含有关 v1.22 版本时间表的详细信息。

https://www.kubernetes.dev/resources/release/

Kubernetes v1.22 的 API 移除

在 v1.22 版本将停止提供我们在下面列出的 API 版本。这些都是以前被弃用的 beta API，以支持更新和更稳定的 API 版本。

ValidatingWebhookConfiguration 和 MutatingWebhookConfigurationAPI 的 Beta 版本（admissionregistration.k8s.io/v1beta1 API 版本） 测试版 CustomResourceDefinitionAPI（apiextensions.k8s.io/v1beta1） 测试版APIServiceAPI（apiregistration.k8s.io/v1beta1） 测试版TokenReviewAPI（authentication.k8s.io/v1beta1） SubjectAccessReview，LocalSubjectAccessReview 的 Beta API 版本 SelfSubjectAccessReview（来自 authorization.k8s.io/v1beta1 的 API 版本） 测试版 CertificateSigningRequestAPI（certificates.k8s.io/v1beta1） 测试版 LeaseAPI（协调 .k8s.io/ v1beta1） 所有 beta IngressAPI（extensions/v1beta1 和 networking.k8s.io/v1beta1 API 版本）

Kubernetes 文档涵盖了 v1.22 的这些 API 删除，并解释了这些 API 中的每一个如何在测试版和稳定版之间的变化。

该怎么办

我们将遍历受这些删除影响的每个资源，并解释你需要采取的步骤。

Ingress

迁移到使用 networking.k8s.io/v1 入口 API，可用自 1.19。

相关的 API IngressClass 旨在补充 Ingress 概念，允许你在一个集群中配置多种 Ingress。如果你当前正在使用已弃用的 kubernetes.io/ingress.class 注释，请计划改用该 .spec.ingressClassName 字段。

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

当你将 Ingress 转换为 v1 API 时，你应该查看该 Ingress 中的每条规则。较旧的 Ingress 使用旧版 ImplementationSpecific 路径类型。代替 ImplementationSpecific，将路径匹配切换为 Prefix 或 Exact。迁移到这些替代路径类型的好处之一是可以更轻松地在不同 Ingress 类之间迁移。

除了升级你自己作为客户端的 Ingress API 使用之外，还要确保你使用的每个 Ingress 控制器都与 v1 Ingress API 兼容。 有关 Ingress 和 Ingress 控制器的更多上下文，请阅读：https://kubernetes.io/docs/con ... sites

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 之间存在一些功能差异，我们的建议是对每个自定义资源定义进行测试，以确保其在升级后按预期工作。

API Service

迁移到 apiregistration.k8s.io/v1 APIService API，从 v1.10 开始可用。

你可以使用 v1 API 来检索或更新现有对象，即使它们是使用较旧的 API 版本创建的。如果您已经使用 API Service 对象进行 API 聚合，则升级后该聚合会继续工作。

TokenReview

迁移到使用 authentication.k8s.io/v1 TokenReview API，从 v1.10 开始可用。

除了通过 HTTP 提供此 API 之外，Kubernetes API 服务器还使用相同的格式将 TokenReviews 发送到 webhooks。v1.22 版本继续使用 v1beta1 API 来默认发送到 webhook 的 TokenReviews。有关切换到稳定 API 的一些具体提示，请参阅下文的“展望未来”。

SubjectAccessReview，SelfSubjectAccessReview 和 LocalSubjectAccessReview

迁移以使用这些授权 API 的 authorization.k8s.io/v1 版本 ，从 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 的一部分下载。有关更多详细信息，请参阅：https://kubernetes.io/releases/download/

你可以使用 kubectl convert 更新清单文件以使用不同的 API 版本。例如，如果你在源代码管理中有一个使用 Beta Ingress API 的清单，你可以检查该定义，然后运行 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-apiservers 切换为使用该设置，这些 beta API 将被删除。你可以测试 API 客户端（kubectl、部署工具、自定义控制器等）是否仍然按照你的预期工作，并且你可以在需要时恢复，而无需计划更具破坏性的降级。

给软件作者的建议

也许你正在阅读本文是因为你是与 Kubernetes 集成的插件或其他组件的开发人员。

如果你开发了 Ingress 控制器、Webhook 身份验证器、API 聚合或任何其他依赖于这些已弃用 API 的工具，你应该已经开始切换你的软件。

你可以使用Rehearse 中的升级提示来运行你自己的仅使用新 API 的 Kubernetes 集群，并确保你的代码运行正常。对于你的文档，请确保读者了解他们应该为 Kubernetes v1.22 升级采取的任何步骤。

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

Kubernetes v1.25 中还有一些弃用，因此也计划涵盖这些弃用。

Kubernetes API 删除

这里有一些关于 Kubernetes 为何删除一些 API 的背景，以及关于 Kubernetes 中稳定API 的承诺。

Kubernetes 对其功能（包括 Kubernetes API）遵循既定的弃用政策。该政策允许从 Kubernetes 替换稳定的（“GA”）API。重要的是，此政策意味着稳定 API 仅在同一 API 的较新稳定版本可用时才会被弃用。

稳定性保证很重要：如果你使用稳定的 Kubernetes API，则永远不会发布新版本迫使你切换到 alpha 或 beta 功能。

早期阶段是不同的。Alpha 功能正在测试中，可能不完整。几乎总是默认禁用 alpha 功能。Kubernetes 版本可以确认删除了尚未解决的 alpha 功能。

在 alpha 之后，是 beta。这些功能通常默认启用；如果测试成功，该功能可以升级到稳定。如果没有，它可能需要重新设计。

去年，Kubernetes 正式为已经达到测试阶段的 API采取了一项政策：

对于 Kubernetes REST API，当新功能的 API 达到测试版时，就会开始倒计时。测试质量的 API 现在有三个版本……分别是： 达到 GA，并弃用测试版，或 有一个新的测试版（并弃用以前的测试版）

在撰写该文章时，三个 Kubernetes 版本发布大约相当于九个日历月。同月晚些时候，Kubernetes 采用了每个日历年三个版本的新发布节奏，因此倒计时现在大约是十二个日历月。

无论删除 API 是因为测试版功能升级为稳定版，还是因为该 API 尚未证明成功，Kubernetes 都将通过遵循其弃用政策并确保记录迁移选项来继续删除 API。

展望未来

如果你使用 Webhook 身份验证检查，则有一个相关设置。未来的 Kubernetes 版本将切换为 authentication.k8s.io/v1 默认使用 API 将 TokenReview 对象发送到 Webhook 。目前，默认是将 authentication.k8s.io/v1beta1TokenReviews 发送到 Webhooks，这仍然是 Kubernetes v1.22 的默认设置。但是，如果需要，你可以立即切换到稳定的 API：添加 --authentication-token-webhook-version=v1 到 kube-apiserver 的命令行选项，并检查用于身份验证的 Webhooks 是否仍按你的预期工作。

一旦你觉得它工作正常，你就可以在 --authentication-token-webhook-version=v1 整个控制平面上保留该选项设置。

计划于明年发布的 v1.25 版本将停止提供几个目前稳定且已经有一段时间的 Kubernetes API 的测试版。相同的 v1.25 版本将删除 PodSecurityPolicy，它已被弃用并且不会升级到稳定版。有关 更多信息，请参阅：《PodSecurityPolicy 弃用：过去、现在和未来》。

为 Kubernetes 1.25 计划的 API 删除的官方列表是：

测试版CronJobAPI（batch/v1beta1） 测试版EndpointSliceAPI（networking.k8s.io/v1beta1） 测试版PodDisruptionBudgetAPI（policy/v1beta1） 测试版PodSecurityPolicyAPI（policy/v1beta1）

总而言之，可以预见，API 删除会给用户带来混乱，不单纯的是弃用，而是直接删除！

声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。