Ingress-nginx 是独立的 Kubernetes 控制器，非 Go 项目组件；Go 应用需通过 ClusterIP Service（标签匹配、端口一致）暴露，Ingress 资源须正确引用 Service 名并配置 path 与 ingressClassName，调试应优先检查 Ingress 状态、ingress-nginx 日志及服务连通性。
Ingress-nginx 不是 Go 项目的一部分，它不部署在你的 main.go 里
很多人一看到“Golang 项目中部署 Ingress-nginx”，就下意识想把 ingress-nginx 当成一个 Go 库或服务进程嵌入到自己的二进制里——这是根本性误解。ingress-nginx 是 Kubernetes 的一个独立控制器（Deployment + Service），运行在集群层面，和你的 Go 应用完全解耦。它只负责把外部 HTTP/HTTPS 请求按规则转发给后端的 Service（比如你用 go run main.go 启动、再打包成镜像部署的 Pod）。
Go 服务暴露给 Ingress-nginx 的关键：Service 必须是 ClusterIP 且标签匹配
你的 Go 应用要能被 ingress-nginx 转发，必须满足两个硬性条件：
- 部署为 Pod，并打上明确标签，例如
app: my-go-api - 配套一个
Service类型为ClusterIP，selector精确匹配上述标签 -
Service的ports.targetPort必须和 Go 程序监听的端口一致（比如http.ListenAndServe(":8080", nil)→targetPort: 8080）
常见错误：Service 类型误设为 NodePort 或 LoadBalancer；selector 拼错；Go 程序监听 127.0.0.1:8080 导致 Pod 内部无法被 Service 访问（必须用 :8080 或 0.0.0.0:8080）。
Ingress 资源对象里 path 和 serviceName 必须严格对应 Service 名称
Ingress 是告诉 ingress-nginx “把 /api/* 的请求转给哪个 Service”的配置文件。它不认你的 Go 代码结构，只认 Kubernetes 对象名：
通过PCO Services API 管理 Planning Center Services 数据的 CLI 工具，包含计划、团队、歌曲和排班人员。
立即学习“go语言免费学习笔记（深入）”；
-
spec.rules.http.paths.backend.service.name必须等于你定义的Service的metadata.name（不是 Deployment 名，也不是容器名） -
path是前缀匹配，/api会匹配/api/users，但不会匹配/apis；如需精确匹配，得用nginx.ingress.kubernetes.io/use-regex: "true"配合正则 - 如果你用的是
ingress-nginxv1.0+，必须用networking.k8s.io/v1API 版本，serviceName已改为service.name，旧写法直接报错
典型错误：service.name 写成 Deployment 名；path 末尾多加 / 导致重定向循环；没加 ingressClassName: nginx（当集群有多个 Ingress 控制器时必填）。
调试流量不通时，优先查这三处日志和状态
请求 502/404/timeout？别急着改 Go 代码，先确认基础设施链路：
- 运行
kubectl get ingress看ADDRESS列是否非空；为空说明ingress-nginx控制器没起来或没监听该 Ingress - 运行
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller，搜"no endpoints available"或"upstream denied"—— 前者代表 Service 没找到 Pod，后者常因 readinessProbe 失败 - 进
ingress-nginxPod 执行curl -v http://my-go-service.namespace.svc.cluster.local:8080/health，验证 DNS 和后端连通性（注意用全限定域名）
Go 应用本身不需要任何特殊依赖或 SDK 来适配 Ingress；真正卡点永远在 YAML 的 label/service/ingress 三级对齐，而不是代码逻辑。
