Kubernetes：如何自动检测和处理弃用的API
作者：Stepan Stipl，DoiT International高级云架构师。客座文章最初在DoiT International博客上发表。
https://blog.doit-intl.com/kubernetes-how-to-automatically-detect-and-deal-with-deprecated-apis-f9a8fc23444c
随着Kubernetes 1.16可用一段时间，并开始在许多托管Kubernetes平台上缓慢推出，你可能听说过API弃用（deprecation）。虽然处理起来相当简单，但是如果无人参与，这种更改可能会严重地中断你的服务。
API弃用是什么？
随着Kubernetes的特性集的发展，API也必须发展以支持这种变化。有一些规则旨在保证兼容性和稳定性。这种情况不会在每个版本中都发生，但最终，你将不得不使用新的API版本和格式，因为旧的API将不再受支持。
https://kubernetes.io/docs/reference/using-api/deprecation-policy/
为什么这对于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，以免这些API给你带来任何麻烦。
现在kubent工具还为时过早，如果你觉得它有用，我很乐意听到任何评论和建议。安全的航行！⛵⛵⛵
额外参考：
- Kube-No-Trouble - kubent GitHub仓库 - https://github.com/doitintl/kube-no-trouble
- 1.16中删除了弃用API：Vallery Lancey博客文章告诉你需要知道的 - https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/
在DoiT International与Stepan工作！在我们的职业网站上申请工程职位。
http://careers.doit-intl.com/