Volcano 新版本发布：10 大功能提升统一调度和细粒度资源管理能力

2024-09-29
广东
本文字数：6943 字
阅读完需：约 23 分钟

本文分享自华为云社区《Volcano v1.10.0 版本正式发布！10大功能全面提升统一调度和细粒度资源管理能力》，作者：云容器大未来

近日，Volcano 社区 v1.10.0 版本^[1]正式发布（Branch：release-1.10^[2]），此次版本增加了以下新特性：

新增队列优先级设置策略
支持细粒度的 GPU 资源共享与回收
支持 Pod Scheduling Readiness 调度
支持 Sidecar container 调度
增强 vcctl 命令行工具功能
Volcano 支持 Kubernetes v1.30
增强 Volcano 安全性
优化 Volcano 性能
提升 GPU 监控功能
优化 helm chart 包安装升级流程

▶ 新增队列优先级设置策略

在传统的大数据处理场景下，用户可以直接设置队列优先级来控制作业的调度顺序，为了更好的帮助用户从 Hadoop/Yarn 迁移到云原生平台，Volcano 也支持了在队列层面直接设置优先级，降低大数据用户的迁移成本，提升用户体验和资源利用效率。

队列是 Volcano 中的一种基本资源，不同队列有着优先级区分，在默认情况下，队列的优先级是由队列的 share 值决定的，share 值是由队列中已分配的资源量除以队列的总容量计算得到的，不需要用户手动配置，share 值越小，则代表队列中已分配的资源比例越小，即队列越不饱和，需要优先分配资源，因此队列的 share 越小，队列的优先级越高，在分配资源时会优先分配给 share 较小的队列，以保证资源分配的公平性。

但是在生产环境尤其是大数据处理场景下，用户更希望可以直接设置队列的优先级，从而能更直观的知道不同队列的优先级顺序，由于 share 值是实时计算得到的，因此会根据队列分配资源的饱和程度而实时变化，为了更加直观的表示队列优先级同时支持用户自行配置，Volcano 在 share 值的基础上为队列新增了 priority 字段，支持用户配置队列优先级，priority 越高则表示队列优先级越高，会优先分配资源给高优先级的队列，并且在回收队列资源时会优先回收低优先级队列内的作业。

队列优先级定义：

type QueueSpec struct {...  // Priority define the priority of queue. Higher values are prioritized for scheduling and considered     later during reclamation.  // +optional  Priority int32 `json:"priority,omitempty" protobuf:"bytes,10,opt,name=priority"`}

复制代码

同时为了兼容 share 值的使用方式，Volcano 在计算队列优先级时也会考虑 share 值，默认情况下用户不设置队列优先级或者队列的优先级相等时，Volcano 会再比较队列的 share 值，此时 share 越小队列优先级越高。用户可以根据实际场景选择设置不同的优先级策略，即 priority 和 share 两种方式。

关于队列优先级设计文档，请参考：Queue Priority^[3]

▶ 支持细粒度的 GPU 资源共享与回收

Volcano 在 v1.9 版本发布了弹性队列容量 capacity 调度功能，用户可以直接为队列设置每一维度资源的容量，同时支持基于 deserved 的队列弹性容量调度，实现了更加细粒度的队列资源共享和回收机制。

弹性队列容量 capacity 调度的设计文档请参考：Capacity scheduling Design^[4]

使用指导请参考：Capacity Plugin User Guide^[5]

为队列配置每一维度 deserved 使用样例：

apiVersion: scheduling.volcano.sh/v1beta1kind: Queuemetadata:  name: demo-queuespec:  reclaimable: true  deserved: # set the deserved field.    cpu: 64    memeory: 128Gi    nvidia.com/a100: 40    nvidia.com/v100: 80

复制代码

在 v1.10 版本中，Volcano 在弹性队列容量 capacity 的基础上，支持了上报不同型号的 GPU 资源，NVIDIA 默认的 Device Plugin 在上报 GPU 资源时无法区分 GPU 型号，统一上报为 nvidia.com/gpu，AI 训推任务无法根据业务特点选择不同型号的 GPU，比如 A100、T4 等型号的 GPU，为了解决这一问题，以满足不同类型的 AI 任务需求，Volcano 在 Device Plugin 层面支持上报不同型号的 GPU 资源到节点，配合 capacity 插件实现更加细粒度的 GPU 资源共享和回收。

关于 Device Plugin 上报不同型号 GPU 的实现和使用指导，请参考：GPU Resource Naming^[6]

注意：

capacity 在 v1.10.0 版本中作为了默认的队列管理插件，capacity 与 proportion 插件互相冲突，当升级到 v1.10.0 后，你需要再设置队列的 deserved 字段，以保证队列功能正常工作，具体的使用说明请参考：Capacity Plugin User Guide^[7]

capacity 插件根据用户指定的队列 deserved 值来划分集群资源，而 proportion 插件则根据队列权重动态划分集群资源，用户可以根据实际场景选择使用 capacity 或者 proportion 插件进行队列管理。proportion 插件的介绍请参考：proportion plugin^[8]

▶ 支持 Pod Scheduling Readiness 调度

Pod 一旦创建就被认为已准备好进行调度，在 Kube-scheduler 中，它会尽力寻找合适的节点来放置所有 Pending 的 Pod。然而，在现实情况下，某些 Pod 可能会长时间处于“缺少必要资源”状态，这些 Pod 实际上以不必要的方式干扰调度程序（以及 Cluster AutoScaler 等下游组件）的决策和运行，造成资源浪费等问题。Pod Scheduling Readiness 是 Kube-sheduler 的一项新增功能，在 Kubernetes v.1.30 版本 GA，成为了一个稳定特性，它通过设置 Pod 的 schedulingGates 字段来控制 Pod 的调度时机。

pod-scheduling-gates-diagram

在前面的版本中，Volcano 已集成了 K8s 默认调度器的所有算法，全面涵盖了 Kube-scheduler 的原生调度功能。因此，Volcano 能够无缝替代 Kube-scheduler，作为云原生平台下的统一调度器，支持微服务和 AI/大数据工作负载的统一调度。在最新发布的 v1.10 版本中，Volcano 更是引入了 Pod Scheduling Readiness 调度能力，进一步满足了用户在多样化场景下的调度需求。

关于 Pod Scheduling Readiness 特性的文档，请参考：Pod Scheduling Readiness | Kubernetes^[9]

Volcano 支持 Pod Scheduling Readiness 调度的设计文档，请参考：Proposal for Support of Pod Scheduling Readiness by ykcai-daniel · Pull Request #3581 · volcano-sh/volcano (github.com)^[10]

▶ 支持 Sidecar container 调度

Sidecar container 是一种相对于业务容器而言的辅助容器，通常用来辅助业务容器的运行，比如收集业务容器日志、监控、初始化网络等。

在 Kubernetes v1.28 之前，Sidecar container 只是一种概念，并没有单独的 API 来标识一个容器是否是 Sidecar container，Sidecar 容器和业务容器处于同等地位，有着相同的生命周期，Kubelet 会并发启动所有 Sidecar 容器和业务容器，这样带来的问题是 Sidecar 容器可能会在业务容器启动之后才启动，并且在业务容器结束之前先结束，而我们期望的是 Sidecar 容器先于业务容器启动，并在业务容器结束之后再结束，这样就能保证 Sidecar 容器收集的日志，监控等信息是完整的。

Kubernetes v1.28 在 API 层面支持了 Sidecar container，并对 init container、Sidecar container、业务 container 做了统一的生命周期管理，同时调整了 Pod 的 request/limit 资源计算方式，该特性在 v1.29 成为 Beta 特性。

该特性在设计阶段经历了漫长的讨论时间，特性本身并不复杂，主要的考虑点在于兼容旧的使用方式，如果定义一个除了 init container、业务容器之外的新的容器类型，会对 API 有较大的破坏性，同时周边组件适配该特性的话会有较多的侵入式修改，带来很多额外开销，因此 Kubernetes 社区并没有引入新的容器类型来支持 Sidecar container，而是直接复用了 init container，通过设置 init container 的 restartPolicy 为 Always 来标识 Sidecar container，完美的解决了 API 兼容性问题和 Sidecar 容器的生命周期问题。

在调度层面，该特性的影响在于 Pod 申请的 request 资源计算方式有所变化，因为 Sidecar container 作为一种特殊的 init container 是持久运行的，需要将 Sidecar container 的 request 值累加到业务容器的 request 值上，因此需要重新计算 init container、Sidecar container 和业务容器的资源 request 值。

Volcano 调度器在新版本更改了 Sidecar container 的资源计算方式，支持了 Sidecar container 的调度，用户可以使用 Volcano 调度 Sidecar container。

关于 Sidecar container 的详细信息，请参考：Sidecar Containers | Kubernetes^[11]

▶ 增强 vcctl 命令行工具功能

vcctl 是操作 Volcano 内置 CRD 资源的一个命令行工具，可以方便的用来查看/删除/暂停/恢复 vcjob 资源，并支持查看/删除/开启/关闭/更新 queue 资源。Volcano 在新版本对 vcctl 做了功能增强，新增以下功能：

支持创建/删除/查看/描述 jobflow 和 jobtemplate 资源
支持查询指定队列里的 vcjob
支持通过 queue 和 vcjob 过滤查询 Pod

vcctl 的详细指导文档，请参考：vcctl Command Line Enhancement^[12]

▶ Volcano 支持 Kubernetes v1.30

Volcano 版本紧跟 Kubernetes 社区版本节奏，对 Kubernetes 的每个大版本都进行支持，目前最新支持的版本为 v1.30，并运行了完整的 UT、E2E 用例，保证功能和可靠性。

如果您想参与 Volcano 适配 Kubernetes 新版本的开发工作，请参考：adapt-k8s-todo^[13] 进行社区贡献。

▶ 增强 Volcano 安全性

Volcano 一直都很重视开源软件供应链的安全，在 license 合规、安全漏洞披露和修复、仓库分支保护、CI 检查等方面遵循 OpenSSF 定义的规范，Volcano 近期在 Github Action 加入了新的 workflow，它会在代码合入时运行 OpenSSF 安全性检查，并实时更新软件安全评分，持续提升软件安全性。

同时 Volcano 对各个组件的 RBAC 权限进行了收缩，只保留必要的权限，避免了潜在的越权风险，提升了系统的安全性。

Volcano 云原生批量计算公开课

Volcano 云原生批量计算公开课由 CNCF 首个批量计算社区 Volcano 核心贡献者开发，通过理论学习+实践操作，帮助学习者由浅入深了解批量计算原理和生产场景应用，晋升批量计算达人！点击免费学习Volcano云原生批量计算公开课

社区介绍：Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano 在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。

Volcano 官网：https://volcano.sh

GitHub: https://github.com/volcano-sh/volcano

每周例会：https://zoom.us/j/91804791393

点击关注，第一时间了解华为云新鲜技术~

发布于: 刚刚阅读数: 4