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工具的集群：

图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就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。