金丝雀发布实现全链路染色需请求从网关起携带唯一标识（如Header或Cookie）并全程透传，Nginx Ingress仅负责首跳分流，后续依赖网关、微服务、异步组件等协同透传与识别，否则无法保障全链路一致性。
金丝雀发布实现全链路染色，关键在于让一次请求从网关入口开始，就携带唯一标识（如特定 Cookie 或 Header），并在整个调用链路中持续透传，确保所有下游服务都路由到同一版本（比如全部走灰度版或全部走稳定版）。Nginx Ingress 本身只负责七层入口的首次分流，真正的“全链路”需要上下游服务配合支持透传与识别。
Header 染色：简单直接，适合统一网关控制
Header 是最常用、最可控的染色方式。前端或测试人员在请求中带上自定义 Header（例如 X-Canary: grey 或 canary-tag: v2），Ingress 根据该字段决定转发目标：
- 配置一个带
nginx.ingress.kubernetes.io/canary: "true"的 Canary Ingress，并设置nginx.ingress.kubernetes.io/canary-by-header: "X-Canary" - 当请求头含
X-Canary: grey，且该值不为never，则命中灰度后端；若为never，则强制走旧版（用于紧急回滚） - 服务内部需确保该 Header 在 HTTP 调用（如 OpenFeign、RestTemplate）或 RPC（如 Dubbo）中被显式透传，否则下游无法感知
Cookie 染色：对用户友好，天然支持会话绑定
Cookie 方式更适合面向终端用户的灰度场景，比如让某批注册用户始终看到新功能界面。Nginx Ingress 支持通过 nginx.ingress.kubernetes.io/canary-by-cookie 实现：
- 设置
nginx.ingress.kubernetes.io/canary-by-cookie: "canary_user"，Ingress 会检查请求 Cookie 中是否存在该 key - 若值为
always，则固定路由至灰度服务；若为never，则排除；其它值忽略 - 前端可在登录成功或灰度准入时写入该 Cookie（
Set-Cookie: canary_user=always; Path=/; Max-Age=86400），后续请求自动携带 - 注意：Cookie 默认作用域受限，需确保 Path 和 Domain 配置覆盖全链路路径（如
Path=/、Domain=.example.com）
全链路透传不是 Ingress 单方面的事
Ingress 只管第一跳，要保证“从网关到数据库中间所有环节都走同一条灰度路径”，必须各层协同：
- 网关层：Zuul、Spring Cloud Gateway、APISIX 等需读取并透传染色 Header/Cookie，不能丢弃或重命名
-
微服务间调用：HTTP 客户端需手动将上下文 Header 注入新请求；Dubbo 需启用隐式传参（如
Attachment）并配置泛化透传规则 - 异步链路：消息队列（如 RocketMQ/Kafka）需在消息头中携带染色信息，消费者处理时再还原上下文
-
日志与链路追踪：建议将染色标识（如
canary_tag）注入 traceId 或 MDC，便于问题定位和指标聚合
实际部署建议
避免“只配 Ingress 就以为全链路生效”的误区：
- 先用 curl 模拟带 Header/Cookie 的请求，验证 Ingress 是否正确分发到对应 Service
- 在灰度服务日志中打印收到的 Header 和下游调用地址，确认是否继续透传
- 使用 SkyWalking 或 Prometheus + Grafana 观察灰度流量在各服务间的分布比例是否一致
- 灰度期间禁用自动扩缩容（HPA），防止新旧 Pod 混合打散路由逻辑
