Go微服务必须先通过ClusterIP Service暴露，再由Ingress指向该Service；Go须监听0.0.0.0:PORT而非127.0.0.1，Service的selector须与Pod标签精确匹配，Ingress中service.name、pathType和ingressClassName必须显式正确配置。
Go 微服务本身不“接入” Ingress，Ingress 是 Kubernetes 集群层面的独立控制器，它只认 Service 对象；你的 Go 服务必须先通过 ClusterIP Service 暴露，再由 Ingress 资源指向该 Service 才能对外提供 HTTP 路由——这是最常被误解、也最容易卡住部署的关键前提。
Go 服务必须监听 0.0.0.0:PORT，不能绑定 127.0.0.1
Pod 内部网络由 kube-proxy 或 CNI 插件管理，Service 的流量经 iptables/IPVS 转发到 Pod 的 IP+端口。若 Go 程序写成 http.ListenAndServe("127.0.0.1:8080", nil)，则只有本机回环可访问，Service 无法连通容器内进程。
- ✅ 正确写法：
http.ListenAndServe(":8080", nil)或http.ListenAndServe("0.0.0.0:8080", nil) - ❌ 常见错误：用
localhost:8080、127.0.0.1:8080，导致kubectl port-forward可通但Service502 - 调试建议：进 Pod 执行
curl -v http://localhost:8080/healthz，再执行curl -v http://<pod-ip>:8080/healthz</pod-ip>，两者都应成功
Service 必须是 ClusterIP 类型且 selector 精确匹配 Pod 标签
Ingress 不直接连 Pod，只连 Service；而 Service 必须靠 selector 动态发现后端 Pod。类型选错或标签不一致，Ingress 就会 404 或 502。
- ✅ 必须使用
type: ClusterIP（不是NodePort或LoadBalancer） - ✅
spec.selector必须和 Deployment 中template.metadata.labels完全一致，例如app: go-user-api - ✅
ports.targetPort必须等于 Go 程序实际监听的端口（如:8080→targetPort: 8080） - ⚠️ 注意：Deployment 的
metadata.name和 Service 的metadata.name可以不同，但 Ingress 里写的service.name必须等于 Service 的metadata.name
Ingress 资源中 service.name 和 pathType 必须显式指定
Kubernetes v1.22+ 默认启用 networking.k8s.io/v1 API，旧版字段已废弃。写错字段名或漏掉必填项会导致 Ingress 创建失败或路由不生效。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
立即学习“go语言免费学习笔记（深入）”；
- ✅
spec.rules.http.paths.backend.service.name必须是 Service 的metadata.name（不是 Deployment 名） - ✅
pathType必须明确设为Prefix或Exact；默认值不存在，漏写会报错 - ✅ 多 ingress-nginx 控制器共存时，必须加
ingressClassName: nginx（否则可能被忽略） - ⚠️ 常见坑：
path: "/api/"末尾带斜杠，而 Go 路由注册的是/api，导致重定向循环；建议统一用path: "/api"+pathType: Prefix
调试时优先检查三处状态，别改 Go 代码
请求返回 502/404/timeout，90% 情况与 Go 逻辑无关，而是基础设施链路断在某一层。
- ✅ 运行
kubectl get ingress，确认ADDRESS列非空（为空说明 ingress-nginx controller 未就绪或没监听该 Ingress） - ✅ 运行
kubectl get svc -n ingress-nginx，确认ingress-nginx-controllerService 存在且有 ClusterIP - ✅ 查
ingress-nginx-controllerPod 日志：kubectl logs -n ingress-nginx deploy/ingress-nginx-controller | grep -i "my-go-api"，看是否解析到 Service、是否有 upstream 错误
真正容易被忽略的是：Ingress 的 ingressClassName 和集群中实际运行的 ingress-nginx Deployment 的 spec.ingressClassResource.name 不一致，或者用了旧版 annotation 如 kubernetes.io/ingress.class: nginx 却没配 ingressClassResource，这种问题不会报错，但路由静默失效。
