在 Kubernetes 上弹性深度学习训练利器 -- Elastic Training Operator

头图.png

作者 | 徐晓舟(萧元)
来源|阿里巴巴云原生公众号

背景

由于云计算在资源成本和弹性扩容方面的天然优势,越来越多客户愿意在云上构建 AI 系统,而以容器、Kubernetes 为代表的云原生技术,已经成为释放云价值的最短路径, 在云上基于 Kubernetes 构建 AI 平台已经成为趋势。

当面临较复杂的模型训练或者数据量大时,单机的计算能力往往无法满足算力要求。通过使用阿里的 AiACC 或者社区的 horovod 等分布式训练框架,仅需修改几行代码,就能将一个单机的训练任务扩展为支持分布式的训练任务。在 Kubernetes 上常见的是 kubeflow 社区的 tf-operator 支持 Tensorflow PS 模式,或者 mpi-operator 支持 horovod 的 mpi allreduce 模式。

现状

Kubernetes 和云计算提供敏捷性和伸缩性,我们可以通过 cluster-AutoScaler 等组件为训练任务设置弹性策略,利用 Kubernetes 的弹性能力,按需创建,减少 GPU 设备空转。

但这种伸缩模式面对训练这种离线任务还是略有不足:

  • 不支持容错,当部分 Worker 由于设备原因失败,整个任务需要停止重来。
  • 训练任务一般时间较长,占用算力大,任务缺少弹性能力。当资源不足时,除非任务终止,无法按需为其他业务腾出资源。
  • 训练任务时间较长,不支持 worker 动态配置, 无法安全地使用抢占实例,发挥云上最大性价比

如何给训练任务赋予弹性能力,是提高性价比的关键路径。近期 horovod 等分布式框架逐渐支持了 Elastic Training,即弹性训练能力。也就是允许一个训练任务在执行的过程中动态的扩容或者缩容训练 worker, 从不会引起训练任务的中断。需要在代码中做少量修改适配,可参考:https://horovod.readthedocs.io/en/stable/elastic_include.html。

对 Elastic training 的实现原理感兴趣可以看这篇 Elastic Horovod 设计文档, 本文不详细介绍。

1.png

在 mpi-operator 中,参与训练的 Worker 都是作为静态资源设计和维护,支持弹性训练模式后,给任务增加了灵活性,同时也给运维层带来了挑战,例如:

  • 必须通过 horovod 提供的 horovordrun 作为入口,horovod 中 launcher 通过 ssh 登陆 worker,需要打通 launcher 和 worker 之间的登陆隧道。

  • 负责计算弹性的 Elastic Driver 模块通过指定 discover_host 脚本获取最新 worker 拓扑信息,从而拉起或停止 worker 实例。当 worker 变化时,首先要更新 discover_host 脚本的返回值。

  • 在抢占或价格计算等场景中,有时需要指定 worker 缩容,K8s 原生的编排元语 deployment,statefulset 无法满足指定缩容的场景。

解决方法

针对以上问题,我们设计开发了 et-operator,提供 TrainingJob CRD 描述训练任务, ScaleOut 和 ScaleIn  CRD 描述扩容和缩容操作, 通过它们的组合,使我们的训练任务更具有弹性。将这个方案开源,欢迎大家提需求、交流、吐槽。

开源方案地址:https://github.com/AliyunContainerService/et-operator

设计

TrainingJob Controller 主要有以下功能:

  • 维护 TrainingJob 的创建/删除生命周期,以及子资源管理。
  • 执行扩缩容操作。
  • 容错,当 worker 被驱逐,创建新的 worker 加入到训练中。

1. 资源创建

TrainingJob 子资源创建顺序如下:

  • 创建打通 ssh 所需的密钥对, 创建 secret。
  • 创建 workers,包含 service 和 pod,挂载 secret 公钥。
  • 创建 configmap, 包含 discover_host 脚本 , hostfile 文件。
  • 创建 launcher,挂载 configmap。由于 hostfile 后续会随着拓扑关系修改,所以 hostfile 单独通过 initcontainer 从 configmap 拷贝到单独目录。

TrainingJob 相关资源:

2.png

TrainingJob CR 的配置分为 Lanucher 和 Worker。在 Launcher 中指定任务的镜像和启动执行, 默认 et-operator 会根据 worker 分配情况,生成一个 hostfile 文件和 discover_host 脚本,discover_host 脚本挂载到 Launcher 的 /etc/edl/discover_hosts.sh 文件, 在入口脚本的 horovodrun 执行中通过 --host-discovery-script 参数指定。在 Worker 设置中指定 worker 的镜像和 GPU 占用 ,并可以通过 maxReplicas / minReplicas 指定 workers 的副本数允许范围。

apiVersion: kai.alibabacloud.com/v1alpha1
kind: TrainingJob
metadata:
  name: elastic-training
  namespace: default
spec:
  cleanPodPolicy: Running
  etReplicaSpecs:
    launcher:
      replicas: 1
      template:
        spec:
          containers:
          - command:
            - sh
            - -c
            - horovodrun -np 2 --min-np 1 --max-np 9 --host-discovery-script
              /etc/edl/discover_hosts.sh python /examples/elastic/tensorflow2_mnist_elastic.py
            image: registry.cn-huhehaote.aliyuncs.com/lumo/horovod:master-tf2.1.0-torch1.4.0-mxnet-py3.6-gpu
            imagePullPolicy: Always
            name: mnist-elastic
    worker:
      maxReplicas: 9
      minReplicas: 1
      replicas: 2
      template:
        spec:
          containers:
          - image: registry.cn-huhehaote.aliyuncs.com/lumo/horovod:master-tf2.1.0-torch1.4.0-mxnet-py3.6-gpu
            imagePullPolicy: Always
            name: mnist-elastic
            resources:
              limits:
                nvidia.com/gpu: "1"
              requests:
                nvidia.com/gpu: "1"
status:
  currentWorkers:
  - elastic-training-worker-0
  - elastic-training-worker-1
  - elastic-training-worker-2
  - elastic-training-worker-3
  phase: Succeeded
  replicaStatuses:
    Launcher:
      active: 1
      succeeded: 1
    Worker:
      active: 4

3.png

2. Worker 扩容 / 缩容

除了 TrainingJob 外,et-operator 同时支持 ScaleOut 和 ScaleIn 两种 CRD,下发训练任务扩容和缩容操作。

当下发一个 ScaleOut CR,ScaleOutController 触发 Reconcile, 这里工作很简单,根据 ScaleOut CR 中的 Selector 字段,找到 Scaler 对应的 TrainingJob,设置到 CR 的 OwnerReferences 上。

以一个 ScaleOut 操作举例:

- apiVersion: kai.alibabacloud.com/v1alpha1
  kind: ScaleOut
  metadata:
    creationTimestamp: "2020-11-04T13:54:26Z
    name: scaleout-ptfnk
    namespace: default
    ownerReferences:
    - apiVersion: kai.alibabacloud.com/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: TrainingJob
      name: elastic-training // 指向扩容对象TrainingJob
      uid: 075b9c4a-22f9-40ce-83c7-656b329a2b9e
  spec:
  selector:
    name: elastic-training
  toAdd:
    count: 2

TrainingJobController 中监听到属于 TrainingJob  的 ScaleOut CR 有更新, 触发 TrainingJob 的 Reconcile,遍历过滤 TrainingJob 下 OwnerReference 指向的 ScaleIn 和 ScaleOut, 根据创建时间和状态时间决定执行的扩容或者缩容。

apiVersion: kai.alibabacloud.com/v1alpha1
kind: TrainingJob
metadata:
  name: elastic-training
  namespace: default
spec: 
  // ...... Launcher and Worker spec
status:
  currentScaler: ScaleIn:default/scaleout-ptfnk
  phase: Scaling
  currentWorkers:
  - elastic-training-worker-0
  - elastic-training-worker-1

ScaleOut 任务 CR:

4.png

ScaleIn 任务 CR:

5.png

详细工作过程:

6.png

运行

1. 安装 ET-Operator

mkdir -p $(go env GOPATH)/src/github.com/aliyunContainerService
cd $(go env GOPATH)/src/github.com/aliyunContainerService
git clone https://http://github.com/aliyunContainerService/et-operator
cd et-operator
kubectl create -f deploy/all_in_one.yaml 

检测 crd 的安装:

# kubectl get crd
NAME                                    CREATED AT
scaleins.kai.alibabacloud.com           2020-11-11T11:16:13Z
scaleouts.kai.alibabacloud.com          2020-11-11T11:16:13Z
trainingjobs.kai.alibabacloud.com       2020-11-11T11:16:13Z

检测 controller 的运行状态,默认安装在 kube-ai 中:

# kubectl -n kube-ai get po
NAME                                         READY   STATUS              RESTARTS   AGE
et-operator-controller-manager-7877968489-c5kv4   0/2     ContainerCreating   0          5s

2. 运行 TrainingJob

运行事先已准备好的示例:

kubectl apply -f examples/training_job.yaml

检测运行状态:

# kubectl get trainingjob
NAME                          PHASE     AGE
elastic-training              Running   77s

# kubectl get po
NAME                                      READY   STATUS             RESTARTS   AGE
elastic-training-launcher                 1/1     Running            0          7s
elastic-training-worker-0                 1/1     Running            0          10s
elastic-training-worker-1                 1/1     Running            0          9s

3. 缩容训练任务 Worker

执行缩容时,可以通过 ScaleIn CR 中的 spec.toDelete.count  或 spec.toDelete.podNames  字段指定缩容的 worker。

通过 count 配置缩容的数量,则通过 index 计算由高到低缩容 Worker。

apiVersion: kai.alibabacloud.com/v1alpha1
kind: ScaleIn
metadata:
  name: scalein-workers
spec:
  selector:
    name: elastic-training
  toDelete:
    count: 1

如果想要缩容特定的 Worker,可以配置 podNames:

apiVersion: kai.alibabacloud.com/v1alpha1
kind: ScaleIn
metadata:
  name: scalein-workers
spec:
  selector:
    name: elastic-training
  toDelete:
    podNames:
    - elastic-training-worker-1

运行一个缩容示例,指定数量缩容 1 个 worker:

kubectl create -f examples/scale_in_count.yaml

检测缩容执行状态和训练任务:

# kubectl get scalein
NAME                                     PHASE            AGE
scalein-sample-t8jxd                     ScaleSucceeded   11s

# kubectl get po
NAME                                      READY   STATUS             RESTARTS   AGE
elastic-training-launcher                 1/1     Running            0          47s
elastic-training-worker-0                 1/1     Running            0          50s

4. 扩容训练任务

在 ScaleOut CR 中,通过 spec.toAdd.count 字段指定扩容的 worker 数:

apiVersion: kai.alibabacloud.com/v1alpha1
  kind: ScaleOut
  metadata:
    name: elastic-training-scaleout-9dtmw
    namespace: default
  spec:
    selector:
      name: elastic-training
    timeout: 300
    toAdd:
      count: 2

运行示例:

kubectl create -f examples/scale_out.yaml

检测缩容执行状态和训练任务:

kubectl get scaleout
NAME                                     PHASE            AGE
elastic-training-scaleout-9dtmw          ScaleSucceeded   30s
kubectl get po
NAME                                      READY   STATUS             RESTARTS   AGE
elastic-training-launcher                 1/1     Running            0          2m5s
elastic-training-worker-0                 1/1     Running            0          2m8s
elastic-training-worker-1                 1/1     Running            0          40s
elastic-training-worker-2                 1/1     Running            0          40s

总结

ET-Operator 提供一组训练和扩缩容 CRD 和 Controller, 让我们在 Kubernetes 上方便地运行弹性分布式训练,支持下发分布式训练任务,并通过和分布式框架的集成联动,在训练任务运行过程中动态地扩容和缩容参与运算的 Workers。使我们的训练任务具有弹性能力,结合抢占实例,能够更好的利用云上的资源弹性和性价比优势。

相关推荐

推荐一款好用的刷题工具

为了帮助正在准备求职季的开发者提升备战效率,阿里云特别推出“通义灵码陪你备战求职季”活动,精心挑选百道历史校招技术面试/笔试题,借助通义灵码智能问答、代码智能生成、代码优化等核心功能,帮助开发者更加准确地了解程序员职业所需的核心技能,加强对问题解决思维和解题能力的练习。

阿里巴巴云原生的博客 1381

通义灵码 Visual Studio 下载安装指南(附安装包)

本安装步骤适用于 Windows 10 及以上操作系统中安装和使用通义灵码。

阿里巴巴云原生的博客 4435

让复杂任务由团队完成:阿里云 AgentCore 多 Agent 协作架构及实践

Alibaba Cloud AgentCore 以身份、通信、团队和任务为基础,让专业 Agent 与人类成员共同参与业务协作。企业可以按职责组合知识、工具、Skill 和模型,用任务系统持续追踪工作,再结合 AgentLoop 评估效果、优化配置。

阿里巴巴云原生的博客 303

易点天下:AI 驱动 IT 运维组织提效的实践

易点天下作为一家专注品牌全球化的营销科技公司,由智能营销、全域增长、智能变现三大引擎驱动。公司旗下拥有“整合营销服务”与“广告平台业务”两大业务线。

阿里巴巴云原生的博客 284

阿里云可观测 2026 年 10 月产品动态

阿里云可观测 2026 年 10 月产品动态

阿里巴巴云原生的博客 188

用 Nacos 3.3.0 ARD 让 Agent 按任务发现工具和 Skill

如今,工作中用 Agent 帮忙已经越来越常见。研发同学用 Coding Agent 写代码、补测试、排查问题,业务同学用 Work Agent 整理资料、分析表格、制作演示文稿。不少过去需要自己一步步操作的事情,现在可以把需求交给 Agent,让它协助完成。

阿里巴巴云原生的博客 308

HiRoute 新版本发布:结合自己的真实工作选择最佳模型

HiRoute[1]是一个开源、运行在本地的 Agent 智能路由引擎。你继续用 Codex、Claude Code、Qoder、Pi、OpenCode、Hermes、DeepSeek Harness 等熟悉的 Agent,由 HiRoute 判断每一步交给哪个模型。

阿里巴巴云原生的博客 377

用户说 App“下不了单”:用 Session Replay 看清流程卡在哪一步

Session Replay(会话回放)将采集到的页面变化重建为可回看的过程。研发可以沿着这次会话,查看操作前后的界面变化,先确认流程停在了哪里,再结合当时的事件、日志和代码检查原因。

阿里巴巴云原生的博客 55

欢迎报名丨Alibaba Cloud AgentCore 企业智能体构建与治理八城巡回沙龙 · 杭州站开启

欢迎报名丨Alibaba Cloud AgentCore 企业智能体构建与治理八城巡回沙龙 · 杭州站开启

阿里巴巴云原生的博客 132

运维走出控制台:阿里云 AgentCore AI Native 运维实践

UModel 让现场能够被关联,运维数字员工让经验能够被调用,AgentCore Team 让分析能够协作,AgentLoop 让质量能够被检验。这些建设共同服务于一件事:让团队对系统的理解,成为每个人处理问题时都能接上的能力。

阿里巴巴云原生的博客 292

从长程 Agent 到 Super-agent,解锁更多场景

Deepseek Harness 提升了架构的透明度,但也带来了工程上的复杂度。这次开源的dsh-superagent-prototype,是对 Agent “连续实体”能力的工程拆解。

阿里巴巴云原生的博客 232

排查提效 50%:淘大集新核心系统的观测护航之路

供应链运维,缺的不是更多机器,是“一条能把指标、日志、链路串起来的线”。阿里云 ARMS+SLS+云监控2.0+STAROps 重构观测底座。

阿里巴巴云原生的博客 147

概率、插座与 5000 个爱因斯坦:专访阿里云研发副总裁周琦

这次访谈发生在 2026 年云栖大会之后。大会期间,阿里云发布了智能体构建和治理平台 AgentCore,将企业级 Agent 基础设施进一步标准化和托管化。

阿里巴巴云原生的博客 152

Agent 数据飞轮平台的选型和实践

用统一标准判断修改效果,积累覆盖不同路径的测试样本,沿执行记录排查失败,并将典型问题纳入后续回归。而这也是宙斯接入 AgentLoop 要解决的问题。

阿里巴巴云原生的博客 28

Durable Agent 详解:如何让 Agent 在云端长期稳定运行

本文使用一个具体的用户任务示例“向五位客户发送通知邮件”,解释为什么保存聊天记录还不够,再以 AgentScope 构建的 Agent 为例,展开任务状态、持久提交和故障恢复的通用设计,最后结合 Alibaba Cloud AgentCore 已有的 Harness 托管与节点恢复能力,讨论共享状态、可靠调度及 Brain / Hands 分离如何支撑更完整的长期托管服务。

阿里巴巴云原生的博客 334

Qoder × AgentLoop:智能体规模化应用,敏感数据保护如何跟上?

智能体观测与优化平台 AgentLoop 持续分析已采集的 Qoder 审计日志,将发现的风险线索关联到具体会话、工具调用、成员和环境,帮助安全团队回查任务过程、明确需要整改的环节,并复查处理效果。

阿里巴巴云原生的博客 288

完整还原已经服务千家企业的 AIOps Agent 的评测和调优实践

阿里云 STAROps 是一个生产运维 Agent,通过连接多域数据、运维工具与专家经验,从被动响应走向智能自治,7×24 保障业务连续、稳定运行。本文将分享 STAROps 的评测和调优实践。

阿里巴巴云原生的博客 198

阿里云云原生四项 AI 应用工程化实荣获“鼎新杯”优秀案例

第五届“鼎新杯”由中国通信标准化协会主办、中国信息通信研究院承办,自2026年05月正式启动,历时近 5 个月,聚焦国内政企数智化转型领域的创新成果,旨在为行业提供可复制、可推广的实践参考。

阿里巴巴云原生的博客 321

交付周期从 51 天缩短到 14 天,多 Agent 协作产品⾃进化背后的组织重构

本⽂结合这段实践,介绍评测如何驱动产品持续进化、⼈机协作的边界如何设定,以及团队如何通过统⼀⽬标、结果标准和责任分⼯,减少跨岗位交接,降低沟通损耗,把技术能⼒转化为实际交付效果。

阿里巴巴云原生的博客 327

从部署上线到运维优化:STAROps 与 ROS Agent 的资源运维自动化实践

STAROps 数字员工提供统一的运维对话入口,结合日志、指标、告警等信息理解问题,并通过 alibabacloud-ros-agent 技能,将基础设施规划和变更任务委派给 ROS Agent。

阿里巴巴云原生的博客 128

车企数据隐私保护必修课:如何用 SLS mask 守住日志中的敏感信息

阿里云日志服务 SLS 的 mask 函数可在采集或写入阶段替换匹配的敏感值,同时保留业务状态与调用链,并结合访问控制和保留期限管理减少暴露。下文通过车辆与车主服务、海外联网订阅、智能座舱交互三类业务中的四组日志,介绍规则选择与脱敏效果。

阿里巴巴云原生的博客 111

切换模型会损失缓存,智能路由还省钱吗?

智能路由会把不同的工作交给不同的模型。很多人随之会问:模型一换,之前积累的缓存就用不上了,这笔损失会不会把省下的钱又花回去?

阿里巴巴云原生的博客 209

LiteLLM 半年两度被投毒,大模型的“钥匙串”该放在哪里?

开源 Higress 把扩展代码关进 Wasm 沙箱,把发布链路锁成不可变;Higress 企业版再把凭证、供应链和防护交给平台托管。选哪一种,取决于你的团队想把精力花在哪里。想先试试托管形态的话,Serverless 标准版 0 元起步,不用先付实例费。

阿里巴巴云原生的博客 315

用 Kimi K3.1 Pro 重新介绍 AgentCore

今天凌晨 Kimi 发布 K3.1 Pro,在前端页面、Three.js 交互场景有明显提升。本文使用 Qoder 上提供的 K3.1Pro 模型,设计并排版了介绍 AgentCore 的全新方式。

阿里巴巴云原生的博客 13

从 Jev 范式决策模型接入,到参与 Team 协作的完整实践

本文将以一个工单分诊助手为例,把开发、打包和上线的过程串起来:用 AgentScope Java 与百炼决策模型(国内网络无法使用 Jev)实现分诊,通过代码包部署到阿里云 AgentCore[1],再验证普通调用和流式调用。文章最后,再看这个助手如何加入 Team,参与任务分工与报告审核。

阿里巴巴云原生的博客 339

MCP 服务无状态,任务状态存哪?RocketMQ LiteTopic 给每个任务一本账

AI Agent 调用一个工具,有时几百毫秒就能返回,有时却要运行好几分钟——比如检索一大批资料、生成一段长内容,或执行一次批处理。让请求一直挂着等结果,会长期占用连接和资源,也很难支撑大规模并发。

阿里巴巴云原生的博客 296

Personal Agent 观察:拆解全天候运行的技术挑战

本文将探讨一下,为什么 Personal Agent 成为了当前新的 AI 应用竞争点,底层技术以及后续国内跟进的可能方向。

阿里巴巴云原生的博客 289

Agent as a Service:驱动 Personal Agent 与企业智能体的服务架构

本文以 AgentScope 为基础,围绕 Sandbox as Tool 展开这条建设路径:将 Harness 托管为远端服务,将 Context、Memory 与恢复状态接入云端状态服务,通过执行权交接支持本地与远端续做,再通过 Brain/Hands 分离连接不同位置的工具执行端。

阿里巴巴云原生的博客 155

非算法工程师也能看懂,推理框架的来龙去脉

虽然 Model、Harness 的概念已深入人心,但推理框架这个算法工程师才会使用的概念似乎还略显陌生。不过,它和我们使用模型的费用和体验息息相关,例如为什么的输出价格是输入的 4 倍,缓存命中的价格是未命中的1/50(以 DeepSeek 当前的定价为例)等等,相信本文对这些疑问会提供一些通俗易懂的解答。

阿里巴巴云原生的博客 148

阿里云微服务引擎 MSE 及 API 网关 2026 年 9 月产品动态

阿里云微服务引擎 MSE 及 API 网关 2026 年 9 月产品动态

阿里巴巴云原生的博客 104
上一篇: 阿里内网热搜开发者工具在线教程推荐
下一篇: 十年再出发,Dubbo 3.0 Preview 即将在 3 月发布
阿里云云原生
阿里云云原生 企业官方账号 企业官方账号
博客等级 码龄8年 1万+粉丝 3143原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值