金丝雀发布在Kubernetes中需借助Istio或Nginx Ingress实现流量分发：Istio通过VirtualService权重路由与DestinationRule子集精准控制；Nginx Ingress则依赖canary注解实现简单分流，但灵活性较低。
在 Kubernetes 中实现金丝雀发布（Canary Release）的流量切换，核心是通过 细粒度控制请求路由，将一小部分生产流量导向新版本服务，同时保留大部分流量给稳定版本。这主要依赖 服务网格（如 Istio）或 Ingress 控制器（如 Nginx Ingress + canary annotation） 来实现，原生 Kubernetes Service 不支持按权重分发流量。
用 Istio 实现基于权重的流量切分
Istio 是最常用、能力最完整的方案，通过 VirtualService 和 DestinationRule 配合实现精确控制：
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
-
定义两个子集（subsets）：在 DestinationRule 中为同一服务的不同版本（如 v1、v2）打标签，声明其对应的 Pod label（如
version: v1/version: v2） - 配置 VirtualService 流量路由：在路由规则中为每个子集设置权重，例如 90% 流向 v1，10% 流向 v2；支持动态调整权重（无需重启），实时生效
-
可叠加条件路由：比如先按 header（
cookie: user-type=beta）或用户 ID 做灰度，再 fallback 到权重分流，实现多级灰度策略
用 Nginx Ingress Controller 实现简单金丝雀
若未引入服务网格，Nginx Ingress（v0.21+）支持基于 annotation 的轻量级 canary：
- 需部署两个独立 Service（如
myapp-v1和myapp-v2），对应不同 Deployment - 主 Ingress 资源指向 v1 Service，并添加注解：
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-weight: "10"
表示将 10% 的请求转发到另一个带canary-by-header或canary-by-cookie注解的 Ingress（指向 v2 Service） - 该方式不依赖应用层修改，但仅支持整条 Ingress 规则级别的分流，灵活性低于 Istio
关键注意事项与实践建议
- 健康检查必须到位：新版本 Pod 必须通过 readiness probe，否则流量不会进入；建议在 v2 Deployment 中设置更严格的探针逻辑，提前拦截异常实例
- 指标与可观测性不可少：对比 v1/v2 的延迟、错误率、成功率（如用 Prometheus + Grafana），一旦 v2 错误率突增，立即回滚权重至 0
- 会话保持谨慎开启：若启用 sessionAffinity，可能破坏流量比例（尤其短连接场景），建议优先用无状态设计，或改用 cookie-based 亲和（Istio 支持）
- 配置即代码 & 自动化：把 VirtualService / Ingress 的权重字段纳入 CI/CD 流水线，用脚本逐步从 5% → 20% → 50% → 100%，失败则自动回退
不复杂但容易忽略的是：流量切分只是金丝雀的“前半场”，真正的价值在于配套的监控判断和快速响应机制。没有数据反馈的流量切换，只是形式上的灰度。
