K8S在美团机器学习平台落地和实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. K8S在美团机器学习平台的落地与实践吴通机器学习平台资源与系统组负责人

2. 目录 CONTENT 01 对比几种场景 02 K8S service 改造 03 Pallas 介绍 04 Kube-collector 介绍 03 未来规划

3. 01 场景对比此前是基于YARN，后切换至K8S

4. 几种场景的对比 ADD RELATED TITLE WORDS • 美团机器学习平台隶属于数据平台 • 此前机器学习平台依赖使用Hadoop YARN 2.7.1管理资源，为此扩展了YARN的能力 • 支持Docker • Gang scheduling • Node Attribute/Placement Constraint • A100多网卡支持拓扑优化 • 更强大的节点健康检查 • 但不同场景特征不同，对资源管理的要求不同

5. 离线场景特征 ADD RELATED TITLE WORDS • 主要负载是ETL和查询，使用YARN作为资源调度系统 • ETL的特征是： 1）同一时刻有大量task等待分配资源，有大量task完成并释放资源 2）Task对资源一般无约束语义表达，仅存在资源数量的诉求 • 由1）决定离线场景资源调度的核心问题是提升调度吞吐 • 由2）决定调度算法能迅速为Task匹配目标节点。 • 美团数仓生产高峰，调度吞吐在8000+/s • K8S由于元数据存储在ETCD，各组件通过watch机制获取数据更新，调度吞吐很能达到要求，业界优化在1600+/s左右

6. 机器学习场景资源特征 ADD RELATED TITLE WORDS • 核心是管理好GPU资源，业界GPU硬件迭代频率在18-30个月 • 管理好GPU，在于用起来-单卡用好-单机用好-分布式用好 • 用起来：减少GPU碎片、闲置 • 单卡用好：合理申请资源、GPU共享 • 单机用好：考虑CPU/GPU/网卡等在NUMA/PCIE/NVLink层面的拓扑 • 分布式用好：考虑跨机通信，需协同硬件选型、网络基础设施和上层引擎

7. 机器学习场景负载特征 ADD RELATED TITLE WORDS • 负载以深度学习任务为主，分为离线训练和在线推理，调度吞吐要求很低，以美团实际负载为例 • App日提交量：2000+ • 峰值调度吞吐：100+ • 需支持上层引擎复杂的调度语义 • 调度算法不用追求高吞吐，而追求更高的调度质量，基于K8S

8. 我们改造了什么 ADD RELATED TITLE WORDS • • • • • • 改造K8S service，使之支持underlay容器网络自研调度器 GPU device plugin支持PCIE拓扑优化节点健康检查支持RDMA 支持pod安全访问HDFS

9. 02 K8S service改造

10. K8S service改造 ADD RELATED TITLE WORDS • • ClusterIP service原理 1. Kube-apiserver为service分配一个VIP 2. Endpoint Controller根据label创建同名的endpoint对象， endpoint维护了VIP和多个关联Pod IP（假设IP为A、B、 C）的映射 3. Kube-proxy（以iptable模式为例，部署在每个Node）监听到endpoint对象，会添加iptables DNAT规则，作用是：当目标IP:Port是VIP:6379时，随机修改为 A/B/C:6379 4. 这样当在内Pod内访问VIP:6379时，经过内核的 netfilter模块修改后，实际访问是A/B/C:6379 并非所有CNI网络都支持ClusterIP service

11. K8S service改造 ADD RELATED TITLE WORDS • CNI可分为两类：overlay和underlay • Overlay：功能全、性能相对差、不能和外部资源互联、支持ClusterIP service • Underlay：性能好，和外部资源互联，不支持ClusterIP service • 美团使用的是underlay CNI，但我们期望支持ClusterIP service

12. K8S service改造 ADD RELATED TITLE WORDS 以pod1访问pod3为例，即10.140.87.97 -> 10.140.73.171。 1. pod1的路由表的默认网关是10.140.87.1，因此数据会转发给10.140.87.1 2. 在数据链路层目标mac地址是X，网络包进入br0， br0检查和自己的mac地址不符，因此将报文广播出去 3. TOR1接受到网络包进入到网关10.140.87.1（mac 地址相同），再通过上层的leaf交换机，将包转发给TOR2 4. 以1.2相反的步骤访问到pod3 Pod1往外发出的网络包不会经过netfileter模块，因此 kube-proxy设置的iptables规则会失效。

13. K8S service改造 ADD RELATED TITLE WORDS • • 核心思路：service是四层负载均衡的，而美团有四层负载均衡的中间件mgw，借助mgw可以实现service的转发功能具体改造方案（以创建service为例）如下： 1. 移除kube-proxy 2. 引入一个MutatingAdmissionWebhook 3. 修改Endpoint Controller逻辑

14. K8S service改造 ADD RELATED TITLE WORDS • • • 简单介绍改造原理，以先创建service，再创建两个pod为例创建service流程为： 1. Kube-apiserver调用webhook 2. webhook调用mgw api创建mgw VIP并patch给Kube- apiserver 3. Kube-apiserver将mgw VIP写入service clusterIP 创建pod时会发生为： 1. Endpoint Controller监听到两个pod创建 2. 这两个pod被service label选中，且pod不在endpoint 对象的subset 3. 调用mgw api将两个pod ip绑定给VIP

15. 03 Pallas介绍

16. 为什么要自研 ADD RELATED TITLE WORDS • Pallas是替代kube-scheduler的自研调度器 • 美团机器学习平台是面向多租户的 • 外卖/买菜/视觉/无人车等业务称为一个租户，一个租户下分别多个队列是使用资源 • 平台向租户保证任意时刻都是保证其配额，比如<10000Core, 40000GB,1000GPU>，配额保证是第一约束 • 配额保证几乎改变了调度的所有流程，比如分配时优先非给配额满足率的用户、抢占仅能抢占那些使用量高于配额的队列中的Pod

17. 为什么要自研 ADD RELATED TITLE WORDS • • 对吞吐量要求高于kube-scheduler的能力 • 结合线上实际情况，吞吐率期望能达到200+/s，kube-scheduler压测显示在 60左右 • 自研调度器Pallas吞吐率未优化峰值在200+/s，预计轻度优化可有2-3倍提升更丰富的特性 • Gang scheduling • 拓扑距离优化 • 精确的调度归因 • DAG调度 • App内按优先级抢占 • 多资源池

18. 重要概念 ADD RELATED TITLE WORDS • • • • • 集群中唯一的调度器两级队列设计：父队列代表租户，子队列为租户内部的某种规则划分 Pod分为两类system pod和user pod，system pod不属于某个队列，user pod属于某个队列 System pod一般是一些系统组件，会部署在一些专用的机器上（daemonset是所有机器），因此无须执行优选流程，也不会被抢占 User pod是业务负载，按照对业务承诺进行调度，流程复杂

19. Pallas关心的对象 ADD RELATED TITLE WORDS • • • • 父队列和podGroup是CR podGroup在调度器内被描述成Job Pod在调度器内被描述成Task 队列 – 子队列 –Job– Task是树形结构

20. 调度架构设计 ADD RELATED TITLE WORDS • • • • Pallas的执行流程是：open session – close session – sleep的无线循环 open session会从informer cache中复制队列、Job和Task数据，以实现调度流程的无锁化 session会依次执行allocate_system、pre_allocate、allocate、preempt等流程 • allocate_system负责分配system pod • pre_allocate负责分配被释放的抢占过来的资源 • allocate是最主要的分配流程 • preempt是抢占流程 close session会记录各类指标、事件

21. 调度架构设计 ADD RELATED TITLE WORDS • 以allocate为例，分配流程如下： 1. 选择一个配额满足率低的父队列P 2. 从P中选择一个配额满足率低的子队列C 3. 从C中选择一个排序靠前的Job J（排序算法可通过插件定制） 4. 构建一个事务分配器（gang scheduling） 5. 从J中选择一个排序靠前的Task T（排序算法可通过插件定制） 6. 为T执行预选-优选-绑定等流程

22. 04 Kube-collector 介绍请替换文字内容，点击添加相关标题文字

23. Kube-collector介绍 ADD RELATED TITLE WORDS • • 实现高可观测性三个关键因素是：日志、指标和跟踪构建丰富的指标体系依赖完善的指标收集系统 • 要收集三类信息：event、object和prometheus的监控数据

24. Kube-collector介绍 ADD RELATED TITLE WORDS • • • • kube-collector根据配置从三类数据源获取更新，并写入磁盘日志收集系统会将变更写入kafka 借助内部实时数仓做去重、合并、聚合计算将kafka中计算好的数导入OLAP数据库Doris

25. Kube-collector介绍 ADD RELATED TITLE WORDS

26. 04 未来规划请替换文字内容，点击添加相关标题文字

27. 未来规划 ADD RELATED TITLE WORDS • 持续优化调度器 • 进一步提升调度性能，包括：参数优化、减少复制、拆分锁 • 交换机拓扑优化 • 调度参数推荐 • 智能调整资源池规模 • DAG调度 • 对接内部存储DolphinFS • IO/网络带宽隔离 • 支持PMEM、DPU、国产GPU等更多硬件 • 从任务和平台视角进一步提升系统可观测性 • 期待加入我们：wutong21@meituan.com

28. 非常感谢您的观看