如何防止跨云网络冲突导致 Overlay 网段重叠
解读
国内企业在“两地三中心”或“混合云+多活”架构下,经常把容器集群部署在阿里云、腾讯云、华为云、私有云等多个环境。Overlay 网络(VXLAN、Geneve)为了隔离租户,会预先分配一段24 位 VNI 空间和一段RFC1918 私网段作为容器子网。若各云各自为政,极易出现 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 三段地址的二次重叠,导致跨云 Pod 互访时路由黑洞、SNAT 失效、TLS 握手失败。面试时,考官想确认你是否具备“跨云 IPAM 顶层设计能力”,而不仅仅是会敲 docker network create -d overlay。
知识点
- Docker Swarm Overlay 默认子网池:
默认--default-addr-pool为 20 段 /16,首段从 10.0.0.0/16 开始顺序分配;若多套 Swarm 都走默认,必然冲突。 - VXLAN VNI 范围:
Docker 使用 VXLAN 时 VNI 从 4096 到 65535,共 61440 个;多套集群无统一规划也会复用。 - 国内云厂商 VPC 预留习惯:
阿里云 VPC 子网最小划分到 /28,但企业常整段预留 10.0.0.0/8;腾讯云习惯用 172.16~172.31;私有云沿用旧网管习惯 192.168.x.0/24。 - RFC 要求与合规:
等保 2.0 要求“地址分配应可审计、可溯源”,若出现重叠,审计日志里源 IP 相同却无法定位真实工作负载,直接算不合规。 - Docker 20.10+ 特性:
支持--default-addr-pool-mask-length 24细粒度拆分,也支持--data-path-port自定义 VXLAN 目标端口,避免与云厂商 4789 冲突。
答案
-
统一 IPAM 规划
由企业网络组牵头,把10.0.0.0/9划给阿里云区域,10.128.0.0/9划给腾讯云区域,172.16.0.0/12留给私有云,192.168.0.0/16做预留及灰度。每套 Swarm 集群通过
docker swarm init --default-addr-pool 10.32.0.0/16 --default-addr-pool-mask-length 24
仅领取 256 个 /24 段,确保跨云地址池正交。 -
VNI 全局注册表
在 CMDB 或 Git 仓库维护一张“VNI 分配表”,字段含云厂商、集群名、用途、Owner。新集群创建前必须先 Pull Request 领取一段 VNI(如 5000-5999),合并后自动触发 Terraform 创建 Swarm,杜绝人工随意指定。 -
NAT 出网统一收口
跨云互联采用云厂商高速通道或专线+BGP,把容器段只发布到企业内网,不进入公网;出公网统一走各云NAT 网关,避免容器源地址直接暴露,也防止与对端云侧 VPN 的 interesting traffic 列表冲突。 -
Docker 守护进程级加固
在每个节点/etc/docker/daemon.json中固定
"default-address-pools": [{"base":"10.32.0.0/16","size":24}]
并设置"userland-proxy":false,减少 iptables 规则干扰;同时把VXLAN 目标端口改为 8472(与 Flannel 一致),避开云安全组默认只开 4789 的坑。 -
运行时监控与漂移自愈
部署 Prometheus+Grafana 监控Swarm_Node_IP_Utilization,当某集群地址池利用率 >80% 时,通过 Webhook 调用脚本自动向 CMDB 申请下一段 /16,并滚动扩容集群;若检测到 VNI 冲突,立即触发网络隔离脚本iptables -I FORWARD -s 重叠网段 -j DROP并告警。 -
合规闭环
每季度由等保测评机构扫描一次,出具《跨云地址分配合规报告》,若发现重叠,需在 30 天内整改,否则影响年审。
拓展思考
- 若未来引入 IPv6,可完全抛弃 RFC1918 私网重叠问题,但国内三大运营商目前仅提供 /56 前缀,且部分 Region 未开放 SLAAC,需评估双栈过渡方案。
- 当业务下沉到边缘 K8s 集群(KubeEdge、OpenYurt)时,边缘节点通过 4G/5G 入云,NAT 层层叠加,可能出现二次 SNAT 导致 MTU 发现失效;此时可把 Docker Swarm 的 MTU 设置为 1450,并在 VXLAN 头中开启 DF 位,让链路上层设备正确分片。
- 若企业后续改用 Cilium+BGP 做路由式网络,Overlay 退居二线,但地址冲突问题会转移到 BGP RR 的 Route Target 规划;可提前在 Swarm 阶段把32 位掩码的 PodCIDR 注册到 CMDB,为 BGP 时代留好干净的路由表。