本文讲的是Docker Swarm：经济高效的容器调度【编者的话】本文探讨了几种容器调度策略，并以内存约束为例，讨论了如何利用Docker Swarm，通过资源约束实现容器的合理调度。其中，对容器资源的约束，包括硬约束和软约束，硬约束是指内存资源的实际限制条件，而软约束则是当服务器实际内存资源有足余时，容器可自由使用，一旦内存资源有所紧缺，则约束开始生效。硬约束和软约束的结合使用，可以在减少资源浪费的同时保证服务的稳定性。
我们每天在数百台服务器上运行成百上千个容器，面临的最大一个挑战是怎样高效地调度容器。容器的调度是指在一组服务器上处理容器分配的问题，以保证服务能平稳运行。由于这些需要调度的容器是客户应用程序的组件，我们必须在还未知晓其性能特点之前进行调度。
不合适的调度方法会导致以下可能的结果：
合适的调度方法对我们而言很重要，以经济高效的方式，提供最好的用户体验。
但是，运行全栈环境和运行代码段是完全不同的事——我们很快发现，这个解决方案并不理想。我们的服务器经常因繁忙导致CPU过载和内存不足。
幸运的是，Docker Swarm拥有了全部这些特性，最近该工具的稳定性也已满足生产环境的要求。我们使用 spread 调度策略，以减少因服务器故障而损坏的容器数量。并设置了基于镜像的类别关系，同类容器可以运行在同样的服务器中。
我们使用了Datadog中 Docker集成 功能，可详细观测容器使用资源的情况。Datadog包含了所有我们需要的数据，可用来描述每个容器的内存或CPU使用率，以及每个服务器的磁盘使用率。
有了这份数据，我们发现内存是制约因素（不是CPU或磁盘），因此，我们决定利用内存约束来调度我们的容器。我们根据观测到的Datalog内存分配情况，设置我们的内存约束在99％的位置即1GB。我们还可以手动重置对每一个容器的约束。
结果显示，这个约束非常有效！我们将不会再看到服务器内存不足，或因超载而运行缓慢。
我们想要更经济高效，但又不能损失稳定性。降低硬约束不是一个好的选择，因为耗内存的应用会因为这个约束而崩溃。
我们需要一种基于估计的约束，在必要时又可以被突破的调度方法。值得庆幸的是，Docker提供了 --memory-reservation 选项来设置内存软约束。当设置该软约束时，容器可以自由地使用所需的内存，但是，当服务器上有内存争用时，Docker会试图缩减内存到软约束值以内。基于软约束的调度会减少浪费，并设置一个硬约束来阻止失控。但Swarm没有这个功能，所以是时候需要我们使用Go语言，给Swarm建立一个 定制版本 分支，可调度软内存约束，而不是硬约束。再使用Datadog收集数据，基于概率选择理想的软约束阀值，并设置硬约束为容器使用的最大值。这个方法显著地减少了浪费，而且也没有影响到稳定。
鉴于软约束的成功，我们的下一步是为每个容器动态地选择软约束和硬约束。因为所有的数据都输送到了Datadog，可通过一个查询，得到理想的软硬约束阈值，保持容器稳定运行而又不浪费资源。敬请关注这个博客，我们一有结果就会让您知道！
原文链接：Cost-efficient container scheduling with Docker Swarm（翻译：陈晏娥，校对：黄帅）
===========================================
译者介绍
我们每天在数百台服务器上运行成百上千个容器，面临的最大一个挑战是怎样高效地调度容器。容器的调度是指在一组服务器上处理容器分配的问题，以保证服务能平稳运行。由于这些需要调度的容器是客户应用程序的组件，我们必须在还未知晓其性能特点之前进行调度。
不合适的调度方法会导致以下可能的结果：
- 过多的资源配置——意味着更高的成本。
- 过少的资源配置——意味着用户的稳定性差。
合适的调度方法对我们而言很重要，以经济高效的方式，提供最好的用户体验。
随机性调度策略
起初，在我们的 早期产品 中使用了相同的调度方法。这个方法（在Docker Swarm之前）没有以任何方式对容器的运行进行约束，而只是简单地随机选择一个服务器。但是，运行全栈环境和运行代码段是完全不同的事——我们很快发现，这个解决方案并不理想。我们的服务器经常因繁忙导致CPU过载和内存不足。
硬约束条件
我们一起根据需要，定义了一种新的调度器：不再随机选择服务器；要能约束运行所需的资源分配，理想情况下，还要易于部署。幸运的是，Docker Swarm拥有了全部这些特性，最近该工具的稳定性也已满足生产环境的要求。我们使用 spread 调度策略，以减少因服务器故障而损坏的容器数量。并设置了基于镜像的类别关系，同类容器可以运行在同样的服务器中。
我们使用了Datadog中 Docker集成 功能，可详细观测容器使用资源的情况。Datadog包含了所有我们需要的数据，可用来描述每个容器的内存或CPU使用率，以及每个服务器的磁盘使用率。
有了这份数据，我们发现内存是制约因素（不是CPU或磁盘），因此，我们决定利用内存约束来调度我们的容器。我们根据观测到的Datalog内存分配情况，设置我们的内存约束在99％的位置即1GB。我们还可以手动重置对每一个容器的约束。
结果显示，这个约束非常有效！我们将不会再看到服务器内存不足，或因超载而运行缓慢。
软约束条件
享受了这个发现所带来的稳定性，在一段时间后，我们注意到，这种策略过度占用了服务器资源。大多数容器实际的内存使用率远远低于该内存硬约束1GB。这意味着我们所付费的比实际使用的多很多。我们想要更经济高效，但又不能损失稳定性。降低硬约束不是一个好的选择，因为耗内存的应用会因为这个约束而崩溃。
我们需要一种基于估计的约束，在必要时又可以被突破的调度方法。值得庆幸的是，Docker提供了 --memory-reservation 选项来设置内存软约束。当设置该软约束时，容器可以自由地使用所需的内存，但是，当服务器上有内存争用时，Docker会试图缩减内存到软约束值以内。基于软约束的调度会减少浪费，并设置一个硬约束来阻止失控。但Swarm没有这个功能，所以是时候需要我们使用Go语言，给Swarm建立一个 定制版本 分支，可调度软内存约束，而不是硬约束。再使用Datadog收集数据，基于概率选择理想的软约束阀值，并设置硬约束为容器使用的最大值。这个方法显著地减少了浪费，而且也没有影响到稳定。
动态范围和突破
Docker1.12.0版中，最酷的一个功能是调度软约束的能力。虽然它仍等待发布，不过我们已经提前尝试，可简便地使用如下命令来调度软约束。docker service create --reserve-memory <SOFT_LIMIT>
鉴于软约束的成功，我们的下一步是为每个容器动态地选择软约束和硬约束。因为所有的数据都输送到了Datadog，可通过一个查询，得到理想的软硬约束阈值，保持容器稳定运行而又不浪费资源。敬请关注这个博客，我们一有结果就会让您知道！
原文链接：Cost-efficient container scheduling with Docker Swarm（翻译：陈晏娥，校对：黄帅）
===========================================
译者介绍
陈晏娥，鞍钢集团矿业公司信息开发中心高级工程师，专注虚拟化技术。
原文发布时间为：2016-08-17
本文作者：陈晏娥
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：Docker Swarm：经济高效的容器调度
