Kubernetes 1.22+升级后需将YAML中networking.k8s.io/v1beta1等弃用API替换为v1版本，并调整字段结构：Ingress移除spec.backend、改用rules[].http.paths[].backend.service；删除spec.template.spec.restartPolicy；用pluto或kubectl命令定位弃用资源，再通过--dry-run验证。
在Kubernetes集群升级到1.22及以上版本后，原有YAML中使用的networking.k8s.io/v1beta1或extensions/v1beta1等API版本会直接被拒绝应用，报错如“no matches for kind 'Ingress' in version 'networking.k8s.io/v1beta1'”，此时资源创建或更新将失败，业务发布卡住。
确认当前集群支持的API版本
执行kubectl api-versions，查找输出中是否包含networking.k8s.io/v1、apps/v1等v1级稳定版本，排除v1beta1类条目。若无v1版本，说明集群版本过低，需先升级集群而非修改YAML。
这一步不能跳过——用错API版本提交后，kubectl会立即返回404或NoMatchError，且不会留下任何事件记录，排查时容易误判为网络或权限问题。
批量定位弃用API资源
方法一：使用pluto工具扫描全集群
下载并运行pluto：curl -sSL https://raw.githubusercontent.com/FairwindsOps/pluto/main/hack/install.sh | bash，然后执行pluto detect-files -d ./k8s-yamls/ --output wide。它会列出所有含弃用API的文件路径、资源类型、旧版本及推荐替换版本。
方法二：用kubectl原生命令快速抽查
执行kubectl get ingress,ingressclasses,deployments,statefulsets -A --show-labels 2>/dev/null | grep -E 'v1beta1|extensions/v1beta1'，能快速暴露正在运行但已弃用的资源实例。注意：该命令仅显示当前存活资源，不覆盖未部署的YAML文件。
【必须先运行此步再改YAML】否则可能把已在线上稳定运行半年的Ingress从v1beta1硬切到v1，触发字段兼容性问题（如v1中rules[].http.paths[].backend必须改为rules[].http.paths[].backend.service）。
逐类修复YAML中的API版本与字段
第一步：替换apiVersion字段
将apiVersion: networking.k8s.io/v1beta1统一改为apiVersion: networking.k8s.io/v1；将apiVersion: extensions/v1beta1改为apiVersion: apps/v1（Deployment/StatefulSet）或apiVersion: batch/v1（Job/CronJob）。
第二步：校验并调整关键字段结构
Ingress资源在v1版本中，spec.backend字段已被移除，必须改用spec.rules[].http.paths[].backend.service.name和.port.name或.port.number；若原YAML用了spec.tls[].secretName，需确认Secret确实存在于对应Namespace，v1版本对此校验更严格，缺失即报错。
第三步：删除已废弃的顶层字段
v1版本不再支持spec.template.spec.restartPolicy（仅限OnFailure和Always有效，且Deployment中必须为Always），若YAML中显式写了restartPolicy: Always，必须整行删除，否则apply时提示“invalid value 'Always'”。
第四步：验证修改后YAML语法有效性
用kubectl apply --dry-run=client -f your-file.yaml -o yaml执行客户端预检，成功输出渲染后YAML即表示语法与API版本匹配；若报错，则根据提示精确定位到哪一行哪个字段不合法，而不是盲目重试。
