B站容器平台混部和容量管理实践
如果无法正常显示，请先停止浏览器的去广告插件。
1. B站容器平台混部和
容量管理实践
B站资深开发 / 许龙
2.
3. 大纲
• 各类混部场景的实践方案
•
CPU在离线混部：在线+转码、在线+大数据
•
CPU潮汐混部：推搜+大数据
•
GPU常态混部：推理+转码
•
GPU潮汐混部：推理+训练
• 容量管理的实践方案
•
弹性伸缩：VPA和HPA
•
合池：quota管理、算力标准化
•
容量运营与可视化
4. B站容器平台架构
• CPU核数：百万级
• 除部分大数据、中间件外全部容器化
离线业务
在线业务
业务层
主站
平台层
直播
发布平台
广告
…
电商
机器学习平台
AI训练
视频转码
边缘计算平台
…
大数据
批处理平台
资源调度 容量管理 混部框架 集群管理
容器运行时 k8s组件 CNI/CSI 镜像仓库
容器
引擎层
基础
设施层
自
建
IDC
服务器
网络
存储
公有
云
云主机
云专线
云存储
5. 混部实践方案
CPU在离线混部 CPU潮汐混部 GPU混部
•在线+视频转码
•在线+大数据 •推搜+大数据 •推理+编解码
•推理+训练
6. CPU在离线混部的难点
调度
• 混部任务尽量不占用在线任务的可用配额（cpu/memory request）
• 调度器需要动态感知节点的可混部资源量
• 满足离线任务的E2E调度性能
QoS保障
• 在线任务的性能不被离线任务干扰：精细化隔离措施（cpu/内存/磁盘/网络…）
• 离线任务也需要一定的性能保障：区分混部资源质量
7. CPU在离线混部的架构
在线发布平台
批任务处理平台
offline colocation pod
online pod
任务下发模块
• 在线任务通过容器发布平台下发
• 离线任务通过批处理任务平台下发
master
kube-scheduler
kube-apiserver
调度模块
• 在线任务采用原生调度器
• 离线任务采用volcano调度器
• 离线任务基于k8s扩展资源进行调度
混部agent模块
• 混部算力的动态计算和上报
• 资源隔离
• 监控数据上报
配置管理模块
• 不同节点组的混部策略管控
webhook
volcano
extended resource
K8s node
cluster
k8s node
k8s node
k8s node
online
pod
offline
pod
colocation-agent
colocation
config manager
prometheus
8. CPU在离线混部-资源上报
混部资源上报
• 基于在线负载，动态计算可混部资源
• 采用k8s device-plugin机制，上报混部扩展资源、
• 通过本机指标采集计算，去除外部监控链路依赖
• 资源分级，结合资源池画像，区分高低优混部资源
高优资源：资源比较稳定，离线任务可较长期稳定
运行
Node
Allocatable:
caster.io/colocation-stable-cpu:
10
caster.io/colocation-free-cpu: 5
api-server
Update node info
kubelet
Colocation agent
Device Manager
register resource
Device Plugin
低优资源：资源比较波动，离线任务容易受到压制
或驱逐
compute resource
在线
离线
k8s node
9. 视频转码业务方
CPU在离线混部-调度方案
服务网关
视频转码场景的挑战
• 计算规模庞大：日均千万级任务
• 计算资源异构：CPU/GPU/混部/混合云
• 系统压力大：并发高，E2E拉起速度要求高
批任务调度模块
Job-manager Job-manager Job-manager
Scheduler
(slave) Scheduler
(master) Scheduler
(slave)
批任务调度模块
• 对混部业务方提供统一的openAPI
• 多集群调度：支持资源余量、优先级等策略
• 单集群调度：采用volcano调度器+自定义plugin
• 高可用：无单点可扩展、支持限流
•
支持多租户
单集群调度性能优化
• etcd：分离event、使用nvme等
• apiserver/controller调大限速
• 镜像p2p下载
• Volcano深度优化：例如job到pod的创建延迟优化
上报资源预留、任
务状态等信息
apiserver apiserver
volcano volcano
agent agent
cluster1 cluster2
Other clusters
10. CPU在离线混部-资源隔离
/sys/fs/cgroup
kubepods
混部大框
besteffort burstable
podxxx podxxx
Podxxx
(guaranteed)
• 根据在线负载动态计算可混部资源量
• 根据可混部资源量调整大框cgroup
混部大框
混部大框
16C/48G
在线负载升高，
混部动态调小
在线负载降低，
混部动态调大
Node
混部大框
8C/16G
混部大框
32C/100G
Node
Node
11. CPU在离线混部-资源隔离
CPU隔离
• 混部大框：最小cpu share、动态扩缩
• 第一阶段：混部绑核（考虑HT）
• 第二阶段：内核层cpu调度优先级
12. CPU在离线混部-资源隔离
内存隔离
memory.limit
• 混部大框：动态扩缩
memory.wmark_high
• 第一阶段：调节oom_score_adj
• 第二阶段：内核层oom优先级；memcg page cache异步回收
page cache
memory.wmark_low
网络隔离
• 离线转码任务采用bridge网络，使用host-local ip
• 基于TC进行混部pod的网络带宽限速
驱逐避让
• 针对内存、磁盘等不可压缩资源，达到阈值后触发混部任务驱逐
• 驱逐冷却
rss
13. CPU在离线混部-资源隔离
内核隔离参数设置方式
• 基于runtime proxy
• 容器创建时，通过hook设置内核参数，
时效性更高
• 后续考虑切到containerd的NRI方式
14. CPU在离线混部-大数据混部场景
申请资源
AM
yarn (resource manager)
资源上报/超配
Yarn NM on k8s
启动MR/spark task
• Yarn NM作为daemonset部署到k8s node
• 混部agent动态上报资源给NM中的agent
• Yarn技术优化：
• 支持remote shuffle
• 基于应用画像调度中小规格任务
• 跨机房网络带宽限速
NM pod NM pod
Amiya sidecar Amiya sidecar
混部资源上报
混部资源上报
colocation agent pod
colocation agent pod
基于在线负载计算
混部资源
基于在线负载计算
混部资源
online pod online pod
K8S node K8S node
k8s master
15. CPU在离线混部-全场景管理
混部资源供给
• 容器化机器默认开启混部
• 未容器化的业务，物理机利用率非常低，推动业务方将机器纳管到k8s跑
混部
• 备机池闲置机器，自动接入k8s跑混部
混部资源使用方
混部资源使用（多租户）
• 推动视频转码、大数据、AI等多种业务场景接入混部
• 高优混部资源：
•
• 资源相对稳定
• 跑高优混部任务，租户粒度设置固定quota
低优混部资源
• 资源较为波动
• 跑低优混部任务，租户粒度按比例分配quota
混部管理平台
• 策略管理
• 节点组、策略类型、水位控制等
• 监控大盘
• 各粒度资源上报量、分配量、使用量等
• 节点侧故障分析指标，内核层指标
视频转码
spark/flink batch
混部调度系统
混部策略管理
hadoop
AI处理
混部可观测
k8s
混部资源供给方
容器化机器
备机
非容器机器（redis、kafka、db、……）
16. 混部实践方案
CPU在离线混部 CPU潮汐混部 GPU混部
•在线+视频转码
•在线+大数据 •推搜+大数据 •推理+编解码
•推理+训练
17. CPU潮汐混部
在线：
1000台
在线：
1300台
08:00
大数据拆
借给在线
场景：推搜+大数据
• 推搜：
在线：
1000台
01:00
大数据回
收机器
正向潮汐
实例规格大，延时非常敏感，较难接受直接在离线直接混部
大数据：
1000台
凌晨使用资源少，白天使用资源多
• 大数据：
能容忍一定程度的排队以及任务延迟
大数据：
1000台
大数据：
700台
07:30
在线回收机
器完成
01:30
在线反向供
给大数据
凌晨资源使用多，白天资源使用少
在线：
900台
大数据：
1100台
07:00
在线开始逐
步扩容，
回收机器
在线：
700台
05:00
在线缩容到
最低
在线：
900台
反向潮汐
大数据：
1300台
大数据：
1100台
18. CPU潮汐混部-正向潮汐
• 自研cluster autoscaling组件
基于自定义k8s crd + controller
支持多种扩缩策略
支持多种资源供给方
• 独立潮汐应用，cronHPA定时扩缩，保障机器按时拆借、归还
• 基于机型的wrr负载均衡，解决机型差异问题
• SLO巡检告警
19. CPU潮汐混部-反向潮汐
• 在线业务基于利用率进行HPA扩缩
• 潮汐应用HPA缩容后如何尽量缩出整机，避免驱逐大规格实
例？
尽量将潮汐应用调度到同一节点
在凌晨HPA缩容前，通过算法挑选出最适合缩容的实例
，并打上delete-cost值
• 混部过程中，实时检测在线实例创建并驱逐nodemanger
20. 混部实践方案
CPU在离线混部 CPU潮汐混部 GPU混部
•在线+视频转码
•在线+大数据 •推搜+大数据 •推理+编解码
•推理+训练
21. GPU混部-vGPU调度
GPU共享调度
• 卡切分粒度：1%算力、256MiB显存
• 调度特性：
支持卡类型调度
支持多卡调度
支持显存调度（单卡跑多任务场景）
支持坏卡隔离
支持binpack，减少卡碎片
22. GPU混部-vGPU隔离
GPU隔离
• 业界隔离方案
MPS、MIG
CUDA劫持
内核劫持
• 方案选择
基于开源驱动的内核隔离
23. GPU混部-vGPU隔离
GPU内核隔离实现原理
自研BGM模块
Nvidia开源内核驱动
gpu-manger
• 用户通过cgroup接口配置一个组(应用)可用
的显存和时间片
• 在显存隔离上，驱动里获取显存信息时，通
获取显存信息
设置GPU隔离参数
显存限制api
获取GPU隔离配置
nvidia.ko
过BGM模块获取第1步配置的显存limit，保
设置时间片
证其不会用超上限
时间片限制api
• 在算力隔离上，在驱动里配置TSG的API里
，通过BGM模块获取第1步配置的slice覆盖
默认的2ms。
• APP申请0.3卡，则time slice设置为：
0.3*单卡调度周期
单卡调度周期
APP1
APP2
……
APP1
APP2
cgroup
24. GPU混部-编解码场景
GPU推理+转码
• 部分显卡比如 NVIDIA T4/A10 有独立的编码器和解码器
• 推理服务不使用编解码器，编解码利用率0
• 视频编解码任务主要使用编解码器
25. GPU混部-编解码场景
GPU推理+转码
• 通过GPU-manager组件上报编解码资源
• 单卡预留固定大小显存给编解码任务
• cuda没有干扰，只需要显存隔离
26. GPU混部-潮汐场景
批任务调度平台
在线任务HPA
apiserver
• 服务配置基于GPU利用率的HPA
K8s-scheduler
在线任务发布平台
• 白天扩容，凌晨缩容
HPA-controller
离线任务调度
• 批任务调度平台感知空闲卡数变化
缩容
扩容
• 离线任务通过平台调度到对应集群
Deployment/rc
任务退避
• 潮汐时间结束，离线任务主动退避
在线pod
在线pod
Deployment/rc
在线pod 在线pod
离线pod 在线pod
在线pod
在线pod
• 在线HPA扩容，调度器基于优先级主动驱逐抢占离线任
务
离线pod
离线pod
在线pod抢占离线pod
在线pod
在线pod
27. 容量管理
容量管理的问题
• 物理资源：划分小池、机型差异、多种调度器&调度策略
• 应用：手动扩缩容、规格不合理、发布缺资源等
易运营
预算
采购
配额
账单
• 运维：节点&应用容量变更无法追踪、缺乏容量趋势报表、缺
乏容量告警等
可运维 变更审计 容量巡检 运维平台
自动化 HPA VPA CA
标准化&统一化 资源合池 统一标准算力 统一调度
• 运营：预算评估困难、配额无管控、缺乏细粒度账单等
容量管理的目标
• 提升效率：通过自动化、流程化、可视化，降低人工操作成
本
• 降低成本：通过平台技术手段&应用治理，提升机器利用率
• 保障稳定性：通过巡检、弹性伸缩等手段保障业务稳定性
IDC&K8S
28. 容量管理实践方案
应用弹性伸缩 合池 可视化
•VPA
•HPA •基准核
•配额管理 •多维报表
•容量事件&巡检
29. 容量管理-VPA
背景
• 容器CPU request设置不合理，导致：节点CPU分配率
高，实际利用率却很低
• 资源池余量不足，用户发版经常卡单
• 服务数多，推动业务调整规格困难
整机总CPU
VPA
• 平台侧对外屏蔽request，用户只需配置limit
VPA
CPU Request
• request通过VPA自动调整至合理值
CPU Used
Node
Node
30. 容量管理-VPA
VPA推荐策略
• 基于服务等级：L0~L3
• 七日峰值分位数据 + 冗余度
VPA更新策略
• 新建pod，通过webhook修改为推荐的request
• 存量pod，基于自研inplace vpa，动态修改
request
31. 容量管理-VPA
VPA管理平台
• 策略管理、预跑、调优
• 策略避让
• 实际执行和效果数据分析
• 稳定性
32. 容量管理-HPA
HPA 1.0
• k8s原生HPA
• 扩缩容步长
• 冷却时间
HPA 2.0 HPA 3.0
• 独立prometheus，提高扩缩容 • 支持优先级，解决多种HPA共存
实效性：高频采集，短时存储
• 支持cronHPA ，满足周期性高
低峰业务的扩缩需求
• 支持预跑模式，满足部分首次接
入用户的验证需求
问题，例如指标HPA和
CronHPA
• 支持发布态HPA，解决发布过程
新老版本共存时的扩缩容问题
• 支持分段HPA，解决潮汐混部场
景中，大规格实例只允许凌晨扩
缩的需求
33. 容量管理-HPA
ScaleMode
• Enable
• Disable
• DryRun
Segments
• 一个HPA可以包含多个段，每个段单独设置时间段、优先
级、类型、上下限等
• 场景：解决部分推广搜服务服务启动耗时长，白天禁止缩
容，只允许晚上缩容
副本数决策
• Dynamic：基于指标动态扩缩
• Cron：定时触发
• Direct：指定时间段扩缩
决策优先级
• 优先取更高优先级的段计算副本数
• 相同优先级取 max replicas
34. 容量管理实践方案
应用弹性伸缩 合池 可视化
•VPA
•HPA •基准核
•配额管理 •多维报表
•容量事件&巡检
35. 容量管理-合池
CPU分配率
合池的必要性
• 便于平台统一管理
• 整合机器资源，共享buffer
• 任务资源规格多样，更容易互补
合池的挑战
• 机器&应用的标准化治理
• 机型不统一，同应用实例间利用率分层
• 配额管理
漫画物理资源池
直播物理资源池
在线统一资源池
OGV物理资源池
36. 容量管理-基准核
Total：110c
Pod占用：10c
cpu quota/share：9.09c
利用率分层问题
• 算力标准化
• 流量调度
Total：90c
Total：100c
Pod占用：10c
Pod占用：10c
cpu quota/share：10c cpu quota/share：11.1c
Total：100c
Total：100c Total：100c
Pod占用：10c Pod占用：10c Pod占用：10c
WRR
算力标准化
P2C算法
• 调度优化
Numa调度
负载感知调度
带宽调度
……
机型a
机型b
机型c
机型a
机型b
机型c
注：机型a作为基准系数1，机型b和c算力系数为0.9和1.1
37. 容量管理-配额管理
配额管理平台
• 支持cpu、memory、gpu等各类资源quota
配额管理平台
发布平台
HPA
• 可视化管理各级部门quota，支持增删改查、转移等功能
• 精细化运营操作：变更审计、各类趋势报表
配置quota
扣减quota
扣减quota
Quota系统
Quota系统
• 基于公司统一的服务树设置各级配额
• 支持发布平台、HPA等各类外部组件扣减quota，通过
resourceVersion解决扣减冲突
•
紧急情况支持一键关闭
各级部门配额
cmdb
应用配额
mysql
配额趋势
操作审计
redis
38. 容量管理实践方案
应用弹性伸缩 合池 可视化
•VPA
•HPA •基准核
•配额管理 •多维报表
•容量事件&巡检
39. 容量管理-可视化
基础容量
• 多维度：节点、资源池、集群、应用、组织等
多维报表展示
• 多指标：使用量、使用率、实例数、分配率等
• 多报表：趋势图、明细、汇总等
节点容量
资源池容量
集群容量
应用容量
业务组织容量
容量事件
• Node新增/删除/可调度/不可调度
clickhouse 容量管理平台
prometheus 发布平台
容量事件&巡检
• 应用发布实例数/规格变更
• HPA扩缩容
• 服务上下线
• …
容量巡检&告警
• 应用：峰值使用率、扩缩容建议
• 资源池：可调度实例数、分配率、峰值使用率
集群运维平台
40. 总结与展望
混部
• Spark/Flink native on k8s混部
• k8s和yarn统一调度
• 推搜等敏感业务场景混部
• 持续增强内核层CPU/GPU隔离能力
容量管理
• 进一步推进合池，优化合池后的调度、实例利用率分层等问题
• 推进基于混合云的集群弹性伸缩能力
• 集群联邦场景下的VPA、HPA、重调度等问题优化
41. 哔哩哔哩技术公众号
42.