必须使用 networking.k8s.io/v1 版本创建 Ingress，Kubernetes ≥ 1.22 已移除 extensions/v1beta1；client-go 需 v0.22.0+，结构体为 networkingv1.Ingress，字段首字母大写，更新须先 Get 再 Modify 并携带 ResourceVersion，且需正确设置 ingressClassName 和 service.name（同 namespace、大小写敏感）。
更新 Ingress 必须用 networking.k8s.io/v1 版本
用 extensions/v1beta1 会报错或静默失败，尤其是 Kubernetes ≥ 1.22 后该 API 已彻底移除。当前稳定版是 networking.k8s.io/v1，client-go 调用时必须匹配这个 group/version，否则出现 the server could not find the requested resource 或 unknown object type "nil"。
对应结构体是 networkingv1.Ingress，不是 v1beta1.Ingress；IngressSpec 字段名首字母大写，小写（如 spec）会导致字段被忽略。
- 检查 client-go 版本是否支持 v1：v0.22.0+ 才完整支持
networkingv1 - 创建对象时必须显式设置
ObjectMeta.Name、ObjectMeta.Namespace和apiVersion: "networking.k8s.io/v1"、kind: "Ingress" - 旧代码里用
ExtensionsV1beta1().Ingresses()的调用要全部替换成NetworkingV1().Ingresses()
更新前必须先 Get 再 Modify，否则 409 Conflict
Update() 不是“补丁式更新”，它要求提交的对象带完整的 ResourceVersion。直接 new 一个 Ingress 结构体然后调用 Update()，一定会返回 409 Conflict。
正确流程是：Get() 当前资源 → 修改 .Spec.Rules 或 .Spec.IngressClassName 等字段 → 调用 Update()。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要覆盖整个
Spec，只改需要的部分，比如只增删Rules里的某条 host 规则，避免意外清空TLS或Annotations - 如果只是加一个新 host，把原
Rules切片 append 进去即可，不用重建整个规则树 - 注意
pathType字段：Kubernetes v1 默认为"ImplementationSpecific"，但 nginx-ingress 实际按"Prefix"处理；若需精确匹配，显式设为"Exact"
Host 和 Service 名字大小写敏感且必须同 namespace
spec.rules[].host 是字符串匹配，不解析 DNS；spec.rules[].http.paths[].backend.service.name 必须和目标 Service 的 metadata.name 完全一致（包括大小写），且两者必须在同一个 namespace 下。
常见错误现象：Ingress 更新成功，但 curl 返回 503 或 404。这时大概率是后端 service 名写错，或者 service 根本不存在于该 namespace。
- 用
kubectl get svc -n <ns></ns>确认 service 名和 namespace - 用
kubectl get ingress -n <ns> -o yaml</ns>检查生成的 Ingress 对象是否真的包含你期望的 host 和 service.name - 不要在
service.name里写命名空间前缀，例如default/my-service是非法的 - 如果 service port 是命名端口（如
http），用service.port.name；如果是数字端口，用service.port.number
更新后 Controller 不生效？先看 ADDRESS 和 Events
Ingress 对象更新成功 ≠ 流量马上通。真正起作用的是 Ingress Controller（如 nginx-ingress），它需要监听到变更并 reload 配置。最快速验证方式是看 kubectl get ingress 输出的 ADDRESS 列是否非空。
如果 ADDRESS 为空，说明 Controller 没有识别到这个 Ingress —— 常见原因是没指定 ingressClassName，或 Controller 没配置监听该 class。
- 确认 Ingress 中设置了
spec.ingressClassName，且值与 Controller 的ingressclass资源名一致（如"nginx"） - 检查 Controller Pod 是否 running：
kubectl get pod -n ingress-nginx - 查 Controller 日志：
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller | grep -i "example-ingress" - Controller 通常有 1–3 秒延迟，不要一更新完就立刻 curl；可加
kubectl wait等待就绪
ingressClassName 字段和 ResourceVersion 的获取逻辑。这两点不处理好，代码编译通过、API 调用也返回 success，但 Ingress 就是不生效，排查起来反而比语法错误更耗时间。 
