赵亚楠：云计算时代携程网络架构变迁之路

　　作者简介

　　赵亚楠，携程云平台资深架构师。

　　2016年加入携程云计算部门，先后从事OpenStack、SDN、容器网络（Mesos、K8S）、容器镜像存储、分布式存储等产品的开发，目前带领CtripCloudNetwork&StorageTeam，专注于网络和分布式存储研发。

　　前言

　　本文内容来自我在GOPS2019深圳站的同名分享。和演讲的版本相比，本文叙述方式稍有调整，以更适合阅读，另外对内容做了少量更新。

　　以下是正文。

　　正文

　　本文介绍云计算时代以来携程在私有云和公有云上的几代网络解决方案。希望这些内容可以

　　给业内同行，尤其是那些设计和维护同等规模网络的团队提供一些参考。

　　本文将首先简单介绍携程的云平台，然后依次介绍我们经历过的几代网络模型：从传统的基

　　于VLAN的二层网络，到基于SDN的大二层网络，再到容器和混合云场景下的网络，最后是

　　cloudnative时代的一些探索。

　　0携程云平台简介

　　携程Cloud团队成立于2013年左右，最初是基于OpenStack做私有云，后来又开发了自己的baremetal（BM）系统，集成到OpenStack，最近几年又陆续落地了Mesos和K8S平台，并接入了公有云。目前，我们已经将所有cloud服务打造成一个CDOS—携程数据中心操作系统的混合云平台，统一管理我们在私有云和公有云上的计算、网络、存储资源。

　　Fig2.TimelineoftheNetworkArchitectureEvolution

　　在私有云上，我们有虚拟机、应用物理机和容器。在公有云上，接入了亚马逊、腾讯云、UCloud等供应商，给应用部门提供虚拟机和容器。所有这些资源都通过CDOSAPI统一管理。

　　网络演进时间线

　　Fig2.TimelineoftheNetworkArchitectureEvolution

　　最开始做OpenStack时采用的是简单的VLAN二层网络，硬件网络基于传统的三层网络模型。

　　随着网络规模的扩大，这种架构的不足逐渐显现出来。因此，在2016年自研了基于SDN的大二层网络来解决面临的问题，其中硬件架构换成了Spine-Leaf。

　　2017年，我们开始在私有云和公有云上落地容器平台。在私有云上，对SDN方案进行了扩展和优化，接入了Mesos和K8S平台，单套网络方案同时管理了虚拟机、应用物理机和容器网络。公有云上也设计了自己的网络方案，打通了混合云。

　　最后是2019年，针对CloudNative时代面临的一些新挑战，我们在调研一些新方案。

　　1基于VLAN的二层网络

　　2013年我们开始基于OpenStack做私有云，给公司的业务部门提供虚拟机和应用物理机资源。

　　1.1需求

　　网络方面的需求有：

　　首先，性能不能太差，衡量指标包括instance-to-instance延迟、吞吐量等等。

　　第二，二层要有必要的隔离，防止二层网络的一些常见问题，例如广播泛洪。

　　第三，实例的IP要可路由，这点比较重要。这也决定了在宿主机内部不能使用隧道技术。

　　第四，安全的优先级可以稍微放低一点。如果可以通过牺牲一点安全性带来比较大的性能提升，在当时也是可以接受的。而且在私有云上，还是有其他方式可以弥补安全性的不足。

　　1.2解决方案：OpenStackProviderNetwork模型

　　经过一些调研，我们最后选择了OpenStackprovidernetwork模型[1]。

　　Fig3.OpenStackProviderNetworkModel

　　如图3所示。宿主机内部走二层软交换，可以是OVS、LinuxBridge、或者特定厂商的方案；宿主机外面，二层走交换，三层走路由，没有overlay封装。

　　这种方案有如下特点:

　　首先，租户网络的网关要配置在硬件设备上，因此需要硬件网络的配合，而并不是一个纯软件的方案；

　　第二，实例的IP是可路由的，不需要走隧道；

　　第三，和纯软件的方案相比，性能更好，因为不需要隧道的封装和解封装，而且跨网段的路

　　由都是由硬件交换机完成的。

　　方案的一些其他方面：

　　二层使用VLAN做隔离

　　ML2选用OVS，相应的L2agent就是neutronovsagent

　　因为网关在硬件交换机上，所以我们不需要L3agent（OpenStack软件实现的虚拟路由器）来做路由转发

　　不用DHCP

　　没有floatingip的需求

　　出于性能考虑，我们去掉了securitygroup

　　1.3硬件网络拓扑

　　图4是我们的物理网络拓扑，最下面是服务器机柜，上面的网络是典型的接入-汇聚-核心三层架构。

　　Fig4.PhysicalNetworkTopologyintheDatacenter

　　特点：

　　每个服务器两个物理网卡，直连到两个置顶交换机做物理高可用

　　汇聚层和接入层走二层交换，和核心层走三层路由

　　所有OpenStack网关配置在核心层路由器

　　防火墙和核心路由器直连，做一些安全策略

　　1.4宿主机内部网络拓扑

　　再来看宿主机内部的网络拓扑。图5是一个计算节点内部的拓扑。

　　Fig5.DesignedVirtualNetworkTopologywithinAComputeNode

　　特点：

　　首先，在宿主机内有两个OVSbridge：br-int和br-bond，两个bridge直连

　　有两个物理网卡，通过OVS做bond。宿主机的IP配置在br-bond上作为管理IP

　　所有实例连接到br-int

　　图中的两个实例属于不同网段，这些标数字的（虚拟和物理）设备连接起来，就是两个跨网段的实例之间通信的路径：inst1出来的包经br-int到达br-bond，再经物理网卡出宿主机，然后到达交换机，最后到达路由器（网关）；路由转发之后，包再经类似路径回到inst2，总共是18跳。

　　作为对比，图6是原生的OpenStackprovidernetwork模型。

　　Fig6.VirtualNetworkTopologywithinAComputeNodeinLegacyOpenStack

　　这里最大的区别就是每个实例和br-int之间都多出一个Linuxbridge。这是因为原生的OpenStack支持通过securitygroup对实例做安全策略，而securitygroup底层是基于iptables的。OVSport不支持iptables规则，而Linuxbridgeport支持，因此OpenStack在每个实例和OVS之间都插入了一个LinuxBridge。在这种情况下，inst1->inst2总共是24跳，比刚才多出6跳。

　　1.5小结

　　最后总结一下我们第一代网络方案。

　　优点

　　首先，我们去掉了一些不用的OpenStack组件，例如L3agent、HDCPagent,Neutronmetaagent等等，简化了系统架构。对于一个刚开始做OpenStack、经验还不是很丰富的团队来说，开发和运维成本比较低。

　　第二，上面已经看到，我们去掉了LinuxBridge，简化了宿主机内部的网络拓扑，这使得转发路径更短，实例的网络延迟更低。

　　第三，网关在硬件设备上，和OpenStack的纯软件方案相比，性能更好。

　　第四，实例的IP可路由，给跟踪、监控等外围系统带来很大便利。

　　缺点

　　首先，去掉了securitygroup，没有了主机防火墙的功能，因此安全性变弱。我们通过硬件防火墙部分地补偿了这一问题。

　　第二，网络资源交付过程还没有完全自动化，并且存在较大的运维风险。providernetwork模型要求网关配置在硬件设备上，在我们的方案中就是核心路由器上。因此，每次在OpenStack里创建或删除网络时，都需要手动去核心交换机上做配置。虽然说这种操作频率还是很低的，但操作核心路由器风险很大，核心发生故障会影响整张网络。

　　2基于SDN的大二层网络

　　以上就是我们在云计算时代的第一代网络方案，设计上比较简单直接，相应地，功能也比较少。随着网络规模的扩大和近几年我们内部微服务化的推进，这套方案遇到了一些问题。

　　2.1面临的新问题

　　首先来自硬件。做数据中心网络的同学比较清楚，三层网络架构的可扩展性比较差，而且我们所有的OpenStack网关都配置在核心上，使得核心成为潜在的性能瓶颈，而核心挂了会影响整张网络。

　　第二，很大的VLAN网络内部的泛洪，以及VLAN最多只有4096个的限制。

　　第三，宿主机网卡比较旧，都是1Gbps，也很容易达到瓶颈。

　　另外我们也有一些新的需求：

　　首先，携程在这期间收购了一些公司，会有将这些收购来的公司的网络与携程的网络打通的需求。在网络层面，我们想把它们当作租户对待，因此有多租户和VPC的需求。

　　另外，我们想让网络配置和网络资源交付更加自动化，减少运维成本与运维风险。

　　2.2解决方案:OpenStack+SDN

　　针对以上问题和需求，数据中心网络团队和我们cloud网络团队一起设计了第二代网络方案：一套基于软件+硬件、OpenStack+SDN的方案，从二层网络演进到大二层网络。

　　硬件拓扑

　　在硬件拓扑上，从传统三层网络模型换成了近几年比较流行的Spine-Leaf架构，如图7所示。

　　Fig7.Spine-LeafTopologyintheNewDatacenter

　　Spine-Leaf是full-mesh连接，它可以带来如下几个好处：

　　第一，转发路径更短。以图7的Spine-Leaf（两级Clos架构）为例，任何两台服务器经过三跳（Leaf1->Spine->Leaf2）就可以到达，延迟更低，并且可保障（可以按跳数精确计算出来）。

　　第二，水平可扩展性更好，任何一层有带宽或性能瓶颈，只需新加一台设备，然后跟另一层的所有设备直连。

　　第三，所有设备都是active的，一个设备挂掉之后，影响面比三层模型里挂掉一个设备小得多。

　　宿主机方面，我们升级到了10G和25G的网卡。

　　SDN:控制平面和数据平面

　　数据平面基于VxLAN，控制平面基于MP-BGPEVPN协议，在设备之间同步控制平面信息。网关是分布式的，每个leaf节点都是网关。VxLAN和MP-BGPEVPN都是RFC标准协议，更多信息参考[2]。

　　VxLAN的封装和解封装都在leaf完成，leaf以下是VLAN网络，以上是VxLAN网络。

　　另外，这套方案在物理上支持真正的租户隔离。

　　SDN:组件和实现

　　开发集中在以下几个方面。

　　首先是自研了一个SDN控制器，称作携程网络控制器（CtripNetworkController），缩写CNC。CNC是一个集中式控制器，管理网络内所有spine和leaf节点，通过neutronplugin与OpenStackNeutron集成，能够动态向交换机下发配置。

　　Neutron的主要改造：

　　添加了ML2和L3两个plugin与CNC集成

　　设计了新的port状态机，因为原来的port只对underlay进行了建模，我们现在有

　　underlay和overlay两个平面

　　添加了一下新的API，用于和CNC交互

　　扩展了一些表结构等等

　　图8就是我们对neutronport状态的一个监控。如果一个IP（port）不通，我们很容易

　　从它的状态看出问题是出在underlay还是overlay。

　　Fig8.MonitoringPanelforNeutronPortStates

　　2.3软件+硬件网络拓扑

　　Fig9.HW+SWTopologyoftheDesignedSDNSolution

　　图9是我们软件+硬件的网络拓扑：

　　以leaf为边界，leaf以下是underlay，走VLAN；上面overlay，走VxLAN

　　underlay由neutron、OVS和neutronOVSagent控制；overlay是CNC控制

　　Neutron和CNC之间通过plugin集成

　　2.4创建实例涉及的网络配置流程

　　这里简单来看一下创建一个实例后，它的网络是怎么通的。图10中黑色的线是OpenStack原有的逻辑，蓝色的是我们新加的。

　　Fig10.FlowofSpawnAnInstance

　　控制节点：从nova发起一个创建实例请求，指定从哪个网络分配IP给这个实例。

　　nova调度器将任务调度到某台计算节点

　　计算节点：novacompute开始创建实例，其中一步是向neutron发起一个create

　　port请求，简单认为就是申请一个IP地址

　　NeutronServer:neutron创建一个port，然后经createport的postcommit方法到达CNCML2plugin；plugin进一步将port信息同步给CNC，CNC将其存储到自己的DB

　　计算节点：port信息从neutronserver返回给nova-compute

　　计算节点：nova-compute拿到port信息，为实例创建虚拟网卡，配置IP地址等参数，并将其attach到OVS

　　计算节点：ovsagent检测到新的device后，就会为这个device配置OVS，添加flow等，这时候underlay就通了，它会将underlay状态上报给neutronserver

　　计算节点：nova-compute做完网络配置后，会发送一个updateport消息给neutronserver，其中带着host_id信息，表示这个port现在在哪台计算节点上

　　NeutronServer:请求会通过postcommit发给CNC

　　CNC：CNC根据host_id找到这台计算节点所连接的leaf的端口，然后向这些端口动态下发配置，这时候overlay就通了，最后将overlay状态上报给neutronserver

　　在我们的系统里看，这时port就是一个ACTIVE_ACTIVE的状态，表示underlay和overlay配置都是正常的，网络应该是通的。

　　2.5小结

　　总结一下我们这套方案。

　　硬件

　　首先，我们从三层网络架构演进到Spine-Leaf两级架构。Spine-Leaf的full-mesh使得服务器之间延迟更低、容错性更好、更易水平扩展。另外，Spine-Leaf还支持分布式网关，缓解了集中式网关的性能瓶颈和单点问题。

　　软件

　　自研SDN控制器并与OpenStack集成，实现了网络的动态配置。

　　这套方案同时支持虚拟机和应用物理机部署系统，限于篇幅这里只介绍了虚拟机。

　　多租户

　　有硬多租户（hard-multitenancy）支持能力。

　　3容器和混合云网络

　　以上方案最开始还是针对虚拟机和应用物理机设计的。到了2017年，我们开始在私有云和公有云上落地容器平台，将一部分应用从虚拟机或应用物理机迁移到容器。

　　容器平台（K8S、Mesos等）有不同于虚拟机平台的一些特点，例如：

　　实例的规模很大，单个集群10k～100k个容器是很常见的

　　很高的发布频率，实例会频繁地创建和销毁

　　实例创建和销毁时间很短，比传统的虚拟机低至少一个数量级

　　容器的失败是很常见，总会因为各种各样的原因导致容器挂掉。容器编排引擎在设计的时候已经把失败当做预期情况处理，例如将挂掉的容器在本机或其他宿主机再拉起来，后者就是一次漂移

　　3.1私有云的K8S网络方案

　　容器平台的这些特点对网络提出了新的需求。

　　3.1.1网络需求

　　首先，网络服务的API必须要快，而且支持较大的并发。

　　第二，不管是agent还是可执行文件，为容器创建和删除网络（虚拟网络及相应配置）也要快。

　　最后是一个工程问题：新系统要想快速落地，就必须与很多线上系统保持前向兼容。这给我们网络提出一个需求就是：容器漂移时，IP要保持不变。因为OpenStack时代，虚拟机迁移IP是不变的，所以很多外围系统都认为IP是实例生命周期中的一个不变量，如果我们突然要改成IP可变，就会涉及大量的外围系统（例如SOA）改造，这其中很多不是我们所能控制的。因此为了实现容器的快速落地，就必须考虑这个需求。而流行的K8S网络方案都是无法支持这个功能的，因为在容器平台的设计哲学里，IP地址已经是一个被弱化的概念，用户更应该关心的是实例暴露的服务，而不是IP。

　　3.1.2解决方案：扩展现有SDN方案，接入Mesos/K8S

　　在私有云中，我们最终决定对现有的为虚拟机和应用物理机设计的SDN方案进行扩展，将容器网络也统一由Neutron/CNC管理。具体来说，会复用已有的网络基础设施，包括Neutron、CNC、OVS、Neutron-OVS-Agent等待，然后开发一个针对Neutron的CNI插件（对于K8S）。

　　一些核心改动或优化如下。

　　Neutron改动

　　首先是增加了一些新的API。比如，原来的neutron是按networkid分配IP，我们给network添加了label属性，相同label的network我们认为是无差别的。这样，CNI申请IP的时候，只需要说“我需要一个‘prod-env’网段的IP”，neutron就会从打了“prod-env”label的network中任选一个还没用完的，从中分一个IP。这样既将外部系统与OpenStack细节解耦，又提高了可扩展性，因为一个label可以对应任意多个network。

　　另外做了一些性能优化，例如增加批量分配IP接口、API异步化、数据库操作优化等待。

　　还有就是backport一些新feature到neutron，我们的OpenStack已经不随社区一起升级了，都是按需backport。例如，其中一个对运维和troubleshooting非常友好的功能是GracefulOVSagentrestart。

　　K8SCNIforNeutron插件

　　开发了一个CNIplugin对接neutron。CNI插件的功能比较常规：

　　为容器创建vethpairt，并attach到OVS

　　为容器配置MAC、IP、路由等信息

　　但有两个特殊之处：

　　向neutron（globalIPAM）申请分配和释放IP，而不是宿主机的本地服务分配（localIPAM）

　　将port信息更新到neutronserver

　　基础网络服务升级

　　另外进行了一些基础架构的升级，比如OVS在过去几年的使用过程中发现老版本的几个bug，后来发现这几个问题在社区也是有记录的：

　　vswitchdCPU100%[3]

　　流量镜像丢包[4]

　　注意到最新的LTS版本已经解决了这些问题，因此我们将OVS升级到了最新的LTS。

　　大家如果有遇到类似问题，可以参考[3,4]。

　　3.1.3容器漂移

　　创建一个容器后，容器网络配置的流程和图10类似，Nova和K8S只需做如下的组件对应：

　　nova->kubemaster

　　nova-compute->kubelet

　　novanetworkdriver->CNI

　　其流程不再详细介绍。这里重点介绍一下容器漂移时IP是如何保持不变的。

　　如图11所示，保持IP不变的关键是：CNI插件能够根据容器的labels推导出portname，然后拿name去neutron里获取port详细信息。portname是唯一的，这个是我们改过的，原生的OpenStack并不唯一。

　　第二个宿主机的CNIplugin会根据name找到port信息，配置完成后，会将新的host_id更新到netronserver；neutron通知到CNC，CNC去原来的交换机上删除配置，并向新的交换机下发配置。

　　Fig11.PoddriftingwiththesameIPwithinaK8Scluster

　　3.1.4小结

　　简单总结一下：

　　在保持基础设施不变的情况下，我们快速地将容器平台的网络接入到已有系统

　　一个IPAM同时管理了虚拟机、应用物理机和容器的网络

　　目前这套新方案的部署规模：

　　4个可用区

　　最大的可用区有超过500个节点（VM/BM/Container宿主机），其中主要是K8S节点

　　单个K8S节点最多会有500+pod（测试环境的超分比较高）

　　最大的可用区有2+万个实例，其中主要是容器实例

　　3.1.5进一步演进方向

　　以上就是到目前为止我们私有云上的网络方案演讲，下面这张图是我们希望将来能达到的一个架构。

　　Fig12.Layeredviewofthefuturenetworkarchitecture

　　首先会有underlay和overlay两个平面。underlay部署各种基础设施，包括Openstack控制器、计算节点、SDN控制器等，以及各种需要运行在underlay的物理设备；在overlay创建VPC，在VPC里部署虚拟机、应用物理机实例等。

　　在VPC内创建K8S集群，单个K8S集群只会属于一个VPC，所有跨K8S集群的访问都走服务接口，例如Ingress，现在我们还没有做到这一步，因为涉及到很多老环境的软件和硬件改造。

　　3.2公有云上的K8S

　　接下来看一下我们在公有云上的网络。

　　3.2.1需求

　　随着携程国际化战略的开展，我们需要具备在海外部署应用的能力。自建数据中心肯定是来不及的，因此我们选择在公有云上购买虚拟机或baremetal机器，并搭建和维护自己的K8S集群（非厂商托管方案，例如AWSEKS[10]）。

　　在外层，我们通过CDOSAPI封装不同厂商的差异，给应用部门提供统一的接口。这样，我们的私有云演进到了混合云的阶段。

　　网络方面主要涉及两方面工作：一是K8S的网络方案，这个可能会因厂商而已，因为不同厂商提供的网络模型和功能可能不同；二是打通私有云和公有云。

　　3.2.2AWS上的K8S网络方案

　　以AWS为例来看下我们在公有云上的K8S网络方案。

　　Fig13.K8Snetworksolutiononpubliccloudvendor(AWS)

　　首先，起EC2实例作为K8Snode，我们自己开发一个CNI插件，动态向EC2插拔ENI，并把ENI作为网卡给容器使用。这一部分借鉴了Lyft和Netflix在AWS上经验[5,6]。

　　在VPC内，有一个全局的IPAM，管理整个K8S集群的网络资源，角色和私有云中的neutron类似。它会调用AWSAPI实现网络资源的申请、释放和管理。

　　另外，我们的CNI还支持attach/detachfloatingIP到容器。还有就是和私有云一样，容器漂移的时候IP保持不变。

　　3.2.3全球VPC拓扑

　　图14是我们现在在全球的VPC分布示意图。

　　在上海和南通有我们的私有云VPC；在海外，例如首尔、莫斯科、法兰克福、加州（美西）、香港、墨尔本等地方有公有云上的VPC，这里画的不全，实际不止这几个region。

　　Fig14.VPCsdistributedovertheglobe

　　这些VPC使用的网段是经过规划的，目前不会跟内网网段重合。因此通过专线打通后，IP可以做到可路由。

　　4CloudNative方案探索

　　以上就是我们在私有云和混合云场景下的网络方案演进。目前的方案可以支持业务未来一段的发展，但也有一些新的挑战。

　　首先，中心式的IPAM逐渐成为性能瓶颈。做过OpenStack的同学应该很清楚，neutron不是为性能设计的，而是为发布频率很低、性能要求不高的虚拟机设计的。没有优化过的话，一次neutronAPI调用百毫秒级是很正常的，高负载的时候更慢。另外，中心式的IPAM也不符合容器网络的设计哲学。Cloudnative方案都倾向于localIPAM（去中心化），即每个node上有一个IPAM，自己管理本节点的网络资源分配，calico、flannel等流行的网络方案都是这样的。

　　第二，现在我们的IP在整张网络都是可漂移的，因此故障范围特别大。

　　第三，容器的高部署密度会给大二层网络的交换机表项带来压力，这里面有一些大二层设计本身以及硬件的限制。

　　另外，近年来安全受到越来越高度重视，我们有越来越强的3-7层主机防火墙需求。目前基于OVS的方案与主流的K8S方案差异很大，导致很多K8S原生功能用不了。

　　针对以上问题和需求，我们进行了一些新方案的调研，包括Calico，Cilium等等。Calico大家应该已经比较熟悉了，这里介绍下Cilium。

　　4.1CiliumOverview

　　Cilium[7]是近两年新出现的网络方案，它使用了很多内核新技术，因此对内核版本要求比较高，需要4.8以上支持。

　　Cilium的核心功能依赖BPF/eBPF，这是内核里的一个沙盒虚拟机。应用程序可以通过BPF动态的向内核注入程序来完成很多高级功能，例如系统调用跟踪、性能分析、网络拦截等等。Cilium基于BPF做网络的连通和安全，提供3-7层的安策略。

　　Cilium组件：

　　CLI

　　存储安全策略的repository，一般是etcd

　　与编排引擎集成的插件：提供了plugin与主流的编排系统（K8S、Mesos等）集成

　　Agent，运行在每台宿主机，其中集成了LocalIPAM功能

　　Fig15.Cilium

　　4.2宿主机内部网络通信（HostNetworking）

　　每个网络方案都需要解决两个主要问题：

　　宿主机内部的通信：实例之间，实例和宿主机通信

　　宿主机之间的通信：跨宿主机的实例之间的通信

　　先来看Cilium宿主机内部的网络通信。

　　Fig16.Ciliumhost-networking

　　Agent首先会创建一个cilium_host<--->cilium_net的vethpair，然后将它管理的

　　CIDR的第一个IP作为网关，配置在cilium_host上。对于每个容器，CNI插件会承担创建vethpair、配置IP、生成BPF规则等工作。

　　同宿主机内部的容器之间的连通性靠内核协议栈二层转发和BPF程序。比如inst1到isnt2，包首先从eth0经协议栈到达lxc11，中间再经过BPF规则到达lxc22，然后再经协议栈转发到达inst2的eth0。

　　以传统的网络观念来看，lxc11到lxc22这一跳非常怪，因为没有既没有OVS或Linuxbridge这样的二层转发设备，也没有iptables规则或者ARP表项，包就神奇的到达了另一个地方，并且MAC地址还被修改了。

　　类似地，容器和宿主机的通信走宿主机内部的三层路由和BPF转发，其中BPF程序连接容器的vethpair和它的网关设备，因为容器和宿主机是两个网段。

　　4.3跨宿主机网络通信（Multi-HostNetworking）

　　跨宿主机的通信和主流的方案一样，支持两种常见方式：

　　VxLAN隧道

　　BGP直接路由

　　如果使用VxLAN方式，Cilium会创建一个名为cilium_vxlan的device作为VTEP，负责封装和解封装。这种方案需要评估软件VxLAN的性能能否接受，以及是否需要offload到硬件加速。一般来说，软件VxLAN的方式性能较差，而且实例IP不可路由。

　　BGP方案性能更好，而且IP可路由，但需要底层网络支持。这种方案需要在每个node上起一个BGPagent来和外部网络交换路由，涉及BGPagent的选型、AS（自治系统）的设计等额外工作。如果是内网，一般就是BGPagent与硬件网络做peering；如果是在AWS之类的公有云上，还可以调用厂商提供的BGPAPI。

　　4.4优劣势比较（Pros&Cons）

　　最后总结一下Cilium方案的优劣势。

　　Pros

　　首先，原生支持K8SL4-L7安全策略，例如在yaml指定期望的安全效果，Cilium会自动

　　将其转化为BPF规则。

　　第二，高性能策略下发（控制平面）。Calico/iptables最大的问题之一就是集群规模大了之后，新策略生效非常慢。iptables是链式设计，复杂度是O(n)；而Cilium的复杂度是O(1)[11]，因此性能非常好。

　　第三，高性能数据平面(vethpair,IPVLAN)。

　　第四，原生支持双栈(IPv4/IPv6)。事实上Cilium最开始只支持IPv6，后面才添加了对

　　IPv4的支持，因为他们一开始就是作为下一代技术为超大规模集群设计的。

　　第五，支持运行在flannel之上：flannel负责网络连通性，Cilium负责安全策略。如果

　　你的集群现在是flannel模式，迁移到Cilium会比较方便。

　　最后，非常活跃的社区。Cilium背后是一家公司在支持，一部分核心开发者来自内核社区

　　，而且同时也是eBPF的开发者。

　　Cons

　　首先是内核版本要求比较高，至少4.8+，最好4.14+，相信很多公司的内核版本是没有

　　这么高的。

　　第二，方案比较新，还没有哪家比较有名或有说服力的大厂在较大规模的生产环境部署了这

　　种方案，因此不知道里面有没有大坑。

　　第三，如果要对代码有把控（稍大规模的公司应该都有这种要求），而不仅仅是做一个用户

　　，那对内核有一定的要求，例如要熟悉协议栈、包的收发路径、内核协议栈数据结构、

　　不错的C语言功底（BPF程序是C写的）等等，开发和运维成本比基于iptables的方案

　　（例如Calico）要高。

　　总体来说，Cilium/eBPF是近几年出现的最令人激动的项目之一，而且还在快速发展之中。

　　我推荐大家有机会都上手玩一玩，发现其中的乐趣。

　　References

　　OpenStackDoc:NetworkingConcepts

　　CiscoDataCenterSpine-and-LeafArchitecture:DesignOverview

　　ovs-vswitchd:Fixhighcpuutilizationwhenacquireidlelockfails

　　openvswitchportmirroringonlymirrorsegresstraffic

　　LyftCNIplugin

　　Netflix:runcontaineratscale

　　CiliumProject

　　CiliumCheatSheet

　　CiliumCodeWalkThrough:CNICreateNetwork

　　AmazonEKS-ManagedKubernetesService

　　Cilium:APIAwareNetworking&NetworkSecurityforMicroservicesusingBPF&XDP

　　说明：本文根据携程赵亚楠老师在GOPS2019·深圳站演讲整理而成。