实测Kubernetes和Mesos在高并发下的网络性能
原文出自【听云技术博客】：http://blog.tingyun.com/web/article/detail/406
随着公司业务的不断增长，我们的应用数量也有了爆发式增长。伴随着应用爆发式的增长，管理的难度也随之加大。如何在业务爆发增长的同时快速完成扩容成了很大的挑战。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的可用性和访问性能，从客户端的角度看是否因为某个模型网络性能差导致用户体验变差。如下图所示：
我们在负载均衡后加入这些机器
其中第一个8080为公有云虚机，30099端口的为VXLAN的service，30098的两台机器为Host-gw的service，8081端口为Docker bridge模式，8080端口为Host模式。
我们先用听云Network看下整体服务是否受到影响。
下图是性能曲线图，有波动，属于正常范围。我们是HTTPS服务，前端负载均衡负责解码SSL，会消耗部分时间。
排除掉一些点本身的网络问题，可用性基本在100%。
接下来对比下看下听云Server。
下图为吞吐率，平均值为425081rpm。 共7台，平均每台吞吐率约为60725rpm。
下图为服务器响应时间图。
时间约为0.67秒，与前边听云Network测试的时间基本吻合。
从图上看大部分时间花在阻塞时间。这里我们要详细分解下阻塞时间，从而获取我们要评测的网络性能。
阻塞时间的定义是从负载均衡到后端RealServer的时间。这个时间在我们的场景下为
K8s： 阻塞时间=SSL解码时间+负载均衡响应时间+转发包给后端虚机时间+flanneld转发包时间。
Mesos bridge： 阻塞时间=SSL解码时间+负载均衡响应时间+转发包给后端虚机时间+本机NAT转发时间
Mesos host： 阻塞时间=SSL解码时间+负载均衡响应时间+转发包给后端Docker时间。
云虚机对比: 阻塞时间=SSL解码时间+负载均衡响应时间+转发包给后端虚机时间。
我们只要对比下各个测试情况下阻塞时间，将云虚机的Docker消耗时间记为0.
其他机器与与云虚机作的阻塞时间做减法，就可以得出相对应网络消耗。
两台机器的我们取平均值。
| 待测机器 | 平均阻塞时间 | Docker本身消耗 |
| K8s flannel vxlan | 644.778ms | 6.778ms |
| K8s flannel host-gw | 641.585ms | 3.585ms |
| Mesos host模式 | 650.021ms | 12.021ms |
| Mesos bridge模式 | 643.67ms | 5.67ms |
| 公有云虚机（对比） | 638ms | 0 |
上表的结果中，Host模式耗时最长出乎我们的意料，可能是个例因素导致。其他结果和我们的预期基本符合。其中VXLAN模式平均比公有云虚机多6ms的同时网络适应能力强，应该可以满足我们的需求。
在更大的并发下会怎样呢？通过横向扩展是否能达到我们的性能需求呢？
我们在此基础上测试了20台K8s vxlan模式与32台云主机机同时跑在上千万rpm的场景。从流量各半到逐步加大K8s的量来观察性能影响，同时观察其稳定性，测试结果下期揭晓。
各位小伙伴在应用架构迁移到K8s、Mesos或者原生Docker时，也可以利用听云的工具，测试下架构变更后对真实系统的影响。
原文链接：