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

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

2016-04-07 673

文章出自：听云博客

随着公司业务的不断增长，我们的应用数量也有了爆发式增长。伴随着应用爆发式的增长，管理的难度也随之加大。如何在业务爆发增长的同时快速完成扩容成了很大的挑战。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时，也可以利用听云的工具，测试下架构变更后对真实系统的影响。

原文链接：http://blog.tingyun.com/web/article/detail/406

微信关注我们

原文链接：https://yq.aliyun.com/articles/25390

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

理解 Keystone 核心概念 - 每天5分钟玩转 OpenStack（18）

作为 OpenStack 的基础支持服务，Keystone 做下面这几件事情：管理用户及其权限维护 OpenStack Services 的 Endpoint Authentication（认证）和 Authorization（鉴权）学习 Keystone，得理解下面这些概念： User User 指代任何使用 OpenStack 的实体，可以是真正的用户，其他系统或者服务。当 User 请求访问 OpenStack 时，Keystone 会对其进行验证。 Horizon 在 Identity->Users 管理 User 除了 admin 和 demo，OpenStack 也为 nova、cinder、glance、neutron 服务创建了相应的 User。 admin 也可以管理这些 User。 Credentials Credentials 是 User 用来证明自己身份的信息，可以是： 1. 用户名/密码 2. Token 3. API Key 4. 其他高级方式 Authentication Authentication 是 Keystone 验证 User ...

2016-04-08

704

上一节介绍了 Keystone 的核心概念。本节我们通过“查询可用 image”这个实际操作让大家对这些概念建立更加感性的认识。 User admin 要查看 Project 中的 image 第 1 步登录当点击时，OpenStack 内部发生了哪些事情？请看下面 Token 中包含了 User 的 Role 信息第 2 步显示操作界面请注意，顶部显示 admin 可访问的 Project 为 “admin” 和 “demo”。其实在此之前发生了一些事情：同时，admin 可以访问 Intance, Volume, Image 等服务这是因为 admin 已经从 Keystone 拿到了各 Service 的 Endpoints 第 3 步显示 image 列表点击 “Images”，会显示 image 列表背后发生了这些事：首先，admin 将请求发送到 Glance 的 Endpoint Glance 向 Keystone 询问 admin 身份的有效性。接下来 Glance 会查看 /etc/glance/policy.json。判断 admin 是...

2016-04-11

542

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。