一个适合 Kubernetes 的最佳网络互联方案


【编者的话】本文比较了几种 Kubernetes 联网方案,包括 Flannel(aws-vpc | host-gw | vxlan)和 IPvlan 。目前建议选择 flannel + host-gw 方案,没有特别依赖,性能也够用。一旦 flannel 支持 IPvlan (有自动化设置工具了),且 Linux 内核版本比较新,就可以采用 IPvlan 方案。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川等公司的技术负责人将带来实践经验分享,3月21日之前购票只需238元,欢迎感兴趣的同学抢购。

Kubernetes 要求集群包含的每一个容器都拥有一个独立、可路由的 IP 地址。IP 地址的分配是由第三方联网解决方案负责, Kubernetes 自己不管。

本研究的目标是找出一个适合 Kubernetes 的最佳联网方案:延迟最低、吞吐最高、设置最容易。我们选择延迟敏感的网络负载,试图衡量在网络负载相对较高时请求占比与延迟的对应关系。我们尤其关注网络负载是最大负载的 30-50% 时联网方案的性能表现,因为我们觉得这是一个尚未超出最大负载系统的最常见负载范围。

联网方案

Docker --net=host

这项测试的结果是一个标杆,代表可能达到的最佳性能,其他方案的测试结果将分别与之比较,评判优劣。

--net=host 是指容器继承宿主机的 IP 地址,不包含任何网络隔离。

与其他实现网络隔离的联网模式相比,Docker --net=host 模式的性能更好,所以我们选择这种模式作为标杆。

Flannel

Flannel 是由 CoreOS 维护的一个虚拟网络方案。这个方案经过精心测试,完全可用于生产环境,它也是最容易设置的。

使用Flannel ,添加一台新机器到集群时,Flannel 做了三件事:
  1. 使用 etcd 为新增机器分配一个子网
  2. 在宿主机上创建一个虚拟桥接接口(名为 docker0 的桥接器)

  3. 设置一个网络转发后端

    • aws-vpc:在 Amazon AWS 实例表中注册新增机器子网。该实例表最多支持 50 项记录,这意味着,如果你使用 flannel + aws-vpc 方案,集群最多只能包含 50 台机器,集群也只能运行在 AWS 云平台。

    • host-gw:通过远程机器 IP ,创建到子网的 IP 路由。这要求运行 flannel 的不同主机在二层直接互通。

    • vxlan:创建一个虚拟的 VXLAN 接口


由于 flannel 使用桥接接口转发网络包,从一个容器发往另一个容器的网络包将历经两个网络栈。

IPVlan

IPvlan是 Linux 内核中的一个驱动,有了它,无需使用桥接接口,就可以创建拥有唯一 IP 地址的虚拟网络接口。

使用 IPvlan 为容器分配一个 IP 地址,需要下列步骤:
  1. 创建一个不包含任何网络接口的容器;
  2. 在默认的网络命名空间中创建一个 ipvlan 接口;
  3. 把新建的 ipvlan 接口转移到容器的网络命名空间。


IPvlan 是一个相对较新的解决方案,现在还没有能完成上述过程的自动化工具。如果集群的机器和容器比较多,部署 IPvlan 的难度不小,不容易设置。

不过, IPvlan 不需要使用桥接接口,网络包从网卡直接转发到虚拟网络接口,我们预期它的性能应该好于Flannel 。

负载测试场景

对每一种方案,执行下列步骤:
  1. 在两台物理机器上设置联网
  2. 在一台物理机的一个容器中运行 tcpkali ,以恒定速度发送请求;
  3. 在另一台物理机的一个容器中运行 Nginx ,收到请求后,返回一个固定大小的文件给请求方;
  4. 记录系统度量和 tcpkali 结果。


测试的两个参数分别是每秒发送的请求数(requests per second, RPS)和静态文件的大小。前者的取值从 50,000 到 450,000 不等,后者主要分为 350B(100 字节的文件内容和 250 字节的文件头) 和 4KB 两类文件。

测试结果

  1. IPvlan 的延迟最低、吞吐量最高, Flannel + host-gwflannel + aws-vpc 方案的性能紧随其后,不过,在负载达到最大值时, 前者的测试结果更好;
  2. 就跟预计的一样,在所有测试中, Flannel + vxlan 方案的测试结果都是最差的。不过,有一个例外,我们怀疑这种方案在 99.999% 这一项的糟糕结果是由软件缺陷造成的;
  3. 返回的文件的大小是 4KB 还是 350B ,测试结果都差不多。有两点不同需要注意:

    • 4KB 时,支持的最大负载(RPS)相对低得多,因为一个 10Gbps 网卡,只需 25kRPS 就达到最大负载了(250k * 4k = 10G);
    • IPvlan 的吞吐量与 --net=host 的吞吐量非常接近,即接近达到吞吐上限。


我们选择 flannel + host-gw 联网方案,因为它没有特别的依赖(例如, aws-vpc 只能运行在 AWS 平台, ipvlan 要求内核版本比较新),与 IPvlan 相比,更容易设置,性能也够用。 IPvlan 是我们的备选方案,一旦 flannel 支持 IPvlan ,我们就会切换到 IPvlan 方案。

虽然 aws-vpc 方案的性能略优于 host-gw ,但是用这种方案设置的集群最多只能包含 50 机器,也只能运行在 AWS 平台上,这是我们无法接受的。

50kRPS,350B

latency-50000rps.png

当每秒发送 50,000 个请求,返回的静态文件大小为 350B 时,所有方案的性能表现都还可以。从中也能看出主要趋势: IPvlan 表现最好, aws-vpchost-gw 紧随其后,而 vxlan 的表现最差。

150kRPS,350B

latency-150000rps.png

150kRPS (约为最大 RPS 的 30% )时请求占比与延迟的对应关系,单位是 ms (毫秒)。
5.png

IPvlan 比 aws-vpchost-gw 表现稍好,不过在请求占比 99.99% 这一项中,它的表现最差。总体上, host-gw 的表现略好于 aws-vpc


译者注:以 IPvlan 为例, 99.99% 对应的延迟取值是 6.7ms 。这意味着每秒有 150,000 * 99.99% 个请求的延迟不高于 6.7ms 。

250kRPS,350B

latency-250000rps.png

这是生产环境中常见的负载,所以这个测试结果特别重要。

250kRPS (约为最大 RPS 的 50% )时请求占比与延迟的对应关系,单位是 ms (毫秒)。
2.png

IPvlan 的表现最佳,但是 aws-vpc 在 99.99% 和 99.999% 两项的表现最好。而 host-gw 在 95% 和 99% 这两项的表现好过 aws-vpc

350kRPS,350B

latency-350000rps-no-vxlan.png

与上面 250krps, 350B 的测试结果差不多,但是在 99.5% 以后,延迟迅速增加,这意味着网络负载已经接近最大值。

450kRPS,350B

这是能产生有意义结果的最大 RPS 取值。

IPvlan 仍然表现最佳,与 --net=host 相比,延迟增加了大约 30% 。
latency-450000rps.png

latency-ipvlan-450000rps.png

有意思的是, host-gw 的表现远超 aws-vpc
latency-450000rps.png

500kRPS,350B

当每秒请求数达到 500,000 个时,只有 IPvlan 方案还能正常工作,甚至比 --net=host 还好!不过,此时的延迟非常高,完全不适合延迟敏感型应用。
latency-500000rps-no-host-gw.png

50kRPS,4KB

latency-150000rps1.png

返回的文件更大,因此占用的网络带宽也更高。这项测试的结果与 50krps, 350B 的测试结果差不多。

50kRPS (约为最大 RPS 的 20% )时请求占比与延迟的对应关系,单位是 ms (毫秒)。
3.png

150kRPS,4KB

latency-150000rps1.png

host-gw 在 99.999% 这一项的表现出人意料地差,低于此比例的表现还是不错的。

150kRPS (约为最大 RPS 的 60% )时请求占比与延迟的对应关系,单位是 ms (毫秒)。
4.png

250kRPS,4KB

latency-250000rps-no-vxlan.png

这是响应文件大小为 4KB 时允许的最大 RPS 。 aws-vpc 表现远远好于 host-gw ,跟响应文件大小为 350B 时的测试结果非常不同。

vxlan 又一次被排除在外(译注:延迟太高了),上图中根本就没画。

测试环境

背景

要想理解这篇文章,重现测试环境,你必须熟悉有关高性能的基础知识。

下列文章非常有用:


机器

  • 两个 Amazon AWS EC2 的 c4.8xlarge 实例,操作系统是 CentOS 7 。
  • 两台机器都开启了增强联网
  • 每台机器包含 2 个处理器( NUMA 架构),每个处理器有 9 核,每核 2 个超线程。也就是说,每台机器能有效地运行 36 个线程。
  • 每台机器有一块 10Gbps 网卡, 60GB 内存。
  • 为了支持增强联网和 IPvlan ,我们安装了 Linux 内核 4.3.0 和 Intel 的 ixdbevf 驱动。


设置

现代网卡都提供了经由多中断线的RSS(Receive Side Scaling, 接收端扩展)功能。 EC2 的虚拟环境只提供两个中断线,我们测试了几种 RSS 和 RPS(Receive Packet Steering,接收包控制)配置,最后选择下列配置,其中有一部分参考了 Linux 内核文档的建议:


译者注: RSS 和 RPS 的作用都是把网络包直接交给特定的 CPU 核处理,前者需要网卡硬件支持,后者是纯软件实现。
IRQ

每台机器有两个 NUMA 节点(处理器)。设置每个 NUMA 节点的第一个 CPU 核专门处理网卡中断。

首先调用 lscpu ,列出处理器与 NUMA 节点的对应关系:
$ lscpu | grep NUMA
NUMA node(s):          2
NUMA node0 CPU(s):     0-8,18-26
NUMA node1 CPU(s):     9-17,27-35

由此可见,要设定第 0 号和第 9 号 CPU 核处理网卡中断,即把 0 和 9 写入 /proc/irq/<num>/smp_affinity_list ,其中 <num> 是中断号,可以通过调用 grep eth0 /proc/interrupts 获得,例如:
$ echo 0 > /proc/irq/265/smp_affinity_list
$ echo 9 > /proc/irq/266/smp_affinity_list


RPS

我们测试了几种 RPS 组合。为了降低延迟,我们只用 CPU 核 1-8 和 10-17 处理中断。不像 IRQ 有可以直接设置的 smp_affinity_list 属性,得用位掩码设定 由哪些 CPU 核处理网络包(参见脚注 1 ):
$ echo "00000000,0003fdfe" > /sys/class/net/eth0/queues/rx-0/rps_cpus
$ echo "00000000,0003fdfe" > /sys/class/net/eth0/queues/rx-1/rps_cpus


XPS(Transmit Packet Steering, 传送包控制)

第一个处理器的 CPU 核(包括超线程,即 0-8, 18-26 )专门处理传输队列 tx0 ,第二个处理器的 CPU 核(9-17, 27-35)专门处理传输队列 tx1 (参见脚注 2 ):
$ echo "00000000,07fc01ff" > /sys/class/net/eth0/queues/tx-0/xps_cpus
$ echo "0000000f,f803fe00" > /sys/class/net/eth0/queues/tx-1/xps_cpus


RFS(Receive Flow Steering,接收流控制)

我们计划使用 60k 永久连接,官方建议把 RFS 设为与之最接近的 2 的次幂:
$ echo 65536 > /proc/sys/net/core/rps_sock_flow_entries
$ echo 32768 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt
$ echo 32768 > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt


Nginx

Ngnix 使用 18 个工作进程,每个进程对应一个专门的 CPU 核(0-17),这是通过 worker_cpu_affinity 选项设定的:
workers 18;
worker_cpu_affinity 1 10 100 1000 10000 ...;


Tcpkali

Tcpkali 本身不支持与特定的 CPU 核绑定。我们用 taskset 执行 tcpkali ,设置调度器,使得线程很少会被从一个 CPU 核调整到另外一个 CPU 核执行:
$ echo 10000000 > /proc/sys/kernel/sched_migration_cost_ns
$ taskset -ac 0-17 tcpkali --threads 18 ...

上面的设置使得中断负载更均匀地分布在 CPU 核上。在同等延迟下,与其他设置相比,这种设置的吞吐量更高。

第 0 号和第 9 号CPU 核只处理网卡中断,不收发网络包。但是它们仍然是最忙碌的 CPU 核:

还使用Red Hat的tuned ,开启网络延迟画像。

为了把 nf_conntrack 的影响降到最小,添加了 NOTRACK 规则

为了支持更多的 tcp 连接,用 sysctl 调整下列参数:
fs.file-max = 1024000
net.ipv4.ip_local_port_range = "2000 65535"
net.ipv4.tcp_max_tw_buckets = 2000000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_low_latency = 1


脚注
  1. Linux 内核文档: RPS 配置
  2. Linux 内核文档: XPS 配置


原文链接: Comparison of Networking Solutions for Kubernetes (翻译:柳泉波)

4 个评论

怎么没有Flannel+UDP的测试呢?是因为性能太差了吗?
host-gw的数据平面及时Linux内核的IP协议栈啊,没有额外开销,docker的--net=host是用的主机的端口。这两个差别为什么这么大
最佳服装适合年轻女士,妇女及女孩
我们有一些您在您的预算更多...
PLZ访问: - <a href= "http://www.dooiitt.com/">设计师Salwar套装</A>
最佳服装适合年轻女士,妇女及女孩
我们有一些您在您的预算更多...
请访问: - <a href= "http://www.dooiitt.com/">设计师Salwar套装</A>

要回复文章请先登录注册