利用听云Server和听云Network实测Kubernetes和Mesos在高并发下的网络性能

文章出自：听云博客

随着公司业务的不断增长，我们的应用数量也有了爆发式增长。伴随着应用爆发式的增长，管理的难度也随之加大。如何在业务爆发增长的同时快速完成扩容成了很大的挑战。Docker的横空出世恰巧解决了我们的问题。利用Docker我们可以快速完成扩容缩容，且配置统一，不易出错。

在Docker的集群管理选型上，我们比较纠结，目前比较流行的是Mesos和Kubernetes。从功能来说，我们更倾向于使用Kubernetes，他在容器编排方面的能力强于Meoso，且提供了持久化存储方案，更适合我们的场景。但是Kubernetes的网络模型要比Mesos复杂，在高并发的情况下性能能否满足需求成了关键问题。

Mesos本身不处理网络问题，利用Marathon我们可以选择Docker本身提供的Host模式和Bridge模式。Host模式与宿主机共享网络栈网络性能是最高的，Bridge模式有待评测。

Kubernetes采用扁平化的网络模型，要求每个Pod拥有一个全局唯一IP，Pod直接可以跨主机通信。目前比较成熟的方案是利用Flannel。Flannel有几种工作模式，分别是UDP、VXLAN、Host-gw和Aws-vpc。Aws-vpc有平台局限性我们不考虑，UDP性能较差不考虑。重点测试VXLAN和Host-gw。有相关评测测试过Host-gw性能好于VXLAN，但是Host-gw模式要求宿主机的网络满足二层直接交换。这在许多共有云平台是无法满足的。即使共有云平台某个机房内可以满足该网络要求，多机房互联时也无法满足该要求。如果VXLAN模式无法满足需求，多机房互联时就需要多个Kubernetes集群，增加了管理难度。

为了使结果更具真实性，我们选了线上一个并发较高的系统进行评测。机器配置均为16C 32G，应用本身不存在性能问题。由于Kubernetes要求网络互联，我们测试Kubernetes时选用两台机器。

综上，我们待测得环境如下：

待测机器	机器配置	机器数量
K8s flannel vxlan	16C 32G	2
K8s flannel host-gw	16C 32G	2
Mesos host模式	16C 32G	1
Mesos bridge模式	16C 32G	1
公有云虚机（对比）	16C 32G	1

听云Server可以监控代码级的响应时间，在负载均衡上加上一个头信息可以监测到负载均衡到后端RealServer的阻塞时间。利用这个特性，我们可以用来评测上述几种网络模型的阻塞时间，从而得出高并发情况下VXLAN模型能否满足我们的需求。

听云Network可以模拟请求到服务端，综合取得全国各地的网络访问时间，我们可以利用它来监测同时用这几种模型的时候是否对生产系统产生影响。

测试方法：我们由公有云提供的负载均衡分别往这7台机器上打相同的流量。通过听云Server来监控这几种模型的阻塞时间来对比他们的性能差异。同时观察听云Network的可用性和访问性能，从客户端的角度看是否因为某个模型网络性能差导致用户体验变差。如下图所示：