[k8s理论知识]6.k8s调度器

k8s默认调度器

k8s调度器的主要职责,就是为一个新创建出来的pod寻找一个适合的节点Node。这包括两个步骤,第一,从所有集群的节点中,根据调度算法挑选出所有可以运行该pod的节点,第二,从第一步的结果中,根据调度算法挑选一个最符合条件的pod作为最终结果。

所以在具体的调度流程中,默认调度器会首先调用一组叫作 Predicate 的调度算法,来检查每个 Node。然后,再调用一组叫作 Priority 的调度算法,来给上一步得到的结果里的每个 Node 打分。最终的调度结果,就是得分最高的那个 Node。

cache化

为了高效的完成调度过程,调度器必须要频繁的查询集群的状态信息,如节点的资源使用情况,节标签、污点等等。这些操作每次都从etcd中获取数据,会导致性能瓶颈。为了解决这个问题,Kubernetes 引入了调度器缓存(scheduler cache)。调度器缓存是一个内存中的数据结构,用于存储集群的节点信息和其他相关元数据。通过将这些信息缓存起来,调度器可以更快地访问和处理这些数据,从而提高调度算法的执行效率。

通过将集群信息尽可能的缓存化,可以提高k8s的调度效率,提高性能。通过将节点信息和其他元数据缓存到内存中,调度器可以减少对 etcd 的直接访问次数,从而降低网络延迟和 I/O 开销。

从上图可以看出,第一个控制循环informer Path的主要目的就是启动一系列的informer,用来监听etcd中的pod、node、service等与调度相关的API对象的变化,如果有调度需求,就将这个pod加入调度队列,这个调度队列是一个优先级队列。调度器还要负责对调度器缓存进行更新(update cache)。

第二个控制循环是负责Pod调度的主循环,叫做scheduling path。Scheduling Path 的主要逻辑,就是不断地从调度队列里出队一个 Pod。然后,调用 Predicates 算法进行"过滤"。这一步"过滤"得到的一组 Node,就是所有可以运行这个 Pod 的宿主机列表。当然,Predicates 算法需要的 Node 信息,都是从 Scheduler Cache 里直接拿到的,这是调度器保证算法执行效率的主要手段之一。接下来,调度器就会再调用 Priorities 算法为上述列表里的 Node 打分,分数从 0 到 10。得分最高的 Node,就会作为这次调度的结果。执行完调度算法之后,调度器就需要将 Pod 对象的 nodeName 字段的值,修改为上述 Node 的名字。这个步骤在 Kubernetes 里面被称作 Bind。

乐观绑定

当进行到上面说的修改nodeName的时候,其实pod还没有被部署到这个节点。但是这个时候scheduler就已经把这个调度信息写入到scheduler cache中了。然后再异步的向API server发起更新pod的请求,以真正的完成bind操作。这种设计被称为乐观假设。

这是因为如果选定node名称之后,发起同步的API server通信等待响应,会显著增加调度器的延迟。通过异步绑定,调度器可以在确定合适节点后立即更新调度器缓存,然后继续处理下一个 Pod 的调度,而不需要等待 API Server 的响应。这大大减少了关键路径上的延迟,提高了调度器的吞吐量。

如果调度失败的话,scheduler cache中写入的内容也会在与etcd更新的时候进行修正,并不会使集群的信息不同步。

admit操作

由于乐观绑定的操作,当一个新的 Pod 完成调度需要在某个节点上运行起来之前,该节点上的 kubelet 还会通过一个叫作 Admit 的操作来再次验证该 Pod 是否确实能够运行在该节点上。Admit 操作会重新执行一组最基本的调度算法,如"资源是否可用"、"端口是否冲突"等,作为 kubelet 端的二次确认。

无锁化

调度器会启动多个 Goroutine,以节点为粒度并发执行 Predicates 算法。这样可以并行地检查多个节点是否满足 Pod 的调度要求,从而显著提高这一阶段的执行效率。在并发编程中,锁是一种常用的同步机制,用于确保多个 Goroutine 之间对共享资源的访问是安全的。比如说多个goroutine可能会同时的向队列中加入或移除pod,或是同时操作scheduler cache。然而,锁的使用会带来一定的性能开销,特别是在高并发场景下。

为了增加predicate过程的速度,调度器采用了无锁化设计,在这些并发路径上,调度器避免设置任何全局的竞争资源,从而避免了没有锁带来的状态难以管理的问题。

默认调度器的重构

随着 Kubernetes 项目的逐步稳定,越来越多的用户开始将其应用于规模更大、业务更加复杂的私有集群中。在这些复杂场景下,用户对默认调度器的扩展和重新实现提出了更高的需求。社区对 Kubernetes 项目的主要诉求之一就是增强默认调度器的可扩展性。

下图是默认调度器的可扩展性设计的示意图。可以看到在调度器生命周期的各个关键点上,为用户暴露出了可以扩展和实现的接口。每一个绿色的箭头都是一个可以插入自定义逻辑的接口。比如,上面的 Queue 部分,就意味着你可以在这一部分提供一个自己的调度队列的实现,从而控制每个 Pod 开始被调度(出队)的时机。

在 Kubernetes 的整体架构中,kube-scheduler 的责任虽然重大,但其实它却是在社区里最少受到关注的组件之一。这里的原因也很简单,调度这个事情,在不同的公司和团队里的实际需求一定是大相径庭的,上游社区不可能提供一个大而全的方案出来。所以,将默认调度器进一步做轻做薄,并且插件化,才是 kube-scheduler 正确的演进方向。

相关推荐
罗狮粉 9932 分钟前
docker部署微信小程序自动构建发布和更新
docker·微信小程序·notepad++
旺仔学IT34 分钟前
CentOS上安装和卸载Docker
docker·centos
前端_库日天1 小时前
部署自己的git托管平台
git·ubuntu·docker
西西弗Sisyphus2 小时前
RAGFlow 基于深度文档理解构建的开源 RAG引擎 - 在 Ubuntu 上安装 Docker Engine
docker·大模型·rag
AKA小徐4 小时前
Debian12使用RKE2离线部署3master2node三主两从的k8s集群详细教程
kubernetes·rancher·rke2
@泽栖8 小时前
Docker 常用命令
运维·服务器·docker
鲁正杰10 小时前
在一个服务器上抓取 Docker 镜像并在另一个服务器上运行
运维·服务器·docker
老大白菜11 小时前
Windows 11 安装 Dify 完整指南 非docker环境
windows·docker·容器
VinciYan14 小时前
基于Jenkins+Docker的自动化部署实践——整合Git与Python脚本实现远程部署
python·ubuntu·docker·自动化·jenkins·.net·运维开发
tntlbb15 小时前
Ubuntu20.4 VPN+Docker代理配置
运维·ubuntu·docker·容器