kubernetes 本身不提供灰度发布功能，需依赖流量路由层（如 istio）配合 deployment、service 标签控制及 destinationrule/virtualservice 成对配置，且须启用 sidecar 注入、统一命名空间与 hosts 对齐。
Kubernetes 本身不直接提供“灰度发布”功能，它只负责调度和管理 Pod；真正实现灰度的是流量路由层（如 Istio、Nginx Ingress）配合 Deployment 和 Service 的标签控制。Go 应用不需要改代码，但必须满足几个关键结构约束，否则灰度规则根本不会生效。
Deployment 和 Pod 标签必须严格对齐
灰度依赖 Kubernetes 的 label selector 匹配机制。Istio 的 DestinationRule 默认按 app 和 version 标签识别子集，而 Service 的 selector 也靠这些标签把流量打到对应 Pod 上：
-
Deployment的spec.template.metadata.labels必须包含app: your-go-service和version: v1（或v2） -
Service的spec.selector要能同时匹配两个版本的 Pod（例如只写app: your-go-service，不带version） - 若用 Istio，
DestinationRule中的subsets的labels必须和 Pod 实际标签完全一致（包括大小写和空格）
Istio 的 VirtualService + DestinationRule 必须成对配置
单独写 VirtualService 没用——它只定义“怎么分”，但没告诉 Envoy “v1 和 v2 到底是哪些 Pod”。DestinationRule 才是定义子集的关键：
-
DestinationRule.host必须和VirtualService.host完全相同（比如都是go-service） -
VirtualService.route.destination.subset引用的名称（如v1）必须在DestinationRule.subsets中明确定义 - 漏掉
DestinationRule或子集名称拼错，所有流量都会 fallback 到默认子集（通常是第一个定义的）
示例中常见的错误配置：subset: canary 写在 VirtualService 里，但 DestinationRule 里定义的是 name: v2 —— 这会导致 100% 流量走 v1。
Sidecar 注入失败是灰度不生效的第一大原因
Istio 的流量控制只对注入了 Envoy sidecar 的 Pod 生效。Go 应用跑得再正确，没有 sidecar 就等于裸奔，所有 VirtualService 规则都被跳过：
- 命名空间必须启用自动注入：
kubectl label namespace default istio-injection=enabled - Pod 模板中容器端口必须带
name字段，例如ports: [{name: http, containerPort: 8080}]；只写数字端口，Envoy 可能无法识别协议 - 检查 Pod 是否真有两个容器：
kubectl get pod xxx -o wide看READY列是否为2/2 - 用
kubectl describe pod xxx查看 Events，确认有没有failed to inject类报错
Go 服务只需暴露可识别的版本标识
灰度逻辑不在 Go 代码里，但可观测性依赖它输出明确的版本信息。别只打日志说“启动成功”，要让日志、HTTP 响应头或健康接口返回实际版本：
- 启动时打印：
log.Printf("service %s v%s started", serviceName, version)，其中version来自构建参数或环境变量（如VERSION=v2.1.0） - HTTP 接口加响应头：
w.Header().Set("X-App-Version", os.Getenv("VERSION")) - 避免硬编码下游地址（如
http://10.244.1.5:8080），统一用 Service 名（如http://order-service），否则 sidecar 无法劫持流量
真正容易被忽略的点是：所有配置对象（Deployment、Service、DestinationRule、VirtualService）必须在同一个命名空间，且 VirtualService 的 hosts 必须和 Gateway 的 hosts 对齐——差一个字符，请求就进不来，你还以为是 Go 服务挂了。
