weixin_42663840的博客

​需要强调的是，本文的污点指的是NoExecute污点，这种污点会驱逐已经运行的pod，这可以从NoExecute字面意思看的出来。《kube-scheduler调度插件》的TaintToleration在Filter阶段会过滤掉pod无法容忍的NoSchedule和NoExecute污点，也就是说调度器不会调度pod到无法容忍污点node上，那NodeLifecycleController管理还要管理NoExecute干什么呢？道理很简单，node的污点会更新，pod的容忍度也会更新，调度器不会因为no

利用SharedIndedInformer过滤未调度的Pod放入调度队列 利用SharedIndexInformer过滤已调度的Pod更新调度缓存 从调度队列取出一个待调度的Pod，通过Pod.Spec.SchedulerName获取调度框架 调度框架是配置好的调度插件集合，既可以通过扩展调度插件的方式扩展调度能力，也可以通过调度扩展器 调度算法利用调度缓存的快照以及输入的调度框架，为Pod选择最优的节点 如果调度算法执行失败，将Pod放入调度队列的不可调度自队列；如果调度算法执行成功，通知调度缓

前言调度器配置中解析了kube-scheduler的各种配置，但是自始至终都没有看到如何根据配置构造调度器。虽然调度器文章中提到了构造函数，但是其核心实现是Configurator，本文将解析Configurator构造调度器的过程。虽然意义远没有调度队列、调度框架、调度插件等重大，但是对于了解调度器从生到死整个过程来说是必要一环，况且确实能学到点东西。ConfiguratorConfigurator定义Configurator类似于Scheduler的工厂，但是一般的工厂类很少会有这么多的

前言kube-scheduler如何配置调度框架和调度插件中提到的插件（比如使能或禁止哪些插件？）？如何配置调度队列的排序函数以及退避时间？本文将详细解析kube-scheduler的配置，在kube-scheduler中，配置也是一种API对象（其实在Kubernetes中都是这种设计，万物皆可API化），它被定义在k8s.io/kubernetes/pkg/scheduler/apis/config包中。本文引用源码为kubernetes的release-1.21分支。KubeSchedul

前言调度算法只对调度周期从PreFilter到Score扩展点进行抽象和实现，那么调度算法又是如何与其他扩展点配合实现Pod的调度呢？这就是本文重点解析的内容，kube-scheduler定义了Scheduler类型，它实现了调度Pod的全流程。本文引用源码为kubernetes的release-1.21分支。SchedulerScheduler定义Scheduler要想实现调度一个Pod的全流程，那么必须有调度队列、调度缓存、调度框架、调度插件、调度算法等模块的支持。所以，Schedu

前言调度框架和调度插件将调度流程抽象为若干的阶段，每个阶段称之为一个扩展点，也就是用户可以在每个阶段扩展自定义的调度插件。由于调度框架和调度插件相对比较复杂，如果将调度视为一种接口(interface)，那么输入应该是一个Pod和全量的Node，输出是为Pod分配的节点。至于接口的使用者就可以弱化调度框架和调度插件的概念，这是一种友好且通用的抽象。再者，Pod.Spec.SchedulerName可以选择调度框架来调度该Pod，虽然不同的Pod的调度框架有所不同，但是调用调度插件的流程大部分都是一致

前言kube-scheduler基于Kubernetes管理的资源（比如CPU、内存、PV等）进行调度，但是，当需要对在Kubernetes外部管理的资源进行调度时，在Extender之前没有任何机制可以做到这一点。有一种方法可以让kubernetes具有扩展性，就是增加HTTP调度扩展程序。有三种方法可以向kube-scheduler添加新的调度规则：更新现有的或添加新的调度插件并重新编译，这个在调度插件和调度框架可以找到答案； 开发一个自定义的kube-scheduler，该进程可代替标准

前言在阅读本文之前，建议先看看调度框架官方文档和调度框架设提案，也有必要先看看调度插件，便于理解本文内容。本文提取以官方文档中笔者认为比较重要的信息，并做了批注：kubernetes-scheduler已添加了许多功能，这使得代码越来越大，逻辑也越来越复杂。一个复杂的调度程序很难维护，其错误也很难找到和修复，并且那些自己修改调度程序的用户很难赶上并集成新的版本更新。当前kube-scheduler提供了webhooks来扩展器功能(Extender)，但是能力有限。调度器功能越来越复杂，很难维护

前言下图是维基百科关于Plug-in (computing)示例插件框架，关于插件机制实现的原理不了解的读者可以看看，本文不赘述了。但是上图中几个知识点本文会提及，所以此处重点说明一下：宿主应用(Host Application): kube-scheduler就是宿主应用，因为所有插件都是给kube-scheduler使用的。 插件管理器(Plugin Manager): 原理上讲Scheduling Profile(后文会有介绍)充当了插件管理器的角色，因为它可以配置使能/禁止插件的.

前言笔者在《kube-scheduler的SchedulingQueue解析》的文章中提到了PodNominator，因为调度队列继承了PodNominator，但是当时为了避免不必要的内容扩展，并没有对PodNominator做任何说明。本文将对PodNominator做较全面的解析，从它的定义、实现直到在kube-scheduler中的应用。本文采用的Kubenetes源码的release-1.20分支。PodNominator的定义首先需要了解PodNominator到底是干啥的，英文

前言在阅读本文之前，建议从《kube-scheduler的SchedulingQueue解析》开始，因为笔者是以调度队列为突破口开始逐步深入的解析kube-scheduler的源码实现。在《kube-scheduler的SchedulingQueue解析》已经总结了，调度队列（SchedulingQueue）中都是Pending状态的Pod，也就是为调度的Pod。而本文分析的Cache中都是已经调度的Pod（更准确的说。。。），Cache是kube-scheduler的调度状态。Cache//

前言到今天为止，笔者从事集群调度领域大约有7年多。突然想看看kubernetes的调度器是如何实现的，主要还是抱着学习的态度，看看kubernetes的调度实现在自己的工作中是否有可借鉴的地方。调度设计一般缺少不了队列的设计，好的队列设计会让调度事半功倍。所以本文以调度队列为突破口，研究调度队列的设计与实现，为后续深入理解调度器的实现做准备。理解调度队列的设计，多半都能推导出调度器的实现，因为调度器的本质就是从队列中取出、决策（放置）然后再送到另一个队列的过程。有一点读者需要知道，虽然kuber

摘要在云规模的计算群集上有效地调度数据并行计算作业对于作业性能、系统吞吐量和资源利用率至关重要。随着集群规模和具有各种特征的更复杂的workload的增长，这变得越来越具有挑战性。本文介绍了Apollo，这是一种高度可扩展协同调度框架，已部署到Microsoft的生产集群上，可每天高效地在数万台计算机上调度数以千计的计算（数百万个任务）。该框架通过松散协调的机制利用全局群集信息以分布式方式执行调度决策。每个调度决策都会考虑未来的资源可用性，并在一个统一的模型中一起优化各种性能和系统因素。Apollo具有

1.摘要大型数据分析框架正在朝着缩短任务执行时间和提高并行度的方向发展来提供低延迟，任务调度器面临的主要挑战是在几百毫秒内完成高度并行的作业调度，这需要在合适的机器上每秒调度数百万个任务，同时提供毫秒级的延迟和高可用性。本文证明了去中心化、随机抽样方法可提供最佳性能，同时避免了中心化设计存在吞吐量和高可用的问题。本文在110台计算机集群上部署Sparrow，并证明Sparrow的性能与理想的调度程序的误差在12%以内。2.介绍当今的数据分析集群运行的时间越来越短，作业的任务越来越多。在对低延迟交

目录前言摘要1.介绍2.动机3.分配特性4.主导资源公平（DRF）4.1举个栗子4.2DRF调度算法4.3加权DRF5.可选的公平分配策略5.1资产公平5.2收入均等的竞争均衡(CEEI)5.3与DRF比较6.分析6.1公平性6.1.1资产公平不具备的特性6.1.2CEEI不具备的特性6.1.3资源单调性VS共享激励和帕累托最...