美团大数据及机器学习基础设施云原生改造实践

1. 美团大数据及机器学习集群云原生改造实践美团数据平台资源与系统负责人 / 吴通

2.

3. 目录 • 早期架构及升级背景 • 云原生改造过程 • 关键问题和思考 • 未来规划

4. 改造前架构

5. 场景特点 • 大数据和机器学习两个大场景，先有大数据，后有机器学习 • 大数据场景供需共构，对扩展性、可观测性等诉求不高，机器故障率低 • 机器学习场景供需异构，对调度语义、扩展性、可观测性、运维友好均有高诉求，机器故障率高

6. 改造前痛点 • 扩展App类型复杂度高 • 依赖AM，而用户无感知，影响资源统计 • 支持GPU、RDMA、NPU等设备复杂度高 • 调度策略定制成本高 • 故障感知、监控、可观测水平低

7. 更深层次的原因 • 离线场景的路径依赖 • 架构变更带来的不确定性

8. K8S VS YARN • YARN：分布式集群资源调度系统 • K8S：分布式集群操作系统，管理集群资源的方方面面，不仅仅是调度

9. 改造后架构

10. 目录 • 早期架构及升级背景 • 云原生改造过程 • 关键问题和思考 • 未来规划

11. 控制面改造内容概览组件改造内容简介 etcd 服务器和客户端均升级至3.5.5，提升性能并修复单节点revision落后较多的问题 kube-apiserver 1. 解决负载不均衡问题 2. httplog获取userAgent可能触发map并发读写问题 3. 修复get&watch在apiserver_request_duration_seconds_bucket错误展示的问题 controller- manager 1. 改造Endpoint Controller，以解决underlay CNI不支持ClusterIP service问题 2. 增强NodeLifecycle Controller处理Not Ready Node的能力，降低节点不可用对已有负载的影响 Operator 1. 2. 3. 4. 5. 6. 调度器自研调度器，支持各种高级特性，吞吐水平较高 SparkOperator：解决spark on k8s，支持spark 2.2和RSS TrainingOperator：解决TF、MPI、PyTorch on K8S，支持容错 AFOServingOperator：以PaaS方式解决TF、PyTorch、Triton 推理 on K8S OrdinaryServingOperator：以类IaaS方式管理在线服务 Codelab Operator：以容器方式给工程师提供开发实验环境 PrestoOperator：Presto cluster on K8S，支持弹性容错

12. 节点端改造内容概览组件改造内容简介物理机调整挂盘方式，借助硬/软Raid解决kubelet不能管理多磁盘的问题 1. 网卡、GPU亲和性支持到PCIE级别 2. 支持多网卡Pod分配多IP kubelet 3. 不同作业采用不同的oom处理策略 4. 改造static cpu manager，适配无预留cpu核心的绑核用法 5. 修复一系列导致kubelet不稳定的问题，如device权限、terminating pod、IP回收等问题 1. gpu-device-plugin支持按卡类型汇报资源名 device 2. gpu-device-plugin、rdma-device-plugin支持更丰富的设备健康检查和异常处理机制 plugin 3. gpu-device-plugin、rdma-device-plugin支持PCIE级亲和策略 4. npu-device-plugin支持ring内 npd 1. 增强节点异常检查功能，保证节点在运行期环境是符合预期的 2. 包括CPU、GPU、网卡等硬件环境，也包括存储系统、IP管理等软件环境网络 1. 采用underlay CNI，实现pod和集群外部网络资源互联 2. 改造clusterIP service实现方式，实现在underlay CNI的负载均衡方案存储 1. 支持访问HDFS，主要解决从NameNode获取token和renew token，并存储到Pod内的问题 2. 支持访问Dolphin FS，实现了一套CSI Driver，采用静态提供PV的方式，并支持文件系统故障后可自动恢复，不影响已有负载 3. 支持访问EBS，实现了一套CSI Driver，采用动态提供PV的方式。用来剥离解决实验开发场景的状态保存，以实现挂起恢复功能

13. 改造内容概览组件改造内容简介监控告警 1. 3分片2副本Prometheus，3thanos，3thanos-ruler 2. 建设k8s_alert对接公司内部的告警系统 3. 建设raptor-adaptor，对接在线服务指标到公司内部中间件可观测 1. 主流日志方案一般采用消息队列实时收集日志，但解决不了时延、时序和丢失问题，对用户 troubleshooting影响很大 2. 自研了一套日志方案，基本思路是在每个节点部署简单的文件服务器用来读取running状态 pod日志，pod结束后持久化到s3 3. 构建了一套数据收集方案，实时收集etcd和Prometheus等数据源的数据，并通过消息队列存储到持久化存储 4. 构建了数百张dashboard，描述系统的运行状况和不同组件的内部细节，并借此指导各类优化工作

14. 自研调度器

15. 简介 • 支持多租户配额管理，支持排队 • 集群唯一调度器，支持Gang Scheduling，租户间、租户内公平调度 • 支持抢占式调度，配额之上增加弹性量，提升资源利用率 • 支持划分逻辑资源池，Pod自适应优选策略，减少GPU碎片 • 支持RDMA亲和性调度，更好地支撑高性能计算需求 • 完善的退避机制，支持租户->Job->Pod多层级退避 • 调度吞吐300+ pods/s

16. 租户-配额管理两级队列：父队列：租户，子队列：租户内细分，min：配额，max - min：弹性量 Pod划分： System Pod，User Pod（指定PodGroup），单调度器统一调度 Gang Job： PodGroup唯一映射一个Gang Job，指定作业提交队列

17. 主流程 • OpenSession：从cache中复制Node、Queue、Job和Pod等对象，使调度流程无锁化 • AllcoateSystem：调度System Pod，无优选过程，快速调度 • PreAllocate：为上一轮抢占成功的User Pod分配节点，Gang Job遵循事务提交 • Allocate：调度User Pod，搜索最优Node，Gang Job遵循事务提交，核心流程 • Preempt：为调度失败的User Pod抢占资源，Gang Job遵循事务提交，核心流程 • CloseSession：更新Job和Pod状态，记录event事件和监控指标数据

18. 调度概述 • 队列公平调度：配额满足率低的队列优先 • Gang Scheduling优先调度：未满足Gang 的Job优先 • Job公平调度：Pod调度率低的Job优先，防止一个大Job『饿死』其他Job • 优先级调度：支持队列内指定Job优先级、 Job内指定Pod优先级 • 异构调度：支持10+种GPU卡型，支持5+ 种生命周期、特点不一的任务 • 调度语义丰富：支持k8s原生调度语义，扩展了如自适应聚集/均衡调度、RDMA网络亲和调度等

19. 抢占概述 • 队列max > min即表示开启弹性调度，max- min部分的资源占用在集群资源紧张时会被抢占 • 队列只在配额未满足的情况下才能抢占，弹性量部分不通过抢占来满足 • 公平性：和调度过程类似，优先为配额满足率低的队列和Pod调度率低的Job发起抢占 • 优先级抢占：支持队列内指定Job优先级、Job 内指定Pod优先级，抢低优保高优 • Gang Scheduling保护：优先抢占每个Job超出 minMember的Pod，如果Gang Scheduling被破坏，则抢占整个Job

20. 抢占关键实现-Gang Scheduling • Gang Scheduling：为Job分配大于等于 minMember数量的Pod • 调度事务化，连续为Job调度足够数量的Pod 后提交调度结果，否则回滚 • 抢占分成两步，先尝试仅抢占超出 minMember部分的Pod，再执行Gang抢占

21. 抢占关键实现-两级事务控制为Gang Job发起抢占会有多个Preemptor，多个Preemptor抢占结果提交需要保证原子性；每个 Preemptor可能抢占Node上的多个Preemptee，多个Preemptee的抢占结果也需要保证原子性。

22. 逻辑资源池划分核心思想：刻画任务类型特征，在资源碎片、可用性、性能和可维护性之间找到平衡点 • 有状态的⻓作业。执行迁移和运维动作困难，尽量聚集在一小批机器上 • 大规模训练作业。单worker占据整机资源，集群需要预留一些空载机器 • 多实例在线服务。将不同实例打散到不同机器，当节点故障时降低对服务的影响在逻辑上分成均衡池和聚集池。均衡池负责多实例应用的容错和提升集群整体IO及网络带宽，聚集池降低大尺寸 Pod的等待时间，并将有状态⻓作业束缚在少量机器上。逻辑资源池只是一种优选机制，当聚集池满了之后，聚集型的Pod也可以被调度到均衡池中，反之亦然。

23. 退避机制前提假设：一轮调度失败的任务，在之后几轮中大概率还是失败四级退避设计：指数退避算法，防”坏分子”，减少调度器做无谓调度，充分保证正常队列、任务的调度需求，在高调度负载场景下可以显著提升调度吞吐

24. Codelab Operator

25. 什么是Codelab • Codelab是基于容器实现的实验开发环境，定位于用户进行小规模开发实验，提供隔离独立的开发环境，持久化存储实验环境和数据，能快速启动和恢复 • Codelab核心功能：1）状态持久化，支持挂起和恢复；2）资源监控；3）集成实验环境及 WebIDE，如JupyterNotebook、PyCharm等

26. Codelab系统架构 1. Application应用层：通过APIService暴露 API给用户，渲染 Codelab yaml 2. Controller控制层：调谐PC的一切行为 3. Storage存储层： Codelab通过PVC挂载或客户端访问所需共享存储

27. Codelab Operator架构 • 准备：前置准备工作，如添加Finalizer，申请HDFS访问token等； • 创建Pod：根据podTemplate创建Pod及其相关资源 • 挂起和恢复：通过spec.pause标记挂起和恢复期望，挂起时删除Pod，恢复时重新创建Pod； • 同步集群外资源：对接公司内服务树系统，将Codelab注册到某个AppKey； • 删除和清理：清理无效Codelab，从Appkey注销，并释放HDFS Token； • 更新状态：计算Codelab状态，并更新.status

28. Codelab启动过程 • 通过容器共享挂载实现初始化容器文件共享 • 使用EBS存储持久化用户开发环境，主要包括yum和 pip包 • 使用Dolphin FS储存组内共享的数据和代码 • pc-start.sh作为systemd 服务初始化Codelab

29. 挂起与恢复 1. 闲时自动挂起Codelab，删除 Pod，释放所占计算资源，保留PV 2. 恢复时将重建Pod，重新挂载 PV，恢复数据和环境

30. Dolphin FS接入

31. 简介 • Host Path -> CSI • 租户目录唯一映射PV，静态绑定加速调度 • 多Dolphin FS集群自动识别，业务无感知 • Pod粒度fuse，提升读写并发 • Fuse进程位于物理机，升级CSI plugin不中断挂载 • 支持挂载点异常检测和热恢复

32. 改造前痛点： • 机器上所有Pod共享同一个挂载点，挂载进程异常影响所有Pod • 客户端发生重启，容器内的挂载点丢失，无法热恢复，只能重启容器 • 客户端升级等运维操作会导致挂载中断，日常运维“战战兢兢” • 针对多集群挂载需求，每一种上层作业引擎需要重复适配

33. 租户-PV映射机制 • 租户挂载固定目录，设计一个租户唯一映射一个PV • 预分发租户PVC和PV，并完成静态绑定，加速调度过程

34. 多集群自动识别 • 多集群的配置信息存到ConfigMap，并挂载到CSI Pod，支持热更新 • CSI通过PV中携带的租户信息定位数据所在Dolphin FS集群，并将对应集群挂载到Pod

35. Pod Level Fuse • 每一个Pod都有独立的Fuse进程，即使Fuse进程挂掉，也不影响其他Pod 的正常读写 • Fuse工作过程涉及用户态和内核态切换，一般对IO的并发有所限制，独享 Fuse在高并发IO时具有性能优势

36. CSI Connector • 如在CSI Pod中启动Fuse进程， container重建导致Fuse进程重启，稳定性差 • 借助csi-connector，将Fuse进程代理到物理机，交由systemd来管理，和 CSI解耦

37. 挂载点检测和热恢复 • 挂载点可以恢复的核心关键在于： Linux Mount Propagation。 • CSI双向传播挂载kubelet数据目录，子目录的挂载/卸载操作会传播到宿主机 • Pod使用HostToContainer，可以将宿主机的挂载事件传播到容器

38. 日志服务

39. 日志架构简介 • 日志收集 • 日志访问

40. 实时收集不可行 • 改造成本高：对多日志缺乏支持，改造成本很高 • 收集链路的要求高：收集链路⻓，fluentbit - > log-agent -> kafka -> es，该架构无法解决收集时延⻓、日志丢失和失序的问题 • 离线方式能较好解决问题

41. 日志收集优化日志挂载—不同pod如何挂载不同目录 • 通过改造kubelet支持如下模式挂载如何感知何时上传至S3 • 调整kubelet的ttl参数，Pod删除后保留几分钟容器元数据，轮询docker接口获取容器信息 • 兜底：从日志路径还原Pod信息

42. 集群外部署日志访问优化 • 当节点故障，日志服务通过Fail over机制访问集群外同等接口提升访问成功率 • 目前节点外部署可以避免约0.43%的访问失败 SEEK接口获取日志 • S3及本地文件均提供seek接口，可根据偏移量获取文件内容，提升接口效率

43. 训练整体流程

44. 作业概览

45. 作业资源监控

46. 作业日志

47. 目录 • 早期架构及升级背景 • 云原生改造过程 • 关键问题和思考 • 未来规划

48. 大规模集群关键问题与思考 • 调度能力 • 稳定性 • 资源效率

49. 调度能力 • 吞吐量、调度语义的权衡 • 生命周期和是否有状态对运维的影响

50. 稳定性 • 基础环境的可预期：标准定义、异常发现、异常处理和标准变更 • 组件稳定性：控制面组件和节点组件 • 资源隔离和QoS：关键是场景需要

51. 资源效率

52. 保有率 • 提升效率的手段运维提效，建设自动投产、维修系统 • 异常检查、自动恢复 • 降低节点级别异常频率：修复节点端各类问题、隔离系统和业务进程 • 节点/单卡故障自动维修 • 故障高效诊断、维修调度率 • • • • 通过抢占释放一些租户暂时不使用的资源作业分级，空闲卡跑低优作业跨集群跨卡型调度机制混部调度负载率 • 优化容器启动速度 • 全方位的作业生命周期异常行为探测，治理不合理用法 • MPS、MIG、vGPU等单卡复用技术 • 预测服务弹性伸缩

53. 未来规划 • 完成大数据离线和实时场景的云原生改造 • 场景间混部提升资源效率 • 构建场景适配的调度能力 • 持续提升稳定性和资源效率

54.