随着新功能和功能的增加，旧的API被弃用并最终移除。虽然这是Kubernetes发展的必要部分，但对于依赖该平台运行应用程序的组织来说，这可能会带来挑战。
Kubernetes API作为与K8集群交互的接口。如果集群中仍在使用已弃用的API，可能会导致中断不可用。
在这篇博客文章中，我们将探讨被弃用的Kubernetes API是什么，它们为什么重要，以及如何有效地管理它们。
我们还将介绍一些用于处理 Kubernetes 中废弃 API 的可用工具，并提供管理废弃 API 的最佳实践。
在阅读完本文之后，您将更好地了解如何处理Kubernetes集群升级，并对您的基础设施充满信心。
Kubernetes遵循alpha → beta → stable的成熟度进展，并且还有一些额外的版本控制，这样资源可以在不需要进入下一个成熟度级别的情况下进行迭代。
一个alpha资源可以从v1alpha1开始，并且可以通过v1alpha2进行迭代，或者如果有破坏性的变化，可能会使用v2alpha1。一个beta 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的微小差异也可能导致烦恼和浪费精力去调查潜在问题。
在这个场景中，弃用意味着确定一个 API 组件最终会被移除。虽然它目前仍在运行，但计划在即将发布的版本中被淘汰。Kubernetes 遵循明确定义的弃用政策，通知用户哪些 API 将被移除或修改。
Kubernetes API作为与Kubernetes集群交互的接口，允许用户查询和操作各种Kubernetes对象，如pod、命名空间和部署。这些API可以通过诸如kubectl之类的工具、直接通过REST 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"要在您的配置中指定特定的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-versionsadmissionregistration.k8s.io/v1admissionregistration.k8s.io/v1beta1apiextensions.k8s.io/v1apiextensions.k8s.io/v1beta1apiregistration.k8s.io/v1apiregistration.k8s.io/v1beta1apps/v1识别集群中利用已弃用API的资源可能会相当具有挑战性。此外，Kubernetes遵循严格的API版本控制协议，导致在多个发布版本中多次弃用v1beta1和v2beta1的API。
他们的政策规定，Beta API 版本在弃用后必须至少获得 9 个月或 3 个发布版本（以较长者为准）的支持，之后可能会被移除。
在一些情况下，如果被弃用的API仍然被工作负载、工具或其他与集群接口的组件所积极使用，可能会导致中断发生。
因此，用户和管理员必须对其集群进行彻底评估，以确定任何即将移除的正在使用的API，并随后迁移受影响的组件，以利用适当的新API版本。
解决处理过时的Kubernetes API 问题，可以采用几种工具：
FairwindsOps推出了Pluto，这是一个自动化解决方案，用于检测代码存储库和Helm发布中已弃用的Kubernetes API。通过无缝集成GitHub工作流程，Pluto确保持续监控，及时识别已弃用的API，并进行积极的管理。
由doitintl开发，Kube No Trouble (kubent) 专注于对过时API的全面集群级检查，重点关注部署以进行检测。该工具需要存储原始清单，提供了一个全面的解决方案，用于识别和解决Kubernetes集群中的过时API。
The Helm MapkubeAPIs Plugin是一个有价值的工具，用于识别在集群上安装的Helm charts中已弃用的API。该插件提供了一种有针对性的方法来管理API的弃用，确保在升级过程中兼容性和平稳过渡。
Plural CD，可全面管理已弃用的Kubernetes API。其多方面的能力有助于在Kubernetes升级期间实现更顺畅的过渡，使其成为识别和有效处理已弃用API的重要组成部分。
这些工具共同帮助用户主动识别和解决已弃用的API，最大限度地减少在Kubernetes升级过程中可能出现的问题。通过将这些工具无缝地整合到您的工作流程中，您可以确保平稳过渡到更新的API版本，提高Kubernetes基础架构的整体稳定性和可靠性。
Kubernetes API被设计为灵活且经常变化，这是其核心优势之一。
用户必须知道他们的资源正在使用哪些组和版本，以确保与当前的Kubernetes API兼容。资源通常可以在没有用户操作的情况下被修改并存储为更新的资源，从而实现逐步的模式更改，并增强对API升级的信心。
重要的是通过工具静态验证资源或使用转换 Webhook 自动转换资源，安全地将资源从一个版本迁移到另一个版本。早期添加测试将有助于增强长期使用 Kubernetes 的信心。
本文链接：http://www.28at.com/showinfo-26-66191-0.html管理弃用的Kubernetes API：优秀实践和工具
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 深入C++异常处理：构建健壮程序的利器
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
