先检查pod是否含istio-proxy和go应用两个容器，确认ready为2/2；确保命名空间已打标istio-injection=enabled；destinationrule需显式定义subset且与pod label严格一致；service port name必须为http或http2；go服务containerport须与listenandserve端口一致。
确认 Istio Sidecar 注入是否生效
没注入 Envoy，所有灰度规则都无效。先检查 Pod 是否含两个容器：istio-proxy 和你的 Go 应用。
常见错误现象：VirtualService 配置好了，但流量全走 v1，istio-proxy 日志里看不到路由匹配记录。
- 确保命名空间已启用自动注入：
kubectl label namespace default istio-injection=enabled - 部署后执行
kubectl get pod -o wide，确认 Pod 的READY列是2/2 - 若手动注入，需用
istioctl kube-inject处理 Deployment YAML，不能只改镜像或加 initContainer
DestinationRule 必须定义 subset 才能路由到版本
Istio 不会自动识别 version: v2 标签——你得显式在 DestinationRule 里声明 subset，否则 VirtualService 引用的 v2 根本不存在。
常见错误现象：VirtualService 中写了 route: [{subset: v2}]，但 kubectl apply 后报错 subset v2 not found for host go-service。
-
subset名称必须小写、无特殊字符，且与 Pod 的 label 值严格一致（如version: v2→name: v2） - label 键名不限于
version，也可用env或canary，但DestinationRule的matchLabels必须完全对齐 - 一个
DestinationRule可同时定义v1和v2subset，无需为每个版本单独创建
VirtualService 路由规则要匹配真实请求特征
Header 匹配失败不是规则写错了，而是请求根本没带上那个 header，或者被中间件过滤了。
常见错误现象：curl 加了 -H "X-Canary: true"，但流量仍走默认 route；或测试时用 Postman 成功，线上 Nginx 反代后失效。
- HTTP header 名区分大小写，Istio 默认只透传标准 header，自定义 header 如
X-Canary需在EnvoyFilter或 Gateway 配置中显式放行 - Kubernetes Service 的 port name 必须是
http或http2（不是tcp），否则 VirtualService 的http路由块不生效 - 权重路由（如 90/10）和 header 路由可共存，但 header 规则优先级更高；若两者冲突，header 匹配成功就不再看权重
Go 服务本身不需要改代码，但必须暴露标准端口
别在 Go 里监听 :8080 然后让 Istio 把流量打到 :80 ——Envoy 只会转发到容器内实际监听的端口，端口不一致会导致 connection refused。
常见错误现象：Pod 里 istio-proxy 日志显示 upstream connect error，curl localhost:8080 在容器内能通，但从集群外访问超时。
- Go 服务
ListenAndServe的地址应为:8080（或任意固定端口），Deployment 中containerPort必须与之相同 - Kubernetes Service 的
targetPort必须等于容器端口，port可不同（如设为 80），但name字段必须是http - 不要在 Go 里解析
X-Canary做业务逻辑分流——那是网关或 Istio 的事；Go 只需处理自己该处理的请求
VirtualService、DestinationRule、Service）引用的 host 名必须完全一致，包括命名空间后缀（如 go-service.default.svc.cluster.local），少一个点或拼错字母，规则就静默失效。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
