mid tier resource in koordinator

[j4ckstraw]

背景

https://koordinator.sh/docs/designs/node-prediction/ 引入了 mid 资源希望使用节点稳定的资源，将 prod 已申请未使用的部分超卖出来，相比 batch 资源更加稳定，提供较为稳定的超卖资源，提升节点利用率时保证超卖业务稳定性。但是目前mid资源模型有很多待改进的地方。

1. mid 计算方式，没有包含未分配资源，没有 prod 作业就没有 mid 资源可用
2. 缺少压制策略，是否需要压制，如何压制？
3. 缺少驱逐策略，是否需要驱逐，如何驱逐？
4. 使用mid资源的pod cgroup参数设置等

提案

User Story

Mid+LS：低优的在线服务，引入后一般不会对现有的Prod应用产生过多影响，不需要常态的压制策略，运行时的性能表现和Prod+LS基本一致，出现干扰时会被驱逐掉（比如整机水位突增）

Mid+BE：AI/流式相关的任务，资源消耗型，而且驱逐重算的代价比大数据作业（Batch+BE）高，对资源容量稳定性有要求，直接引入会对会对现有的Prod应用产生资源竞争和干扰，需要常态开启一些压制策略，避免干扰和驱逐。

理论上，一个节点内可以同时存在Prod+LS（高优在线）、Mid+LS（低优在线）、Mid+BE（AI、流式任务）、Batch+BE（大数据任务）几种应用。

优先原则

默认情况下，同样是LS，prod/mid的运行性能表现应该是基本相同的，对于BE for mid/batch也是类似的。QoS策略适配需要具体来看，但一般来说，对于QoS相同，Priority不同的情况，不需要拉开太大的差异，比如只是驱逐的优先顺序，像内存回收这种可以增加一些advanced的配置（常态下不需要配），但像CPU Group Identity这种，目前其实没有更细的配置粒度，所以暂时也不需要额外的适配。后续针对Core Schedule+cpu idle这类的高级能力需要考虑。

资源超卖

目前mid设计的是超卖形式：prod_reclaim*buffer_ratio1+prod_unallocatable*buffer_ratio2
接下来Mid也可以支持非超卖形式：prod_unallocatable*buffer_ratio ，参考mid-tier-overcommitment

扩展资源mid-cpu

使用mid-cpu：需要webhook对pod注入扩展字段（同batch），对于Mid+LS，需要额外的方法避免其进入到besteffort QoS，例如注入limit，kubelet会将其放入burstable组；request设置为0，不占用正常资源。

对于非超卖场景，prod与mid在调度时是否需要共享账本

共享账本情况下需要增加filter和抢占的能力，prod在pending时需要将mid抢占后才能调度。
非共享账本的情况下，需要单机或其他外围机制（descheduler），在必要的情况（热点）下对mid做迁移，Mid LS可能会影响到Prod LS。
取决于Mid账本的计算策略，自身带来的干扰程度，对于预设的目标场景下，Mid账本的计算应相对保守，且应用类型不应引入过多干扰。

QoS策略适配Mid LS/BE

CPU QoS

Group identity，在container级别根据qos配置，其余级别都是0，reconciler模式下不及时。直接在besteffort/burstable分组级别设置可以提升reconciler的及时性，但对cgroup层级的设计会有要求。

Resctrl QoS

根据QoS导入pid到分组

基于用量水位的驱逐（Memory Evict）

驱逐时根据优先级和资源用量做排序，先Batch再Mid，对于Mid+LS也可以考虑优先驱逐，以保证LS作业的性能。

CPU Suppress

常用于CPU QoS不支持的场景下，BE QoS受压制，压制范围根据水位阈值和其他Pod的用量计算，为了保证reconciler的及时性，目前在根组级别生效。

CPU Evict

只与满足度相关，只要Pod满足度低就驱逐，满足度有多种计算方式，目前虽然是从CPU Suppress的角度，长期应从OS指标的角度做，可以考虑类似现有memory evict方式，按照cpu使用率进行驱逐。

cfsQuota/memoryLimit设置

根据参数直接配置

Memory QoS

回收分级，container级别配置项直接设置
公平性
high：容器级别自身限制约束
min：建议为LS设置，不建议为BE设置
low：先回收BE，后回收LS，回收顺序受层级关系影响，BE/LS需要同层
异步回收按配置

cpuShare

Mid+LS：和其他LS的应一致（Prod+LS），包括层级和系数
Mid+BE：和其他BE的应一致（Batch+BE），包括层级和系数

cgroup层级位置

Mid LS放到burstable分组，Mid BE放到besteffort分组
pros：完整对标了K8s和Koordiantor的QoS模型
cons：需要通过webhook注入limit字段的方式，或者LS申请cpu，BE申请mid-cpu的方式实现；burstable分组的cpu shares会被kubelet定期刷新

trade-off-result

使用mid-cpu/mem扩展资源
Mid与Prod在调度器不共享账本
对Mid+LS，使用webhook注入limit，让其进入burstable qos分组管理，Mid+BE直接默认进入best-effort

完善mid资源后，koordiantor将支持以下组合，参考koordinator QoS
koor-priority和resource type绑定

koor-priority	resource type	koord-QoS	k8s-QoS	应用场景
koord-prod	cpu/memory	LSE	guaranteed	中间件类应用
koord-prod	cpu/memory	LSR	guaranteed	高优在线服务，CPU绑核
koord-prod	cpu/memory	LS	guaranteed	高优在线服务，微服务工作负载
koord-prod	cpu/memory	LS	burstable	高优在线服务，微服务工作负载
koord-mid	mid-cpu/mid-memory	LS	burstable	低优的在线服务
koord-mid	mid-cpu/mid-memory	BE	besteffort	AI/流式相关的任务，资源消耗型
koord-batch	batch-cpu/batch-memory	BE	besteffort	大数据任务等
koord-free	待定	待定	待定	待定

TODO

• mid 计算方式，没有包含未分配资源，没有 prod 作业就没有 mid 资源可用
• midresource runtimehook，配置使用mid资源pod的cgroup 相关参数
• BE压制策略修改以适配mid资源
• 驱逐策略修改以支持mid资源

thanks co-authors: @zwzhang0107 @jiasheng55
more information see discussion at https://shimo.im/docs/5xkGoegGB8fvM9kX/

[eahydra]

Mid + BE 对外透露还是有点困惑的。虽然目的是为了获得更稳定超卖的资源以及获得压制的机制，但是理解上就会联想到Batch + BE，使用即Mid 资源的BE策略和Batch的BE策略有啥具体的区别么？

[j4ckstraw]

没有，除了mid资源相对batch资源更加稳定，驱逐更少之外，QOS上应该没有其他差异。

[j4ckstraw]

@eahydra 好的，mid+BE我们也不太需要，只是设计上感觉可以这样。如果不合适可以暂不添加。
还有其他问题吗？

[zwzhang0107]

一些调度/重调度相关的优化讨论没有列进来：打散/filter/迁移，另外可以提交一个正式的proposal了。

[j4ckstraw]

关于迁移我理解是Mid+LS要优先保证性能，如果节点资源紧张可以考虑优先驱逐Mid+LS，而非Batch+BE。
关于调度和重调度确实了解不多。还请帮忙补充。@zwzhang0107

[j4ckstraw]

proposal编写中 ✌️

[j4ckstraw]

#1762

[saintube]

Resctrl/RDT 的使用，Mid 资源有没有考虑做不同的划分规则（有无场景需求）

[j4ckstraw]

resctrl按照QoS设置（LS或者BE），暂时没有考虑新增QoS级别。

暂无特殊场景需求。