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>,看 Events 是否有Failed to fetch endpoints或no corresponding IngressClass - 查 Service 是否匹配到 Pod:
kubectl get endpoints <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,然后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)。这些地方错一个字符,整个链路就静默失败。


















