Docker Swarm 集群管理性能全面碾压 Kubernetes

摘要:Docker 官方邀请了独立技术顾问杰夫·尼科洛夫对统一框架下的编排工具的性能进行准确评估。结果相当震撼!在集群接近满载时,要想列举所有运行中的容器,Kubernetes 需要的时间是 Swarm 的七倍之多,超过 2 分钟。此外,随着集群从 10% 到 100% 满载运行,Kubernetes 的反应时间比 Swarm 多 98 倍(没错,这不是笔误,的确是 98 倍!不是 98%!)

本文由 DaoCloud 独家翻译。

本期内容:

肯定会有人和你提及,整个容器社区的话题已经毫无避免的导向了容器编排领域。

现实的确如此。近期一份针对 500 多名受访者,涉及开发运维、微服务和公有云的调查显示,Docker Swarm、Google Kubernetes 和亚马逊 EC2 容器服务(ECS)在容器编排方面呈三足鼎立之势

swarm-1

我们相信,以下三个关键指标,是客户根据环境选择编排工具时必须考虑的:

  • 性能:用户可以在多短的时间内启动并大规模运行容器?系统在大负载情况下响应速度如何?
  • 易用性:起步时的学习曲线是什么?维持运转是否复杂?系统中有多少不定项?
  • 灵活性:是否可以和我当前的环境和工作流相整合?我的应用从开发到测试再到生产,是否可以无缝衔接?我会不会被限制在某个平台上?

Docker Swarm 在这三个领域内均占有一定优势。

规模性能

一年多前 Swarm 发布了第一款测试版,此后便突飞猛进。在不到一年的时间里,Docker 推出了 Swarm 1.0(2015 年 11 月),并确保 Swarm 可以同一生产环境中,支持多达 1000 个节点的运行。团队的内部测试也证明了这点。

谷歌早前在自家博客上公示了 100 个节点集群的性能测试细节。客户面临的问题是,他们无法真正比较两种测试结果,因为两次测试的方法存在本质区别。

要准确评估不同编排工具的性能,就必须有统一的框架标准。

为此,Docker 公司聘请了独立技术顾问杰夫·尼科洛夫来协助搭建框架,让整个容器行业有可供参考的评估标准。

今天杰夫公布了他对 Docker Swarm 和 Google Kubernetes 规模性能的独立研究成果。其研究和论文(受 Docker 公司委托)测试了两者在 1000 个节点集群上运行 30000 个容器的性能。

测试的目的在于测量两项指标:

1. 容器启动时间:新容器能在多短时间内真正接通网络,而非简单按计划启动。

2. 系统负载条件下的响应时间:大负载情况下系统能以多快的速度响应操作指令(所有容器都运行的情况下)

测试设备会随着集群的搭建测量这些指标。一个满负荷的集群将以 1000 个节点运行在 30000 个容器之中(每个节点 30 个容器)。

随着节点被添加到集群上,设备会停下来测量容器的启动时间和系统的响应速度。几个断点分别是集群的资源占用率达到 10%、50%、90%、99% 和 100% 的时候。在每个断点上设备会做 1000 次数据迭代。

这就意味着,举个例子,当集群的占用率为 10%(100 个节点和 3000 个容器)时,设备就暂停增加新的节点,计算启动一个新容器(本例中指第 3001 个容器)所需的时间,以及列举全部运行容器(3001个)所需的时间,并把这一特定次序重复 1000 次。第 3001 个容器创建完毕,启动时间和列举时间算好了,移除了 1000 次。

结果显示,平均下来,Swarm 在容器启动速度上比 Kubernetes 快 5 倍,在传输操作指令速度上快 7 倍(传输指令在大规模生产环境中是运行集群的必要条件)。 

细看容器启动时间的测试结果,Swarm 在各种负载条件下都拥有明显的性能优势。

转自杰夫的博客:

通常情况下,只要集群的占用率低于 90%,Swarm 就可以在不到 0.5 秒的时间内启动一个容器。而一旦集群的占用率高于 50%,Kubernetes 则需要 2 秒才能启动。

swarm-2

必须指出的是,此项测试无关于容器的安排,而是关于容器的启动和工作。

现实是,没人关心容器是否 “将要” 运行,人们关心的是容器正在运行。我想这就像:我出去吃饭,点菜和把菜单交给厨房的过程是必要的,但真正重要的是,我点的菜需要多长时间才能做好,才能端上我的餐桌。

容器的一项重要指标是响应速度。对于要求近乎实时响应的分布式应用而言,5 倍的启动滞后将会酿成大祸。就算是不需要实时响应,要多花这么多的时间来搭建运行架构也是非常痛苦的——想想看,在连续整合的工作流中,更慢的启动速度会直接拖长测试的循环时间。

把 30000 个容器装进一个集群是一回事,有效管理整个环境又是另一回事。系统负载条件下的敏捷度对于高效管理至关重要。在容器的生存时间只有几分钟的世界里,不能实时收集环境数据,意味着你永远无法知道你的基础设施里此刻正在发生着什么。

为了测量系统的敏捷度,测试设备计算了集群在不同载荷下列举所有运行容器的时间。

结果:在集群接近满负载时,要想列举所有运行中的容器,Kubernetes 需要的时间是 Swarm 的七倍之多,超过 2 分钟。不仅如此,随着集群从 10% 到 100% 满载运行,Kubernetes 的反应时间比 Swarm 多 98 倍(没错,这不是笔误,的确是 98 倍!不是 98%!)

swarm_kubernetes3

易用性

所以,为什么 Kubernetes 比 Swarm 的响应速度要慢很多呢?这得看系统架构。看一看杰夫测试环境里的图表,就知道 Swarm 比 Kubernetes 的不定项更少。

swarm-3

每个模块都给整个结构的初始化引入了复杂项,延迟了执行命令的时间,同时使得定位错误以及修复带来困难。下方图表展现了 Kubernetes 与 Swarm 各自模块层间的交互次数的比较。

比起 Swarm,Kubernetes 需要 8 倍的 “hops” 来 “启动” 或者 “列举” 容器,这导致它有更多延迟,在重要的业务流程编排上会多出 7 倍的时间。如此频繁的交互带来了另一个问题:一旦命令未能执行,我们很难推断到底是哪里出了问题。

swarm-4

Kubernetes 诞生于 Google 内部的 Borg(大规模集群管理)项目,因此人们认为 Kubernetes 在 “超大规模云平台扩展” 上运行才能成功。测试结果证明 Kubernetes 与 Borg 有非常大的差异,不过两者的确有共同点:架构极其复杂,需要一个能力出众、专业素养极高的云工程师团队天天负责实施和管理。

另一方面,Swarm 沿用了 Docker 的核心法则——将复杂的云技术解藕。Swarm 自创建的第一天起,就打算成为容器编排的最佳工具,能够适应任何规模的组织,不需要成群的工程师来维护。无论你是在笔记本电脑上测试一个小集群,在数据中心建立测试服务器,还是创建生产环境下的云基础设施,Swarm 都能为你提供非常棒的体验。

正如杰夫所说:“从量化结果来看,Docker Swarm 在使用和支持方面比 Kubernetes 集群组件更方便。”

有些人可能会反驳,Kubernetes 之所以复杂,是因为它能做更多任务。然而,如果 “更多任务” 不是你想要的,那么 “做更多” 也不会带来更多价值。在现实操作中,“做更多任务” 并不一定都是有利的,因为 “更多任务” 意味着更有可能出现失败的情况,更高昂的维护费用,以及不必要的基础设施投资。

或者像杰夫描述的一样:

“……Kubernetes 是一个大型项目,拥有更多不断变化的组件,拥有更多需要学习的技术点以及更多失败的可能。尽管 Kubernetes 采用的架构可以避免 Swarm 架构中已知的几处缺陷,它也可能带来难解的问题,更多微妙之处。”

灵活性

正如我在文章开头所说,当评估编排工具时,性能和易用性只是其中的两个因素。第三个重要因素是灵活性,而灵活性本身意味着很多方面。

之前提及的调查结果表明,公司正在使用或计划使用的三种主要编排工具包括:Docker Swarm, Google Kubernetes 和 Amazon EC2 Container Service (ECS).

以上三种工具中,只有 Docker 致力于确保你的应用程序在基础设施中运行的整个过程不受阻碍:从开发环境,测试环境,一直到平台的生产部署;从笔记本电脑,到私有数据中心,再到你选择的云厂商,Docker Swarm 能让你在任何地方托管集群和编排容器。

Docker 除了让你在公有和私有基础设备上轻松装卸,它还有基于插件的架构特点。这些插件确保你被 Docker 化的应用程序,能在现有的技术设备中工作,与网络、存储和计算互补毫无问题,还能移动到一个新的网络或存储环境,而且无需改变应用程序的代码。

最后,一个吸引人的编排工具是任何一个容器服务(CaaS)都不可缺少的部分。事实上,编排工具并不是平台,而是更大技术栈的一小部分。

文章之前提及的研究同样表明,用户想要这样一款能够处理应用整个生命周期的工具,这是一款为开发工程师和运维工程师所服务的集成工具,同时能够支持最多种类的开发工具。

swarm-5

Docker Swarm 可以让使用者充分运用 DockerCLI 和 APIs 的强大原生功能。它让开发者不受干扰地工作,不需要担心复杂的开发环境和运行环境。Docker 能极好地与你目前的基础设备兼容,同时你也可以轻松转换其他供应商。我们的设计理念是永远把你和你的应用程序放在首位。

Leave a Reply

Your email address will not be published. Required fields are marked *