一、主流方案总览

容器网络方案的演进可以划分为三条主线，每条主线背后对应着不同的设计哲学。

纯路由方案（Flannel host-gw、Calico BGP、MacVLAN/IPVLAN）追求极致性能。它摒弃隧道封装，依托原生 IP 路由实现数据包转发，性能接近物理机。但代价是跨网段扩展受限，策略能力较弱，适合对延迟敏感且网络拓扑可控的业务。

隧道封装方案（Flannel VXLAN、Calico IPIP）追求部署灵活性。通过在原始报文外层封装新的网络头部，跨越物理子网的限制，实现扁平化组网。额外封装带来约 10-20% 的性能损耗，但换来了对底层网络的低依赖，是大多数通用场景的“安全牌”。

高级 Overlay 方案（OVN、Cilium）追求功能完备性。提供逻辑网络隔离、精细化策略、负载均衡等全栈网络能力，适合大规模、多租户、对网络要求极高的云原生集群。代价是架构复杂、运维门槛高。

这三条主线之间，本质上是性能、功能、运维复杂度三者的权衡，不存在绝对的最优解，只有最适合业务场景的选择。

名称	实现方式	封装类 型	性能表现	运维复杂度	隔离能力	核心限制
Flannel host-gw	纯三层路由	无封装	★★★★★	极低 (即装即用)	L3 基础隔离	依赖Underlay连通，不支持跨子网，无网络策略
Calico BGP	BGP路由分发	无封装	★★★★★	中 (需懂BGP)	L3/L4 策略隔离	网络架构较复杂，跨网需路由反射器(RR)
MacVLAN/IPVLAN	网卡直通映射	物理直通	★★★★★	高 (IP管理难)	物理层隔离	不支持K8s网络策略，IP资源消耗大，不灵活
Flannel VXLAN	内核态隧道	MAC-in-UDP	★★★☆☆	极低 (傻瓜式)	L2 广播域隔离	1450 MTU限制，有封装开销，仅基础转发
Calico IPIP	IP-in-IP 隧道	IP-in-IP	★★★☆☆	中 (策略管理)	L3/L4 策略隔离	仅支持IPv4，跨节点有开销，不支持组播
自建 OVN/OVS	SDN 流表转发	Geneve/GRE	★★★☆☆	极高 (专家级)	L2-L7 深度隔离	架构极其复杂，资源占用高，故障排查困难

二、纯路由方案详解

2.1 Flannel host-gw：最简单的高性能方案

Flannel host-gw 是所有 CNI 方案中架构最简单的之一。其核心原理是利用 Linux 内核的路由表，将 Pod 网段的下一跳直接指向目标节点物理 IP。

每个节点上的 flanneld 进程从 etcd 获取全集群的 Pod CIDR 与节点物理 IP 的映射关系，动态注入内核路由表。数据包离开 cni0 网桥后直接通过路由表转发，无任何隧道封装，性能损耗极低。

这种“无封装高速转发”的设计有两个显著优势：一是性能接近裸机网络，二是部署运维极简，无需配置复杂的隧道参数。但代价同样明显——所有节点必须在同一个二层网络内。跨子网、跨机房的部署场景下，host-gw 模式直接失效。

在大规模集群中，路由表条目随节点数线性增长（千级节点对应千级路由条目），虽不至于造成严重性能问题，但确实增加了路由查找的时间开销。

2.2 Calico BGP：纯三层的企业级方案

Calico BGP 将纯路由方案推进到了企业级水平。每个节点运行 BIRD 守护进程，通过 BGP 协议向集群广播本机 Pod 网段，实现动态路由宣告与学习，无需人工维护路由表。

这种设计带来了几个核心优势：无封装开销，网络性能接近物理机；支持跨子网通信，通过 BGP 路由穿透三层网络；原生支持 NetworkPolicy，Felix 进程将策略转化为 iptables 规则实现微隔离；扩展性极强，通过部署路由反射器（Route Reflector）可支撑万级节点。

运维挑战同样显著：需要团队具备 BGP 协议知识；FullMesh 模式下节点间 BGP 连接数呈平方级增长（1000 节点约 50 万连接），必须部署路由反射器；需要底层网络设备放行 BGP 协议端口。

2.3 MacVLAN / IPVLAN：性能天花板

MacVLAN 和 IPVLAN 代表了容器网络性能的极致。它们在物理网卡上创建虚拟子接口，Pod 数据包直接进出物理网卡，完全绕过宿主机内核网络栈，无任何虚拟化损耗。

MacVLAN 为每个虚拟接口分配独立 MAC 地址，在交换机看来每个 Pod 都是一台独立的物理设备；IPVLAN 则共享 MAC 地址，通过 IP 区分设备，避免了交换机 MAC 表压力。

极致性能的背后是显著的架构限制。Pod IP 必须与宿主机同网段，无法跨子网通信；节点故障时 Pod IP 无法在其他节点漂移；IP 管理复杂，与 VPC 规划容易冲突；原生不支持 NetworkPolicy。

 

三、隧道封装方案详解

当集群需要跨子网部署时，纯路由方案的“同二层限制”成为硬约束。隧道封装方案通过 Overlay 技术打破了这个限制。

3.1 Flannel VXLAN：部署最灵活的方案

Flannel VXLAN 利用 Linux 内核的 VXLAN 功能，在每个节点创建 flannel.1 虚拟网卡作为 VTEP（VXLAN Tunnel Endpoint）。源 Pod 发出的 IP 包到达 cni0 网桥后，flanneld 在原始包外封装 VXLAN 头部和外层 UDP/IP 头部，通过物理网络传输到目标节点后解封装还原。

这种设计使 Flannel VXLAN 具备了极强的兼容性——支持跨子网、跨云厂商的混合网络环境，不依赖底层网络插件。部署极简，仅需 etcd 和 flanneld 守护进程。

性能代价是 VXLAN 封装/解封装消耗 CPU；外层头部占用约 50 字节，需调整 MTU 避免 IP 分片；原生 Flannel 不支持 NetworkPolicy。

3.2 Calico IPIP：轻量封装的折中方案

Calico IPIP 是纯路由和 Overlay 之间的折中方案。它在跨子网时启用 IPIP 隧道，仅增加 20 字节外层 IP 头（远小于 VXLAN 的 50 字节）；同子网流量自动降级为纯 BGP 路由转发，消除封装开销。

这种“智能路由降级”机制使 IPIP 成为跨子网场景下性能最优的隧道方案之一。同时，IPIP 无缝集成 Calico NetworkPolicy，实现微隔离。

四、OVN Overlay 深度解析

在所有容器网络方案中，OVN 是功能最完整、架构最复杂的。它源自 OpenStack 生态，为大规模云平台提供网络虚拟化能力，后来被引入 Kubernetes 生态（通过 ovn-kubernetes）。

4.1 核心架构：控制与数据分离

OVN 采用经典的“集中式控制 + 分布式转发”架构，控制面与数据面完全解耦。

控制平面由三个核心组件构成：NB DB（北向数据库）存储用户定义的逻辑网络配置，是管理员操作的入口；ovn-northd 是核心翻译引擎，将高层逻辑配置编译为底层可识别的逻辑流表；SB DB（南向数据库）存储全集群共享的逻辑流表和网络状态，是控制面与数据面同步的枢纽。

数据平面由每个节点上的 ovn-controller 和 OVS（Open vSwitch）组成。ovn-controller 订阅 SB DB 的变更，将逻辑流表转换为物理流表下发到本地 OVS；OVS 内核模块执行流表，完成数据包的高速转发，利用 Geneve/VXLAN 隧道跨越物理网络。

4.2 多租户逻辑网络

OVN 的多租户能力是其核心竞争力之一。每个租户拥有独立的逻辑交换机和逻辑路由器，VNI（VXLAN Network Identifier）实现二层广播域的物理级隔离，不同 VNI 的流量在隧道层完全隔离。每个租户的逻辑路由器包含专属路由表、NAT 规则及网关配置，租户间路由策略互不影响。ACL 提供基于逻辑端口、IP、协议及应用层的精细化访问控制，支持状态防火墙规则。

4.3 逻辑流表四层架构

OVN 的四层流表设计体现了高度的抽象能力：

1. 用户逻辑层：接收抽象网络配置，完全屏蔽底层物理细节

2. 逻辑流表层：ovn-northd 编译为通用逻辑流表，与物理位置无关

3. 物理适配层：ovn-controller 结合物理信息转换为具体流表

4. 硬件转发层：转换为 OVS 内核态流表，利用 MegaFlow 缓存加速

这种分层设计实现了业务逻辑与物理基础设施的解耦，网络策略可在不同环境间无缝迁移。但代价是架构复杂、运维门槛高。

 

五、性能与资源对比

5.1 转发路径与性能特征

纯路由模式的数据路径最短：Pod → 内核路由表查表 → 物理网卡出包。全程内核态转发，无上下文切换开销。性能随节点规模线性缓慢衰减，无雪崩风险。

OVS/OVN 模式存在内核态+用户态混合转发。约 95% 的流量命中 MegaFlow 缓存，直接在内核态转发，性能接近原生网卡；约 5% 的新建流触发 Upcall 机制上送用户态全量解析，耗时是内核路径的 10-100 倍。这种机制使 OVN 在稳定流量下性能优异，但在短连接风暴或流表规模爆炸时，Upcall 风暴可能引发 CPU 利用率骤升和性能断崖式下跌。

5.2 内存占用估算

不同方案的内存消耗差异显著：

• 纯路由（按节点聚合） ：约 4,000 条路由条目，占用约 800KB，几乎可忽略（单租户或者多租户共享子网 = 节点数）

• 纯路由（Per-Pod /32） ：100 万条约 300MB，随 Pod 线性增长但可控（节点数*租户数）

• OVS 单节点流表：50-200 万条约 50-400MB  

• OVN 全集群逻辑流表：500-2000 万条约 5-60GB，随集群规模指数级上升，单宿主机节点都是按需承载租户的流表

• Conntrack 连接跟踪：数千万条约数 GB 到数十 GB，是真正的“内存大户”

关键结论：纯路由基于节点聚合的路由模式几乎不占用额外内存，是支撑超大规模集群网络稳定性的最优基础方案；OVN 逻辑流表在全集群维度会产生海量条目，需严格规划；Conntrack 是动态连接场景下的主要内存瓶颈。

 

六、多租户隔离

6.1 三种隔离方案对比

纯路由方案（Underlay） 通过网段划分隔离，配合 NetworkPolicy 做三层访问控制。不支持 IP 重叠，广播域共享，二层隔离性弱。适合同一 IP 规划、租户间信任度较高的场景。

Overlay/OVN 方案基于 VXLAN 封装，租户拥有独立 VNI 空间与逻辑路由，完全支持 IP 重叠，租户间网络完全不可见。适合公有云/PaaS 平台、强安全合规场景。

VRF + 纯路由方案是 Linux 内核级的硬隔离，不同 VRF 拥有独立路由表和转发表，IP 地址可完全重叠，转发性能极低。但配置极其繁琐，缺乏负载均衡、ACL 等高级功能，在云原生时代逐渐边缘化。

6.2 隔离能力对比速览