阿里云弹性网络接口技术的容器网络基础教程

基于容器的虚拟化是一种虚拟化技术。与虚拟机（VM）相比，容器更轻量级，部署更方便。Docker是目前主流的容器引擎，支持Linux、Windows等平台，以及Kubernetes（K8S）、Swarm、Rocket（RKT）等主流Docker编排系统。常见的容器网络支持多种模型，如桥接网络、Overlay网络、Host网络和用户自定义网络。K8S 等系统依靠容器网络接口（CNI）插件进行网络管理。常用的 CNI 插件包括 Calico 和 Flannel。

本文九河云将介绍容器网络的基础知识。ECS容器网络基于阿里云弹性网卡（Elastic Network Interface，简易）技术，具有高性能、易部署易维护、隔离性强、安全性高等特点。

传统集装箱网络解决方案

本节介绍传统容器网络的工作原理。

CNI 是由云原生计算基金会（CNCF）管理的开源项目。它为各大厂商制定标准并提供源码库，以开发用于 Linux 容器网络管理的插件。著名的 CNI 插件包括 Calico 和 Flannel。Calico 通过 Flex/Bird 实现 BGP 等协议，并将其存储到分布式内存数据库中，以建立大型的 Layer 3 网络，使不同主机上的容器无需发送 ARP 即可与不同子网上的容器进行通信。

Flannel 实现了基于 VXLAN 等隧道技术的容器覆盖网络。Calico/Flannel 等 CNI 使用 VETH 对来配置容器网络。将创建一对 VETH 设备，其中一端绑定到容器，另一端绑定到 VM。虚拟机通过网络协议栈（覆盖网络）、Iptables（Calico 插件）或 Linux Bridge 等技术转发容器网络。（当容器网络在ECS中通过网桥连接到交换机时，VPC只能到达ECS级别，容器网络是网桥上的内网。

下图显示了目前主流容器网络的工作流程，它与多网卡容器网络的不同之处体现在以下几个方面：

主机 1 上的容器发送的消息通过 VETH 传输到虚拟机上的 Linux 网桥，Linux 网桥运行转发逻辑，将消息虚拟机上的网卡发送到主机上的交换机。
主机 2 上的虚拟机接收 vSwitch 发送的消息，并使用 Linux Bridge 的转发逻辑通过 VETH 将其发送到容器。

在整个网络系统中，虚拟机内部需要 K8S 等编排系统的 CNI 插件进行网络配置。交换机支持 Openflow 和 Netconf 等通信协议，这些协议通过软件定义网络（SDN）控制器进行管理和配置。主流ToR交换机使用Netconf协议进行远程配置。支持Openflow的SDN物理交换机也已上市。

为了管理整个网络，需要两个不同的网络控制系统。配置相对复杂，由于实现机制等因素，存在一定的性能瓶颈。主机上的安全策略不能应用于容器应用程序。

多网卡容器网络

当 VM 具有多个动态热插拔的网络接口卡（NIC）时，可以在容器网络上使用这些 NIC，因此容器网络将不再需要使用 Linux VETH 和 Bridge 等技术。同时，将消息转发到主机上的虚拟交换机（vSwitch），通过简化流程提高网络性能。

解决方案概述

如下图所示，主机上正在运行一个交换机，用于转发来自虚拟机和容器的流量。多个虚拟网卡连接到交换机。在虚拟机上启动容器时，虚拟网卡会动态绑定到主机上容器所在的虚拟机，然后虚拟机内部的网卡绑定到容器所在的网络命名空间，容器中的网络流量可以通过网卡直接发送到主机上的交换机（即容器网络可以直接连接到交换机）。

在交换机中应用ACL、QoS、Session等规则进行流量转发。当主机 1 上的 VM 上运行的容器访问主机 2 上的 VM 上运行的容器时，流量通常会经过以下过程：

网络消息通过容器核心网络协议栈。查询路由后，消息通过eth0网卡发送。
主机上的交换机通过虚拟端口接收来自容器的消息，并运行交换机的转发逻辑，通过物理网口将报文发送到架顶式交换机。如果为容器或虚拟机网络建立了 Virtual Private Cloud （VPC），则需要使用 VXLAN 等隧道技术对消息进行封装。
ToR 交换机通过连接到主机 2 的物理端口查询路由并转发消息。
主机2上的交换机接收到物理端口消息，通过转发逻辑发送到连接容器的虚拟端口。
容器中的协议栈 eth0 接收另一端发送的消息，然后由容器中的网络协议栈处理该消息。

方案特点

相较于传统容器在虚拟机上运行的方案，该方案具有高性能、易管理、隔离性强等特点。

直连VPC

多网卡方案允许容器直接访问VPC网络面，使每个容器都能提供完整的VPC网络功能，包括EIP、SLB、DDoS高防、安全组、HAVIP、NAT和用户路由。

跨VPC

通过多网卡方案直接访问VPC网络面的容器，可以使用VPC的一些高级功能，如对等功能。跨VPC弹性网卡也可用于访问云产品，不同VPC内的多个网卡可以分配给容器。这确保了容器可以跨多个 VPC 使用。

高性能

在多网卡解决方案中，容器中的网络流量不需要通过虚拟机上的 Iptables/Bridge 转发，而是直接转到主机上的交换机。这样就省去了虚拟机上的数据消息转发逻辑，简化了数据复制过程，大大提升了容器网络的性能。下表列出了不同解决方案在单次测试中的基本性能数据。

	单线程（Mbps）	单线程（pps）	多线程（pps）	TBase测试 1 KB （QPS）
Linux 桥接器	32.867	295,980	2,341,669	363,300
多网卡解决方案	51.389	469,865	3,851,922	470,900
性能改进	56.35%	58.7%	64.49%	29.6%

强隔离

在传统的桥接方案中，所有容器实例都位于同一个大型二层网络上，导致广播、组播和未知单播泛滥。多网卡方案提供的直连功能，以及ECS网络提供的ACL和安全组功能，可以有效保障安全隔离。即使在容器的管理面上也无法查看容器网络流量。安全规则应用于容器级别，而不是 VM 级别。

易于管理

当管理系统将容器分派到虚拟机时，控制系统会在虚拟机所在主机的交换机上创建一个网卡，通过热插拔将网卡插入虚拟机，并将网卡配置到虚拟机上的容器网络命名空间中。通过配置交换机的流量转发规则，然后在xGW上配置HaVIP，外部应用和客户端可以访问容器提供的服务。

多网卡解决方案还有助于容器迁移。以另一台迁移到同一台主机的虚拟机为例，K8S 的 Kubelet 模块迁移应用，然后通过 CNI 插件重新配置网络，管理容器 IP 和 VIP，并配置访问容器应用的方式。整个过程很复杂，但 NIC 解决方案可以使它变得简单。将容器分派到 VM 后，绑定到旧容器的 NIC 将从旧 VM 中拔出，并插入到新容器所在的 VM 中。然后，将 NIC 绑定到 VM 上的容器网络命名空间。新容器可以正常通信，无需再重新配置网络。

DPDK 支持

由于其优越的性能优势，DPDK已经普及，越来越多的应用是基于DPDK开发的。传统的容器网络使用VETH作为网络设备，目前无法直接使用DPDK的PDK驱动，因此基于DPDK的应用不能直接在容器中使用。在多网卡方案中，容器使用ECS网络设备，即常见的E1000或virtio_net设备。两台设备都有一个 PMD 驱动程序，容器可以使用该设备直接运行基于 DPDK 的应用程序，从而提高容器内应用程序的网络性能。

VM 多 NIC

要启用物理主机的跨域，您需要在物理机中插入多个网卡。由于 PCI 插槽和成本的限制，在一台物理机上部署两个以上的 NIC 的情况很少见。打开或关闭硬件设备的电源或多或少会给整个系统增加脉冲，从而影响机器的稳定性，并限制设备的热插拔。常见的热插拔设备是 USB 设备。PCI 设备的热插拔直到最近几年才获得限制性支持，因为需要两个枚举和电源效应。

在虚拟环境中，虚拟网卡的低成本和灵活性大大提高了虚拟机的可用性。用户可以根据需要动态分配或释放网卡，在不影响虚拟机正常运行的情况下，动态地将网卡插入或拔出虚拟机。libvirt/qemu 模拟虚拟设备的方式具有物理主机无法比拟的以下优势：

资源限制

只要系统有足够的内存等资源，就可以模拟多个网卡，并将它们分配给同一个虚拟机，一个虚拟机上可以安装64个甚至128个网卡。与物理硬件环境相比，软件模拟 NIC 的成本要低得多。它们还具有更好的支持多队列和主流硬件的一些卸载功能，提高了系统的灵活性。

动态热插拔

VM 上的 NIC 由软件模拟。因此，当需要网卡时，软件会分配一些基础资源来模拟网卡。热插拔框架使 libvirt/qemu 能够轻松绑定到正在运行的 VM 上，并且 VM 可以立即使用 NIC 发送网络消息。当不再需要 NIC 时，可以通过 libvirt/qemu 接口调用将其“拔出”，而无需停止 VM。分配给 NIC 的资源被销毁，分配给 NIC 的内存被回收，中断被恢复。

容器网络实施

本节介绍如何使用虚拟机多网卡逐步实现容器网络通信。

在阿里云控制台创建云主机，创建实例时选择多个网卡。然后，VM 上会显示多个 NIC。
在 VM 上部署容器应用程序。
```
～# docker run -itd --net none ubuntu:16.04
```
注意：启动 Docker 时，将容器的网络类型指定为 none
登录到 VM，并将其中一个 NIC 绑定到容器命名空间。在以下示例中，新动态插入的 NIC 是 eth2，容器的网络命名空间是 2017（为澄清起见，docker inspect 看到的 PID 用作网络命名空间）。
```
~# mkdir /var/run/netns
~# ln -sf /proc/2017/ns/net /var/run/netns/2017
~# ip link set dev eth2 netns 2017
~# ip netns exec 2017 ip link set eth2 name eth0
~# ip netns exec 2017 ip link set eth0 up
~# ip netns exec 2017 dhclient eth0
```
注意：根据发布版本，用户可能不需要通过手动创建连接来“创建”容器的网络命名空间。将 eth2 绑定到容器的网络命名空间后，将其重命名为 eth0。
查看 VM 和容器中的 NIC 配置状态。
检查 VM 上是否仍存在 NIC。
```
～# ifconfig -a
```
检查容器中是否有新配置的网卡。
```
/# ifcofig -a
```
可以看出，eth2 已从虚拟机中移除并应用到容器中。
重复步骤 1 到 4 以启动另一个 VM 和容器。

使用 sockperf 等工具进行性能测试和比较。

$ cat server.sh

#!/bin/bash
for i in $(seq 1 $1)
do
    sockperf server --port 123`printf "%02d" $i` &
Done

$ sh server.sh 10
$ cat client.sh

#!/bin/bash
for i in $(seq 1 $1)
do
    sockperf tp -i 192.168.2.35 --pps max --port 123`printf "%02d" $i` -t 300 &
done

$ sh client 10

蚂蚁金服使用案例

Tier-Base （TBase）是一个类似于 Redis 的分布式 KV 数据库。它是用 C++ 编写的，支持几乎所有的 Redis 数据结构。它还支持 RocksDB 作为后端。TBase在蚂蚁金服中应用广泛。本节将介绍该方案的 TBase 业务测试。

传统 Linux 桥接测试

测试环境

服务器：16C60G x 1（半个A8）

客户端：4C8G x 8

TBase 服务器部署：7G x 7 实例

TBase 客户端部署：8 x（16 个线程 + 1 个客户端）=> 128 个线程 + 8 个客户端

检测报告

操作	数据包大小	客户	网卡	负载1	中央处理器	PP2型	平均 rt	第 99 RT
设置	1 KB	8	424兆字节	7.15	44%	363,300	0.39 毫秒	< 1 ms
获取	1 KB	8	421兆字节	7.06	45%	357,000	0.39 毫秒	< 1 ms
设置	64 KB	1	1,884兆字节	2.3	17%	29,000	0.55 毫秒	< 5 ms
设置	128 KB	1	2,252兆字节	2.53	18%	18,200	0.87 毫秒	< 6 ms
设置	256 KB	1	2,804兆字节	2.36	20%	11,100	1.43 毫秒	< 5 ms
设置	512 KB	1	3,104兆字节	2.61	20%	6,000	2.62 毫秒	< 10 ms

弹性网卡多网卡测试

测试环境

服务器：16C60G x 1（半个A8）

客户端：4C8G x 8

TBase 服务器部署：7G x 7 实例

TBase 客户端部署：16 x（16 个线程 + 1 个客户端）=> 256 个线程 + 16 个客户端

检测报告

操作	数据包大小	客户	网卡	负载1	中央处理器	PP2型	平均 rt	第 99 RT
设置/获取	1 KB	16	570兆字节	6.97	45%	470,900	0.30 毫秒	< 1 ms

测试结论

基于弹性网卡多网卡方案，整体性能提升，时延明显缩短（QPS提升30%，平均时延降低23%）。假设使用16C60G服务器，QPS在470左右。在本例中，平均 rt 为 900.0 ms，第 30 个 rt 小于 99 ms。用户、sys、si 和 st 分别消耗了 1%、45%、29% 和 18% 的 CPU。与 Linux Bridge 相比，多 NC 解决方案的 CPU 消耗显著降低。通过内核队列分散，将 st 的 CPU 消耗分布在多个不同的内核上，使处理资源使用更加均衡。

对于VPC路由表Flannel/Canal的解决方案，在带宽和吞吐量上没有实质性的损失。相对于主机，延迟约为 0.1 毫秒。使用Nginx测试QPS，页面较小时损失在10%左右。对于弹性网卡方案，相对于主机，带宽和吞吐量没有实质性的损失，延迟略低于主机。在应用测试中，性能比主机网络上的性能高出 10% 左右，因为 POD 没有受到 iptables 的约束。对于默认的 Flannel VXLAN，带宽和吞吐损失约为 5%，而在 Nginx 小页面测试的最大 QPS 下，相对于主机，性能损失约为 30%。