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

什么是弃用 API?

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

为什么 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 中,尝试使用其中任何一种来创建资源,都会完全失败。

如何检查是否受影响?

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

如何检测?

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

如何解决该问题?

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

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 管道中或进一步处理结果,该格式会更合适。

如何处理检测到的资源?

在某些时候,这和在 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