kubernetes中用ingress实现canary灰度发布需先启用canary功能，即为目标ingress添加nginx.ingress.kubernetes.io/canary: "true"注解使其成为金丝雀入口；再按优先级（header→cookie→weight）选择一种分流策略配置对应注解；同时确保主ingress与canary ingress的host和path完全一致，且后端service selector不重叠；最后通过curl、浏览器cookie或权重日志实测验证流量分发效果。
在 Kubernetes 中用 Ingress 实现 Canary 灰度发布，核心是通过 Ingress-Nginx Controller 的注解（Annotations）控制流量分流，让新功能只对部分用户或请求生效，从而安全验证效果。不需要改代码、不依赖 Service Mesh，配置清晰、落地快。
必须先启用 Canary 功能
所有灰度规则的前提是：目标 Ingress 资源必须显式声明为 Canary 入口。否则其他规则全部无效。
- 添加注解：
nginx.ingress.kubernetes.io/canary: "true" - 这个 Ingress 就是“金丝雀入口”，它指向新版本服务（如
myapp-v2） - 同时需确保主 Ingress（指向旧版
myapp-v1）不带该注解，且域名、路径等匹配规则一致
按场景选一种分流方式
Ingress-Nginx 支持三类主流策略，优先级固定：Header → Cookie → Weight，高优先级规则命中即终止判断。
-
按请求头灰度（推荐用于测试/AB）
加两个注解组合使用：
–nginx.ingress.kubernetes.io/canary-by-header: "version"
–nginx.ingress.kubernetes.io/canary-by-header-value: "v2"
只要请求带version: v2，就进新版本；其他请求走旧版。 -
按 Cookie 灰度（适合用户级灰度）
只需一个注解：nginx.ingress.kubernetes.io/canary-by-cookie: "canary"
当浏览器 Cookie 中含canary=always时走新版本；canary=never强制走旧版；其他值忽略。 -
按权重灰度（适合小流量观察）
用注解：nginx.ingress.kubernetes.io/canary-weight: "5"
表示约 5% 的随机请求打到新版本；从 1 开始逐步调高，确认稳定后再升到 100。
配套资源要部署到位
光配 Ingress 不够，前后端服务必须就绪：
- 旧版本 Deployment + Service（如
myapp-v1），由主 Ingress 指向 - 新版本 Deployment + Service（如
myapp-v2），由 Canary Ingress 指向 - 两个 Service 的 selector 标签不能重叠，避免 Pod 混合调度
- Ingress 规则中 host 和 path 必须完全一致，否则 Nginx 不会触发分流逻辑
上线后怎么验证是否生效
别只看配置，要实测流量走向：
- 用 curl 测试 Header 方式：
curl -H "version: v2" https://myapp.example.com/api，检查响应是否来自 v2 - 用浏览器开发者工具清空 Cookie 后手动设置
canary=always，刷新页面看是否加载新 UI - 开多个终端并发请求，配合
canary-weight: 10，用日志或 Prometheus 查看两套服务的请求量比例是否接近 9:1 - 留意 Ingress-Nginx 日志（
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller），搜索canary或后端 service 名，确认路由决策
