集群从 1.24 升到 1.29，apply 旧的 Ingress 清单直接报 no matches for kind Ingress in version extensions/v1beta1。日志里能对上时间点，这种反而好排。
extensions/v1beta1 和 networking.k8s.io/v1beta1 在 1.22 之后被移除，apiserver 不再提供这个版本。清单里的 apiVersion 没改，kubectl 找不到对应资源。这一点先确认清楚，后面就不用反复试。
kubectl api-resources | grep ingress kubectl convert -f old-ingress.yaml --output-version networking.k8s.io/v1 > new-ingress.yaml kubectl apply --dry-run=server -f new-ingress.yaml
围绕「API 版本废弃」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。改完隔一天再看一次，当场正常不代表能稳住。
测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
处理上按这个顺序：用 api-resources 查当前集群支持的 Ingress 版本；把 apiVersion 改成 networking.k8s.io/v1 补上 pathType 和 backend.service；用 kubectl convert 批量转旧清单 再人工核对字段；Helm chart 里的 capabilities 判断也要同步改。
结果对不对很好判断，dry-run 通过 apply 后 kubectl get ingress 能看到新对象。