3. Istio多集群部署模式详解：主-远程模式（Primary-Remote）
主-远程模式（Primary-Remote）是 Istio 多集群部署中最常用的架构之一。该模式通过一个主集群（Primary Cluster）集中管理控制面，而远程集群（Remote Cluster）仅运行数据面组件，从而在降低资源消耗的同时，实现跨集群的服务连通与流量治理。
3.1 架构原理
在 Primary-Remote 模式下，主集群 部署完整的 Istio 控制面组件（istiod、Ingress/Egress Gateway），而 远程集群 仅部署数据面组件（Envoy Sidecar、Ingress/Egress Gateway），并通过网络隧道与主集群的控制面通信。
核心特征：
- 控制面集中化： 所有集群的配置下发、证书签发、服务发现均由主集群的 istiod 统一管理。
- 数据面分布式： 远程集群的 Envoy 代理通过 Kubernetes API Server 或 Istio 的 East-West Gateway 与主集群建立长连接。
- 网络要求： 主集群与远程集群之间需要网络互通（通常通过 VPN、VPC Peering 或专用网络链路）。
3.2 组件通信流程
Primary-Remote 模式的组件通信分为 控制面通信 和 数据面通信 两个层面：
| 通信类型 | 源组件 | 目标组件 | 协议/端口 | 说明 |
|---|---|---|---|---|
| XDS 配置下发 | 主集群 istiod | 远程集群 Envoy | gRPC (15012) | 通过 East-West Gateway 或直连 API Server 代理 |
| 证书签发 | 主集群 istiod (Citadel) | 远程集群 Envoy | gRPC (15014) | 通过 CSR 请求获取工作负载证书 |
| 服务发现 | 远程集群 API Server | 主集群 istiod | HTTPS (6443) | istiod 通过 Remote Secret 访问远程集群 API |
| 跨集群流量 | 远程集群 Envoy | 主集群 Envoy | mTLS (隧道) | 通过 East-West Gateway 建立 L4 隧道 |
关键通信路径： 远程集群的 Envoy 启动时，会通过 Kubernetes DNS 解析主集群 istiod 的 Cluster IP 或 LoadBalancer IP，建立长连接。如果网络隔离，则通过 East-West Gateway 的 SNI 路由进行代理。
3.3 证书分发机制
Istio 在 Primary-Remote 模式下使用 双向 TLS（mTLS） 保证通信安全。证书分发遵循以下流程：
- 根证书生成： 主集群的 istiod（Citadel 组件）生成自签名根证书（Root CA），并保存为 Kubernetes Secret。
- 远程集群注册： 管理员在主集群创建
RemoteSecret，包含远程集群的 API Server 访问凭证。 - 工作负载证书签发： 远程集群的 Envoy 启动时，通过 gRPC 向主集群 istiod 发送 CSR（证书签名请求）。
- 证书分发： istiod 验证请求后，签发短期证书（默认 24 小时），并通过 XDS 通道下发到远程 Envoy。
- 证书轮换： Envoy 在证书过期前自动发起轮换请求，istiod 重新签发。
3.4 部署配置示例
以下是在主集群上创建 RemoteSecret 的典型配置：
# 在主集群上创建远程集群的访问凭证
istioctl x create-remote-secret \
--name=remote-cluster-1 \
--namespace=istio-system \
--kubeconfig=/path/to/remote-kubeconfig.yaml \
--type=remote \
| kubectl apply -f - -n istio-system
注意事项：
- 远程集群的 kubeconfig 必须具有足够的 RBAC 权限（至少能读取 Service、Endpoint、Pod 资源）。
- 如果主集群与远程集群网络不通，需要额外部署 East-West Gateway 并配置 SNI 路由。
- 证书轮换期间，Envoy 会保持旧证书直到新证书生效，不会造成连接中断。
3.5 模式对比
| 对比维度 | Primary-Remote 模式 | Multi-Primary 模式 |
|---|---|---|
| 控制面数量 | 1 个（主集群） | 每个集群 1 个 |
| 资源消耗 | 低（远程集群无控制面） | 高（每个集群运行完整控制面） |
| 配置一致性 | 强（统一下发） | 需手动同步 |
| 故障隔离 | 主集群故障影响所有集群 | 单个集群故障不影响其他集群 |
| 适用场景 | 中心化治理、边缘集群 | 高可用、多区域独立运营 |
最佳实践： 对于大多数企业级多集群场景，推荐使用 Primary-Remote 模式作为起点。当业务规模增长到需要跨区域高可用时，再逐步演进到 Multi-Primary 模式。