升级集群时如何处理基于 kops 的 kubernetes api 的更新？答案

【问题标题】：How to approach update of kops based kubernetes api's when upgrading the cluster?升级集群时如何处理基于 kops 的 kubernetes api 的更新？
【发布时间】：2021-03-25 10:59:29
【问题描述】：

目前，我们运行 15 版的基于 kops 的集群。我们计划先将其升级到 16 版，然后再进一步升级。但是，yaml 中各种 kubernetes 服务的 api 版本也需要更改。在集群升级之前，您将如何解决这个问题？有没有办法用不兼容的 api 版本枚举集群中的所有对象，或者最好的方法是什么？我怀疑 kops 创建的对象，例如kube-system 对象会自动升级。

【问题讨论】：

您好，您有没有偶然查看过这篇博文？ tauceti.blog/post/kubernetes-upgrade-nodes-1.15-1.16

标签： kubernetes kops kubernetes-upgrade

【解决方案1】：

当您升级集群时，API 服务器将负责升级集群中的所有现有资源。当您想要部署更多资源并且升级后这些资源仍在使用旧的 API 版本时，就会出现问题。在这种情况下，您的部署（比如kubectl apply）将会失败。

即集群中已经运行的任何东西都不会中断。但如果他们仍然使用旧版本，未来的部署将会。

kOps 管理的资源已经使用新的 API 版本。

【讨论】：

Ole，感谢您的回答，但我需要知道如何枚举使用 api 部署的所有资源，这些资源将在下一个版本中过时，例如查看所有已部署对象的当前 api 版本，并将它们与将在下一个 kube 版本（升级后）中使用的 api 版本进行比较。 IE。我想在 kubernetes 升级之前更新我的 yaml 文件以避免运行 kubectl create -f anydeployment.yaml 时出现此类问题
抱歉不清楚。您谈论的版本仅适用于 API。一旦部署到集群，它就不再作为固定的 API 版本存在。就像一个资源对象。您可以请求现有资源作为任何受支持的版本。例如，您可以同时执行 kubectl get hpa.v2beta2.autoscaling -o yaml 和 kubectl get hpa.v1.autoscaling -o yaml 并且响应将在指定的 API 版本上。即您不能使用任何服务器端验证您的 yaml 文件。好消息是，从 1.19 开始，如果您尝试创建/应用已弃用的资源版本，API 服务器会发出警告。
这种情况下，在集群（kubernetes）升级之前，需要将yaml文件更新为api版本，当前集群版本和下一个集群（kubernetes）版本都支持。据我所知，我需要手动挖掘特定 kubernetes 版本的文档并在此基础上更新 yaml 文件。