Cluster Schedulers

note： 此新闻是几万字原文的总结。全本原文地址：https://medium.com/@cindysridharan/schedulers-kubernetes-and-nomad-b0f2e14a896

原文又臭又长，删节版也没好到哪去。

摘要： Imgix的工程师Cindy Sridharan对使用容器调度器的目的、使用时的挑战等方面进行了深入讨论，并建议使用Nomad作为调度器。

作者： Cindy Sridharan

正文：

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的方案可以解决组织现实中遇见的眼下的问题。

容器调度器由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的网络问题7，imgix最终没有选择Kubernetes。Nomad可以部署多种程序，包括静态连接的二进制包；同时，Nomad与服务发现程序Consul良好兼容（imgix的技术栈依赖Consul）。

在选择新技术，特别是运行技术时的重要原则是选择可以无缝加入现有架构的技术，这样对现有可用架构的修改最少。

Sridharan说，Nomad赢得竞争的原因有：
- 对现有打包方法的修改最小，兼容Consul服务发现；
- 开发者可以制定程序的操作语义;
- "操作民主化"，即不同的程序共享类似的工作文件（job file），无论程序使用什么语言，是长时间运行还是批量操作：这样工程师可以迅速理解如何部署。
- 操作简单：例如，每个节点的Nomad仅为一个二进制文件。
Nomad的问题包括缺乏访问控制列表（ACL），这个问题可以用入站防火墙或HAProxy这种反向代理解决。其他问题包括没有配额选项、优先级控制，以及超额请求集群资源等。

本文的全文，集群调度器可在Medium查看，Twitter的讨论串在此。

查看英文原文：Cluster Schedulers