没有合适的资源?快使用搜索试试~ 我知道了~
Kubernetes 资源拓扑感知调度优化.doc
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 63 浏览量
2022-07-09
22:53:24
上传
评论
收藏 1.56MB DOC 举报
温馨提示
试读
16页
Kubernetes 资源拓扑感知调度优化.doc
资源推荐
资源详情
资源评论
Kubernetes 资源拓扑感知调度优化
笔者
星辰算力团队,星辰算力平台基于深入优化云原生统一接入和多云调度,加固容器运行态
隔离,挖掘技术增量价值,平台承载了腾讯内部的 CPU 和异构算力服务,是腾讯内部大规
模离线作业、资源统一调度平台。
背景
问题源起
近年来,随着腾讯内部自研上云项目的不断发展,越来越多的业务开始使用云原生方式托
管自己的工作负载,容器平台的规模因此不断增大。以 Kubernetes 为底座的云原生技术极
大推动了云原生领域的发展,已然成为各大容器平台事实上的技术标准。在云原生场景下,
为了最大化实现资源共享,单台宿主机往往会运行多个不同用户的计算任务。如果在宿主机
内没有进行精细化的资源隔离,在业务负载高峰时间段,多个容器往往会对资源产生激烈的
竞争,可能导致程序性能的急剧下降,主要体现为:
资源调度时频繁的上下文切换时间
频繁的进程切换导致的 CPU 高速缓存失效
因此,在云原生场景下需要针对容器资源分配加以精细化的限制,确保在 CPU 利用率较
高时,各容器之间不会产生激烈竞争从而引起性能下降。
调度场景
腾讯星辰算力平台承载了全公司的 CPU 和 GPU 算力服务,拥有着海量多类型的计算资
源。当前,平台承载的多数重点服务偏离线场景,在业务日益增长的算力需求下,提供源源
不断的低成本资源,持续提升可用性、服务质量、调度能力,覆盖更多的业务场景。然而,
Kubernetes 原生的调度与资源绑定功能已经无法满足复杂的算力场景,亟需对资源进行更
加精细化的调度,主要体现为:
Kubernetes 原生调度器无法感知节点资源拓扑信息导致 Pod 生产失败
kube-scheduler 在调度过程中并不感知节点的资源拓扑,当 kube-scheduler 将 Pod 调度
到某个节点后,kubelet 如果发现节点的资源拓扑亲和性要求无法满足时,会拒绝生产该
Pod,当通过外部控制环(如 deployment)来部署 Pod 时,则会导致 Pod 被反复创建-->
调度-->生产失败的死循环。
基于离线虚拟机的混部方案导致的节点实际可用 CPU 核心数变化
面对运行在线业务的云主机平均利用率较低的现实,为充分利用空闲资源,可将离线虚拟
机和在线虚拟机混合部署,解决公司离线计算需求,提升自研上云资源平均利用率。在保证
离线不干扰在线业务的情况下,腾讯星辰算力基于自研内核调度器 VMF 的支持,可以将
一台机器上的闲时资源充分利用起来,生产低优先级的离线虚拟机。由于 VMF 的不公平
调度策略,离线虚拟机的实际可用核心数受到在线虚拟机的影响,随着在线业务的繁忙程度
不断变化。因此,kubelet 通过 cadvisor 在离线宿主机内部采集到的 CPU 核心数并不准
确,导致了调度信息出现偏差。
资源的高效利用需要更加精细化的调度粒度
kube-scheduler 的职责是为 Pod 选择一个合适的 Node 完成一次调度。然而,想对资源进
行更高效的利用,原生调度器的功能还远远不够。在调度时,我们希望调度器能够进行更细
粒度的调度,比如能够感知到 CPU 核心、GPU 拓扑、网络拓扑等等,使得资源利用方式
更加合理。
预备知识
cgroups 之 cpuset 子系统
cgroups 是 Linux 内核提供的一种可以限制单个进程或者多个进程所使用资源的机制,
可以对 CPU、内存等资源实现精细化的控制。Linux 下的容器技术主要通过 cgroups 来实
现资源控制。
在 cgroups 中,cpuset 子系统可以为 cgroups 中的进程分配独立的 CPU 和内存节点。
通过将 CPU 核心编号写入 cpuset 子系统中的 cpuset.cpus 文件中或将内存 NUMA 编号写
入 cpuset.mems 文件中,可以限制一个或一组进程只使用特定的 CPU 或者内存。
幸运的是,在容器的资源限制中,我们不需要手动操作 cpuset 子系统。通过连接容器运
行时(CRI)提供的接口,可以直接更新容器的资源限制。
// ContainerManager contains methods to manipulate containers managed by a
// container runtime. The methods are thread-safe.
type ContainerManager interface {
// ......
// UpdateContainerResources updates the cgroup resources for the container.
UpdateContainerResources(containerID string, resources
*runtimeapi.LinuxContainerResources) error
// ......
}
NUMA 架构
非统一内存访问架构(英语:Non-uniform memory access,简称 NUMA)是一种为多处
理器的电脑设计的内存架构,内存访问时间取决于内存相对于处理器的位置。在 NUMA
下,处理器访问它自己的本地内存的速度比非本地内存(内存位于另一个处理器,或者是处
理器之间共享的内存)快一些。现代多核服务器大多采用 NUMA 架构来提高硬件的可伸缩
性。
从图中可以看出,每个 NUMA Node 有独立的 CPU 核心、L3 cache 和内存,NUMA Node
之间相互连接。相同 NUMA Node 上的 CPU 可以共享 L3 cache,同时访问本 NUMA Node
上的内存速度更快,跨 NUMA Node 访问内存会更慢。因此,我们应当为 CPU 密集型应
用分配同一个 NUMA Node 的 CPU 核心,确保程序的局部性能得到充分满足。
Kubernetes 调度框架
Kubernetes 自 v1.19 开始正式稳定支持调度框架,调度框架是面向 Kubernetes 调度器的
一种插件架构,它为现有的调度器添加了一组新的“插件”API,插件会被编译到调度器之中。
这为我们自定义调度器带来了福音。我们可以无需修改 kube-scheduler 的源代码,通过实
现不同的调度插件,将插件代码与 kube-scheduler 编译为同一个可执行文件中,从而开发
出自定义的扩展调度器。这样的灵活性扩展方便我们开发与配置各类调度器插件,同时无需
修改 kube-scheduler 的源代码的方式使得扩展调度器可以快速更改依赖,更新到最新的社
区版本。
调度器的主要扩展点如上图所示。我们扩展的调度器主要关心以下几个步骤:
PreFilter 和 Filter
这两个插件用于过滤出不能运行该 Pod 的节点,如果任何 Filter 插件将节点标记为不可行,
该节点都不会进入候选集合,继续后面的调度流程。
PreScore、Score 和 NormalizeScore
这三个插件用于对通过过滤阶段的节点进行排序,调度器将为每个节点调用每个评分插件,
最终评分最高的节点将会作为最终调度结果被选中。
Reserve 和 Unreserve
这个插件用于在 Pod 真正被绑定到节点之前,对资源做一些预留工作,保证调度的一致
性。如果绑定失败则通过 Unreserve 来释放预留的资源。
Bind
这个插件用于将 Pod 绑定到节点上。默认的绑定插件只是为节点指定 spec.nodeName 来
完成调度,如果我们需要扩展调度器,加上其他的调度结果信息,就需要禁用默认 Bind 插
件,替换为自定义的 Bind 插件。
剩余15页未读,继续阅读
资源评论
书博教育
- 粉丝: 1
- 资源: 2834
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功