Cindy Sridharan 谈调度器的意义以及为何 imgix 选择了 Nomad

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

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

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

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。