1. 课程导入与全景认知

当企业的业务系统从单一数据中心扩展到多个公有云、私有云和边缘节点时，网络工程师面对的第一个现实问题往往不是“怎么配路由”，而是“我到底在管一张什么样的网”。传统数据中心里，IP地址、VLAN、防火墙策略、路由域边界都相对清晰；而在多云环境中，同一套应用可能分布在AWS的VPC、阿里云的VPC、自建Kubernetes集群和IDC机房中，每个云厂商都有自己的网络模型、地址规划习惯和路由控制面。多云Overlay网络与路由架构，正是为了解决“跨云、跨域、跨集群的连通与策略一致性”而出现的一整套技术体系。

要建立全景认知，先要抓住三个层次。第一层是Underlay，即云厂商或物理网络提供的底层IP可达性，包括VPC、子网、专线、VPN、云企业网等。第二层是Overlay，在Underlay之上通过隧道封装（如VXLAN、IPsec、WireGuard、Geneve）构建虚拟网络，使不同云、不同集群中的Pod或虚拟机看起来处于同一逻辑网络。第三层是路由与控制面，负责把Overlay网段、服务网段、外部路由互相通告，并施加策略，常见组件包括BGP、路由反射器、Service Mesh控制面、CNI插件和云原生网关。三层之间的关系可以用下面的全景图来理解。

从这张全景图可以看到，多云Overlay网络并不是单一产品，而是“底层可达 + 虚拟封装 + 路由控制 + 策略治理”的组合。理解这一点后，后续章节的学习地图就清晰了：先掌握Underlay的连通方式，再理解Overlay的封装与转发，然后深入BGP路由通告、CNI实现、服务网格流量治理，最后落到排障与性能优化。

为什么需要多云Overlay网络

假设一家公司有两个Kubernetes集群，一个在阿里云，Pod网段为10.244.0.0/16；另一个在AWS，Pod网段为10.245.0.0/16。两个集群各自内部通信正常，但跨集群的服务调用无法直接进行，因为云厂商VPC路由表不认识对方的Pod CIDR。最直接的方案是打通VPC对等连接，但VPC对等连接通常只支持VPC主网段，不支持Pod网段，而且当集群数量增加到十几个时，对等连接会变成网状结构，运维复杂度急剧上升。

Overlay方案的做法是：在每个集群部署一个隧道网关或CNI插件，把Pod流量封装进UDP或IPsec隧道，通过Underlay的VPC可达性传输到对端，再解封装还原为原始Pod包。这样，Underlay只需要保证节点之间IP可达，Overlay负责承载Pod网段。路由控制面则通过BGP把10.244.0.0/16和10.245.0.0/16互相通告，使两端节点知道对方Pod网段的下一跳是隧道端点。

典型场景与选型判断

多云Overlay网络常见的落地场景有四类。第一类是多集群服务互通，例如生产集群与灾备集群需要互相调用API；第二类是混合云统一网络，IDC中的虚拟机需要访问云上Pod；第三类是边缘计算，边缘节点通过Overlay接入中心集群；第四类是多租户隔离，不同业务线共享Underlay但需要独立的Overlay网段和策略。

选型时，可以先回答三个问题：Underlay是否已经提供了跨云IP可达？如果只有公网，通常选择IPsec或WireGuard；如果已有专线或云企业网，可以选择VXLAN over专线。第二，是否需要Pod网段直接互通？如果只需要Service互通，可以优先考虑服务网格或API网关，避免暴露Pod CIDR。第三，路由控制面由谁维护？如果团队已有BGP运维能力，可以用BGP通告Pod网段；如果希望云厂商托管，可以选择云企业网或托管CNI方案。

整体技术栈与学习路径

从技术栈角度看，多云Overlay网络可以拆成五个模块。第一是封装协议，包括VXLAN、Geneve、IPsec、WireGuard，决定数据包如何被包裹和传输。第二是隧道端点，通常是节点上的VTEP或网关Pod，负责封装和解封装。第三是路由通告，通过BGP或静态路由把Pod CIDR、Service CIDR传播到对端。第四是策略控制，包括NetworkPolicy、服务网格授权策略和云防火墙规则。第五是可观测性，包括流日志、隧道状态、BGP邻居状态和延迟指标。

学习路径建议按“先通后优”的顺序推进：先理解Underlay可达性和Overlay封装原理，再动手搭建一个双集群BGP互通实验，观察路由表和隧道状态；然后引入NetworkPolicy和服务网格，验证策略是否生效；最后学习排障方法，例如用traceroute、tcpdump、ip route和BGP邻居日志定位问题是出在Underlay、Overlay还是策略层。