3、多集群网络基础：集群间网络连通性要求、服务网格（Istio）在多集群存储中的作用、DNS与跨集群服务发现

3.1 多集群网络连通性核心要求

多集群存储架构的首要前提是建立可靠、低延迟、高吞吐的集群间网络。不同于单集群内部扁平化的 Pod 网络，跨集群通信面临 NAT、防火墙、非扁平网络拓扑等挑战。以下表格总结了多集群网络连通性的关键维度与最低要求：

3.2 服务网格（Istio）在多集群存储中的角色

Istio 在多集群存储架构中承担 安全隧道、流量治理 与 可观测性 三重职责。下图展示了 Istio 如何连接两个集群中的存储组件：

3.3 Istio 在存储场景中的关键能力

• mTLS 自动加密： 存储控制器与数据节点之间的所有跨集群流量自动启用双向 TLS，无需在应用层配置证书。对于 RBD 镜像、NFS 挂载、S3 网关同步等敏感操作，mTLS 提供传输层零信任安全。
• 流量分割与故障转移： 通过 VirtualService 定义存储请求的权重路由。例如，80% 的读请求发往本地集群，20% 发往远端灾备集群；当本地存储节点故障时，自动 100% 切换至远端。
• 细粒度访问控制： 使用 AuthorizationPolicy 限制只有特定 ServiceAccount（如 csi-controller、replication-agent）才能访问跨集群存储端点，防止非存储组件滥用网络。
• 统一可观测性： 所有跨集群存储 I/O 请求自动生成分布式追踪（Jaeger/Zipkin），帮助定位延迟瓶颈。例如，区分“网络延迟”与“存储后端处理延迟”。

3.4 DNS 与跨集群服务发现

多集群存储依赖 全局 DNS 解析 实现存储端点的动态发现。Kubernetes 原生 DNS（CoreDNS）仅感知单集群，跨集群场景需要额外方案。下表对比了三种主流跨集群服务发现模式：

对于存储场景，Istio ServiceEntry 模式 是最佳选择。以下是一个典型的跨集群存储服务发现配置示例：

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: remote-storage-gateway
  namespace: storage-system
spec:
  hosts:
  - remote-storage.primary.svc.cluster-b.local
  addresses:
  - 10.200.1.100  # 远端集群 Service ClusterIP
  ports:
  - number: 2049
    name: nfs
    protocol: TCP
  - number: 8080
    name: s3-api
    protocol: TCP
  location: MESH_INTERNAL
  resolution: DNS
  endpoints:
  - address: 192.168.10.50  # 远端集群 Pod IP
    ports:
      nfs: 2049
      s3-api: 8080
    labels:
      cluster: cluster-b
      role: storage-gateway

3.5 跨集群服务发现流程（Istio 模式）

下图展示了存储控制器在集群 A 中如何通过 Istio 服务发现找到集群 B 的存储网关：

3.6 网络连通性验证清单

在部署多集群存储前，建议按以下清单逐项验证网络基础：

1. Pod 到 Pod 连通性： 使用 kubectl exec 在集群 A 的存储 Pod 中 ping 集群 B 的存储 Pod IP，确认 ICMP 可达。
2. 端口可达性： 使用 nc -zv <远端IP> <端口> 验证 NFS(2049)、S3(8080)、RBD(6789) 等存储端口开放。
3. MTU 测试： 使用 ping -M do -s 1472 <远端IP> 测试端到端 MTU，确保不低于 1400。
4. 延迟基准： 使用 ping -c 100 <远端IP> 记录平均延迟与丢包率，同步复制场景要求延迟 < 10ms，丢包率 < 0.1%。
5. mTLS 握手验证： 在 Istio Sidecar 日志中搜索 mTLS handshake completed，确认跨集群连接已加密。
6. DNS 解析测试： 在存储 Pod 内执行 nslookup remote-storage.primary.svc.cluster-b.local，确认返回正确的远端端点 IP。