我与volcano的那些事儿【与云原生的故事】
【摘要】 作者简介：李乾坤，喜马拉雅AI云开发工程师，专注于k8s、机器学习平台等领域。缘起我的职业经历蛮单调的，从毕业至今一直在一家公司。但岗位经历还蛮丰富的，一开始在公司做业务，后来做容器化，21年8月份转入公司的AI云平台团队负责机器学习任务训练，由此开始接触volcano。到目前为止，为volcao提过多个pr，包括根据label筛选volcano可以调度的node、 支持queue资源配额、...
作者简介：李乾坤，喜马拉雅AI云开发工程师，专注于k8s、机器学习平台等领域，技术博客：http://qiankunli.github.io。
缘起
我的职业经历蛮单调的，从毕业至今一直在一家公司。但岗位经历还蛮丰富的，一开始在公司做业务，后来做容器化，21年8月份转入公司的AI云平台团队负责机器学习任务训练，由此开始接触volcano。到目前为止，为volcao提过多个pr，包括根据label筛选volcano可以调度的node、 支持queue资源配额、支持task优先级、特定label的task保护、支持弹性等，有幸成为volcano的member，参与开源项目并成为其中的一份子，这种感觉就像一个士兵真的上过战场、打败过敌人一样骄傲，对应的，volcano带给我的成长也非常深刻。
理解调度
在我开始接触公司的机器学习平台的时候，集群就已经在用volcano了，主要是因为gang scheduler等特性。 我之前在做容器化的时候，已经深度接触了k8s，但那时主要支持web、rpc服务，对k8s调度器的理解仅限于“预选”和“优选”，一度以为k8s调度的世界就那样了。volcano给我打开了一个新世界的大门，正因为有批调度的存在，k8s 支持大数据、ai任务才成为可能（或者说这两类业务向k8s迁移的需求催生了批调度），再进一步支持业务、大数据、ai 等多种类型的workload 运行在一个集群上。作为技术人员，能为推动公司往这个方向走一走（推动业界就不敢说了），想想就是一个很激动的事情，也能基于此吃好几年的饭。做多种类型的workload混部，volcano所处的调度层，就是一个很好的着力点。
volcano也是我第一个深度接触的k8s周边产品，每一个k8s开发，都有一个写crd的梦。但之前接触的crd 都是workload类的，而volcano中的PodGroup/Queue/Job以及JobFlow等概念明显更复杂，基于k8s 可以实现如此复杂的功能，对k8s作为未来互联网基础设施的可行性又信了半分。volcano虽然支持的功能很多，但核心设计framework/action/plugin一直未变，可见volcano早期作者的设计功力。
机器学习弹性
在多个pr里面，我印象最深刻的功能是支持弹性调度，改动代码最多，耗时最长。说到弹性调度，人们天然想到的是HPA等机制，我当时也确实在测试环境详细的部署、测试过HPA，但发现机器学习任务的弹性用HPA 实现起来有很多不和谐的地方。核心区别是，普通web/rpc 要不要扩缩容跟服务当前的负载、延迟等有关系，核心是为了确保服务可用。而机器学习任务弹性的目的是：集群空闲的时候充分利用资源，紧张的时候（一些训练job缩一下）让更多的job可以run起来，核心是确保集群资源利用率（训练任务越快完成越好，但也有个上限，让机器学习任务1分钟训练完不实际也没必要）。这就意味着机器学习任务的弹性组件要了解整个集群的信息，不像HPA 一样监听至多两三个metric就行了。而了解整个集群的资源、job信息，非调度器莫属，所以机器学习任务的弹性是一定要volcano深度参与的。当然，还有一条路是volcano将所有必要的信息暴露出来，由外置的HPA组件做决策，但觉得有些麻烦。
当时先把这个想法拿到社区里讨论，得到了几个小伙伴的认可，后面详细梳理了volcano支持弹性需要做的六七个代码变更点，自然的，在这个过程中对volcano的设计、代码实现理解的更深刻了。对一个事情确定方向，再一步步梳理、落地，弹性feature到现在（22年4月）才接近落地， 是一个非常有意义的工程体验。具体细节参见 基于Volcano的机器学习任务弹性训练实践
开源项目的运作
在github之前，我从未深度参与一个开源项目，对一个开源项目的运作 连“见过猪跑”都算不上，最多就是在github上提几个issue，真正的参与进去之后，收获还是蛮多的。
- 对英文的使用，issue/pr 交流都需要英文，尤其是一些比较大的特性，volcano还要求撰写设计文档，很多特性中文说的通俗易懂都不容易，英文写一遍更是费了少头发。
- 之前我对git的使用仅限于“git clone/pull/commit/push/checkout”，不能更多了，我还是算可以的，习惯用命令行操作git，很多同事日常都是ui操作git。为volcano贡献代码时，因为要提交pr，并且提交完pr后，可能社区讨论后要改动一些细节，但为了方便大家review这个pr，就要保证这个pr只有一个commit，以便大家查看FileChanged，git rebase/cherry-pick 这些之前在我看来都是“只可远观不可亵玩”的大招，也不得不好好研究了一把。
- 一般来说，日常的工作是一个岗位一个坑，组内的小伙伴为一个大目标服务。但具体到每个人做的事情的细节，因为分工不同对彼此的工作内容不是很熟悉，碰到难题、方案抉择很难跟小伙伴有比较深度的讨论，有一种一个人在走夜路的孤独，这个时候，社区反而更容易找到相同关注点的人。此外，我是专注AI与volcano结合的，社区还有许多伙伴因大数据而关注volcano，那么一个feature提出，交由社区充分讨论，也促进了自己更全面的看问题。
- 对开源项目的运作流程有了一些了解，维护一个开源项目非常不易，每周社区例会、文档、自动化testcase（说实话，从业六七年也没有很认真的写过很多case）。一开始觉得效率特别低，恨不能上午有个想法改好代码，下午就合进master。但开源项目以文字异步沟通为主，大家日常有自己的工作，复杂点的pr可能还需要在社区例会上讨论，一个pr一般要两周左右才能合进去，但是一个项目要走的远，这也是一个必要的方式，也向volcano的维护者们致敬。
【与云原生的故事】有奖征文火热进行中：https://bbs.huaweicloud.com/blogs/345260
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）