Kubernetes调度器¶
在 Kubernetes概览 已经初步介绍了Kubernetes组件的关系，其中提到了Kubernetes Scheduler调度器工作原理：调度器通过Kubernetes的监视(Watch)机制来发现Controller Manager新创建的但是尚未调度到Node上的Pod。调度器会将发现的每一个未调度的Pod调度到合适的Node上运行。
kube-scheduler¶
kube-scheduler是Kubernetes集群默认调度器。如果有需求，Kubernetes设计是可以允许自己写一个调度组件并替换原有的kube-scheculer。
在一个集群中，所有满足Pod调度的节点(Node)被称为 可调度节点 。如果没有任何一个节点满足Pod的资源请求，那么这个Pod将一直停留在Pending(未调度)状态直到直到能够找到合适的节点。
调度器会在集群中找到一个Pod的所有可调度节点，然后通过一系列函数对这些可调度节点打分，选出最高得分的节点来运行Pod。然后调度器会将这个调度决定通知给kube-apiserver，整个过程称为绑定(binding)。
调度据测的考虑因素有：
单独和整体的资源要求
硬件/软件/策略限制
亲和以及反亲和要求 将Pod分配给节点
数据局限性(data locality)
负载间的干扰
等等
kube-
为什么调度系统不支持横向扩展架构¶
你可能会注意到几乎所有的集群调度系统都不支持横向扩展(scale out)：例如，Hadoop MRv1早期是单一节点，集群最大规模是5000台主机。在YARN资源管理集群，依然有2个调度器，但是只有主调度器工作，另一个是备份，则最大管理服务器规模是10000台。在Mosos中通过优化，一个集群最大可以管理80000台。在Kubernetes 1.13则最大管理集群节点是5000台。
这是因为集群调度系统不能扩展导致的，要管理更多服务器只有创建多个集群。
为什么在Kubernetes集群中，即使部署了多个scheduler(通常我们会部署3个)，但也只有一个scheduler是真正工作状态？常见的Internet应用程序通常都使用某种分布式技术来横向扩展，以便实现更大规模。
对于电子商务系统，很容易实现scale-out的横向扩展架构：
这是因为进入订单可以负载均衡放置到队列中(注意，这个队列是一个概念，实际上可以由消息队列程序构建，也可以由关系型数据库锁实现)，由后端的订单处理进行匹配后就能从无依赖资源池取出处理。
请注意，在电商系统中，每个商品就是一个完全独立的资源池，购买「乔布斯传」和购买「黑客与画家」的订单系统是完全独立的（相互无依赖也不干扰）。
集群调度系统”无依赖资源池”只有一个¶
回到集群调度系统，就会看到，每个服务器节点就是一个资源，当自全请求发来时候，是需要将整个集群视为一个完整的集群资源池来使用，也就是不能分割：
调度系统需要全局检查整个集群资源来找到最优匹配资源服务器
对于多个调度器系统，则需要同步整个集群资源池的变化
这个设计就导致类似Oracle RAC系统，即使创建了多个调度服务器，也必须使用共享的资源池索引信息库来实现同步，所以锁开销会非常大，也非常难以实现横向扩展。