背景

云端图片、视频处理，非常费cpu or gpu，相对应的成本也非常的贵，因此，合理、有效、充分地调度好cpu、gpu资源显的尤为重要，毕竟，直接影响到成本。

痛点梳理

监控指标不够细

工欲善其事，必先利其器，要想做好：资源调度，必先收集好：相关的指标数据，以便：数据化决策。在实际项目中，资源调度与数据指标是相互完善的过程。

类别	类别	备注
pod指标	cpu利用率
pod指标	内存利用率
pod指标	集群的cpu核数
业务指标	图片处理个数
业务指标	视频处理个数
业务指标	输入视频时长
业务指标	处理时长/视频时长
业务指标	处理时长
业务指标	计算成功率
业务指标	错误码占比
队列指标	队列堆积数
带宽指标	上传带宽
带宽指标	下载带宽
带宽指标	下载耗时
带宽指标	上传耗时
小文件存储	结果文件容量
小文件存储	结果文件个数
小文件存储	中间结果文件容量
小文件存储	中间结果文件个数
小文件存储	输入文件容量
小文件存储	输入文件个数
月度账单	耗费多少钱（目录价 + 真实价格）

负载不均

1、因不同业务请求里面的图片、视频的复杂性，导致不同请求，所耗费的资源是不一样的，长时间跑起来，有可能会导致：有些cpu忙死，有些cpu闲死。
2、有些业务请求所包含的计算，是重cpu，例如：libx264转码，有些业务请求所包含的计算，是重IO，轻cpu，例如：视频合并。若调度不合理，会导致：忙的忙死，闲的闲死。
3、图片计算与视频计算，所费的资源是不一样的。因此，其pod所配置的并发数，也是不一样的。若配置不正确，极容易导致负载不均衡。

波峰波谷

大部分业务，都有此类特点，例如：晚上7点 ~ 晚上11点，波峰，但是：凌晨1点 ~ 凌晨7点，又是波谷。如果机器都按照：波峰时准备，那么，整个集群的利用率大概率不会超过：10%

资源不够

假如某一个业务量级突然之间暴涨，导致某个云上的所有GPU、CPU卡都不够了。此时，该如何处理？限流？不太合适吧？？

解决方案

大体流程如下图所示：

说明：
1、为啥需要MQ代理消费，请参考：算法、模型工程化相对应的章节。
2、请尽量单元化部署，毕竟：小文件存储的公网带宽，很贵，真的很贵。
3、以下策略，请根据实际情况，相互配合使用。

虚拟化

如今2024年了，应该没人继续使用物理机了吧？至少都是：K8S，或者上云。

设置合理阈值

不断地根据：监控指标 + 账单，不断地调整阈值。

资源分类

不同的业务请求，有不同的特点。例如：面对以下业务场景：

业务	特点	备注
社区相关：264转码	feed发布完，1min内处理完
社区相关：265转码	feed发布完，播放数超过多少时处理完，达人用户发布的视频，1min内处理完
社区相关：视频加水印	24小时处理完即可
社区相关：多码率	24小时处理完即可
视频meta信息查询	200ms以内，越快越好
图片meta信息查询	100ms以内，越快越好
工具相关：画质修复	分钟级处理完，或者：处理时长/视频时长 = 0.5
工具相关：超分	分钟级处理完，或者：处理时长/视频时长 = 0.5

需对cpu池子 + gpu池子，按照业务场景，进行分类。例如：以下仅仅只是举个例子，实际情况，根据实际业务来区分

topic	单个cpu核数	pod处理并发数	调度策略
video_0	8核	1	频繁
video_1	4核	1	次频繁
video_2	4核	1	凌晨频繁
img_0	8核	4	频繁
img_1	4核	4	次频繁
img_2	4核	4	凌晨频繁

被动调度

监听某个指标，如果大于预设的值，则采取某种扩容策略，小于预设的值，则采取缩容的策略。举些例子：

策略1：监听cpu的使用率，如果长时间高于60%，则逐步扩容多少个pod，反之，亦然。
策略2：监听内存使用率，如果长时间高于：90%，则逐步扩容多少个pod，反之，亦然。
策略3：从某个监控指标上（例如：grafana or 普罗米修斯）获取数据，如果某个指标大于某个预设的值，则逐步扩容多少个pod，反之，亦然。
策略4：从kafka的堆积lag数获取数据，如果大于某个预设的值，则逐步扩容多少个pod，反之，亦然。

主动调度

业务代码（例如：网关处），分析业务指标（例如：输入视频的时长、输入视频的大小） + 监控指标（当前cpu池子的负载情况），主动创建合适的cpu池子，来处理当前的业务请求。

定时调度

既然业务有波峰 + 波谷的特点，那么，可以按照业务的波峰波谷的时间，定时扩缩容cpu or gpu 池子。举个例子：

时间区间	操作	pod 区间
凌晨1点 ~ 凌晨7点	缩容	1 < pod个数 < 10
早上8点 ~ 早点12点	扩容	5 < pod个数 < 50
中午12点 ~ 下午14点	缩容	2 < pod个数 < 20
中午15点 ~ 下午17点	不变	2 < pod个数 < 20
中午17点 ~ 下午19点	扩容	10 < pod个数 < 60
中午19点 ~ 下午22点	扩容	60 < pod个数 < 120
中午22点 ~ 凌晨1点	缩容	1 < pod个数 < 10

备注：
1、以上仅仅只是举个例子，具体配置，得根据具体项目来分析。

同卡调度

在视频切片加速的场景下，同一个视频的不同片，需跑在同一种卡类型下，否则，会导致：花屏、黑屏等奇奇怪怪的问题（目前原因不明，有可能是不同型号的硬件，在细微差异上有问题）。因此，此时，需要对同一个视频的不同片，调度在同一种卡类型上。