k8s集群调度

一、概述

Kubernetes是通过 List-Watch的机制进行每个组件的协作，保持数据同步的，每个组件之间的设计实现了解耦。
用户是通过 kubectl根据配置文件，向 APIServer 发送命令，在 Node节点上面建立 Pod和 Container。
APIServer经过 API调用，权限控制，调用资源和存储资源的过程，实际上还没有真正开始部署应用。这里需要Controller Manager、Scheduler和kubelet 的协助才能完成整个部署过程。

在 Kubernetes 中，所有部署的信息都会写到 etcd 中保存。实际上 etcd 在存储部署信息的时候，会发送Create 事件给APIServer，而APIServer 会通过监听(watch)eted 发过来的事件。其他组件也会监听（Watch)APIServer 发出来的事件。

二、Pod启动典型创建过程

(1)这里有三个 List-Watch，分别是Controller Manager(运行在Master), Scheduler(运行在Master), kubelet (运行在Node）。他们在进程已启动就会监听（watch）APIServer 发出来的事件。

(2)用户通过 kubectl 或其他 API客户端提交请求给APIServer 来建立一个 Pod对象副本。

(3) APIServer尝试着将Pod对象的相关元信息存入eted 中，待写入操作执行完成，APIServer即会返回确认信息至客户端。

(4）当etcd 接受创建 Pod信息以后，会发送一个Create事件给APIServer。

(5)由于Controller Manager一直在监听(watch，通过http的8080端口)APTIServer 中的事件。此时 APTServer接受到了Create事件，又会发送给Controller Manager。

(6)Controller Manager 在接到create事件以后，调用其中的 Replication Controller来保证Node上面需要创建的副本数量。一旦副本数量少于RC 中定义的数量，RC 会自动创建副本。总之它是保证副本数量的Controller (PS:扩容缩容的担当)。

(7)在Controller Manager创建 Pod副本以后，APIServer 会在 etcd中记录这个 Pod 的详细信息。例如 Pod的副本数，Container 的内容是什么。

(8)同样的etcd会将创建Pod 的信息通过事件发送给APIServer。

(9)由于Scheduler 在监听（watch)APIServer，并且它在系统中起到了"承上启下"的作用，"承上"是指它负责接收创建的 Pod事件，为其安排 Node;“启下"是指安置工作完成后，Node 上的 kubelet进程会接管后继工作，负责 Pod生命周期中的"下半生”。换句话说，Scheduler 的作用是将待调度的 Pod按照调度算法和策略绑定到集群中 Node 上。

(10)Scheduler调度完毕以后会更新Pod 的信息，此时的信息更加丰富了。除了知道 Pod的副本数量，副本内容。还知道部署到哪个Node 上面了。并将上面的 Pod 信息更新至API Server，由 APIServer更新至etcd中，保存起来。

(11) etcd 将更新成功的事件发送给 APIServer，APIServer也开始反映此 Pod对象的调度结果。

(12) kubelet 是在 Node .上面运行的进程，它也通过List-Watch的方式监听(@atch，通过https的6443端口）APIServer 发送的Pod更新的事件。kubelet 会尝试在当前节点上调用Docker 启动容器，并将 Pod以及容器的结果状态回送至APIServer。

(13）APIServer将Pod状态信息存入etcd中。在 etcd确认写入操作成功完成后，APTIServer将确认信息发送至相关的kubelet，事件将通过它被接受。

注意:
在创建 Pod的工作就已经完成了后，为什么 kubelet还要一直监听呢?原因很简单，假设这个时候kubectl发命令，要扩充Pod副本数量，那么上面的流程又会触发一遍，kubelet 会根据最新的 Pod 的部署情况调整Node 的资源。又或者Pod副本数量没有发生变化，但是其中的镜像文件升级了，kubelet也会自动获取最新的镜像文件并且加载。

三、调度过程

Scheduler 是 kubernetes的调度器，主要的任务是把定义的 pod分配到集群的节点上。其主要考虑的问题如下:

●公平:如何保证每个节点都能被分配资源
●资源高效利用:集群所有资源最大化被使用
●效率:调度的性能要好，能够尽快地对大批量的 pod 完成调度工作
●灵活:允许用户根据自己的需求控制调度的逻辑

Sheduler 是作为单独的程序运行的，启动之后会一直监听 APIServer，获取 spec.nodeName 为空的 pod，对每个pod都会创建一个binding，表明该pod 应该放到哪个节点上。

调度分为几个部分
首先是过滤掉不满足条件的节点，这个过程称为预算策略(predicate):然后对通过的节点按照优先级排序，这个是优选策略(priorities)﹔最后从中选择优先级最高的节点。如果中间任何一步骤有错误，就直接返回错误。

Predicate 有一系列的常见的算法可以使用:
(1)PodFitsResources:节点上剩余的资源是否大于pod 请求的资源。
(2)PodFitsHost:如果 pod 指定了NodeName，检查节点名称是否和NodeName匹配。
(3)PodFitsHostPorts:节点上已经使用的port是否和pod 申请的port 冲突。
(4)PodSelectorMatches:过滤掉和 pod指定的 label不匹配的节点。
(5)NoDiskConflict:已经mount的 volume和 pod 指定的 volume 不冲突，除非它们都是只读。

如果在 predicate过程中没有合适的节点，pod 会一直在 pending 状态，不断重试调度，直到有节点满足条件。经过这个步骤，如果有多个节点满足条件，就继续 priorities过程:按照优先级大小对节点排序。

优先级
优先级由一系列键值对组成，键是该优先级项的名称，值是它的权重（该项的重要性)。有一系列的常见的优先级选项包括:

(1)LeastReq