我们每天在数百台服务器上运行成百上千个容器，面临的最大一个挑战是怎样高效地调度容器。容器的调度是指在一组服务器上处理容器分配的问题，以保证服务能平稳运行。由于这些需要调度的容器是客户应用程序的组件，我们必须在还未知晓其性能特点之前进行调度。
不合适的调度方法会导致以下可能的结果：
过多的资源配置——意味着更高的成本。
过少的资源配置——意味着用户的稳定性差。
合适的调度方法对我们而言很重要，以经济高效的方式，提供最好的用户体验。
随机性调度策略
起初，在我们的早期产品中使用了相同的调度方法。这个方法(在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(翻译：陈晏娥，校对：黄帅)