随着新功能和功能的增加，旧的API被弃用并最终移除。虽然这是Kubernetes发展的必要部分，但对于依赖该平台运行应用程序的组织来说，这可能会带来挑战。
Kubernetes API作为与K8集群交互的接口。如果集群中仍在使用已弃用的API，可能会导致中断不可用。
在这篇博客文章中，我们将探讨被弃用的Kubernetes API是什么，它们为什么重要，以及如何有效地管理它们。
我们还将介绍一些用于处理 Kubernetes 中废弃 API 的可用工具，并提供管理废弃 API 的最佳实践。
在阅读完本文之后，您将更好地了解如何处理Kubernetes集群升级，并对您的基础设施充满信心。
API生命周期
Kubernetes遵循alpha → beta → stable的成熟度进展，并且还有一些额外的版本控制，这样资源可以在不需要进入下一个成熟度级别的情况下进行迭代。
一个alpha资源可以从v1alpha1开始，并且可以通过v1alpha2进行迭代，或者如果有破坏性的变化，可能会使用v2alpha1。一个beta API可能与alpha API具有相同的规范，但是成熟度和与用户的约定将会有所不同。
- Alpha API是实验性的。它们可能存在错误和不兼容的更改。它们不是默认启用的，您应该谨慎使用。
- Beta API经过充分测试，并默认启用。它们可以被依赖于未来的功能，但其实现可能会根据用户反馈或可扩展性等约束而发生变化。
- 稳定的API不会有“beta”或“alpha”名称。它们用版本号表示（例如，v1），其实现不应该在不更改版本号的情况下进行破坏性更改。
我提到的生命周期如下所示：
- 如果一个API同时存在多个版本，Kubernetes API 可能会自动为您升级其中一些版本。然而，您仍应确保您拥有正确的资源方案，特别是因为随着 alpha API 的成熟，方案可能会在不同版本之间发生变化。
- 如果一个API同时有多个版本可用，Kubernetes API可以为您悄悄地升级其中一些版本。然而，您仍应确保您拥有正确的资源方案，特别是因为随着alpha API的成熟，方案可能会在不同版本之间发生变化。
您可以在这里查看k8s API概述，例如，部署属于应用程序组，并具有v1版本。
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/
可以列出它们：
/apis/apps/v1/namespaces/{namespace}/deployments淘汰和移除Kubernetes API
如果您正在运行过时的Kubernetes API版本，那么您的应用程序就面临着可能导致大量停机时间的风险。即使升级不会导致停机，Kubernetes API的微小差异也可能导致烦恼和浪费精力去调查潜在问题。
在这个场景中，弃用意味着确定一个 API 组件最终会被移除。虽然它目前仍在运行，但计划在即将发布的版本中被淘汰。Kubernetes 遵循明确定义的弃用政策，通知用户哪些 API 将被移除或修改。
Kubernetes API作为与Kubernetes集群交互的接口，允许用户查询和操作各种Kubernetes对象，如pod、命名空间和部署。这些API可以通过诸如kubectl之类的工具、直接通过REST API，或者使用客户端库来访问。随着Kubernetes的发展，旧的API被标记为弃用，并最终被淘汰。这凸显了用户或维护者需要意识到弃用的Kubernetes API的重要性。
弃用的Kubernetes API 的关注点
在配置Kubernetes中的应用程序时，用户需要在YAML清单或Helm图表中的apiVersion字段中指定所使用的Kubernetes对象的API版本，这是一个关键的方面。这强调了用户和维护人员需要及时了解已弃用的Kubernetes API版本及其在即将发布的版本中计划移除的重要性。
在 Kubernetes 集群升级过程中，遇到废弃的 API 可能会成为一个潜在问题，特别是如果升级后的版本不再支持这些 API。例如，如果您集群中的资源使用了过时的 API 版本，那么依赖该资源的应用程序可能因为新集群版本中废弃的 API 而无法正常运行。这种情况可能导致显著的停机时间，就像 Reddit 的全站宕机一样。
一个具体的案例是在Kubernetes版本v1.22中移除了Ingress资源的APIVersion extensions/v1beta1。在您的配置中尝试使用已移除的API版本将导致错误消息。
Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Ingress" in version "extensions/v1beta1"K8s APIs的使用方式
要在您的配置中指定特定的API版本，请参考下面的示例，该示例摘自Kubernetes文档：
apiVersion: apps/v1 <------ API Version of the kubernetes objectapiVersion: apps/v1 <------ API Version of the kubernetes object
kind: Deployment
metadata:
name: nginx您可以通过官方文档或使用kubectl命令行工具的api-versions命令来查看所有支持的API组及其版本。
kubectl api-versions
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1识别弃用的API所面临的挑战
识别集群中利用已弃用API的资源可能会相当具有挑战性。此外，Kubernetes遵循严格的API版本控制协议，导致在多个发布版本中多次弃用v1beta1和v2beta1的API。
他们的政策规定，Beta API 版本在弃用后必须至少获得 9 个月或 3 个发布版本（以较长者为准）的支持，之后可能会被移除。
在一些情况下，如果被弃用的API仍然被工作负载、工具或其他与集群接口的组件所积极使用，可能会导致中断发生。
因此，用户和管理员必须对其集群进行彻底评估，以确定任何即将移除的正在使用的API，并随后迁移受影响的组件，以利用适当的新API版本。
管理弃用的Kubernetes API 的工具
解决处理过时的Kubernetes API 问题，可以采用几种工具：
工具1：FairwindsOps的Pluto — 自动化检测和GitHub集成
FairwindsOps推出了Pluto，这是一个自动化解决方案，用于检测代码存储库和Helm发布中已弃用的Kubernetes API。通过无缝集成GitHub工作流程，Pluto确保持续监控，及时识别已弃用的API，并进行积极的管理。
工具2：Kube No Trouble (kubent) by doitintl — 全面的集群范围检查
由doitintl开发，Kube No Trouble (kubent) 专注于对过时API的全面集群级检查，重点关注部署以进行检测。该工具需要存储原始清单，提供了一个全面的解决方案，用于识别和解决Kubernetes集群中的过时API。
工具3：Helm MapkubeAPIs插件 — 基于图表的API识别
The Helm MapkubeAPIs Plugin是一个有价值的工具，用于识别在集群上安装的Helm charts中已弃用的API。该插件提供了一种有针对性的方法来管理API的弃用，确保在升级过程中兼容性和平稳过渡。
工具 4：Plural CD — 多功能 API 管理
Plural CD，可全面管理已弃用的Kubernetes API。其多方面的能力有助于在Kubernetes升级期间实现更顺畅的过渡，使其成为识别和有效处理已弃用API的重要组成部分。
这些工具共同帮助用户主动识别和解决已弃用的API，最大限度地减少在Kubernetes升级过程中可能出现的问题。通过将这些工具无缝地整合到您的工作流程中，您可以确保平稳过渡到更新的API版本，提高Kubernetes基础架构的整体稳定性和可靠性。
结论
Kubernetes API被设计为灵活且经常变化，这是其核心优势之一。
用户必须知道他们的资源正在使用哪些组和版本，以确保与当前的Kubernetes API兼容。资源通常可以在没有用户操作的情况下被修改并存储为更新的资源，从而实现逐步的模式更改，并增强对API升级的信心。
重要的是通过工具静态验证资源或使用转换 Webhook 自动转换资源，安全地将资源从一个版本迁移到另一个版本。早期添加测试将有助于增强长期使用 Kubernetes 的信心。
