这篇文章主要针对Docker Swarm和Kubernetes在大规模部署的条件下的3个问题展开讨论。在大规模部署下，它们的性能如何？它们是否可以被批量操纵？需要采纳何种法子来撑持他们的大规模部署和运维？

序文

我很开心地向大家透露，这篇文章是被扶助的独立研究与开发的成就。Docker公司不只孝敬了工程师们的名贵时间，并且采办AWS的处事来撑持该事情的不停迭代和测试。颁布全部的相关内容用于检测，反复操作以及第三方测试是我们的配合方针。如果你或者你的组织对扶助其他的创新研究感兴趣，请通过联系我。

我在此次研究的过程中学习到很多常识，不只局限于测评的功效和集群架构。如果你想要随时参预讨论，请在Twitter上存眷我或阅读我的博客，因为这些内容细节将跟着时间流逝被我垂垂淡忘。

这个项目带来一个暗中的现实那就是——云不是无限的——当我用光us-west-2a上所有m3.medium的容量时，集群安排位置成为了我的存眷焦点。Oops！正在回滚……

现实中Swarm和Kubernetes在大规模集群中的性能表示怎么样？

我认可，当我最初提出这个问题时并不知道怎么回答。我读过一些文章，好比Kubernetes Performance Measurements and Roadmap和Scale Testing Swarm to 30,000 Containers等。但是这些文章都存在一个问题：我们很难理解作者真正要测什么，以及测试环境是怎么样的。越发让人痛苦的是，没有供给清晰的法式或工具让测试重现。每个泛起出来的数据会变得没有意义，因为读者已经迷掉在上下文中。我认为，对付读者来说，这些数据比起没有被证明的表述反而越发危险。因为读者会更愿意去相信你的数字，即使它们很难理解。

现有的研究和文献的另一个问题是，很少有文章在丈量不异的对象。这样就很难来对照功效呈报。我们需要一个通用或完整的成果测试基准，让这类的工具可以测试每个平台（不只仅是Swarm和Kubernetes），这样就可以辅佐到DevOps社区，就如同QuirksMode.org辅佐网页开发者一样。

这个项目面临的挑战是成立一个通用的框架来评估在一个现实部署环境中的通用成果，同时辅佐读者记录流程。终究我需要让每个普通读者可以拿到功效信息。而在真正的执行前，成立一个通用的定名方法是很重要的，例如Docker是给与Container技术，一个“pod”是Kubernetes中的最小部署单元，一个pod由至少一个Container构成。我们所描述的事情都是使用单容器的pod，所以接下来的这篇文章中，我会使用Container来替代pod。文章中接下来的内容，我将引用Kubernetes的功课（job）。一个功课是一个Kubernetes的控制面板所打点的单元，是用户但愿完成的任务。一个功课通过一个pod执行，在这里也是一个Container。

选择用于丈量的操纵

Swarm和Kubernetes供给了差此外API和成果的抽象。 Swarm是Docker的一个子项目，它的感化在集群级别下就如同Docker在一台单独的机器中起到的成果。你可以使用Swarm来打点单个容器或者列出集群中所有运行的容器。而Kubernetes拥有并行启动，自动扩容，有差另外批措置惩罚惩罚和处事生命周期，负载均衡等特性。因此，颠末全面的评价后，我将”容器启动延迟”和”容器罗列时间”作为两个最佳的候选操纵。

最小化容器的启动时间对付延迟敏感的措施而言非常重要。举个例子，类似于AWS lambda的即时编译（Just-in-time）容器处事会在收到一个依赖于它特定成果的请求之后，才真正地启动一个容器。 而即时编译容器在物联网（IoT）范围也有其实际的应用。此外，功课或者批措置惩罚惩罚软件素质而言就是“按需的”。而无状态的微处事和固化的部署单元也是被广泛倡导和给与的。我坚信当上述提到的趋势进一步的趋向于作为即时编译处事存在时，响应式部署根本架构的盛行会是一种自然地演化功效。而对付这种类型的系统而言，低延迟是一个须要的需求。

对付“容器罗列时间”所需的低延迟而言，并没有相关的用例撑持。但从目前所堆集的相当经验来看，在一个集群上罗列容器命令的延迟与否会和运维人员的效率有密切的联系。如果罗列容器操纵相当慢，那么运维人员可以考虑成立用于更新本地容器列表缓存的一个后台执行任务，基于此我们可以供给比直接执行罗列容器操纵越发好的性能来提升效率。

开发测试工具套件

Kubernetes和Swarm都供给了同步API挪用来获取容器列表。 这意味着他们的命令行客户端同时会被梗阻，直至收到整个列表信息以后才会退出。所以可以便利的使用time命令来测试两者罗列容器所需要的时间。 Swarm此外供给了同步的接口来创建容器，因此我可以使用同样的测试模式（基于time命令）来测定启动的延迟。不过，Kubernetes使用异步的方法来完成同样的成果（创建一个容器），换句话说，客户端会在容器真正启动之前就已经退出。 所以，对付Kubernetes启动时间的测定需要使用差此外要领。