管理弃用的Kubernetes API:优秀实践和工具

开发 云计算
在这篇文章中,我们将探讨被弃用的Kubernetes API是什么,它们为什么重要,以及如何有效地管理它们。

随着新功能和功能的增加,旧的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 的信心。

责任编辑:赵宁宁 来源: 云原生运维圈
相关推荐

2023-05-04 16:08:43

2020-12-03 18:29:30

KubernetesDocker容器

2019-05-21 10:45:44

Docker架构容器

2021-05-18 08:00:00

Kubernetes容器进程

2022-09-01 08:50:22

kubernetes容器

2021-11-16 09:00:00

安全加密密钥工具

2021-05-12 10:52:38

漏洞网络安全网络攻击

2021-06-04 05:21:19

KubernetesDocker容器

2022-06-03 09:41:03

DockerKubernetes容器

2022-11-23 10:49:41

IT资产管理IT战略

2022-06-28 13:25:19

K8sPrometheusGrafana

2021-03-01 19:24:13

Kubernetes备份容器

2021-03-11 14:33:28

Kubernetes开源容器

2023-11-29 09:00:00

KubernetesDevOps

2021-06-08 10:26:10

云计算云计算产业云应用

2020-12-18 09:23:41

KubernetesDocker

2024-01-15 08:00:00

开发API文档集成

2022-12-26 07:52:33

DockerfileFROM命令

2022-05-27 05:42:34

容器云安全

2022-04-18 10:20:31

数据映射工具
点赞
收藏

51CTO技术栈公众号