原文：http://www.firmament.io/blog/...集群调度器是现代基础设施中非常重要的组件，尤其是近几年有了很大的发展。该架构已经从单一的应用程序设计演变为更加灵活、去中心化和分布式的设计。然而，目前，许多开源应用程序仍然是单体应用程序或缺乏关键功能。这些功能对现实世界的用户很重要，因为它们需要高使用率。这是我们关于大型集群任务调度系列的第一篇文章，亚马逊、谷歌、Facebook、微软或雅虎都在实际使用这些集群。调度是一个重要的话题，因为它直接影响集群的运行成本：一个糟糕的调度器会导致极低的利用率，让昂贵的机器闲置，造成资金浪费。集群本身的高利用率并不容易：除非做出谨慎的决定，否则负载会相互影响。架构演进本文讨论调度架构在最近几年是如何演进的，以及为什么会发生这种情况。图1可视化了这些不同的方式：灰色方块代表机器，圆圈代表任务，标有S的成员代表调度程序。箭头代表调度程序做出的决策，三种颜色代表不同类型的工作负载（例如，Web服务、批处理分析、机器学习）。许多集群调度器——例如高性能计算(HPC)调度器、Borg调度器、早期的Hadoop调度器和Kubernetes调度器——都是单体的。单例调度进程在一台机器上冒泡（比如Hadoop的第一版JobTracker，Kubernetes的kube-scheduler），为机器调度任务。所有工作负载都由同一个调度程序处理，所有任务都运行相同的调度逻辑（图1a）。这种简单性和统一性导致了越来越复杂的调度程序。例如，看一下Paragon和Quasar调度程序，它们使用机器学习来避免资源上的工作负载调度冲突。今天许多集群运行许多不同类型的应用程序（在早期只有HadoopMapReduce作业在运行）。因此，由于以下原因，维护单个调度程序实现来处理混合工作负载是很棘手的：显然，我们希望调度程序以不同方式处理长期服务任务和批处理分析任务。不同的应用程序有不同的要求，要支持所有这些需要向调度程序添加许多功能，增加逻辑和实现的复杂性。调度器处理任务的顺序成为一个问题：排队效应（队头阻塞）和积压问题需要仔细设计调度器。总而言之，这听起来像是一场工程噩梦——调度程序开发人员将收到无穷无尽的功能请求。本文来自微信公众号《麦芽面包》，id“darkjune_think”转载请注明。微信扫一扫关注公众号。交流邮箱：zhukunrong@yeah.net
