如何自动检测、处理 K8s 弃用 API

作者：Jessie

翻译：Bach（才云）

校对：星空下的文仔（才云）、bot（才云）

随着 Kubernetes v1.16 推出了一段时间，许多 Kubernetes 托管平台已开始使用，大家应该已经听说过弃用 API（API Deprecation），这事看似简单，但如果不加注意，也会严重影响服务。

K8sMeetup

什么是弃用 API？

随着 Kubernetes 功能的发展，API 也必须跟着发展以支持变化，不是每个版本都会出现这种情况，但最终，我们都必须使用新版本和新格式的 API，因为旧的 API 版本和格式不再被支持。

K8sMeetup

为什么 v1.16 特别重要？

在 Kubernetes 之前版本中保留的一些弃用 API，在 v1.16 中被彻底删除，即以下 API Group 和版本：

• Deployment — extensions/v1beta1、apps/v1beta1 和 apps/v1beta2

• NetworkPolicy — extensions/v1beta1

• PodSecurityPolicy — extensions/v1beta1

• DaemonSet — extensions/v1beta1 和 apps/v1beta2

• StatefulSet — apps/v1beta1 和 apps/v1beta2

• ReplicaSet — extensions/v1beta1、apps/v1beta1 和 apps/v1beta2

如果我们在 v1.16 中，尝试使用其中任何一种来创建资源，都会完全失败。

K8sMeetup

如何检查是否受影响？

我们可以手动遍历所有 manifest ，但这会非常耗时，并且如果有多个团队部署在集群中，或者没有将所有 manifest 放在一个地方，那么很容易会漏掉。这种做法也有点不切实际，不过 **Kube-No-Trouble（kubent）**在此就可以发挥其作用。

K8sMeetup

如何检测？

我们通常无法访问有关用于创建资源的 API 版本信息，因为资源会在首选存储版本（preferred storage version）中转换并存储，但如果使用 kubectl 或 Helm 来部署资源，原始 manifest 会存储在集群中，我们就可以使用了。

K8sMeetup

如何解决该问题？

最简单直接的方法是安装这个：

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

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

配置 kubectl 的当前上下文（current context）以指向要检查并运行 kubent 工具的集群：

Kubent 运行输出例子

Kubent 会连接到集群，检索所有可能受影响的资源，扫描并打印这些资源的 Summary。

我们也可以使用 -f json flag 获取 JSON 格式的输出，如果要将其集成到 CI/CD 管道中或进一步处理结果，该格式会更合适。

K8sMeetup

如何处理检测到的资源？

在某些时候，这和在 manifest 中更改 apiVersion 一样简单，但有时候，其结构已经更改并且需要调整。另外，不同版本会有许多默认值更改，因此，仅更改 apiVersion 并应用相同的 manifest，我们可能得到不同的结果。例如 StatefulSet 的 updateStrategy.type 从 OnDelete 更改为 RollingUpdate，就会导致不同的结果。

以前使用的 kubectl convert 命令现在已经弃用了，并且对于前面提到的默认值，它可能无法正确转换资源。

**最好的方法是简单地应用资源（如果已经拥有了使用 kubent 检测过的资源）并使用新版本 API。**这可以确保将资源正确转换为新版本。有一点我们要注意，kubectl 对于返回的版本有些不确定性（Non-Deterministic），所以要请求特定的 API 版本，最好使用完整格式：

kubectl get ingress.v1beta1.extensions -o yaml

希望这可以帮助大家在 Kubernetes 集群中检测和处理弃用 API，以避免出现问题。

原文链接：https://mp.weixin.qq.com/s/7KnFSvyz3Gz-FEir5kBq6g