侧边栏壁纸
博主头像
问道

问道的小花园,总能给你带来惊喜

  • 累计撰写 33 篇文章
  • 累计创建 22 个标签
  • 累计收到 3 条评论

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

问道
2022-08-28 / 0 评论 / 0 点赞 / 283 阅读 / 3,248 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2022-08-28,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

引子

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),随后就是绑定目标节点,完成调度。

  1. 过滤阶段:遍历所有目标Node,筛选出符合要求的候选节点。在此阶段,Scheduler会将不合适的所有Node节点全部过滤,只留下符合条件的候选节点。其具体方式是通过一系列特定的Filter对每个Node都进行筛选,筛选完成后通常会有多个候选节点供调度,从而进入打分阶段;如果结果集为空,则表示当前还没有符合条件的Node节点,Pod会维持在Pending状态。
  2. 打分阶段:在过滤阶段的基础上,采用优选策略(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监控管理的,它会保证资源达到用户的需求。

0

评论区