3. 多集群网络规划
多集群生产环境里，网络规划不是“给每个集群分一段 IP”这么简单。它同时决定了三件事：Pod 与 Service 地址能否跨集群互通、外部流量如何进入并落到正确后端、以及故障时能否快速定位是 DNS、负载均衡还是路由策略的问题。本节围绕 CIDR 分配、东西向与南北向流量治理、DNS 与负载均衡策略展开，并给出可直接参考的规划表与配置示例。
一、CIDR 分配：先定“不可重叠”的地址空间
OpenShift 集群内部至少涉及三类地址：节点网络（Node CIDR）、Pod 网络（Cluster Network）、Service 网络（Service Network）。多集群场景下，如果两个集群的 Pod CIDR 或 Service CIDR 重叠，跨集群通信、集群间服务发现和全局负载均衡都会出现不可预测的冲突。因此第一步是建立全局地址池，再按集群切分。
假设企业规划了以下私有地址空间（示例，非实测）：
| 用途 | 全局地址池 | 集群 A | 集群 B | 集群 C |
|---|---|---|---|---|
| 节点网络 | 10.10.0.0/16 | 10.10.1.0/24 | 10.10.2.0/24 | 10.10.3.0/24 |
| Pod 网络 | 10.128.0.0/14 | 10.128.0.0/16 | 10.129.0.0/16 | 10.130.0.0/16 |
| Service 网络 | 172.30.0.0/16 | 172.30.0.0/18 | 172.30.64.0/18 | 172.30.128.0/18 |
分配时遵循三条原则：Pod CIDR 与 Service CIDR 不得与节点网络、企业办公网、IDC 物理网络重叠；每个集群的 Pod CIDR 至少预留 2 倍增长空间；Service CIDR 一旦确定，后期修改成本极高，应一次性规划到位。在 OpenShift 安装时，这些值通过 install-config.yaml 固定：
networking:
clusterNetwork:
- cidr: 10.128.0.0/16
hostPrefix: 23
serviceNetwork:
- 172.30.0.0/18
machineNetwork:
- cidr: 10.10.1.0/24
其中 hostPrefix: 23 表示每个节点从 Pod CIDR 中分到 /23，即 512 个 Pod IP。若单节点预期运行 300 个 Pod，/23 足够；若预期 600 个，则应改为 /22。这个参数直接决定单节点可调度 Pod 上限，规划时必须结合业务密度计算。
二、东西向与南北向流量治理
东西向流量指集群内部或跨集群的服务间通信，南北向流量指集群外部用户或系统访问集群内服务。两者治理目标不同：东西向关注服务发现、跨集群可达性与加密，南北向关注入口收敛、TLS 终止与流量切分。
东西向方面，OpenShift 常用 Submariner 打通跨集群 Pod 与 Service 网络。Submariner 通过 Gateway 节点建立 IPsec 或 VXLAN 隧道，并借助 Lighthouse 提供跨集群 DNS 解析。部署后，集群 A 的 Pod 可以直接访问集群 B 的 Service，无需经过外部负载均衡。关键检查点是：各集群的 Pod CIDR 与 Service CIDR 不重叠，否则 Submariner 无法正确建立路由。
南北向方面，推荐使用全局负载均衡（如 F5、HAProxy 或云厂商 LB）将外部流量分发到各集群的 Ingress Controller。每个集群的 Ingress Controller 再根据 Route 或 Ingress 规则转发到 Service。若需要按地域或权重切分，可在全局负载均衡层配置健康检查与权重策略。
三、DNS 与负载均衡策略
多集群 DNS 规划要解决两个问题：集群内服务发现与跨集群服务发现。集群内由 OpenShift 内置的 CoreDNS 负责，每个 Service 自动获得 <service>.<namespace>.svc.cluster.local 记录。跨集群场景下，若使用 Submariner，Lighthouse 会为导出的 Service 生成 <service>.<namespace>.svc.clusterset.local 记录，使集群 A 的 Pod 能解析到集群 B 的 Service。
南北向 DNS 则建议采用全局 DNS 方案：为同一应用在各集群部署相同 Service，通过全局 DNS 按地域、权重或健康状态返回不同集群的入口 IP。例如 app.example.com 在正常情况下返回集群 A 和集群 B 的入口 IP，当集群 A 健康检查失败时，DNS 只返回集群 B 的 IP。这种方案与全局负载均衡配合，可实现跨集群故障转移。
负载均衡策略上，建议分层设计：
- 全局层：使用 F5 GTM、云 DNS 或 HAProxy 做跨集群流量分发，配置健康检查间隔 5s、失败阈值 3 次、恢复阈值 2 次。
- 集群入口层：每个集群的 Ingress Controller 使用 NodePort 或 LoadBalancer 暴露，配置会话保持（如需要）和 TLS 终止。
- 服务层：Kubernetes Service 使用 ClusterIP 或 Headless Service，配合 EndpointSlice 实现 Pod 级负载均衡。
- 各集群 Pod CIDR、Service CIDR、节点 CIDR 是否全局唯一且不重叠？
- hostPrefix 是否根据单节点最大 Pod 数计算？
- Submariner Gateway 节点是否具备足够带宽和公网/专线连通性？
- 全局 DNS TTL 是否设置合理（建议 30～60s），避免故障切换延迟过长？
- Ingress Controller 副本数是否至少为 2，且分布在不同节点？
subctl show connections），再确认两端 Pod CIDR 是否重叠；南北向访问失败时，先检查全局负载均衡健康检查状态，再检查 Ingress Controller 的 Route 是否就绪，最后确认 DNS 解析结果是否指向正确入口 IP。
总结来说，多集群网络规划的核心是“地址不重叠、流量分层治、DNS 可切换、负载可观测”。CIDR 分配是地基，东西向与南北向治理是骨架，DNS 与负载均衡是入口控制面。三者协同，才能在生产环境中实现跨集群的高可用与可运维。