—01 —
如何理解 Kubernetes 中动态资源?
要理解 Kubernetes 中的“动态资源”,需要区分传统资源管理方式和 Kubernetes 的创新之处。传统方式通常是静态分配资源,而 Kubernetes 引入了多种机制来实现资源的动态管理,从而更好地适应不断变化的应用程序需求。
众所周知,在传统的虚拟化或裸金属环境中,资源分配通常是静态的。通常情况下,管理员预先为应用程序分配固定的 CPU、内存、存储等资源,这些资源在应用程序运行期间保持不变。这种方式存在以下局限性:
1、资源浪费: 如果应用程序的负载波动较大,静态分配的资源可能在低峰时闲置,造成浪费。
2、弹性不足: 当应用程序需要更多资源时,静态分配无法快速响应,可能导致性能下降甚至服务中断。
3、管理复杂: 对于大规模部署和复杂的应用程序,静态资源管理变得非常繁琐。
为了解决上述痛点以及面对不断新颖的业务需求场景,动态资源的概念便应运而生。
其实,围绕着 Kubernetes 历史发展,其已经通过多种机制实现了资源的动态管理,主要包括以下几个方面:
1、资源请求和限制(Requests and Limits): 在 Pod 规范中,可以定义容器的资源请求(Requests)和限制(Limits)。Requests 指定容器运行所需的最小资源量,Kubernetes 调度器会根据 Requests 来选择合适的节点。Limits 指定容器可以使用的最大资源量,防止容器过度使用资源影响其他应用。虽然 Requests 和 Limits 是静态配置的,但它们为后续的动态调整奠定了基础。
2、Horizontal Pod Autoscaler (HPA): HPA 可以根据 CPU 利用率、内存使用率或其他自定义指标自动调整 Pod 的副本数量。当指标超过预设的阈值时,HPA 会自动增加 Pod 副本,反之则减少。这实现了应用程序的水平弹性伸缩,根据实际负载动态调整资源使用。
3、Vertical Pod Autoscaler (VPA): VPA 可以自动调整 Pod 中容器的资源请求(Requests)和限制(Limits)。VPA 监控容器的资源使用情况,并根据历史数据和实时负载推荐合适的资源配置。VPA 可以自动更新 Pod 的资源配置,或者提供建议供管理员手动调整。这实现了应用程序的垂直弹性伸缩,根据实际需求动态调整单个 Pod 的资源分配。
4、动态卷分配(Dynamic Volume Provisioning): Kubernetes 允许根据需要动态创建和分配持久卷。当 Pod 需要存储时,可以动态地创建一个新的持久卷并将其挂载到 Pod 上。这避免了预先创建大量持久卷的麻烦,提高了存储资源的利用率。
5、动态资源分配(DRA - Dynamic Resource Allocation): 这是 Kubernetes 较新的一个特性,旨在解决除 CPU、内存和存储之外的其他类型资源的动态分配问题,例如 GPU、FPGA 等硬件加速器。DRA 允许应用程序以更精细的方式请求和使用这些特殊资源,并允许资源驱动程序根据实时需求进行分配和管理。DRA 将持久卷 API 的概念推广到通用资源的管理,提供了更灵活、更高效的资源分配机制。
本文主要围绕“动态资源分配(DRA - Dynamic Resource Allocation)” 进行展开描述。在详细解析 DRA 之前,我们先了解一下 Device Plugin 概念,那么,什么是 Device Plugin 呢?
Kubernetes 的 Device Plugin 机制(源于 KEP-3573)是一项早期就引入 Kubernetes 的重要功能,旨在扩展 Kubernetes 的资源管理能力,使其能够支持除 CPU 和内存之外的各种硬件资源,例如图形处理器(GPU)、数据处理单元(DPU)、现场可编程门阵列(FPGA)以及非统一内存访问(NUMA)节点等。
Device Plugin 机制通过提供一个简单而强大的接口——Device Plugin Interface,实现了对这些硬件资源的抽象和管理。通过实现这个接口,第三方供应商或用户可以开发自己的 Device Plugin,从而将特定的硬件资源集成到 Kubernetes 集群中。
如何在 Kubernetes 中使用 GPU 资源 ?
众所周知,长期以来,在云计算领域,人们普遍认为计算资源主要以中央处理器(CPU)为中心,应用程序的开发和部署也大多围绕 CPU 进行。这种以 CPU 为中心的模式在过去很长一段时间内有效地支撑了各种业务需求。然而,随着人工智能、大数据分析、高性能计算等技术的蓬勃发展,以及新兴业务模式的不断涌现,越来越多的应用场景对计算能力提出了前所未有的高要求,需要远超传统 CPU 的强大算力才能有效支撑业务的持续发展和创新。
在传统的虚拟化或裸金属服务器环境中部署和承载这些高算力需求的业务,往往会导致显著的资源浪费。例如,为满足峰值负载而配置的硬件资源,在业务低谷期会处于闲置状态,造成巨大的经济成本消耗。此外,传统的部署方式在资源弹性伸缩和快速部署方面也存在诸多限制,难以满足现代应用快速变化的需求。
为了有效应对这些挑战,实现降本增效的目标,越来越多的企业开始积极拥抱云原生技术,探索如何在云原生生态系统中实现资源的动态承载。云原生技术以容器化、微服务和自动化等为核心,能够更好地管理和调度各种计算资源,包括 CPU、GPU、FPGA 等异构计算资源,从而实现资源的按需分配、弹性伸缩和高效利用,最大程度地降低成本并提高运营效率。
然而,在 Kubernetes 中部署 GPU 节点池,即使是初始阶段,也需要一些特定于供应商的软件组件,其中最关键的包括 Kubernetes 设备插件和 GPU 驱动程序。安装 GPU 驱动程序是必不可少的,这是毋庸置疑的。然而,我们为什么还需要安装特定的设备插件呢?
原因在于 Kubernetes 平台本身并不原生支持诸如 GPU 这类特殊硬件资源。设备插件的关键作用就在于发现并向应用程序暴露这些资源。其工作机制是:设备插件通过设备插件 API 接收可分配资源列表,并将其传递给 kubelet,从而对外呈现节点上的 GPU 数量。kubelet 负责持续跟踪这些资源,并将节点上各种资源类型的数量汇报给 API Server,以便 kube-scheduler 在进行 Pod 调度决策时能够充分利用这些信息。
然而,这种基于设备插件的方案存在一些固有的局限性:
1、资源选择的精细程度有限: 只能通过一些节点属性和标签来对节点上的资源类型进行相对粗略的选择,无法进行更精细的控制。
2、缺乏有效的调度反馈机制: 设备插件和 kube-scheduler 之间缺乏有效的反馈回路。这意味着,即使 kube-scheduler 为一个待调度的 Pod 找到了看似合适的节点,设备插件也无法根据节点的就绪状态等关键因素进行进一步的“校验”,这可能导致 Pod 被错误地调度到尚未完全准备好接收新资源的“未就绪”节点上。
为了有效克服上述局限性,Kubernetes 引入了动态资源分配(DRA)机制。DRA 的核心目标是确保应用程序能够在恰当的时机获得所需数量的资源。“动态资源分配 API”将持久卷 API 的设计理念扩展到通用资源的管理,例如 GPU 等。它支持基于实时需求和预设配置进行动态的资源调整,从而最大程度地减少人工干预的需求。
如何理解 DRA(Dynamic Resource Allocation) ?
通常而言,DRA 核心特性与工作机制主要体现在如下几点,具体可参考:
1. 对通用资源持久卷 API 的泛化
传统的资源分配方式通常只涵盖 CPU 和内存等通用资源,而 DRA 的出现则使 Kubernetes 能够支持更广泛的资源类型。这种泛化的实现,使得 DRA 不仅限于硬件设备的管理,还能够扩展到其他复杂资源类型,从而满足不同场景下的动态需求。例如,在深度学习场景中,用户不仅可以请求 GPU 资源,还可以指定具体的显存大小或计算核心数,以便更精确地满足任务需求。
2. 第三方资源驱动程序的关键作用
DRA 的高效运行离不开第三方资源驱动程序的支持。这些驱动程序主要负责以下任务:
资源发现:检测和报告节点上的可用资源状态,例如 GPU 的数量、型号和当前负载情况。
资源分配:根据用户的具体需求分配资源,并将资源绑定到目标 Pod。
资源监控:在资源生命周期内持续跟踪资源的使用状态,以确保任务的顺利完成并避免资源冲突。
通过第三方驱动程序,DRA 能够实现对资源的细粒度控制。例如,在 AI 模型训练任务中,用户可以通过自定义驱动程序参数指定 GPU 显存分配的上限,以适应特定模型对显存的需求,从而最大化计算性能和资源利用率。
3. 参数化与结构化的资源管理
DRA 在 Kubernetes 1.30 中引入了一种基于结构化参数的机制。这一机制允许用户为不同类型的资源定义灵活的需求和初始化参数。例如:
GPU 配置:可以指定显存大小、计算核心数、CUDA 支持版本等。
FPGA 配置:可以定义板卡型号、逻辑单元使用量或频率等。
网络设备:支持指定带宽、吞吐量或 RDMA 能力。
基于这种参数化设计为用户提供了高度灵活的资源定制能力,同时也为复杂资源的动态管理奠定了基础。
Happy Coding ~
Reference :
Adiós !
不知道读者们,压力是否过大?若是,不妨读一读余华的作品,或许能够找到自己的命运之口...👇
··································
对云原生网关 Traefik 技术感兴趣的朋友们,可以了解一下我的新书,感谢支持!
Hello folks,我是 Luga,Traefik Ambassador,Jakarta EE Ambassador, 一个 15 年+ 技术老司机,从 IT 屌丝折腾到码畜,最后到“酱油“架构师。如果你喜欢技术,不喜欢呻吟,那么恭喜你,来对地方了,关注我,共同学习、进步、超越~