3. 多集群网络基础：集群间网络连通性要求、DNS解析、TLS/mTLS证书信任链
在构建跨集群Envoy流量调度体系之前，必须夯实多集群网络的基础设施。本章聚焦三个核心维度：网络连通性（L3/L4可达性）、DNS解析（服务发现与域名路由）以及TLS/mTLS证书信任链（身份验证与加密通信）。任何一层的缺失或配置错误，都会直接导致Envoy跨集群调度失败或性能劣化。
3.1 集群间网络连通性要求
Envoy实例之间、Envoy与控制平面（如Istiod）之间、以及跨集群的服务Pod之间，必须满足严格的网络连通性条件。以下表格总结了关键连通性需求：
| 通信方向 | 协议 | 端口 | 用途 | 连通性要求 |
|---|---|---|---|---|
| Envoy → 远端Envoy | TCP / HTTP / gRPC | 自定义（如80, 443, 8080） | 跨集群业务流量转发 | 双向可达，延迟稳定，MTU一致 |
| Envoy → 远端控制面 | gRPC / XDS | 15012 (Istiod) | 拉取端点发现、监听器、路由配置 | 必须可达，支持长连接 |
| 控制面 → 远端控制面 | gRPC / TCP | 15012 / 15014 | 多集群服务发现同步（如Istio Mesh Expansion） | 跨集群网络扁平或通过VPN/专线 |
| Sidecar → 本地控制面 | gRPC / XDS | 15012 | 本地配置下发 | 本地集群内可达 |
常见陷阱： 跨集群网络未开启IP转发或存在对称NAT，导致Envoy主动建立的gRPC长连接被中间防火墙中断。建议使用WireGuard或Cilium ClusterMesh建立扁平Overlay网络，避免NAT穿透问题。
3.2 DNS解析：跨集群服务发现的核心
Envoy通过DNS解析获取上游集群的端点IP。在多集群场景下，DNS解析面临两个关键挑战：全局唯一域名与跨集群DNS可达性。
3.2.1 DNS解析模式对比
| 模式 | 实现方式 | 适用场景 | 延迟 | 一致性 |
|---|---|---|---|---|
| 全局DNS（ExternalDNS + CoreDNS） | 每个集群注册Service到全局DNS | 跨云、跨地域 | 中等（依赖TTL） | 最终一致性 |
| Istio ServiceEntry + DNS代理 | Envoy代理DNS请求，返回虚拟IP | 同城多活、Mesh内 | 低（本地缓存） | 强一致性（控制面驱动） |
| Kubernetes联邦DNS | kube-dns跨集群同步 | 传统联邦架构 | 高（同步延迟） | 最终一致性 |
3.2.2 DNS解析故障排查清单
- 检查DNS记录是否存在：
dig @<dns-server> <service>.<namespace>.svc.cluster.local - 验证Envoy DNS缓存： Envoy默认使用c-ares库，可通过
config_dump查看DNS解析状态。 - 确认跨集群DNS转发： 确保CoreDNS配置了
forward . <peer-cluster-dns>规则。 - TTL设置： 跨集群场景建议TTL设置为30-60秒，平衡收敛速度与DNS服务器压力。
最佳实践： 在Istio多集群部署中，优先使用ServiceEntry + WorkloadEntry方式定义跨集群服务，并启用DNS代理（
meshConfig.defaultConfig.proxyMetadata.DNS_PROXY_ENABLE: "true"），让Envoy直接响应DNS查询，减少对全局DNS的依赖。
3.3 TLS/mTLS证书信任链
跨集群通信必须建立双向身份验证。Envoy支持上游TLS上下文和下游TLS上下文配置。在多集群场景下，证书信任链的设计直接影响安全性与性能。
3.3.1 证书信任链架构
下图展示了跨集群mTLS通信的证书信任链结构：
3.3.2 证书信任链配置要点
- 统一根CA： 所有集群必须信任同一个根CA，否则mTLS握手将失败。
- 中间CA隔离： 每个集群使用独立的中间CA，便于证书吊销和集群级安全策略。
- 证书轮换： Envoy支持自动证书轮换（通过SDS），轮换周期建议设置为24小时。
- SAN（Subject Alternative Name）： 证书中必须包含Envoy实例的SPIFFE ID（如
spiffe://cluster.local/ns/<ns>/sa/<sa>），用于身份验证。
3.3.3 mTLS性能影响与优化
| 因素 | 影响 | 优化建议 |
|---|---|---|
| 握手延迟 | 每次新连接增加1-3 RTT | 启用TLS会话复用（Session Resumption） |
| 证书链长度 | 每增加一级CA，握手数据量增加约1KB | 使用2级CA（根CA + 中间CA），避免超过3级 |
| 加密算法 | ECDHE比DHE快3-5倍 | 优先使用ECDHE-RSA-AES256-GCM-SHA384 |
| SDS轮换频率 | 频繁轮换增加控制面负载 | 轮换周期设为24小时，并启用证书缓存 |
性能调优提示： 在Envoy的
tls_context中设置common_tls_context.alpn_protocols: ["h2", "http/1.1"]，优先使用HTTP/2连接，减少TLS握手次数。同时启用session_ticket_keys实现无状态会话恢复。
3.4 综合故障排查流程
当跨集群Envoy流量调度出现问题时，建议按以下步骤排查：
- 验证网络连通性： 使用
ping、telnet或nc测试Envoy Pod之间的端口可达性。 - 检查DNS解析： 在Envoy Pod内执行
nslookup <service>.<namespace>.svc.cluster.local，确认返回正确的远端ClusterIP。 - 验证TLS证书： 使用
openssl s_client -connect <remote-envoy>:443 -showcerts检查证书链是否完整。 - 查看Envoy日志： 搜索
SSL error、connection failure、dns resolve等关键字。 - 确认控制面同步： 检查Istiod日志，确认跨集群Endpoint是否已正确推送至Envoy。
关键提醒： 证书信任链断裂是跨集群通信中最隐蔽的故障。如果Envoy日志中出现
TLS error: certificate verify failed，请立即检查根CA是否一致、中间CA是否被正确签发、以及SAN是否匹配Envoy的SPIFFE ID。