KubeFed 本身不负责流量调度，仅同步资源到成员集群，不干预请求路由；流量调度需依赖外部组件如 ExternalDNS+Route53 或 Istio 的 DestinationRule/VirtualService 协同实现。
为什么 KubeFed 本身不负责流量调度
KubeFed 是联邦控制平面，只同步资源（如 Deployment、Service）到成员集群，不干预请求如何路由。它不生成 Ingress、不改写 DNS、也不注入 sidecar。所谓“多集群流量调度”，实际要靠外部组件协同完成——比如 nginx-ingress + ExternalDNS + 自定义健康探针，或服务网格（Istio）的 DestinationRule + VirtualService。
常见错误是以为启用 KubeFed 后，发往 myapp.example.com 的请求会自动按权重分到北京/上海集群——不会。没配 DNS 轮询、没设健康检查、没暴露对应 Service 的 ClusterIP 或 LoadBalancer，流量根本到不了目标集群。
- 确认每个成员集群中，目标
Service类型是LoadBalancer或已通过NodePort+ 外部 LB 暴露 - 避免依赖
ClusterIP：联邦场景下它只在本集群内有效，跨集群不可达 -
KubeFed的FederatedService仅用于声明“该 Service 需在哪些集群部署”，不产生任何网络规则
用 ExternalDNS + Route53 实现基于延迟的 DNS 调度
这是最轻量、兼容性最好的方案：让 DNS 解析结果动态指向延迟最低的集群入口。前提是各集群 Ingress Controller 已暴露公网 IP，并配置了健康检查端点（如 /healthz）。
关键不是写死 A 记录，而是让 ExternalDNS 监听 Service 的 status.loadBalancer.ingress 字段，并结合自定义脚本做延迟探测后更新 Route53 的加权记录（Weighted Routing Policy）。
立即学习“go语言免费学习笔记（深入）”；
- 必须给每个集群的
Service加上唯一标签，例如cluster-id: cn-beijing，供ExternalDNS区分来源 -
ExternalDNS默认不支持延迟感知，需额外部署一个latency-prober服务，定时测各集群入口延迟，把结果写入 ConfigMap；再用kubectl patch更新Service的 annotation 触发ExternalDNS刷新 - Route53 的 TTL 必须设低（如 60s），否则客户端缓存导致故障切换延迟过高
Istio 多集群服务网格里怎么写 DestinationRule
如果已用 Istio 组成多集群网格（通过 east-west-gateway 连通），流量调度逻辑就移到网格内部。此时 KubeFed 只管应用部署，Istio 管路由。
核心是：为同一服务在不同集群注册不同的 subset，再用 VirtualService 按权重或 Header 分流。但注意——DestinationRule 中的 host 必须是服务全名（myapp.default.svc.cluster.local），且所有集群中该服务的 service-name.namespace.svc.cluster.local 必须一致，否则 Istio 不认作同一服务。
- 每个集群的
DestinationRule要单独部署，subset名称（如beijing、shanghai）需全局唯一，不能重复 - 必须开启
PILOT_ENABLE_SERVICEENTRY_SELECTORS=true，否则ServiceEntry无法按 label 匹配跨集群实例 - 不要在
DestinationRule里配trafficPolicy的loadBalancer策略来“跨集群负载均衡”——Istio 不支持跨集群实例的轮询，只支持显式 subset 选择
本地开发时如何快速验证跨集群调用是否通
别等上线才查，用 curl 直连各集群 Ingress 地址 + Host 头是最快验证方式。例如：
curl -H "Host: myapp.example.com" http://203.205.128.10/healthz
失败原因八成是证书、Host 头、或 Ingress 规则没对齐。KubeFed 不会帮你校验这些。
- 检查每个集群的
Ingress是否设置了正确的host和tls.hosts，尤其 wildcard 证书是否覆盖所有集群域名 - 确认
Ingress所在命名空间有对应Gateway（Istio 场景）或ingress.class注解匹配控制器（Nginx 场景） - 用
kubectl get endpoints -n <ns> <svc-name>查看后端 Pod 是否真实 Ready——KubeFed 同步成功 ≠ Pod 已就绪
真正的难点从来不在 KubeFed 配置本身，而在于你能否清晰拆解：哪层负责部署、哪层负责发现、哪层负责路由、哪层负责健康反馈。少一层对齐，流量就断在半路。
