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. 非常感谢您的观看