共计 1704 个字符，预计需要花费 5 分钟才能阅读完成。
作者：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
