17370845950

ingress-nginx 的 rewrite-target 注解在 Go 服务中不生效，因该重写由控制器在反向代理时完成，Go 服务仅接收重写后的路径；若路由注册仍按原始路径则返回 404。

为什么 ingress-nginx 的 rewrite-target 注解在 Go 服务里不生效？

Go 服务本身不解析 Kubernetes Ingress 的注解，rewrite-target 是 ingress-nginx 控制器在反向代理时做的路径重写，Go HTTP 服务只看到重写后的请求路径。常见错误是开发者在 Go 代码里还按原始路径（如 /api/v1/users）注册路由，但实际收到的是重写后路径（如 /users），导致 404。

实操建议：

• 确认 ingress-nginx 版本 ≥ 0.22.0，旧版本用 nginx.ingress.kubernetes.io/rewrite-target，新版本推荐用 nginx.ingress.kubernetes.io/path-type: Prefix + path 字段配合 PathRewrite 能力
• Go 服务的路由注册必须与重写后路径一致：若 Ingress 配置了 rewrite-target: / 且 path 是 /backend/，则 Go 应监听 / 而非 /backen

  

  d/
• 调试时直接 curl Ingress 域名 + 路径，并在 Go handler 中打印 r.URL.Path，验证是否已被重写

Go 服务如何感知 Ingress 的 host 和 path 用于灰度路由？

Ingress 的 host 和 path 不会自动注入到 Go 进程环境，需通过请求头或中间件提取。Kubernetes 不修改原始请求头，但 ingress-nginx 默认透传 Host 头，并可配置添加自定义头（如 X-Original-Host 或 X-Ingress-Path）。

实操建议：

• 在 Ingress YAML 中使用 nginx.ingress.kubernetes.io/configuration-snippet 注入路径信息：

  nginx.ingress.kubernetes.io/configuration-snippet: |
    set $ingress_path $uri;
    add_header X-Ingress-Path $ingress_path always;

• Go 中通过 r.Header.Get("X-Ingress-Path") 获取原始匹配路径，用于分流逻辑（如 /v2/ 流量进新版本 Go 服务）
• 避免依赖 r.Host 做路由判断——它可能被客户端篡改；应结合 X-Forwarded-Host（需 ingress 开启 use-forwarded-headers: "true"）和 TLS SNI 信息交叉校验

用 Go 写一个轻量 Ingress Controller 是否现实？

不现实。Ingress Controller 的核心职责（TLS 终止、动态规则加载、健康检查、连接池管理、Lua/OpenResty 扩展）远超标准 Go net/http 能力范围。社区已有 ingress-nginx、traefik、envoy 等成熟方案，它们底层严重依赖 epoll/kqueue、零拷贝转发、动态配置热加载等机制。

实操建议：

• 若需定制流量策略（如基于 JWT claim 的路由），应在 Go 服务内实现业务级中间件，而非替换 Ingress Controller
• 可用 Go 编写 admission webhook 或 operator 来校验/生成 Ingress 资源，这是更合理且可落地的扩展点
• 硬要“Go 实现”只能做 demo 级代理（如用 httputil.NewSingleHostReverseProxy），但无法处理真实生产中的证书轮换、长连接保活、gRPC 流复用等场景

Go HTTP Server 的 ReadTimeout 与 Ingress 的 proxy-read-timeout 冲突怎么办？

两者作用层不同但会叠加：Ingress 的 proxy-read-timeout 控制 nginx 等待上游（Go 服务）响应的时间，Go 的 ReadTimeout 控制读取客户端请求头/体的超时。若 Go 设置了过短的 ReadTimeout（如 5s），而 Ingress 设置了 60s，可能导致 Go 在 nginx 还没发完 body 时就关闭连接，触发 broken pipe 错误。

实操建议：

• Go 服务应禁用 ReadTimeout 和 WriteTimeout（设为 0），改用 ReadHeaderTimeout（推荐 5–10s）+ IdleTimeout（推荐 60s）组合，避免阻断流式响应
• Ingress 侧设置 nginx.ingress.kubernetes.io/proxy-read-timeout: "60" 和 nginx.ingress.kubernetes.io/proxy-send-timeout: "60"，与 Go 的 IdleTimeout 对齐
• 对 SSE 或 gRPC 流，必须关闭 Go 的 KeepAlivesEnabled（默认 true）并显式设置 IdleTimeout，否则连接可能被空闲超时意外中断

真正容易被忽略的是：Ingress 规则变更后，ingress-nginx pod 不会立刻 reload 配置，而是通过 shared informer watch 事件触发更新，这个过程有秒级延迟；同时 Go 服务的连接池（如 http.Transport）若复用旧连接，可能短暂出现 502。上线前务必验证连接复用行为和配置生效时间差。