Imgix的工程师Cindy Sridharan撰写了一篇综述，讨论了采用Kubernetes和HashiCorp公司的Nomad等容器调度器（container scheduler）的目的；为了应对在程序打包、部署和生命周期等方面遇到的技术挑战，Imgix决定在架构中加入调度器；Imgix最终选择Nomad作为调度器：作者在文中对Kubernetes和Nomad进行了对比分析，大体描述了最终的技术实践。原文纲要：

为何Google当年使用了调度器Google当年的探索在多大程度上解决了其他人的问题为什么即使容器数量不多，也应该使用调度器在现有架构上增添调度器的挑战在混合环境上运行调度器为什么Imgix选择了Nomad，而不是Kubernetes还需解决的问题新工具引进的新问题未来的发展方向

Sridharan表示，现在的开发比十年前要复杂许多。即使核心商业逻辑很简单，考虑到高可靠性、高可用性、客户满意度、快速创新、持续交付、快速反馈和持续迭代的问题，可靠的标准化工具变得至关重要。很多组织会学习Google这种业界独角兽的实践。但其局限性在于：

“人人都可用的Google架构”只是指那些能够解决组织眼下问题的技术。

容器调度器最初由Google的Borg（白皮书）发扬光大。十余年来，Google一直将所有服务都放在容器中运行，由Borg管理集群。由于Docker的成功，容器化不再是大型组织的专利，反过来促使了Kubernetes的诞生。

调度器乍一看很吓人，仿佛大大超出大部分组织的工程能力：实际上，调度器可以改变游戏规则，大大改变传统的软件生命周期管理手段。调度器带来的灵活性和即时效益不可估量。

Sridharan表示，Imgix团队在探索调度器技术时，遇见了三个挑战：

打包——为了打包不同语言写作的程序，调度器需要支持类POSIX标准（虽然Docker容器接近POSIX，但仍有局限性）部署——不存在标准的与语言无关的方式来部署那些通过静态链接的二进制包或一系列更为复杂的软件包生命周期——构建分布式系统时需要考虑单点失效、功能降级（degraded application functionality）、服务级别目标（service level objective, SLO）和服务级别协议（SLA）

虽然在架构中加入调度器的成本不低，imgix最终还是选择了Nomad作为调度器。在选择技术时，由于Kubernetes和Docker关系紧密（如果选用，imgix需要修改现有程序的打包方法）和Kubernetes的网络问题，imgix最终没有选择Kubernetes。Nomad可以部署多种程序，包括静态连接的二进制包；同时，Nomad与服务发现程序Consul良好兼容（imgix的技术栈依赖Consul）。

在选择新工具时，特别是在选择运维工具时，很重要的一点是要选择可以无缝加入到现有基础设施的工具，尽量避免修改现有的东西。

Sridharan说，Nomad赢得竞争的原因有：

对现有打包方法的修改最小，兼容Consul服务发现开发者可以制定程序的操作语义“运维大众化”，即不同的程序共享类似的作业文件，无论程序使用什么语言，不管是长时间运行还是批量操作，工程师都可以迅速了解部署的细节操作简单：例如，部署在每个节点上的Nomad仅为一个二进制文件。不过Nomad目前还存在一些问题，包括缺乏访问控制列表（ACL），这个问题可以通过使用入口网关或HAProxy反向代理来解决。其他问题还包括没有配额选项、优先级控制，以及超额请求集群资源等

本文的全文集群调度器可在Medium中查看，Twitter上的讨论可以在这里找到。

查看英文原文：“Cluster Schedulers”: Cindy Sridharan on the Purpose of Schedulers, and Why imgix Chose Nomad