Kubernetes中用Istio实现金丝雀发布需先确认Sidecar注入及version标签，再定义DestinationRule声明v1/v2子集，最后通过VirtualService按权重或请求头路由流量，全程无需改代码、不重启、秒级生效。
在 Kubernetes 集群中用 Istio 实现微服务金丝雀灰度发布，核心是让 5%～10% 的真实生产流量精准命中新版本 Pod，其余流量仍走稳定版本，且整个过程无需修改业务代码、不重启服务、秒级生效。
确认服务已注入 Sidecar 并打标
先检查目标服务的 Pod 是否已自动注入 istio-proxy 容器：kubectl get pod -l app=reviews -o wide。若任一 Pod 的 READY 列显示 1/2 或 2/2，说明注入成功；若为 1/1，则需重新启用自动注入或手动注入。
确保旧版本（v1）和新版本（v2）Pod 均带有明确的 version 标签：kubectl get pod -l app=reviews -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.version}{"\n"}{end}'。输出中必须同时存在 version: v1 和 version: v2 的条目，【缺少任一标签将导致 DestinationRule 无法识别子集】。
定义服务子集（DestinationRule）
创建 DestinationRule 资源，明确告诉 Istio “哪些 Pod 属于 v1，哪些属于 v2”：
① 编写 YAML 文件（如 reviews-dr.yaml），关键字段必须严格匹配 Pod 标签：
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: reviews-dr
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
② 执行 kubectl apply -f reviews-dr.yaml。这一步不触发任何流量变更，仅注册子集定义。
③ 验证子集是否注册成功：kubectl get destinationrule reviews-dr -o yaml | grep -A 5 subsets。若输出中清晰列出 v1 和 v2 两个子集，说明注册完成。
配置流量权重路由（VirtualService）
这是真正控制“多少流量去哪”的一步，必须等 DestinationRule 生效后再部署。
方法一：按百分比切分（最常用）
编写 reviews-vs-weight.yaml：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews-vs
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10
执行 kubectl apply -f reviews-vs-weight.yaml 后，约 10 秒内所有经过该 VirtualService 的请求就会按 90:10 比例分发到 v1/v2 子集。
方法二：按请求头灰度（精准定向）
适用于测试特定用户或内部人员——只要请求携带 header: "x-canary: true"，就强制走 v2：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews-vs-header
spec:
hosts:
- reviews
http:
- match:
- headers:
x-canary:
exact: "true"
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1
这个配置会覆盖上一个 VirtualService，因为同 host 的规则按声明顺序匹配，header 匹配优先级高于无条件权重路由。
验证流量是否真实切分
进入任意网格内 Pod（如 productpage）执行循环请求：
kubectl exec -it $(kubectl get pod -l app=productpage -o jsonpath='{.items[0].metadata.name}') -c productpage -- sh -c "for i in {1..50}; do curl -s -H 'Host: reviews' reviews:9080/reviews/0; echo; done" | grep -o "v[12]" | sort | uniq -c
观察输出：若看到类似 "45 v1" 和 "5 v2"，说明 10% 流量已准确命中 v2；若全是 v1，检查 VirtualService 是否 applied、DestinationRule subset 名称是否拼写一致、Pod label 是否真实存在。
实时查看 Envoy 访问日志确认上游地址：
kubectl logs -l app=reviews -c istio-proxy | grep "upstream=" | tail -20
日志中 upstream 字段的 IP 应来自不同 Pod（v1 和 v2 各自的 IP 段），这是流量真正落地的最终证据。
