kubernetes核心对象辨析：controller Manager和scheduler的理解与区别

引子

kubernetes中的概念比较多，对入门或理解kubernetes会造成一定的难度，尤其是有些概念有相近之处，更加让初学者摸不着头脑。

所以对于概念之间的联立比较，区别它们之间的异同，对清晰的理解kubernetes中的有关概念有很大的帮助。

controller Manager和scheduler是kubernetes的核心对象，两者都和集群的运行调度、状态维护相关。controller Manager负责维护kubernetes集群的状态，比如故障检测、自动更新等，scheduler负责资源调度，按照预定的策略将pod调度到响应的机器上。两个概念从职能上还是有明显区分的，两个核心对象的深入理解和相互联系是本文的阐述重点。

Controller Manager

Controller Manager概念

Controller Manager 集群内部的管理控制中心，其主要目的是实现Kubernetes集群的故障检测和恢复的自动化工作。通过API Server提供的（List-Watch）接口实时监控集群中特定资源的状态变化，当发生各种故障导致某资源对象的状态变化时，Controller会尝试将其状态调整为期望的状态。比如根据RC的定义完成Pod的复制或移除，以确保Pod实例数符合RC副本的定义；根据Service与Pod的管理关系，完成服务的Endpoints对象的创建和更新；其他诸如Node的发现、管理和状态监控、死亡容器所占磁盘空间及本地缓存的镜像文件的清理等工作也是由Controller Manager完成的。

Controller Manager组成

kubernetes内部几乎每种特定资源都有特定的 Controller 维护管理，每种Controller都负责一种特定资源的控制流程，而Controller Manager正是这些Controller的核心管理者。而 Controller Manager 的职责便是把所有的 Controller 聚合起来进行管理。Controller Manager内部包含了几十种Controller，常用的如下图所示：

K8s中有几十种 Controller，这里列举一些相对重要的Controller：

部署控制器（Deployment Controller）：负责pod的滚动更新、回滚以及支持副本的水平扩容等。
节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。
副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)。
服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌

Controller 工作流程

Controller Manager 主要提供了一个分发事件的能力，而不同的 Controller 只需要注册对应的 Handler 来等待接收和处理事件。

在 Controller Manager 的帮助下，Controller 的逻辑可以做的非常纯粹，只需要实现相应的 EventHandler 即可。以Deployment controller为例：

List & Watch：

Controller manager与api-server的通信主要通过两种方式：List 和 Watch。
List是短连接实现，用于获取该资源的所有object；
Watch是长连接实现，用于监听在List中获取的资源的变换。
api-server检测到资源产生变更时，会主动通知到Controller manager（利用分块传输编码）。

Scheduler

scheduler概念

kubernetes scheduler是集群中的调度器，负责Pod在集群节点中的调度分配。当集群的计算节点非常多时，如何为pod寻找合适的node，这也是Kubernetes调度器的工作职责所在。Kubernetes调度器的输入是再调度的pod,经过一系列算法执行之后，为pod选择了合适的node，其输出对于pod资源对象变化而言，yaml文件里spark node name里添加了一个node的值。

Kubernetes scheduler 的特点：

基于队列的调度器
一次只调度一个Pod
调度时刻全局最优

scheduler调度流程

Kubernetes Scheduler在整个系统中承担了“承上启下”的重要功能，“承上”是指它负责接收Controller Manager创建的新Pod，为其安排一个落脚的“家”—目标Node；“启下”是指安置工作完成后，目标Node上的kubelet服务进程接管后续工作，kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，然后获取对应的Pod清单，下载Image镜像并启动容器。

调度总体上包括两个阶段：过滤（Filtering）+打分（Scoring），随后就是绑定目标节点，完成调度。

过滤阶段：遍历所有目标Node，筛选出符合要求的候选节点。在此阶段，Scheduler会将不合适的所有Node节点全部过滤，只留下符合条件的候选节点。其具体方式是通过一系列特定的Filter对每个Node都进行筛选，筛选完成后通常会有多个候选节点供调度，从而进入打分阶段；如果结果集为空，则表示当前还没有符合条件的Node节点，Pod会维持在Pending状态。
打分阶段：在过滤阶段的基础上，采用优选策略（xxx Priorities）计算出每个候选节点的积分，积分最高者胜出，因为积分最高者表示最佳人选。挑选出最佳节点后，Scheduler会把目标Pod安置到此节点上，调度完成。

kubernetes scheduler调度策略和算法

主要有两类算法：Predicate和Priority。Predicate是对于所有的node进行筛选，滤除不合格的节点，Priority是对于Predicate筛选过的node进行打分，挑选最优的节点。通过Predicate策略筛选符合条件的Node，主要是node上不同的pod会存在资源冲突，Predicate主要的目的是为了避免资源冲突、节点超载、端口的冲突等。

典型Predicate算法

典型Priority算法

controller Manager和scheduler的联系

controller manager和scheduler是相互协同的关系，scheduler将新建的pod根据调度算法安排到某个node上，然后由controller来维护pod的状态，使其与期望的状态保持一致，当然kubernetes中的其他资源对象也有相对应的controller进行状态维护。

用一个创建pod的过程的例子进行描述kubernetes组件之间的功能和联系：

如需要创建3个pod，那整体流程：

1）通过Kubectl提交一个创建RC的请求，该请求通过API Server被写入etcd中

2）此时Controller Manager通过API Server的监听资源变化的接口监听到这个RC事件，分析之后，发现当前集群中还没有它所对应的Pod实例，于是根据RC里的Pod模板定义生成一个Pod对象，通过API Server写入etcd

3）接下来，此事件被Scheduler发现，它立即执行一个复杂的调度流程，为这个新Pod选定一个落户的Work Node，然后通过API Server讲这一结果写入到etcd中

4）随后，目标Work Node上运行的Kubelet进程通过API Server监测到这个“新生的”Pod，并按照它的定义，启动该Pod。

5）用户的需求是3个pod；那到底有没有启动了3个；是由Controller Manager监控管理的，它会保证资源达到用户的需求。