必须使用 networking.k8s.io/v1 API 创建 Ingress，spec.tls 独立配置且 secret 需同 namespace，spec.rules 为 host+path 列表，更新时注意 ingressClassName 和 host 变更限制，PathType 需用常量且兼容 controller 特性。
如何用 client-go 创建和更新 Ingress 资源
直接操作 Ingress 的核心是使用 client-go 的 NetworkingV1().Ingresses() 接口。Kubernetes 1.19+ 默认启用 networking.k8s.io/v1，旧版 extensions/v1beta1 已弃用且在 v1.22+ 完全移除，必须用新 API。
- 确保
rest.Config正确加载 kubeconfig 或 in-cluster 配置，否则会报错no endpoints available for service "kubernetes" - 命名空间（
namespace）必须显式指定，""表示 default，空字符串不能省略 -
Ingress的spec.rules是列表，每条规则对应一个 host + path 组合；spec.tls独立配置，不嵌套在 rule 里 - 若要复用已有 TLS secret，secret 名必须存在于同一 namespace，且
spec.tls[].secretName字段不能为空
ingress := &networkingv1.Ingress{
ObjectMeta: metav1.ObjectMeta{
Name: "my-app-ingress",
Namespace: "default",
},
Spec: networkingv1.IngressSpec{
TLS: []networkingv1.IngressTLS{{
Hosts: []string{"app.example.com"},
SecretName: "app-tls-secret",
}},
Rules: []networkingv1.IngressRule{{
Host: "app.example.com",
IngressRuleValue: networkingv1.IngressRuleValue{
HTTP: &networkingv1.HTTPIngressRuleValue{
Paths: []networkingv1.HTTPIngressPath{{
Path: "/api",
PathType: networkingv1.PathTypePrefix,
Backend: networkingv1.IngressBackend{
Service: &networkingv1.IngressServiceBackend{
Name: "api-svc",
Port: networkingv1.ServiceBackendPort{Number: 8080},
},
},
}, {
Path: "/",
PathType: networkingv1.PathTypePrefix,
Backend: networkingv1.IngressBackend{
Service: &networkingv1.IngressServiceBackend{
Name: "web-svc",
Port: networkingv1.ServiceBackendPort{Number: 80},
},
},
}},
},
},
}},
},
}
_, err := clientset.NetworkingV1().Ingresses("default").Create(ctx, ingress, metav1.CreateOptions{})
为什么 Ingress 更新后路由不生效
常见原因不是代码逻辑错误，而是字段不可变性或控制器未就绪。Kubernetes 的 Ingress 对象中，metadata.name 和 metadata.namespace 是不可变的，但更隐蔽的问题出在 spec.ingressClassName 和 spec.rules[].host 的变更方式上。
- 修改
spec.rules内容（如增删 path、改 backend service name）是允许的，调用Update()即可生效 - 但若首次创建时没设
spec.ingressClassName，后续补上会导致部分 Ingress controller（如 nginx-ingress）忽略该资源，需先删后建 - 某些 controller（如 Traefik）要求
host必须为 FQDN，填*或空字符串会被跳过 - 检查 controller 日志：运行
kubectl logs -n ingress-nginx ingress-nginx-controller-xxxxx，搜ignored或no object
如何批量管理多个 namespace 的 Ingress 规则
client-go 不支持跨 namespace 列表查询 Ingress，必须遍历 namespace 或使用 metav1.ListOptions{FieldSelector: "metadata.namespace!=kube-system"} 全局拉取再过滤——后者更高效，但要注意 RBAC 权限。
- RBAC 中需授予
ingresses/list在all namespaces的权限，而非单个 namespace - 用
clientset.NetworkingV1().Ingresses("").List()（注意 namespace 传空字符串）获取全部 Ingress - 遍历时用
ing.Namespace区分归属，避免误操作系统 namespace（如kube-system、ingress-nginx） - 对每个 Ingress 做 patch 比全量 update 更安全，尤其当只改某条 path 时，用
Patch()+types.StrategicMergePatchType
Go 中处理 Ingress PathType 的兼容性陷阱
PathType 只有三个合法值：Exact、Prefix、ImplementationSpecific。但不同 Ingress controller 对 Prefix 的语义理解不同：nginx-ingress 要求 path 以 / 开头且不以 / 结尾（/api 合法，api/ 不合法），而 Contour 认为 /api/ 才匹配 /api/v1。
立即学习“go语言免费学习笔记（深入）”；
- 硬编码
PathType时务必用常量：networkingv1.PathTypePrefix，别用字符串"Prefix"，否则编译不报错但 runtime 失败 - 若 controller 版本较老（如 nginx-ingress < 1.0），它根本不识别
v1的PathType字段，会静默忽略整条 path - 调试技巧：用
kubectl get ingress my-app -o yaml看实际存入 etcd 的字段，确认pathType是否被截断或转成空
真正难的不是写几行 Go 代码，而是搞清你用的 Ingress controller 实际执行哪套路径匹配逻辑——它不看 Kubernetes spec，只认自己解析规则。每次升级 controller 或切换实现前，都得重验 path 行为。
