【编者的话】本文建立了一套通用测评工具，通过容器启动时延等指标测评Swarm和 Kubernetes 在大规模部署下的性能表现，分析结果认为Swarm比 Kubernetes 的性能好。此外还提供了详尽的测试数据， 供应用者参考。
这篇文章主要针对 Docker Swarm和 Kubernetes 在大规模部署的条件下的 3 个问题展开讨论。在大规模部署下，它们的性能如何？它们是否可以被批量操作？需要采取何种措施来支持他们的大规模部署和运维？
- 我们需要使用侧重于用例的基准测试来对所有容器平台进行比较，这样采用者才可以做出正确的决策。
- 笔者从用户的角度建立了一套测评工具，用普通的方法测试 Docker Swarm和 Kubernetes。我只评估了通用的功能：容器的启动时间和容器罗列时间。
- Swarm的性能比 Kubernetes 好。
- Kubernetes 和Swarm都在 1000 个节点的集群上执行同样的工作。
- 无论从架构还是功能的角度来看，Kubernetes 都是一个更加成熟且复杂的系统，因此它就需要更多的精力去部署和运维。
- 以下所分析和呈现的数据可以帮助用户基于自身的需求来选择一个合适的平台。
序文
我很高兴地向大家透露，这篇文章是被资助的独立研究与开发的成果。Docker 公司不仅贡献了工程师们的宝贵时间，并且购买 AWS 的服务来支持该工作的不断迭代和测试。发布全部的相关内容用于检测，重复利用以及第三方测试是我们的共同目标。如果你或者你的组织对资助其他的创新研究感兴趣，请通过http://allingeek.com联系我。
我在这次研究的过程中学习到很多知识，不仅局限于测评的结果和集群架构。如果你想要随时参与讨论，请在 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 启动时间的测定需要使用不同的方法。
使用罗列容器的接口来获取完整的信息，或者使用“运行时间”来确定一个容器启动所需要的时间是十分有吸引力的方案。这个策略依赖于获取信息操作本身有足够合理的精度。但结果将显示，罗列容器的延迟非常巨大，以至于使用精度在十到百毫秒的测定命令来确定时间不是十分合理。 使用这样的测试方法会引入太多的错误。
因此，使用等同和通用的测试方法来做测定是一个更好的方案。在上述讨论案例中，两个平台都会最终启动一个容器。当它收到新容器的信息时，超时的进程将会退出。
按照上述方法测定启动延迟会引入一定的额外开销，但是额外开销对于所有的平台而言都是均衡的，因此也就不影响比较的结果。
测试环境
我在 AWS 上使用 1000 个节点的集群测试了 Kubernetes 和 Swarm。这是 AWS 平台上比较受欢迎的测试方法。节点运行在 m3.medium 的实例（1 vCPU，3.75 GB）上。基础设施机器使用 m3.xlarge 的实例（4 vCPU，15GB）。键值数据库运行在 c4.xlarge 的实例（4 vCPU，7.5 GB）上。Kubernetes 的 API 层采用 6 个冗余备份。测试运行在同一个 VPC 中的一台单机（t2.micro）上。
我基于以上配置选择了这些实例种类用于其它研究，并且在早期的迭代中观察性能。通用组件的性能特征：测试节点，worker 节点和 etcd 都是一样的。每个集群节点所提供的资源不会影响到这些测试的性能，除非这些资源不支持平台组件。你可以根据你自己大致的资源要求，规模大小和成本要求来决定自己部署的实例类型，集群大小。在这个测试中，软件没有太强需求。
用预加载到机器中的一些休眠程序来填充每个节点。使用者一般会采用预加载镜像这个通用的策略用来减少不稳定性和启动延迟。Kubernetes 节点用“gcr.io/google_containers/pause:go”镜像，而 Swarm 使用 Dokcer Hub 上的“alpine:latest”镜像中的休眠命令。被测试的容器都是通过“alpine:latest”镜像创建的，并且都只执行 nc 命令。
所有集群都根据大规模部署最佳实践和领域专家的指导意见进行配置。这些配置与一个产品环境有着如下不同之处：
- 不采用 multi-host 网络部署
- 不采用高可用的键值数据库配置
- 不采用安全 TLS 通信，并且对网络配置并不进行安全加固。
- Kubernetes 并不启用身份认证和授权的功能
我测试的软件版本是 Kubernetes v1.2.0-alpha.7 和 Dokcer Swarm v1.1.3-rc2（是从dockerswarm/swarm:master 拉取的）。两个集群的键值数据库都采用 etcd v2.2.1。
此次测评的目的是给预测级别的性能概率建立一些统计置信度。要完成该任务需要多次测量（或采样）相同的操作。每个目标级别，相同集合的性能分布可以帮助我们理解“下一次”操作的性能概率。大采样量可以提高精度，并且降低噪声或异常样本带来的的影响。
这个测评程序集群使用率分别为 10%、50%、90%、99%和 100%，每个目标使用级别收集 1000*的样本。在这个环境下，当一个节点运行 30 台容器时就会满了。所以，当一个 1000 节点的集群有 30000 台运行的容器时，这个集群也满了。测量时每次就采集一个样本，所以在测试盒或 API 服务上并不会产生任何的资源竞争。
在对 Kubernetes 测评时，会使某些级别的一系列操作样本数量降低到 100 个。随后，测评程序上的每个操作都会消耗超过 100 多秒。最终，1000 个样本将会消耗大约 28 小时来完成每个目标级别的操作。
测试结果
由于统计结果的数据经常被曲解，所以下列显示的图表和周围的注释我们会尽量保持简洁，确保不会给读者带来困惑。此外，在阐述相关数据的时候，我永远不会跟你说“相信我吧”。我得到的所有数据都在 GitHub 上。你可以用来做你自己的分析。
下面 4 个图表所提供的数据，可以帮助我们来回答一个问题：“当我的集群资源使用率是 X%的时候，将需要多长时间来启动下一个容器？”每个图表有一个小标题比如：“10%的样本容器在少于……时间内启动”。这就表示，在同样的目标水平，你有 10%的概率将在少于图表中给的时间启动的下一个容器。所有值的单位都是秒。
如果你想要在 Kubernetes 上在一秒内启动一台容器，如果你的系统上已经有一些负载的话，这可能性比较小。第 3001 台容器想要在 1.83 秒内启动的概率是 10%。
只要集群负载没有达到 90%，Swarm 有一半的概率可以在小于 0.5 秒的时间内启动一台容器。如果集群负载达到 50%或更多，Kubernetes 有一半的时间概率可以在大于 2 秒的时间启动一台容器。
到了资源占用率为 90%时，在两个平台之间的测评数据有最明显差别，那就是 Swarm 在启动容器的速度上快大约 4 至 6 倍。
在分析结果之前，我们看到在 Kubernetes 的 90%至 99%资源占有率过程中，数据有点走样。在和同事讨论该异常时，我们推测是 etcd 测试的线性性质和“模型建立”原因导致的问题。这些问题导致系统经历一个异常的减速，并且在后面 99%部分的变得很不稳定。我仍然在图中标注上该数据，是因为这些数据也许可以表明集群长期运行下会出现的稳定性问题，这是非常有趣的。我曾经听到一些说法是 etcd v3 会有一些改进，包括性能增强和清理任务等，也许可以帮助解决这个问题。所以，之后我使用了一个全新的集群来测试负载 100%下的 Kubernetes。由于该原因，所以我在以下的分析中不计在 90%和 99%资源使用率下的测试数据。
在分析这些图表和得到的数据，你可以做一些着重的观察：
- Kubernetes 的第 30001 台容通常在 2.52 秒至 3.1 秒启动，而 Swarm 则只需要 0.56 秒至 0.67 秒。
- 当集群中有 3000 台至 30000 台容器时，Kubernetes 容器的启动延迟会增加 0.69 秒至 0.74 秒，而 Swarm 只有 0.22-0.27 秒。
- 观察到 Swarm 的最长启动延迟是 1.14 秒（第 30001 台容器），比 Kubernetes 的最短延迟（在第 3001 台容器是 1.69 秒）还短大约 0.5 秒多。
当做这类的测评时大的采样量是很重要的，因为数据可以让你更好地理解遇到一个特殊结果的可能性。在这个案例下，我们知道 Kubernetes 将花费几秒的时间来启动单台容器。Swarm 通常可以在一秒内启动一台容器，一般可以在 0.7 秒内启动，除了 10%的其他情况。那么这么小的延迟肯定会对一个真实的基础架构决策有着实际的应用。
如果要我去建立一个“刚好及时”的容器系统，像 AWS Lamda，那么我肯定会采用 Swarm 为基础来搭建那个系统。
有趣的是，我想补充一点，复制控制器提供的 Kubernetes 并发容器调度的效果是很惊人的。使用 Kubernetes 复制控制器，我可以在 155 秒内创建 3000 个容器副本。如果没有使用并发的话，将在 Swarm 上需要大约 1100 秒，在 Kuberntes 上则需要 6200 秒。
一些时候采用并行的方法是一个非常好的想法，这也正是编排系统平台的闪光点所在。
罗列容器命令的测试结果如下所示。请注意，Kubernetes 在 99%资源占有率下的测试结果是异常的，随后我会用是一个健康的集群来在 100%负载下重新测评。
Kubernetes 里罗列容器命令的性能在集群资源使用率为 90%至 100%时，表现跟其他迭代测试的结果一致。
Swarm 和 Kubernetes 在容器密度较低时都表现得很好。在 10%集群资源使用率的情况下，Kubernetes 罗列所有容器所花费的时间总是比创建一个容器耗费的时间短。
数据表明，在集群资源使用率为 50%至 90%之间的某一点，Kubernetes 的性能会超过某个阈值，而性能的降低也比它在 10%至 50%时的快。更深层地探究数据，我发现第 50 个百分点是 6.45 秒，而第 75 个百分点时是 28.93 秒。对于这一点，我更愿意解释为 Kubernetes 在集群使用率达到 50%的时候罗列容器命令的性能开始出现大幅下滑。
Swarm 的性能数据则比较少有戏剧性的变化但仍然说明了一些问题。就如同 Kubernetes，Swarm 也会有一个性能的临界点，由有一个平缓的增长趋势后跳到一个高很多级别的平缓增长趋势。就是说该临界点会影响集群在负载 90%-99%时使效率提高，而在负载为 50%到 90%的区域使效率降低。
在所有的测试级别中，Swarm 在集群使用率为 99%时的性能表现比 Kubernetes 在集群使用率为 10%时的性能仍快 4 到 6 倍。
在我跑完该基准测试后，我想对照现有可搜集到的其他测试数据确认一下我的发现。最终找到 GitHub 上一个从 2015 年 1 月开始的对调查容器启动时间的项目。他们号称可以达到他们的目标，“在一个 100 节点，3000 个 pod 的集群上，可以使 99%的预先拉取过镜像的点对点 pod 的启动时间达到小于 5 秒的性能指标。”我不能确定他们使用的是什么测试环境，但是我所收集的数据有着相同的数量级。
GitHub 上的评论指出，测试端对端容器的启动时间的延迟与测试调度吞吐量是不同的。CoreOS 的 Hongchao Deng 在几周前发布了一篇文章，关于 Kubernetes 的调度程序，并在一个虚拟或空环境中测试性能。那个测试把调度程序的性能与其他来源如网络，资源竞争的噪音隔离开来。但真实环境并没有那样的隔离，所以想要在自然环境下有那样的性能，有点不现实。CoreOS 的文章写得非常好，我逐字拜读了。它是在实际应用工程中如何提高单个组件性能最好的一个例子。
总结一下，这些测评结果显示我们所测试的操作在 Swarm 上运行得比 Kubernetes 的快。两个集群用的都是相同的数据库技术，相同的测试工具和网络拓扑。我们可以推测，造成不同结果的原因是在架构和算法选择上。在下一章，我们会深入到两种架构中来了解。
Kubernetes 和 Swarm 是否真的具有操作 1000 个节点的能力？
我曾经把两个集群都扩建到 1000 个节点。这需要的时间就像 90 次迭代一样，用了 100 多小时的研究和实践。这一章将阐述了它们的架构，资源利用的设计理念等。
我在每个平台都启动了默认工具。Kubernetes 运行一个叫做 kube-up.sh 的脚本来启动一个在某个云服务上的单主控节点的集群。大多数的 Swarm 教程和指导会让读者用 Docker Machine 来生成集群（包括我自己）。然而两种方法都不能让集群扩到 1000 个节点。
为 Kubernetes 所创建的单主节点运行着 etcd 数据库、API 服务、kubelet、scheduler，、controller-manager、 flannel、kube-proxy 和 一个 DNS server。Kube-up.sh 可以提供这个集群但只要一个有 300 个备份的备份 controller 节点准备运行，那么 master 节点的性能就会下降。内存不会产生问题，但这些负载会消耗 CPU。资源消耗所产生不稳定性和性能问题，会导致集群不可用。
用 Docker Machine 部署机器太慢了，并且当生成一个 1000 节点的集群时，经常会遇到不可恢复的错误，造成无法成功部署。我最初的实验采用一些比如并行 10 个进程的方法。那会花费大约 4 个小时来创建前 100 个节点。当我增加并发数到 100 时，我马上就后悔这么做。
那导致我的第一次经历 AWS 的流量限速，并且导致 AWS 的 web console 不能用。
经过好几个小时，又创建了另外 100 个节点来弥补错误（大约有 10%的错误率——机器挂了，不是 Docker）。我承认这不是个好想法，并终止了实验。
自定义模板
当时我只在 AWS 上做测试。我选择了 CloudFormation，因为这是云服务上自带的。但后来反思我觉得我还是应该使用 Terraform 来在其他云上测试。
我根据现有的最佳实践和社区专家的专业知识设计了每个模板。我首先注意到，Swarm 大集群的最佳之间与我之前创建了 100 次的演示集群有着相同的架构。Kube-up 提供的 Kubernetes 集群需要一个架构上的改变。两个架构图如下图所示。
左图：Swarm 的节点和管理器直接依赖于基于 etcd 的键值对存储。而用户端直接与 Swarm 的管理器连接。右图：全部的 Kubernetes 节点，主组件和用户端通过一个横向扩展的 API 和一个负载均衡器通信。只有 API 服务与 etcd 通信。
上图中，“Docker Group”和“Node Group”是各个集群的 1000 个节点组成的组。这些是用户请求运行容器的机器。标注为“test-node”的机器用于跑测试。
有一个很有意思的地方是，根据 Google 这篇“Borg, Omega, and Kubernetes”文章描述，Swarm 的框架与 Omega 类似。两个系统都让控制板组件直接与数据库连接。而 Kubernetes 把全部组件间的通信都集中在一个横向扩展的 API 上。
Kubernetes 的 API 服务允许你根据资源和组类别关联数据库，通过设置–etcd-servers-overrides 标志字就可以完成。我把热数据（例如指标和事件）与可操作资源如 job 和 pod 隔离开来。Kubernetes large cluster configuration guide这篇指导描述了怎么关联数据库。实现 1000 个节点或更多节点的集群就需要这么做。
下图表示启动一个容器的不同序列以及不同顺序会怎么影响性能数据。每个灰色的列代表一个网络上的不同 host。
启动 Swarm（1）中的一个容器，就会有一个客户端连接到 Swarm 管理器。管理器执行一个基于以及采集好的资源数据设计的计划算法。然后（2）管理器会直接连接到目标节点，并且启动容器。当节点启动容器，它会反馈给管理器。管理器会立即给客户端响应。在操作的过程中，客户端的连接是打开的。
以下这个序列图是基于我对系统架构大致了解的介绍，可能会包含细节上的错误。该图忽略了大多数内部进程和非正式的交互（某些 API 服务或组件在工作是因为它在运行的状态，并不是因为它与一个请求在进行交互）。
在 Kubernetes，（1）一个客户端通过一个负载均衡器连接到一个 API 服务，（2）会在 etcd 中产生一个资源。Etcd 执行它的状态机然后（3、4）通过 API 服务器就新的资源数据更新观察者服务，之后，（5、6）controller-manager 会对一个新的 job 请求做出响应并且通过再次调用 API 服务来创建一个新的 pod 资源。然后，（7、8）etcd 会通过 API 更新这个新资源的监视器，（9）同时会触发程序调度器做一个新的调度决策，并且（10、11）通过 API 把 pod 指派给一个节点。最后，（12、13）etcd 和 API 把指派信息通知目标 Kubernetes 节点并（14）启动容器。在容器启动之后，（15、16）会通过 API 来吧状态改变记录在 etcd 中。
Kubernetes 的工作流程比 Swarm 涉及更多在网络的交互，API 调用和数据库中的资源。同时，Swarm 的架构缺少一个控制的中心点和一个组件来分担未来更多功能加进来时对数据库造成的负担。
在大规模的 Kubernetes 系统中，API 机器的运行会占用 15%到 30%的 CPU。数据库也差不多。Swarm 的管理器会占用大约 10%的 CPU，而数据库大约是 8%。
笔者个人猜想，Swarm 可以再扩展几千个节点，数据库才会遇到一些问题。而 Kubernetes 扩展架构则需要更过的 API host（你会知道什么时候应该关注这些机器的 CPU 使用量）。
如何支持这些大规模系统是另一个问题
每个人都有自己的偏爱和己见。市场上的宣传，痛苦的经历，长长的评论栏，冷却的推测都会使偏爱升温。不做量化的综述， 我提出两种估算应用的方法，同样可以适用于估算建立一个系统所需的工作量。如果你有其他的定义或改进我的估算方法，我希望听到你的意见。
总的说来，Docker Swarm 一定程度上比 Kubernetes 集群组件更加容易应用和支持。
应用工作量（adoption effort）指的是从一个新手到熟练地操作一项新技术所需要的工作量。这适用于一个团队采用一项新的技术和每次团队新增一个成员时的情景。观察发现，任何组件的学习曲线和这个组件的抽象概念的数量成正比，所以我提出下列这个公式来计算一个应用工作量指数（adoption effort index ，AEI）：
adoption effort = component count * abstraction count
就像 AEI，一个运维工作量指数（a support effort index ，SEI）是一个指标，表示长期运维一个平台所需要的工作量级别是多少。基于笔者自己的实验，发现这个指数应该与组件之间交互序列的平均长度成比例。SEI 反映了一个操作失败的机会数。我提出了以下的计算公式：
support effort = component count * interaction sequence length
诸如此类的标准对于社区可以专注于讨论具体的论点是非常重要的。不然对话可能会变得模凌两可或情感导向。在这种情况下，社区的发展很难有进一步前进。
Kubernetes 提供的功能相对于 Swarm 来说是一个超集。出于单项对比的考虑，我们只比较测试他们之间可以类比的组件。测试的 Kubernetes 配置有以下组件：
- Docker Engine
- kubelet binary
- Pod-master
- Controller-manager
- Scheduler
- API server
- Etcd
一个包含网络环境的生产环境配置也需要包括：
- Flannel
- kube-proxy
- kube-dns
测试的 Swarm 配置有如下组件：
- Docker Engine
- Swarm Manager
- Swarm in Join Mode
- etcd
一个 multi-host 的网络的 Swarm 集群应该只需要增加一个组件：libnetwork——这个是 Docker daemon 的一部分——也在其他的一些工具如 Flannel、Weave 或者是 Calico 项目之中。
剔除通用组件（Docker Engine 和 etcd）和不计一些影响不大的组件，如负载均衡器等等之后，Kubernetes 的组件数只剩 5 个，而 Swarm 只有 2 个。
Docker 和 Swarm 提供相同的抽象功能，但 Swarm 还把集群本身抽象成为一台机器。相同的抽象有：
- Containers
- Images
Kubernetes 还提供“集群”抽象，另外在测试中还使用以下抽象：
- Containers
- Images
- Pods
- Jobs
最终结果是 Swarm 的抽象数量为 3，而 Kubernetes 是 5 个。Kubernetes 的功能丰富，这个数字还忽略了“replication controllers，” “services” 。采用这些抽象会提高 AEI。
把这些数值插入到应用工作量指数等式中，得到的 Kubernetes 的指数是 25，而 Swarm 是 6。
对比支持工作量指数可以用模糊数学评估。据我所知，全部的 Swarm 操作都需要引入单个内部组件交互来完成。那么列举操作可能频繁使用这种并发的交互。Kubernetes 中最短的操作可能是列举操作需要至少两步完成。我所理解的创建 job 操作需要 5 或更多的交互。
Swarm 的运维工作量指数是 2，Kubernetes 是至少 25。
反观这些数字，我想确定的是，很明显，选择 Kubernetes 并不是我的意图。这些数字反映 Kubernetes 是一个庞大的项目，有很多可移动的部分，有很多方面可以学习，但也有更多潜在失败的机会。即使如此，Kubernetes 所完成的架构可以防止一些 Swarm 上已知的弱点，这就有可能产生更多深奥的问题和细微差别。
所调查的这些工作量可以作为参考，只作为一个实施者想要使用 Kubernetes 提供的扩展功能集所需要投入的时间与精力。
行动的召唤
整个工程社区似乎都醉心于容器和上述提到那些奇妙的工具之中。 我非常高兴有机会去实验或者实践其中的一些。 这些推动的力量加上这些工具帮助整个社区以比起以往更加快的速度推动技术的进步。
但是”拥有某个工具”和”理解某个工具在大生态圈中表现出来的优势和劣势”是有差别的。而优化一个没有任何衡量标准的工具是非常困难的。 因此，进一步的做类似的研究和开发对于整个社区而言是有益的。同时， 制定开放和可复验的测试基准，透明的分析过程和清晰的相关标准将会帮助决策制定者在一个数据驱动的环境中完成他的决策工作。
最后，请帮助我们在这个话题上做进一步的拓展。 我们需要其他领域，云供应上和集群配置方面的数据。 我们需要拓展我们的公共测试基准，使其能覆盖更多的功能点。 我们需要一个更加具有可拓展性的测试工具。 我们需要更多对于将猜测剥离出设计本身感兴趣的人士的参与。
所有我所用到的代码和模板都能在GitHub上找到。 请亲自尝试运行这些测试然后帮助我们改进或者提出改进的建议。 如果你有突发的灵感并且自己开发了一些东西，请别犹豫，将它们给分享给大家吧。 我们需要这些数据。
Cloud Container Cluster Common Benchmark：https://github.com/allingeek/c4-bench
Evaluating Container Platforms at Scale Data：https://github.com/allingeek/ecps-data
原文链接：Evaluating Container Platforms at Scale（翻译：Lynna）
