本次分享由阿里云高级技术专家姜文锋(令吾)为大家介绍三种基于阿里云弹性计算网络能力提升容器密度的主要方法和最佳实践。

关键词：弹性网卡、弹性网卡多IP、 弹性网卡中继、容器密度

演讲嘉宾简介：姜文锋(令吾)，阿里云高级技术专家。来自阿里云弹性计算控制&体验团队，主要负责弹性计算（ECS）网络、安全组相关组件和产品的研发工作。

以下内容根据演讲视频以及PPT整理而成。>>>观看回放
更多课程请进入“玩转ECS详情页”了解

本次分享主要围绕以下四个方面：

一、弹性网卡直通
二、弹性网卡多IP
三、弹性网卡中继
四、创建容器网络方案总结

云原生和容器化是主流的趋势，实现容器化时推荐大家使用云厂商的容器服务，如阿里云ACK。但由于部分用户因为一些原因需要自建容器，此时不得不面临一个问题，就是如何能够在一台宿主机上提升容器数量，降低容器成本。

借此机会，本次分享由阿里云高级技术专家姜文锋(令吾)为大家介绍基于阿里云弹性计算网络能力，具体讲解三种构建容器的网络架构方案，同时横向对比各种方案在提升容器密度方面的优缺点。下面主要介绍三种构建容器的网络架构方案，分别是弹性网卡直通方案、弹性网卡多IP方案、弹性网卡中继方案。

一、弹性网卡直通

所谓弹性网卡直通就是将一个ECS上的弹性网卡直接加入到容器命名空间内。这种架构非常简单，无技术风险，同时缺点也非常明显：ECS容器数量受限于ECS可挂载弹性网卡数量。而目前阿里云最高规格实例大约支持20块网卡左右，对容器密度敏感的用户，这不是合适的选项。

二、弹性网卡多IP构建容器

1、弹性网卡+网卡多IP+策略路由

网卡多IP是阿里云为了提升IP数量而提供的方案，可以让一个弹性网卡支持多个IP，这样就具备了在ECS上创建更多容器的基础。下图展示了结合弹性网卡+网卡多IP+策略路由构建容器的架构。与弹性网卡直通对比下，引入的复杂度是路由设置问题。

由于弹性网卡直通方案中容器与网卡的比例为1：1，路由极其简单，无需管理。而引入了网卡多IP之后，容器与网卡的比例关系是n：1，需要正确的管理路由，实现入方向和出方向上容器与网卡正确的对应。

具体做法：首先使用veth pair打通容器与ECS网络命名空间，使得容器IP与ECS弹性网卡IP可见；之后进行策略路由的设置，实现容器与弹性网卡的正确对应。如下图所示，入方向策略路由表表明当访问192.168.10.1-3时需要查找main路由表进行包转发，main路由表把不同的ip指向不同的veth pair设备，这样就可以路由到正确的容器内。出方向上如果源地址是192.16.10.1-3的话，则需要去1006路由表。路由表1006表示要将所有包路由到eni1上，从而找到正确的网卡。

整个方案的优点是可以有效提高单ECS容器密度，创建可观的容器数量。目前单网卡最大支持20个ip，单ECS最大支持15个弹性网卡。

但弹性网卡多IP缺点主要有三点：首先，安全组是实现云安全的基本能力，而安全组只支持eni粒度，无法针对容器粒度配置安全组，这意味着下图中关联到同一个网卡的三个容器的安全配置完全相同，无法对每一个单独的容器做安全配置。另外，相对而言架构更加复杂。最后由于引入了veth-pair，转发性能会比弹性网卡直通方案稍差。

2、弹性网卡+网卡多IP+IPvlan

基于弹性网卡多IP的方案还有更加简单的做法：IPvlan。

IPvlan是linux内核提供的网卡虚拟化技术，能够从物理网卡虚拟出多个虚拟网卡。多个虚拟网卡有相同mac地址，但是有独立的IP。

使用IPvlan之后，从容器往下看，ECS便有了更多的网卡，如下图中ECS有三个弹性网卡，每个网卡3个IP，每个IP对应一个IPvlan设备。将IPvlan设备直接放到容器的命名空间内，打通整个链路。

相对于弹性网卡+网卡多IP+策略路由方案，IPvlan方案架构更加简单，性能更好，同时可以起到提升容器密度的效果。但缺点同样有三点：首先对linux kernal版本有要求，只有大于等于4.2版本才建议使用IPvlan。其次如果自建k8s，需要解决kube-proxy依赖流量走host namespace，而IPvlan默认无法和host namespace交互。还有依然无法支持容器粒度设置安全组。

三、弹性网卡中继构建容器

如果即要提升容器密度，又要求安全组支持容器粒度，那么阿里云推荐弹性网卡中继（EniTrunking）构建容器的方案。EniTrunking是阿里云提供的一种提升单ECS挂载弹性网卡数量的技术。

下面介绍EniTrunking中的几个主要概念：

1) 首先是TrunkEni（如下面图中的te_1，te_2），它是正常的弹性网卡，方案中充当通信通道的角色。
2) 另外就是MemberEni（如下图中的me_i），是与TrunkEni连接的弹性网卡，流量通过MemberEni“中继”到对应的TrunkEni，拥有弹性网卡的绝大部分特性，但是不支持弹性网卡多IP。
3) 最后是DeviceIndex，一个TrunkEni对应多个MemberEni，DeviceIndex是给MemberEni分配一个Index，表示TrunkEni中的位置，在此范围内保持唯一。

基于EniTrunking的方案主要操作步骤如下：

1) 首先申请开通EniTrunking功能白名单。
2) 然后通过ECS API创建几个TrunkEni并挂载。
3) ECS API创建MemberEni（具体数量参考官方文档），再将MemberEni中继到TrunkEni上。
4) 把MemberEni加入到容器网络namespace中，并配置路由，从而实现整个链路的打通。

MemberEni包含大部分的弹性网卡特性，这就使得弹性网卡中继构建容器方案可以有效提高单ECS容器密度以及容器数量，并可以为每个MemberEni设置独立的安全组，安全控制更灵活。对于某些安全网络产品使用弹性网卡中继构建容器方案是非常适合的。但同时由于中间多了一个环节，所以弹性网卡中继构建容器方案转发性能会比网卡直通方案差。

目前弹性网卡中继构建容器方案在灰度阶段，后续会提供相关设置的最佳实践和帮助文档，有兴趣的同学可以关注一下。

四、创建容器网络方案总结

前面具体介绍了4种创建容器网络方案，下面简单做一个总结：

1) 弹性网卡直通方案的优点是非常简单，支持容器粒度安全组。但受限于ECS可挂载弹性网卡数量，导致容器成本较高。弹性网卡直通方案对企业自建或容器密度不是关键考虑因素的用户比较适用。
2) 弹性网卡多IP+策略路由方案可以有效提升容器密度，方案较为成熟，无技术风险。但它不支持容器粒度的安全组，而且由于引入了策略路由和veth-pair设备导致转发性能稍差。
3) 弹性网卡多IP+IPvlan方案与弹性网卡多IP+策略路由方案类似，但架构会更加简单，因为使用了linux原生的网卡技术。同样，弹性网卡多IP+IPvlan方案也不支持容器粒度安全组，对linux内核版本有一定的要求，用户需要自己解决IPvlan默认不走host namespace的问题。企业自建容器或容器服务的用户可以考虑这两种方案。
4) 弹性网卡中继方案，最大优点是即可以提升容器密度，还支持容器级别安全组。只是转发性能会比弹性直通方案略差。

关注百晓生，笑谈云计算