Istio的多集群能力是Service Mesh落地过程中最容易被低估的功能之一。当企业业务从单一Kubernetes集群扩展到多个集群时，最朴素的需求其实很简单：集群A里的订单服务，能不能像调用本地服务一样调用集群B里的库存服务？这就是所谓的East-West流量（东西向流量），也就是服务与服务之间的横向调用流量，与之相对的North-South流量（南北向流量）则指外部进入集群的入口流量。Istio通过统一的控制面配置和数据面证书体系，可以让跨集群的服务调用做到服务发现互通、mTLS加密、负载均衡覆盖多集群端点，体验上几乎与单集群无异。
一、East-West流量的工作机制：Istio是怎么找到另一个集群里的Pod的
要理解多集群配置，关键是搞清楚Envoy代理的端点发现逻辑。在单集群模式下，istiod通过监听Kubernetes API Server，把Service对应的Pod IP整理成Endpoint列表下发给Envoy。而在多集群模式下，istiod会同时监听多个集群的API Server（需要通过remote secret授权），把所有集群中同名Namespace、同名Service的端点合并成一个逻辑端点集合。
举个例子，集群cluster-a和cluster-b里都有namespace为prod、名为inventory的Service，那么两个集群里该服务的Pod IP会被合并。当集群A里的frontend服务访问inventory.prod.svc.cluster.local时，Envoy拿到的端点列表里既有集群A的Pod IP，也有集群B的Pod IP，负载均衡会在所有端点之间进行。这就是East-West流量打通后的直接效果：同一个服务在多个集群的副本对外表现为一个整体。
这里有个非常关键的前提：跨集群访问的流量必须能直接路由到目标Pod IP，或者通过东西向网关中转。前者要求集群之间的Pod网络在三层可达（比如扁平网络或VPC打通），后者则适用于网络不通的场景，需要依赖东西向网关做流量入口。这两种模式对应的配置差异很大，后面会分别说明。
二、配置前的准备工作：统一信任根是跨集群mTLS的基础
多集群环境下，所有集群的Istio必须共享同一个根证书（Root CA），否则集群A的Envoy发起mTLS握手时，集群B的Envoy无法验证对方证书。这是最容易遗漏的一步，很多按照官方文档操作到一半发现流量不通，九成是因为证书体系没有统一。
首先用istioctl自带的证书生成工具创建根证书，注意中间证书的有效期配置建议不要设得太长，生产环境通常一年轮换一次：
# 在中间节点执行，生成根证书并分发到两个集群 mkdir -p certs && pushd certs make -f ../tools/certs/Makefile.selfsigned.mk root-ca # 为cluster-a生成中间证书 make -f ../tools/certs/Makefile.selfsigned.mk cluster-a-cacerts make -f ../tools/certs/Makefile.selfsigned.mk cluster-b-cacerts popd
生成之后，把对应的证书目录通过Kubernetes Secret写入各集群的istio-system命名空间：
kubectl create namespace istio-system --context cluster-a kubectl create secret generic cacerts -n istio-system \ --from-file=cluster-a/ca-cert.pem \ --from-file=cluster-a/ca-key.pem \ --from-file=cluster-a/root-cert.pem \ --from-file=cluster-a/cert-chain.pem \ --context cluster-a
除了证书，还要在每个集群创建用于远程发现的Secret，让本地istiod可以读取其他集群的API Server。这个Secret的名字有严格要求，格式为istio-remote-secret-{集群名}：
# 在cluster-a中创建访问cluster-b的凭证 istioctl x create-remote-secret \ --context=cluster-b \ --name=cluster-b | \ kubectl apply -f - --context=cluster-a
执行成功后，集群A的istiod就能以只读方式列出集群B的Service和Endpoint了。可以用kubectl get endpoint在集群B里验证目标服务确实有端点，再检查集群A的istiod日志确认远程连接建立成功。
三、单网络多集群配置：网络打通时的推荐方案
如果两个集群的Pod网络是扁平的（例如同一VPC内不同子网，Pod IP之间可以直接路由），那么配置相对简单，只需要让双方istiod互相发现即可。这种模式下跨集群流量直接走Pod到Pod，延迟最低，也不需要额外的网关开销。
两个集群的IstioOperator配置中，网络标签要设置为同一个值，表示处于同一个网络平面：
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
values:
global:
meshID: mesh-demo
multiCluster:
clusterName: cluster-a
network: network-1
集群B做相同配置，把clusterName改成cluster-b即可。安装完成后做一个连通性验证：在集群A里起一个sleep Pod，带上ServiceAccount令牌去请求集群B里的httpbin服务。如果返回200，并且通过istioctl proxy-config endpoint查看端点，能看到两个集群的IP，说明East-West流量已经打通。
需要提醒的是，单网络模式虽然省事，但对网络基础设施有硬性要求。跨VPC或者跨云厂商的场景下，Pod IP路由不可达，此时强行使用该模式会导致流量黑洞，Envoy把请求发往一个不可达的IP后只能等待超时，排查起来非常痛苦。
四、多网络多集群配置：借助东西向网关中转流量
网络不互通是更常见的实际情况，比如一个集群在阿里云、一个在自建机房。这时需要用到东西向网关（East-West Gateway），它在每个集群暴露一个入口，专门接收来自其他网格内服务的mTLS流量，再转发给本集群的Pod。
多网络模式下，先安装东西向网关并暴露服务。关键点在于gateway标签必须是istio-east-westgateway，并且hosts要开启匹配模式，因为跨集群访问的Host是内部域名而不是公网域名：
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: cross-network-gateway
namespace: istio-system
spec:
selector:
istio: eastwestgateway
servers:
- port:
number: 15443
name: tls
protocol: TLS
tls:
mode: ISTIO_MUTUAL
hosts:
- "*.local"
同时每个集群的IstioOperator中network字段要设置为不同的值（例如network-1和network-2），这样istiod在计算端点时，会发现目标端点不在本地网络，自动把流量路由到对方集群的东西向网关地址。这个发现过程依赖Kubernetes中名为istio-mc-endpoint的特殊Endpoint，Envoy通过它知道远端网关的可达地址。
还有一个容易踩的坑：东西向网关的地址必须是各集群互相可达的公网或专线地址，且15443端口的防火墙规则一定要放开。很多团队配置完发现跨集群请求失败，抓包才发现是安全组拦截了15443端口。另外建议在东西向网关的Service上开启externalTrafficPolicy: Local之外的默认策略即可，跨集群场景不需要保留源IP，保留反而可能导致回程路由异常。
五、方案对比与生产落地建议
两种模式各有取舍，简单对比一下：
| 对比项 | 单网络多集群 | 多网络多集群 |
|---|---|---|
| 网络要求 | Pod IP三层互通 | 仅要求网关地址互通 |
| 链路延迟 | 低，Pod直连 | 较高，多一跳网关 |
| 配置复杂度 | 低 | 高，需维护网关和证书 |
| 跨云跨机房 | 不适用 | 适用 |
生产环境落地时，建议优先做好这几件事。第一，把根证书纳入统一的密钥管理系统，不要用自签名证书直接上生产，可以考虑对接Vault做证书签发。第二，规划好集群名和Namespace约定，多集群依赖同名Namespace加同名Service来合并端点，命名混乱会导致服务意外聚合。第三，配置好控制面的监控指标，重点观察istiod的远程集群连接数和推送延迟，一旦某个集群的API Server不可达，本地istiod日志会出现远程连接错误，需要及时告警。第四，灰度阶段可以先只让测试Namespace打通跨集群流量，通过Sidecar资源的egress配置限制访问范围，避免误把生产服务暴露给其他集群。
整体来说，Istio的多集群East-West流量配置核心就三件事：统一信任根、打通端点发现、解决网络可达性。把这三点理清，无论选择哪种部署模型，配置过程都会有章可循。建议在测试环境先用两个kind集群完整演练一遍证书分发和网关暴露流程，再迁移到生产，能省去大量现场排障时间。
Istio多集群East-West流量跨集群服务通信修改时间：2026-09-05 12:32:43