Published at 2020-11-13 | Last Update 2020-11-13

• 1 引言
• 2 裸金属（BM）时代
  • 2.1 平台特点
  • 2.2 网络需求
  • 2.3 网络解决方案
  • 2.4 网络瓶颈分析（计算规模相关）
• 3 虚拟机（VM）时代
  • 3.1 平台特点
  • 3.2 网络需求
  • 3.3 网络解决方案
  • 3.4 网络瓶颈分析（计算规模相关）
• 4 容器时代
  • 4.1 沿用大二层模型
  • 4.2 避免网络瓶颈
  • 4.3 重新审视容器的网络需求
  • 4.4 网络解决方案
  • 4.5 云原生网络 Cilium+BGP
• 5 总结
• 6 关于我们
• References

---

本文其实是前一篇文章 迈入 Cilium+BGP 的云原生网络时代 的铺垫，二者合起来，是近期在公司所做的一次技术分享的内容。 抛砖引玉，希望可以引起大家一些思考。

过去二十多年网络发生了很多的变化，比如，

1. 数据中心物理拓扑方面，由接入-汇聚-核心三级网络架构演进到 Spine-Leaf 两级架构；
2. 软件方面，出现了各种各样的网络虚拟化，例如软件实现的虚拟网桥、虚拟机交换机、 虚拟路由器、软件 overlay 网络等等；
3. 另外还出现了很多新的概念和模型，例如软件定义网络（SDN）的转发与控制分离 思想，实现上可以像 Google 一样基于 OpenFlow，可以是后来用的比较多的 BGP EVPN；另外还有 Spine-Leaf 中的分布式网关概念；还有大二层网络与纯三层路 由网络等等概念。

Fig 1-1. Various network solutions over the past years

具体到一些我们所熟悉的计算平台，

1. 早起的 bare metal 集群可能会采用 DHCP 加扁平二层（flat L2）网络，
2. 虚拟机时代 —— 比较有代表性的 OpenStack 平台，采用的是 Neutron+OVS 大二层网络，
3. Docker 内置的典型网络模型是宿主机内的 bridge 加出宿主机的 SNAT，并定义了 CNM 网络模型，
4. Kubernetes 定义了 CNI 网络规范，符合这个规范的实现有我们现在所熟悉的 Flannel、Calico、Cilium 等等。

那么，我们的一个问题是，为什么会有这么多网络方案呢？ 或者说，网络架构和解决 方案为什么在不断演进呢？这其中当然有很多方面的原因，我们今天尝试从 不断增长的计算规模 来分析一下这个问题。

Fig 1-2. The ever-increasing compute endpoints' scale

这里的计算资源基本单位可以是一台 BM、VM，也可以是容器。相应的对应三个时代：

1. 2000-2008 裸金属时代：传统计算模型。
2. 2008-2016 虚拟机时代：云计算兴起。
3. 2016- 容器时代：云原生开篇。

2.1 平台特点

Fig 2-1. Logical BM cluster topology and traffic patterns

如图所示，BM 时期计算平台的特点有：

1. 计算资源没有做虚拟化。
2. 应用（applications）直接运行在物理服务器上。
3. 典型的应用访问模式（application accessing pattern）：客户端-服务器（client-server）模式。
4. 南北向流量（进出集群的流量）远大于东西向流量（集群内应用互访的的流量）。

2.2 网络需求

这种计算模型给网络提出的需求也很简单：

首先，能够比较高效地处理南北向流量；

第二，集群内应用之间的互访（东西向流量），也就是节点间的网络连通性，这与本文 讨论的主题（计算实例规模）密切相关；

第三，在连通性的基础上，要有必要的访问控制和安全措施。例如可以基于硬件防火墙做网 段级别的控制、基于 iptables 做一些简单的主机防火墙功能等等。这些内容不在本文 讨论范围。

2.3 网络解决方案

针对以上需求，业界设计了经典的接入、汇聚、核心三级网络架构，如下图所示：

Fig 2-2. Typical network solution for BM platforms

1. 南北向流量在核心交换机处理。
2. 所有内部子网的网关一般也配置在核心，因此集群内跨网段需要经过核心交换机。
3. 整张网络是一个二层网络，也叫桥接网络或交换网络。

在这种模型中，由于节点/应用之间通信都可能要经过核心，因此核心交换机需要记录所 有节点的 IP 和 MAC 地址信息。

2.4 网络瓶颈分析（计算规模相关）

在这种网络方案中，与计算节点规模相关的瓶颈最可能出现在核心交换机，因为要实现 任何两台之间节点之间可达，核心交换机需要占用硬件表项（FIB TCAM）来记录集群内所有 主机的 IP/MAC 信息。

Fig 2-3. Bottleneck analysis

我们来算一下。假设，

1. 每个机房（或 POD）200 个机柜
2. 每个机柜 10 台服务器

那可以算出整个机房有 2000 台服务器。假设每个 node 占用一到两个 IP 地址，核心交 换机将占用 2k~4k 条表项。

假设使用的核心交换机有 16K 条表项，其中能用到 70% 左右（太高会导致哈希冲突， 包只能交由交换机 CPU 软件处理，导致 CPU 升高、丢包甚至宕机），因此有效表项 是 11K 条。

2K~4K 与 11K 相比可以得出结论：转发表项非常充裕，核心交换机没有表项瓶颈。

2008 年以后，业界开始对计算资源做大规模虚拟化，我们来到了云计算时代。

3.1 平台特点

Fig 3-1. Logical VM cluster topology and traffic patterns

这一时期的特点：

1. 将基础设施作为服务（IaaS）交付给用户，相应地，计算资源的基本单位也从物理机（BM）变成虚拟机（VM）。
2. 计算资源的数量或部署密度比之前高了一个数量级。
3. 典型的应用访问模式不再是之前的客户端-服务器模型，而是变成了微服务（ micro-service）模式。
4. 与微服务模型对应的一个重要网络变化是：东西向流量超过了南北向流量，成为数据中心的主要流量。

代表性的计算平台有：

1. Amazon Web Service (AWS), 2008
2. OpenStack, 2010

3.2 网络需求

这时对网络的需求：

首先肯定虚拟机之间的网络连通性，需要考虑的问题包括，

1. 同宿主机、同网段的虚拟机之间如何通信；
2. 同宿主机、跨网段的虚拟机之间如何通信；
3. 跨宿主机、同网段的虚拟机之间如何通信；
4. 跨宿主机、跨网段的虚拟机之间如何通信；
5. 虚拟机和宿主机或物理机之间如何通信；
6. 虚拟机进出集群（集群边界）如何通信等等。

第二，虚拟机的 IP 和 MAC 地址要在虚拟机的生命周期内保持不变，这一点特别重要。本 质上来说这是由 IAAS 计算模型决定的：在 IAAS 模型中，交付给用户的是一台一台的 虚拟机资源，因此用户看到的就是 虚拟机这一层抽象，而 IP 和 MAC 是虚拟机的资源 属性，底层虚拟机迁移要做到用户无感知，因此 IP/MAC 地址不能变。

此外还有硬多租户（hard multi-tenancy）和安全，这两点也非常重要，但跟本文要讨论的 关系不大，因此这里也不展开。

3.3 网络解决方案

Fig 3-2. Typical network solution for VM platforms

针对以上需求，典型的解决方案是所谓的大二层网络，如上图所示：

首先，在每个宿主机内运行一个虚拟交换机（vswitch），虚拟交换机向上连接到物理交换 机，向下连接到每个虚拟机。因此网络的边界从原来的接入交换机（顶置交换机）这一层， 下沉到宿主机内部，我们开始有了网络虚拟化（network virtualization）。 这样整张网络成为一个大二层网络。

这里大二层的意思是，同网段的虚拟机，不管它们是否在同一台宿主机上，彼此都能 够通过二层（MAC）访问到对方。即，逻辑上它们位于同一个二层网络（二层域）。

和这种模型对应的是一个全局的（或中心式的）负责 IP 地址分配和管理的服务（IPAM）。

大二层网络可以基于数据中心网络实现，也可以在宿主机内用虚拟网络实现，例如 VxLAN 隧道，如果需要动态下发配置，还可以引入 SDN。

如果是基于数据中心网络的大二层，那核心交换机此时不仅需要记录宿主机的 IP/MAC 信息 ，还需要记录所有虚拟机的 IP/MAC 信息，这样才能支持虚拟机全网可迁移。OpenStack 的 provider network 模型就是这样的设计，如下图所示：

Fig 3-3. OpenStack provider network model

OpenStack 网络方案中有如下几个组件：

1. Neutron-server：这是一个全局的负责 IP、Network、Subnet 等网络资源的分配和管理的服务，即上面所说的 global IPAM。
2. 每个计算节点上会运行一个 Neutron-OVS-agent，负责虚拟机创建/销毁时的网络配置。
3. 每台计算节点上会运行 OVS，负责连接所有虚拟机、虚拟机流量的转发等数据平面的功 能。实际的拓扑比这个还要更复杂一些，因为为了支持安全组还引入了一层 Linux bridge。

Provider 模型中，网关配置在数据中心网络设备（例如核心交换机）上，所有跨网段的 包要经过核心交换机转发。图中从 1 到 18 的数字连起来，就是跨网段的两个虚拟机之间的转发路径。

3.4 网络瓶颈分析（计算规模相关）

Fig 3-4. Bottleneck analysis

我们来算一下此时核心交换机的表项规模。假如这时我们机房更大了一些，

1. 总共 300 个机柜，但其中只有 2/3 的节点用来做虚拟化，1/3 跑传统 BM 应用，例如数据库服务，
2. 每个 node 平均 15 台虚拟机，

那可以算出总共有 30k 虚拟机，需要占用核心交换机 ~30K 表项。

如果使用的是主流交换机，核心有 64K 表项，乘以 70% 是 44K，也就是能支撑 4 万 左右实例，大于 ~30K，因此能满足需求。

所以我们得出结论，大二层方案是适合 VM 或 IAAS 模型的。

2016 年开始，我们进入了大规模容器时代。容器也被称为轻量级虚拟机，所以它的很多 网络需求与虚拟机类似，但部署密度高了一个数量级。典型的容器平台：

1. Mesos
2. Kubernetes

4.1 沿用大二层模型

如果还是用前面的大二层模型，只是将虚拟机换成容器，如下图所示：

Fig 4-1. If still using large L2 network

如果没有一些很特殊的业务需求，只是单纯基于已有大二层网络实现这样一套容器方案，其 技术难度和开发量都不是很大，例如，如果要将 Kubernetes 接入OpenStack Neutron 网络 ，开发一个针对 Neutron+OVS 的 CNI 插件就可以了 [1]。

但前面提到，这种 global IPAM + central gateway 方案中，核心交换机需要记录 每个实例的 IP/MAC 信息，再考虑到容器的部署密度，可以预见的是，交换机硬件表项将 撑不住。我们来具体算一下。

假设还是 2/3 节点做虚拟化，平均每台 node 部署 75 个容器，那总容器将达到 150K， 远远超过了核心的表项规模。所以这种物理的大二层网络是无法支撑容器规模的。

除了硬件交换机表项这个瓶颈，在软件上，其实 global IPAM 也已经无法在性能上满足容 器频繁的漂移、创建、销毁的需求了。所以大二层方案在软件和硬件上都已经陷入了困境。

因此，网络在容器时代必须做出变化了。

4.2 避免网络瓶颈

刚才提到的 64K 表项交换机其实在今天还不算过时，那如何在这张物理网络上支撑 15万、 20 万甚至 30 万以上容器呢（刚才的计算中，还有 1/3 的节点没有做虚拟化，而且容器部 署密度可以进一步提高）？

显然，最重要的一点就是不能让核心交换机记录所有的容器的 IP 信息。怎么做到这一 点呢？

Fig 4-2. If still using large L2 network

比较主流的方式是，

1. 在每个 node 内用虚拟路由器（vrouter）替换虚拟交换机（vswitch），将整 张大二层网络拆分成众多的小二层网络。
2. 每个 node 管理一个网段，负责该节点内容器 IP 的分配和回收，即从原来的 global IPAM 变成了 local IPAM。
3. 每个节点内是一个二层域，节点内容器之间走交换（bridging/switching）；跨节点就 是跨二层域，需要走路由（routing）。
4. 每个节点内运行一个 BGP agent，负责节点之间或节点和数据中心网络之间的路由同步。

采用这样的设计之后，

1. 核心交换机就只需要记录 node 本身的 IP 和它管理的网段，表项重新回到与宿主机数量同一量级，而与容器的数量没有直接关系。
2. IPAM 从中心式变成了分散式，性能瓶颈也解决了。

4.3 重新审视容器的网络需求

前面看到，只要对网络方案做出一些变化，就可以避免交换机的硬件瓶颈和 IPAM 的软件瓶 颈。

现在我们来重新审视一下容器的特点，以便从需求的角度来讨论什么样的方案才是最适合容 器平台的。

Fig 4-3. Container platform vs. VM paltform

容器编排平台，例如 Kubernetes，跟 OpenStack 这样的虚拟机编排平台相比，最大的不 同之一就是抽象的层次更高。

1. 虚拟机平台交付的是虚拟机实例，抽象层次是计算资源本身这一层。
2. 而容器平台交付的是服务，例如 k8s 里的 Service，服务屏蔽掉了后面的计算实例的细 节。客户端只需要知道 ServiceIP 等一些更上层的访问入口。

这带来的一个重要变化就是：客户端不再关心服务的具体实例数量，以及每个实例的 IP/MAC 等信息。因此实例的 IP/MAC 地址没有那么重要了，例如 Kubernetes 里大部 分类型的 Pod 在重新发布之后 IP 都会变化。

此时，容器的核心网络需求：

1. 规模：例如还是刚才那个机房，现在要能支持 15 万以上容器。
2. 快速：包括 IPAM API 的相应时间、为容器创建和删除网络的时间等，否则网络部分会 拖慢整体的容器发布效率。
3. 弹性：动态、大规模扩缩容。
4. 其他一些需求，例如软的多租户、安全等等，本文不展开。

4.4 网络解决方案

综合以上需求，合理的容器网络解决方案就是：

1. 小二层网络，加每个 node local 的 IPAM，管理自己的网段
2. 再加跨宿主机的直接路由或者隧道

如下图所示，

Fig 4-4. Typical network solution for container platforms

那么，和这种模型对应的容器网络方案有：

1. Calico + BGP/VxLAN，前几年用的比较多
2. Cilium + BGP/VxLAN，最近一两年越来越火

Spine-Leaf 架构

实际上数据中心网络拓扑近些年也有一个变化，从原来的接入-汇聚-核心三级架构变成了现 在的 Spine-Leaf 量级架构，如下图所示：

Fig 4-5. Typical network solution for container platforms, with Spine-Leaf

Spine 层和 Leaf 层组成一个全连接网络，换句话说，任何一个 Leaf 都连接到了任何一个 Spine。这种架构的好处：

1. 横向扩展性非常好：任何一层有带宽瓶颈，只需要添加一台新设备，然后和另一层的所 有设备连接起来。
2. 链路利用率更高：通过三层（L3）组网，不需要 STP 协议（STP 避免了二层环路，但使 可用带宽减半）。
3. 东西向带宽更高：更适合现代微服务的场景。
4. 故障域更小：挂掉一台设备，影响范围更小。

Spine-Leaf 拓扑下，容器的网络方案是类似的，还是基于小二层加 local IPAM，只是 BGP 建连会稍有不同 [2]。

4.5 云原生网络 Cilium+BGP

这里稍微就 Cilium 网络展开一些讨论，这是最近一两年流行起来的网络方案。

Fig 4-6. Cilium powered Kubernetes cluster [5]

Cilium 的组件如上图所示，主要包括，

1. cilium-agent：每台 node 上跑一个，同时监听 k8s apiserver 和 cilium kvstore。
2. cilium kvstore：存储 cilium 的一些全局状态，例如 identity。
3. cilium-operator：每个集群一个，图中没画出来，在公有云上承担 IPAM 的功能。

Cilium 的核心基于 eBPF，这是 4.8 内核 引入的一项革命性技术：它使得内核变得可编程 。这里可编程的意思是，以前要改变内核行为，需要修改内核代码、编译调试、重新打镜像、 安装运行等等，而且还要维护自己的内核分支，现在可能写几行 eBPF 代码然后动态加载到 内核就能实现同样的效果。

eBPF 目前主要用在两个方向：动态跟踪（tracing） 和网络（networking）。

有了 eBPF/XDP 之后，我们可以看到数据平面处理（dataplane processing）有一个趋势：

• 早期基于内核协议栈处理，更多地以功能为主
• 前些年内核到达性能瓶颈，于是一些团队尝试将部分网络处理放到用户态，预留专门的 、独享的网卡、CPU、内存等资源来收发包，例如 DPDK。
• 最近几年开始重新回到内核。比较有代表性的是 Facebook 的 L4LB Katran，用 eBPF/XDP 重新之后比原来基于 IPVS 的版本快了 10 倍，性能已经和 DPDK 一个量级， ，而且还可以复用内核已有的基础设施和生态。而用户态方式最大的问题之一是原有的网 络工具几乎都失效了，并且没有通用的 L4-L7 协议栈支持。

Cilium 是基于 eBPF 实现的一个网络方案，主打高性能和安全。 对内核要求较高，但也不是非常高，根据我们的使用经验，

1. 4.14 能用，
2. 4.19 够用；
3. 5.x 内核外做了一些优化，或者原生实现了某些高级功能。

更多关于 Cilium+BGP 的实践，可以参考我们之前的文章 [2,3]。

网络方案的演进是一个复杂的过程，涉及到很多因素，本文尝试从计算规模的角度对这一问 题进行了分析。从中可以看出，每种网络方案或网络模型都不是凭空出现的，它们本质上都 是业务需求在网络层的反映；而所有业务需求中，最重要的可能就是规模。

如果对我们团队感兴趣，可以关注我们的技术博客 https://ctripcloud.github.io 。

1. 云计算时代携程的网络架构变迁（2019）
2. Trip.com: First Step towards Cloud-native Networking
3. 迈入 Cilium+BGP 的云原生网络时代
4. Facebook L4LB: Katran
5. Cilium ClusterMesh: A Hands-on Guide