平面设计主要用的软件,郑州seo外包,wordpress视屏类型不受支持,公司图标大全前面我们说到 K8S 的基本原理和涉及的四大组件#xff0c;分享了前两个组件 etcd 和 ApiServer
这一次我们接着分享一波#xff1a;
调度器 scheduler控制器管理器 controller manager
调度器 scheduler
调度器#xff0c;见名知意#xff0c;用于调度 k8s 资源的…前面我们说到 K8S 的基本原理和涉及的四大组件分享了前两个组件 etcd 和 ApiServer
这一次我们接着分享一波
调度器 scheduler控制器管理器 controller manager
调度器 scheduler
调度器见名知意用于调度 k8s 资源的那么这个调度器具体主要是调度啥资源呢
实际上看我们 k8s 中运行的一个一个的 pod这些 pod 在我们创建的时候还记得我们有分享过是可以指定即将要生成的 pod 默认被调度了指定节点吗
一般情况下我们也没有去刻意指定 pod 要调度到哪个节点但是最终 pod 一定会被调度到集群中的某一个节点
实际上这就是调度器在起作用了没错调度器就是调度 pod 资源到对应的节点上
咱们的调度器也是利用了 API 服务器的监听机制来新创建 pod 资源的创建好的 pod 资源会将其调度到资源充足甚至没有 pod 的节点上
那么你是否会认为是调度器直接控制节点来运行指定的 pod nonono并不是这样的前面我们有说到过基本上很多的组件都是通过 ApiServer 来进行处理的
调度器在这里也不例外
这里的是调度器是通过 ApiServer 来更新 pod 的定义然后 ApiServer 再去通知 Kubelet 这个 pod 已经被调度器调度过了这个时候实际对应节点上的 Kubelet 发现自己节点上有 pod 被调度过来那么 kubelet 就会创建并且运行 pod 中的容器
那么 k8s 默认是如何调度 pod 的总有一个优先级吧
是的没错总会有一定的规则咱们画个图来感受一下 例如一开始集群中有 4 个节点在运行过程中节点 2 和 节点 3 变为不可用了接下来若有新的 pod 需要调度那么调度器会从可用的 2 个节点里面选择一个最优的节点
例如磁盘内存空间较大或者 pod 资源个数较少的会按照综合优先级递减排序
例如就会生成 pod 调度到节点 4
那么问题就来了k8s 是如何找到满足需求的可用节点呢
当然 k8s 找到可用节点的条件也是不少了不是随便一个节点就可以接得住的例如 k8s 会检查这些条件
节点的资源是否被耗尽了pod 是否设置了一定要 / 一定不要 调度到某一个节点上如果这个 pod 需要绑定主机的端口那么该节点的端口是否被占用了节点可以满足创建 pod 对应硬件资源的要求吗该节点上有没有和我们即将要创建的 pod 参数和规格一致的标签呢pod 若需要特定的卷该节点支持吗… 等等
以上的条件都必须要满足才有机会将 pod 调度到这个节点上来
我们是否可以设置 pod 全部集中在一个节点或者分散到多个节点中去呢
实际上我们知道管理 pod 的资源是 RS / RC一般情况下 他们会尽可能的将 pod 分散到不同的节点上面但是也不能保证每一次都是这样的
如果我们自己有需求可以在 pod 模板中设置 pod 的亲缘性 和 非亲缘性来设置定pod 调度到哪些符合要求的节点上去
总的来说pod 分散到不同的节点可以降低风险增强健壮性若其中一个节点挂掉并不会应 pod 提供的服务
之前说到 etcd ApiServer 都可以是多个的那么这里的调度器仍然可以是多个若是真的只有一个调度器服务多了之后他也扛不住嘞
我们也可以看到 kube-system 命名空间中 这些核心组件都是以 pod 的方式运行的如果我们需要多个 scheduler那么就多创建几个就好了
但是我们在创建 pod 的时候如果没有指定使用哪一个调度器去调度的话那么 k8s 中会使用默认的调度器如果我们有需求实际可以在 pod 模板中使用 shedulerName 关键字来指定调度器的名字
控制器管理器 controller manager
控制器管理器 controller manager 见名知意他是一个管理器 manager管理的对象是控制器 controller
Replication 管理器我们可以理解为资源管理器也就是我们之前学过的 RC ReplicationController
控制器的话就比较多了之前我们学过的大部分资源都有对应的控制器进行管控例如
Node 控制器Service 控制器Endpoints 控制器Namespace 控制器ReplicaSet 控制器DaemonSet 控制器Job 控制器Deployment 控制器StatefulSet 控制器PersistentVolume 控制器
为啥需要控制器管理器
之前分享的各个组件中他们就好像只管好自己就可以独善其身了总得有一个角色为大家负重前行吧
比如说 ApiServer 只去和 etcd 交互然后通知监听的客户端有变更 调度器 Scheduler 又仅仅是给 pod 分配节点
那么对于资源的扩缩容以及资源的期望状态又谁来进行监听和处理呢
那就得 控制器管理器了
那么我们上述的控制器主要是干啥
首先通过控制器的名字我们应该是知道这些控制器主要是控制自己对应资源的状态的
然而不仅仅是这一点哦控制器做的事情就稍微杂一点综合能力比较强
例如
控制器会监听 ApiServer 资源变更执行相应的操作例如创建编辑删除查看等等
这里的控制器也是不会相互通信的都是和 ApiServer 交互可以理解为 控制器一直在做满足别人期望的事情是一个调和的角色
例如我们将期望的副本数改变了那么控制器便会去处理直到满足期望后将最新的状态写入资源的 status
那么 Replication 管理器又是何方神圣
刚才有说到他是管理控制器的控制器又那么多可以把他看做控制器的管家吧
官方定义启动 ReplicationController 资源的控制器叫做 Replication 管理器
那么对于 RC 的行为我们应该心里都有数吧当修改了 RC 的副本数之后RC 回去调和 pod 的数量
这个实际动作其实是 Replication 管理器 这个幕后大佬做的
之前我们说到 RC 的时候当我们修改这个副本数大家是否会认为 k8s 中会有一个轮询机制当获取到 RC 的副本变化的时候会去满足期望
实际上也是和 ApiServer 那一块分享的类似此处也是用到了监听机制控制器会通过监听机制订阅可能会影响期望副本数的变更事件
若有变更事情时则会做出相应动作
RC 会实际去运行 pod 吗
看到这里是否还会有疑问既然 RC 会去满足期望那么是 RC 直接去运行的 pod 吗
并不是的
当出现当前数量和期望副本数量不一致的时候 RC 回去创建新的 pod 清单并发布到 APiServer 上最终会让调度器和节点上的 Kubelet 来调度 pod 并运行 pod
管理器管理那么多的控制器肯定有一个统一管理资源的管理流程的具体的简单流程如下 简单来说就是 Replication 管理器会监听具体的资源然后通过 ApiServer 来操作对应的资源对象最终达到更新的目的
当然其他控制器也是这样的都是监听资源通过 ApiServer 进行更新资源
每一种控制器实际上我们在分享到其对应资源的时候基本都有分享到他们的行为这里就不再重复了
今天就到这里学习所得若有偏差还请斧正
欢迎点赞关注收藏
朋友们你的支持和鼓励是我坚持分享提高质量的动力 好了本次就到这里
技术是开放的我们的心态更应是开放的。拥抱变化向阳而生努力向前行。
我是阿兵云原生欢迎点赞关注收藏下次见~
更多的可以查看 零声每晚八点直播https://ke.qq.com/course/417774
