Go应用无需修改代码即可接入金丝雀发布，因流量调度由Kubernetes层（如Ingress NGINX Controller）在请求到达Pod前完成分流，应用仅需正确响应健康探针、不提前关闭监听即可天然适配。
金丝雀发布不是 Go 语言的特性，Go 应用本身不需要改代码就能接入——关键在 Kubernetes 层的流量调度，而不是应用层逻辑。
为什么不用改 Go 代码也能做金丝雀
Go 应用只要遵循标准 HTTP 生命周期（比如正确响应健康探针、不提前关闭监听），就天然适配金丝雀。Ingress NGINX Controller 的 canary 路由完全在七层网关侧完成，请求到达 Pod 前已按权重或 Header 决定走向哪个后端。你的 Go 服务甚至感知不到自己是“主版本”还是“金丝雀版本”。
- 就绪探针（
readinessProbe）必须配，否则新 Pod 可能未初始化完成就被注入流量 - 避免在 Go 代码里硬编码分流逻辑（如解析
X-CanaryHeader 并手动跳转），这会和 Ingress 的分流冲突 - 日志中建议打上
os.Getenv("POD_NAME")或hostname，方便后续验证流量是否真的打到了金丝雀 Pod
Ingress 注解配置金丝雀的最小必要项
你得有两个 Ingress 资源：一个主版本（无特殊注解），一个金丝雀版本（带 nginx.ingress.kubernetes.io/canary: "true"）。两者 host 和 path 必须完全一致，否则控制器不会合并后端。
- 主 Ingress 不需要任何 canary 注解，只需正常指向
service: my-app-v1 - 金丝雀 Ingress 必须包含：
nginx.ingress.kubernetes.io/canary: "true" - 至少选一种分流方式：
nginx.ingress.kubernetes.io/canary-weight: "5"（5% 流量），或nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"，或nginx.ingress.kubernetes.io/canary-by-cookie: "canary-flag" - 金丝雀 Ingress 的
serviceName必须指向新版本 Service（如my-app-v2），不能复用主 Service
常见错误：503 / 404 / 流量不进金丝雀 Pod
这类问题基本都卡在 Ingress 合并阶段，不是 Go 应用的问题。
-
503 Service Temporarily Unavailable：金丝雀 Ingress 的service不存在，或该 Service 没有匹配的 Endpoints（检查kubectl get endpoints my-app-v2） -
404 Not Found：两个 Ingress 的host或path不完全一致（注意大小写、末尾斜杠），控制器拒绝合并 - 流量始终走主版本：忘记加
nginx.ingress.kubernetes.io/canary: "true"，或值写成"True"（必须小写"true"） - 权重生效但没效果：确认 Ingress NGINX Controller 版本 ≥ v1.0.0（旧版只支持 header/cookie，不支持 weight）
验证金丝雀是否真正生效
别只看日志有没有新 Pod 打印，要从请求源头确认分流结果。
- 用 curl 发起带标头的请求：
curl -H "X-Canary: always" https://your-domain.com/api，应稳定命中金丝雀 Pod - 用 ab 或 hey 压测时加随机 header：
hey -H "X-Canary: $(if [ $((RANDOM % 100)) -lt 5 ]; then echo always; else echo never; fi)" -n 1000 https://your-domain.com/，再查两个版本的日志计数比是否接近 5:95 - 直接查 NGINX 配置生成结果：
kubectl exec -n ingress-nginx deploy/ingress-nginx-controller -- cat /etc/nginx/nginx.conf | grep -A 10 "upstream upstream-default-backend"，能看到主 + 金丝雀两个 upstream 的 weight 定义
最易被忽略的是：金丝雀 Ingress 创建后，控制器需要几秒到十几秒重新加载 NGINX 配置；在这期间发请求，可能仍走旧路由。别一创建完就立刻断言失败。
