技能介绍

要解决的问题

Kubernetes 每个大版本都会移除一批已弃用的 API。比如 extensions/v1beta1、apps/v1beta1 在 1.16 中被删除，networking.k8s.io/v1beta1 在 1.22 中消失。如果你的清单还在使用这些版本，升级集群后轻则资源无法创建，重则工作负载直接不可用——而问题往往要等到升级完成、发布时才暴露。

手工排查并不现实：仓库里可能有几十个 YAML 和 Helm chart，实时集群里还有历史遗留的 CRUD 资源没人记得是谁创建的。这个技能的目标就是在升级窗口开启之前，把所有引用了即将移除 API 的地方找出来。

技能如何工作

核心是调用 Pluto——FairwindsOps 维护的 API 版本检测工具。它的工作方式分三步：

收集目标：可以指定 Helm chart、一组 YAML 清单，或者直接连接实时集群，检测集群内正在运行的资源。
比对清单：Pluto 内置各 Kubernetes 版本中「已弃用」和「已移除」的 API 版本列表，将扫描到的 apiVersion 与目标升级版本的列表比对。
输出结果：列出哪些文件或资源命中了弃用规则，方便你在升级前逐项修复，比如把 extensions/v1beta1 的 Deployment 迁移到 apps/v1。

技能内置了 Pluto 的安装与调用约定，并提供了可直接接入 CI 的 GitHub Action 用法，可以把检测步骤挂在流水线里，在合并前就拦住不兼容的变更。

适用边界与注意点

只做版本检测，不做渲染校验：Pluto 告诉你某个 API 版本是否会被移除，不会验证资源本身的字段是否合法。修复后的清单仍需经过 kubectl apply --dry-run 或 kube-score 这类工具检查。
需要 Pluto 二进制和集群访问权：扫描实时资源时需要有效的 kubeconfig；只扫清单则不需要集群权限，但 Pluto 必须提前安装。
容器镜像源已迁移：上游镜像已从 Docker Hub 迁至 us-docker.pkg.dev/fairwinds-ops/oss/pluto，使用容器方式部署时需同步更新拉取地址，避免拉不到镜像。
清单来源要可靠：检测覆盖率取决于你能提供多少输入。只扫仓库不扫集群，漏掉的历史遗留资源就不会被发现——建议两者都跑一遍再开升级窗口。

截图预览

使用场景

计划把集群从K8s 1.21升级到1.24前，扫描仓库内所有Helm chart和YAML清单，找出引用了`networking.k8s.io/v1beta1`等1.22移除API的资源，提前修复避免升级后失效。
准备发布新版本应用到生产集群前，检查应用依赖的所有CRD和工作负载的apiVersion，确认在目标集群版本中未被标记为弃用或移除。
接手维护一个运行超过一年的K8s集群，通过连接实时集群扫描所有运行中的资源，找出历史上遗留的、使用已弃用API版本的资源并登记修复计划。
在CI流水线中集成该技能，当开发者提交修改了K8s清单的MR时，自动扫描变更内容，阻止引入将被移除的API版本进入主分支。

适合人员

负责Kubernetes集群版本升级的运维工程师，核心诉求是提前发现集群内外引用已弃用API的资源，避免升级后工作负载故障影响业务。
需要频繁迭代Kubernetes应用的研发工程师，核心诉求是快速确认自己修改或新增的manifests中的API版本在目标集群中未被弃用，保证应用兼容新版本集群。
维护运行超过1年的历史Kubernetes集群的SRE，核心诉求是排查实时集群中遗留的、使用已弃用API版本的资源，解决升级过程中遇到的兼容性问题。
负责Kubernetes应用发布流程的DevOps工程师，核心诉求是在CI流水线中集成API版本检测，阻止引入将被移除的API版本，降低升级风险。