ingress-nginx 是独立 kubernetes 控制器，不编译进 go 应用；go 服务须监听 0.0.0.0:8080，service 必须为 clusterip 且 selector、targetport 严格匹配，ingress 中 service.name、ingressclassname、namespace 等必须准确对齐，否则导致 502/404。
Ingress-nginx 不是 Go 应用的一部分，它不编译进你的 main.go，也不运行在你的 Go 进程里；它是一个独立的 Kubernetes 控制器，只负责把外部请求按规则转发给你的 Go 服务对应的 Service。部署失败，90% 是因为没对齐 Service 名、标签、端口或 Ingress 配置项。
Go 服务必须监听 0.0.0.0，不能只绑 127.0.0.1
Kubernetes 的 Service 通过 ClusterIP 访问 Pod，流量路径是：Ingress → Service → Pod IP → 容器端口。如果 Go 程序写成 http.ListenAndServe("127.0.0.1:8080", handler)，它只接受本容器内的回环请求，Service 流量根本进不来，结果就是 502 或连接拒绝。
- 正确写法：
http.ListenAndServe(":8080", handler)（等价于0.0.0.0:8080） - 更推荐显式写法：
http.ListenAndServe("0.0.0.0:8080", handler)，避免歧义 - Dockerfile 中确保暴露端口：
EXPOSE 8080 - 检查 Pod 日志是否报错
listen tcp 127.0.0.1:8080: bind: cannot assign requested address—— 这是典型绑定错误
Service 必须是 ClusterIP，且 selector 和 targetPort 要严格匹配
Ingress 只能转发到 type: ClusterIP 的 Service。NodePort 或 LoadBalancer 类型虽然也能访问，但会绕过 Ingress 控制逻辑，导致 path 路由、TLS 终止等功能失效。
-
spec.selector必须和 Pod 的metadata.labels完全一致，比如 Pod 有app: my-go-api，Service 的 selector 就得是app: my-go-api，拼错一个字母就匹配不上 -
ports.targetPort必须等于 Go 程序实际监听的端口，例如http.ListenAndServe(":8080", ...)→targetPort: 8080；若写成targetPort: http，需确保容器ports.name也定义为http - 别漏掉
ports.port（Service 暴露的端口），它会被 Ingress 的service.port.number引用
Ingress 资源中 service.name 和 ingressClassName 必须准确无误
从 ingress-nginx v1.0+ 开始，networking.k8s.io/v1 API 要求字段名变更，旧写法直接报错；同时多控制器场景下，ingressClassName 是硬性要求。
-
spec.rules.http.paths.backend.service.name必须等于你定义的Service的metadata.name，不是 Deployment 名，也不是容器名 -
spec.ingressClassName必须和集群中已存在的IngressClass对象名一致，比如你用 Helm 安装时设了controller.ingressClassResource.name: prod，这里就得填prod -
pathType推荐用Prefix；若需精确匹配/api而非/api/xxx，得配合 annotation：nginx.ingress.kubernetes.io/use-regex: "true"+ 正则路径path: ^\/api$ - 检查
kubectl get ingress输出的ADDRESS列：为空说明 ingress-nginx 控制器没就绪，或没监听该 Ingress（比如 namespace 不匹配、IngressClass 不存在）
调试时优先查三处状态和日志，别改 Go 代码
502 Bad Gateway / 404 Not Found / timeout 不代表 Go 服务挂了，大概率是基础设施链路断在某一层。
- 查 Ingress 状态：
kubectl describe ingress <name></name>，看 Events 是否有Failed to fetch endpoints或no corresponding IngressClass - 查 Service 是否匹配到 Pod：
kubectl get endpoints <service-name></service-name>，输出为空说明 selector 没匹配上任何 Pod - 查 ingress-nginx 控制器日志：
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller，重点搜no endpoints、upstream connect error、invalid ingress - 跳过所有中间环节直连测试：
kubectl port-forward svc/<your-service> 8080:80</your-service>，然后curl localhost:8080/health—— 如果通，问题一定出在 Ingress 配置或控制器本身
最容易被忽略的是：Ingress 资源和 Service 必须在同一个 namespace；Ingress 的 service.port.number 必须和 Service 的 ports.port 数值一致（不是 targetPort）；以及 Helm 安装 ingress-nginx 时若自定义了 controller.ingressClassResource.controllerValue，Ingress 的 ingressClassName 必须和它完全对应，包括协议前缀（如 k8s.io/ingress-prod）。这些地方错一个字符，整个链路就静默失败。
