Kubernetes中如何自动检测和处理弃用的API

这篇文章给大家介绍Kubernetes中如何自动检测和处理弃用的API,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。

网站的建设创新互联公司专注网站定制,经验丰富,不做模板,主营网站定制开发.小程序定制开发,H5页面制作!给你焕然一新的设计体验!已为成都玻璃钢坐凳等企业提供专业服务。

随着Kubernetes 1.16可用一段时间,并开始在许多托管Kubernetes平台上缓慢推出,你可能听说过API弃用(deprecation)。虽然处理起来相当简单,但是如果无人参与,这种更改可能会严重地中断你的服务。

API弃用是什么?

随着Kubernetes的特性集的发展,API也必须发展以支持这种变化。有一些规则旨在保证兼容性和稳定性。这种情况不会在每个版本中都发生,但最终,你将不得不使用新的API版本和格式,因为旧的API将不再受支持。

为什么这对于1.16版本如此重要?

在最近几个K8s版本中保留了一些弃用的API,最终在Kubernetes 1.16版本中被完全删除。即以下API组和版本:

  • Deployment — extensions/v1beta1, apps/v1beta1 and apps/v1beta2

  • NetworkPolicy — extensions/v1beta1

  • PodSecurityPolicy — extensions/v1beta1

  • DaemonSet — extensions/v1beta1 and apps/v1beta2

  • StatefulSet — apps/v1beta1 and apps/v1beta2

  • ReplicaSet — extensions/v1beta1, apps/v1beta1 and apps/v1beta2

如果尝试在1.16中使用其中之一创建资源,操作将会失败。

如何检查我是否受到影响?

你可以手动遍历所有清单,但这可能相当耗时。如果有多个团队部署到集群中,或者在一个地方没有当前的所有清单,那么很容易丢失一些清单,并且可能非常不实际。这就是kubent(Kube-No-Trouble)来帮忙的地方。

问题是什么?

用于创建给定资源的API版本的信息通常是不容易找到,因为资源总是在内部转换为首选存储版本并存储在首选存储版本中。然而。如果你使用kubectl或Helm来部署资源,原始清单也存储在集群中,我们可以利用它。如果是kubectl,则形式为kubectl.kubernetes.io/last-applied-configuration注释;如果是Helm,则形式为ConfigMap或Secret。

如何解决弃用产生的问题

最简单的方法是安装:

sh -c "$(curl -sSL 'https://git.io/install-kubent')"

这将把kubent的最新版本安装到/usr/local/bin中。

(如果你和我一样,不相信别人在博客文章中发布的随机脚本,请下载针对你的平台的最新版本,然后解压缩到你喜欢的任何地方。)

配置kubectl的当前上下文,以指向你想要检查和运行kubent工具的集群:

Kubernetes中如何自动检测和处理弃用的API

图1:kubent运行的示例输出

Kubent将连接到你的集群,检索所有可能受到影响的资源,扫描并打印那些受到影响的资源的摘要。

你还可以使用-f json标记来获得JSON格式的输出,这更适合让你将其集成到你的CI/CD流水线中或进一步处理结果。关于可用配置选项的更多细节在doitintl/kube-no-trouble仓库的README文件中描述。

我应该如何处理检测到的资源?

在某些情况下,这就像改变manifest中的apiVersion一样简单,但在其他情况下,结构可能已经改变,需要调整。另外,要注意,版本之间有很多默认值会发生变化(关于这方面的好文章是David Schweikert的Kubernetes 1.16 API deprecations and changed defaults),因此,仅更改apiVersion并应用相同的清单,就会得到不同的结果。例如,StatefulSet的updateStrategy.type从OnDelete更改为RollingUpdate,导致了非常不同的行为。

https://medium.com/google-cloud/kubernetes-1-16-api-deprecations-and-changed-defaults-e53ccc5c73d5

以前使用的kubectl convert命令现已弃用,可能不能根据前面提到的默认值正确地转换资源。

最好的方法可能是简单地应用资源(如果你使用kubent检测到它们,那么你已经有了这些资源)并从API检索新版本。这将确保资源被正确地转换为新版本。你可能已经注意到,kubectl在某种程度上不确定地返回的版本。要请求一个特定的API版本,使用完整的形式:

kubectl get ingress.v1beta1.extensions -o yaml

关于Kubernetes中如何自动检测和处理弃用的API就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。


分享名称:Kubernetes中如何自动检测和处理弃用的API
分享URL:http://azwzsj.com/article/gpcscp.html