Service Mesh跨集群通信需统一控制平面，共用istiod并配置clusterName/network标签；Go服务调用需用.global域名，依赖CoreDNS+istio-coredns-plugin解析；mTLS需MeshPolicy级PeerAuthentication和DestinationRule配置；排查应优先分析istio-proxy日志与stats而非Go应用日志。
Service Mesh 跨集群通信必须解决控制平面统一问题
多集群微服务在 Go 中跑不起来，往往不是代码写错了，而是 Istio / Linkerd 的控制平面没对齐。单集群里 istiod 管一整套数据面没问题，跨集群时，如果每个集群都独立部署 istiod，服务发现、mTLS 证书、路由策略就天然割裂——bookinfo 的 reviews 服务根本看不到另一个集群的 ratings 实例。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
istioctl install --set values.global.multiCluster.enabled=true启用多集群模式，而不是手动复制istiod - 所有集群共用同一个
istiod控制平面（推荐主集群托管，其他集群只部署istio-cni和istio-proxy） - 必须配置
clusterName和network标签，否则Sidecar资源无法识别远端集群的服务端点 - Go 微服务本身无需改任何代码，但
http.Client发请求时，目标域名必须走.global后缀（如ratings.prod.svc.cluster.local→ratings.prod.svc.cluster.local.global）
Go 服务调用跨集群服务时 DNS 解析失败的典型原因
lookup ratings.prod.svc.cluster.local.global: no such host 是最常卡住开发者的错误。这不是 Go 的 net/http 问题，而是 coredns 或 istio-coredns-plugin 没把 .global 域名转发给 istiod 的 dns 服务。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认
CoreDNS配置中已加载istio-coredns-plugin插件，并启用global域名拦截 - 检查 Go Pod 的
/etc/resolv.conf是否指向集群内corednsService IP，而非宿主机 DNS - 不用在 Go 代码里硬编码 IP 或改
http.Transport，DNS 层失效了，再怎么调http.Client.Timeout都没用 - 临时验证：进 Pod 执行
nslookup ratings.prod.svc.cluster.local.global，看是否返回istiod注册的 ClusterIP + 端口
Go 微服务启用了 mTLS，但跨集群调用被 403 拦截
Istio 默认开启严格 mTLS，而跨集群流量默认不自动继承 PeerAuthentication 策略。即使两个集群都开了 STRICT，ratings.prod.svc.cluster.local.global 的请求仍可能因证书链不匹配被拒绝。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须在所有集群统一部署
PeerAuthentication，作用域设为MeshPolicy，且mtls.mode显式设为STRICT - 检查
DestinationRule中是否为.global域名设置了trafficPolicy.tls.mode: ISTIO_MUTUAL - Go 服务不需要生成或加载证书文件，
istio-proxy自动完成双向 TLS 握手；但若你在 Go 里用了自定义http.Transport.TLSClientConfig，反而会干扰 sidecar 流量劫持 - 用
istioctl authz check查具体哪个 AuthorizationPolicy 拦了请求，别直接关 mTLS
Go 服务日志里看不到跨集群调用的真实延迟和错误码
因为流量经过 istio-proxy，原始 Go 应用的 log.Printf 或 Prometheus http_client_duration_seconds 只记录出站请求发起时间，不包含跨集群网络抖动、DNS 回退、mTLS 握手耗时等真实瓶颈。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 依赖
istio-proxy的访问日志（access_log），打开 JSON 格式并包含upstream_cluster、upstream_transport_failure_reason字段 - 用
istioctl proxy-status确认所有 sidecar 都同步到了最新的Endpoint，尤其关注global类型 endpoint 是否有健康实例 - 不要在 Go 里用
context.WithTimeout设过短的超时（比如 100ms），跨集群 RTT 天然比同集群高，容易掩盖真实问题 - 排查时优先看
istio-proxy的stats：执行curl <pod-ip>:15090/stats | grep -i 'outbound_.80_.*/global'
跨集群最难的从来不是 Go 怎么写，而是搞清哪一层在丢包、哪一层在拒绝、哪一层压根没看到对方服务——istio-proxy 日志和 stats 是唯一可信信源，别跳过它去翻 Go 应用日志。
