阿里巴巴2020年云原生编程赛赛道二（一）题目解读

阿里巴巴云原生编程赛2—实现规模化容器静态布局和动态迁移

目前存在问题

业界多数调度器均通过通过队列使用不同打分策略以one-by-one的方式调度容器，设计上并不感知后续待调度容器信息，串行扩容顺序会左右调度结果，进而极大地可能会导致资源的浪费。因此需要感知集群状态，并且进行容器迁移以减少资源的浪费与作业队列等待

赛题描述

• 应用建模

1. 应用信息实际以 “应用名、应用分组” 两个维度的形式呈现，同一个应用名下会有多个应用分组(appName:group=1:N)
2. 集团内部应用与应用、分组与分组之间有各种调度规则约束，如应用分时错峰、CPU/内存密集型应用交错布局。但本赛题简化问题描述，不增加这些复杂约束
3. 集团应用根据不同画像特性，cpu-model定义了cpu-share、cpu-set 两种类型

• 约束描述

1. 在一定时间内调度的得分
2. 资源: 我们强约束机器上所有容器占用资源不能超过机器可用资源，尽可能避免因为超卖导致极端的cpu时间片争抢、OOM等情况发生。
3. 干扰：目前不涉及
4. 绑核: 我们期望在容器调度的时候，socket、core、cpu 对于不同的应用容器绑定上有削峰填谷的效果，抑或numa场景下同node下cpu分配。
   具体来说有一下三种约束：（1）应用容器（可能会使用多个cpu的时候）尽可能不要跨socket分配cpu（2）应用容器尽可能不要同core分配cpu。下图中应用5违背此规则。（3）cpu敏感应用容器之间尽可能不要同core分配cpu。
   总结起来就两句话对于使用多核的容器尽量不要夸socket分配；相同的容器或者cpu敏感型应用容器避免资源竞争不要同core分配cpu
5. 堆叠: 根据应用的特性，我们需要满足 堆叠和打散 的需求。一台机器上最多部署的容器个数

一句话概括任务需求

找到容器实例（pod）调度的最佳节点。

数据描述

• rule.source:有两个不太易混的字段

1. defaultMaxInstancePerNode：与堆叠约束相关，限制单机部署单个应用分组容器数量的上限
2. replicasMaxInstancePerNode：在容器实例到达一定数量的情况下，单机实例的堆叠数

结果评测

• 静态布局分数：S_static = S_resource(资源成本) + S_group(容器堆叠与打散约束) + S_cgroup(精细化cpu调度)

• 动态迁移：S_transition = S_migrate(迁移成本) + S_m-static(迁移后静态布局得分)

官方赛题详解

• 赛题优化角度

1. 调度结果满足设定的约束，并尽可能的降低约束
2. 最小化资源碎片，每个宿主机节点的资源尽量用完
3. 最少化机器使用量，节省机器成本

• 主要考察点

1. 打散约束：我们希望通过约束同一应用容器单机的部署数量，来减少宕机、同机其他容器对该应用容器的影响，且需要尽可能去优化容器堆叠数。
2. 绑核约束：期望同一宿主机上容器部署，单一容器尽可能不要跨socket分配cpu、单一容器尽可能不要同core分配cpu、敏感应用容器之间尽可能不要同core分配cpu。不然易给业务容器带来性能上的损失。
3. 迁移约束：容器动态迁移无论在调度链路还是业务稳定性上都是有损的，因而我们期望在动态调整整个集群时能够尽可能少的减少迁移的容器数量。

• 可供参考算法：

1. 可参考kubernetes多套打分调度算法。
2. 可参考各类启发调度算法。
3. 可参考各类搜索算法。
4. 可参考线性规划类调度算法。
5. 可参考mesos多资源DRF算法。
6. 可参考矢量装箱算法。
7. 可参考智能粒子群算法。
8. 可参考机器学习训练应用、机器分数权重来优化调度打分算法。

• 解题思路

1. 可考虑同规格应用合并优化。
2. 可考虑一部分数据提前贪心布局，一部分数据最优求解。
3. 可考虑混合多算法结合，如启发、群算法。
4. 可考虑将整个数据规模切分，分治法求解。
5. 可考虑利用多核特性并发求解，取最优。