容器工作流

背景

目前某平台使用计算容器和解析容器，这两种容器目前通过rabbitmq消息来进行链接，形成容器工作流，使用容器工作流框架可以省去两个容器中间环节的控制，不需要再使用java代码对容器的操作，通过容器工作流框架即可控制容器之间的启动。

kubeflow-pipeline

1 介绍

kubeflow-pipeline (KFP)项目，是 kubeflow 社区开源的一个工作流项目，用于管理、部署端到端的机器学习工作流。KFP 提供了一个流程管理方案，方便将机器学习中的应用代码按照流水线的方式编排部署，形成可重复的工作流；由google开源，其全面依赖Argo作为底层实现，Argo是一个开源原生容器工作流引擎用于在Kubernetes上开发和运行应用程序。

2 安装部署

kubeflow Pipelines独立安装方式如下：

export PIPELINE_VERSION=1.8.1

kubectl apply -k "github.com/kubeflow/pipelines/manifests/kustomize/cluster-scoped-resources?ref=$PIPELINE_VERSION"

kubectl wait --for condition=established --timeout=60s crd/applications.app.k8s.io

kubectl apply -k "github.com/kubeflow/pipelines/manifests/kustomize/env/dev?ref=$PIPELINE_VERSION"

注意：需要替换grc.io中的镜像，grc.io在国内目前无法访问，需使用hub.docker.com仓库镜像地址：https://hub.docker.com/u/lingduhuanbing。

安装的负载：

pipline server：处理来自SDK和UI的请求，用于Pipeline、Experiment、Run的的管理（创建、删除、查看、对比等）

ml-pipeline-ui	Kubeflow Pipeline UI静态页面的加载；为将前端页面的服务请求转发给ml-pipeline-server和mlmetadata
ml-pipeline-server	主要用来响应Kubeflow Pipeline UI和Kubeflow Pipeline SDK发送的请求；
ml-pipeline-persistence-agent	监听workflow和scheduler workflow两个对象，并将监听到的信息汇报给ml-pipeline-server并存储到mysql中

controller：用于实现常规工作流和定时任务工作流的controller

Workflow-controller	Kubeflow Pipelines直接使用了argo的workflow controller来实现工作流的step调度功能
scheduled workflow controller	用来执行周期性workflow的controller，其会监听workflow和scheduler worklfow两类对象，并判断对应的scheduler workflow是否到达下一个周期，如果是则会创建一个新的workflow；

storage：存储pipelines相关的元数据和artifact数据；

minio	日志等文件
mysql	存储容器运行的详情数据

MLmeta：用于实现mlmeta功能的组件

metadata-grpc-deployment	Google开源的ml metadata，用于record和retrieve机器学习相关的metada data；其本质是一个grpc server，外界通过grpc client进行数据的写入和读取，metadata server则将数据写入到mysql中；
metadata-envoy-deployment	是一个proxy，Kubeflow Pipeline UI通过grpc-web访问metadata grpc server时，需要使用其进行协议的转换；
metadata-writer	是一个controller，其watch所有属于workflow的pod，并调用metadata的grpc接口将pod的Artifact信息写入到metadata grpc server中；

cache step：用来缓存已经执行过的容器

cache-deploy-deployment	用来创建MutatingAdmissionWebhook，会match所有label为pipelines.kubeflow.org/cache_enabled: "true" 的create pod请求，并发送给cache-server.
cache-server	webhookserver会判断request的pod是否命中cache，如果命中则会对pod进行更改，以使得该pod不再执行真正的工作流任务

3 使用

通过python脚本编写容器流，生成yaml文件，该yaml 文件可通过pipeline ui提交运行也可通过脚本提交接口运行容器工作流；在此通过脚本提交运行。

定义工作流，这里定义了两个容器，分别是计算容器和解析容器：

调用接口，运行容器工作流：

4 架构设计

Pipeline web server & Pipline Service：用来创建、管理和展示pipeline、experiments、runs和artifacts等信息；

Pipeline Persistence Agent：用来watch pipeline执行的相关信息，并向信息写入到Mysql和mlmetada中；

orchestration controllers：Kubeflow Pipelines所使用的controller，典型的如Argo Workflow controller用来执行workflow、Scheduler Workflow Controller用来执行定时任务；

Artifact storeage：用于存储每次pipeline运行的input、output和日志等信息；

5 总结

Kubeflow-pipeline 目前启动16 个容器，启动的容器较多；安装过程中，可能会下载失败；

不过，kubeflow-pipeline 拥有UI 操作界面，可以看到容器工作流的工作状态；目前在模型云平台中（开发环境）已经实现该容器工作流框架。

二，Volcalno

1 介绍

Volcano是一个基于 Kubernetes 构建的批处理系统，主要用于高性能计算场景，支持大部分的主流计算框架，它还提供了包括基于各种主流架构的CPU、GPU在内的异构设备混合调度能力；Volcano 也是云原生计算基金会(CNCF) 的孵化项目

2 安装

通过 Deployment Yaml 安装，这种安装方式支持x86_64/arm64两种架构；在你的kubernetes集群上，执行如下的kubectl指令。

Kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/master/installer/volcano-development.yaml

安装的负载：

vc-scheduler	根据配置的调度策略为每一个 Pod 选取合适节点，调度策略都以插件的形式存在。 eg：DRF, Priority, Gang
vc-webhook-manager	校验yaml文件是否合法及设置默认值；eg: schedulerName,queue
vc-controller-manager	用于 Volcano Job/PodGroup/Queue 自定义资源的生命周期管理

安装的配置字典：

volcano自定义资源：

3，使用

编写 JobTemplate yaml 文件,用于定义任务模板，分别对应计算模板和解析模板。

编写JobFlow yaml 文件，用于定义任务的依赖关系。

4 架构设计

Volcano scheduler的工作流程如下：

① 客户端提交的Job被scheduler观察到并缓存起来。

② 周期性的开启会话，一个调度周期开始。

③ 将没有被调度的Job发送到会话的待调度队列中。

④ 遍历所有的待调度Job，按照定义的次序依次执行enqueue、allocate、preempt、reclaim、backfill等动作，为每个Job找到一个最合适的节点。将该Job 绑定到这个节点。action中执行的具体算法逻辑取决于注册的plugin中各函数的实现。

关闭本次会话。

Actions

enqueue	Enqueue action筛选符合要求的作业进入待调度队列。当一个Job下的最小资源申请量不能得到满足时，即使为Job下的Pod执行调度动作，Pod也会因为gang约束没有达到而无法进行调度；只有当job的最小资源量得到满足，状态由”Pending”刷新为”Inqueue”才可以进行。一般来说Enqueue action是调度器配置必不可少的action
allocate	Allocate action负责通过一系列的预选和优选算法筛选出最适合的节点。
preempt	Preempt action负责根据优先级规则为同一队列中高优先级任务执行抢占调度。
reclaim	Reclaim action负责当一个新的任务进入待调度队列，但集群资源已不能满足该任务所在队列的要求时，根据队列权重回收队列应得资源。
backfill	backfill action负责将处于pending状态的任务尽可能的调度下去以保证节点资源的最大化利用。

Plugins

gang	Gang调度策略是volcano-scheduler的核心调度算法之一，它满足了调度过程中的“All or nothing”的调度需求，避免Pod的任意调度导致集群资源的浪费。具体算法是，观察Job下的Pod已调度数量是否满足了最小运行数量，当Job的最小运行数量得到满足时，为Job下的所有Pod执行调度动作，否则，不执行。
conformance	conformance plugin认为命名空间kube-system下的任务具有更高的优先级。这些任务不能被抢占。
DRF	DRF plugin认为占用资源较少的任务具有更高的优先级。它会尝试计算已分配给抢占者和被抢占者的资源总量，并在抢占者资源资源份额更少时触发抢占行为。
nodeorder	nodeorder plugin通过一系列维度的打分算法，算出针对某个任务时所有的节点的得分情况。得分最高的节点被认为是针对该任务最合适的节点。
predicates	predictions plugin通过一系列维度的评估算法，决定某个任务是否适合被绑定到某个节点。
priority	priority plugin用于比较两个job或任务的优先级。它通过比较job.spec.priorityClassName来决定哪个job的优先级更高。对于两个任务，它会依次比较 task.priorityClassName、task.createTime、task.id in order来决定谁的优先级更高。
Binpack	binpack调度算法的目标是尽量把已有的节点填满（尽量不往空白节点分配）。具体实现上，binpack调度算法是给可以投递的节点打分，分数越高表示节点的资源利用率越高。binpack算法能够尽可能填满节点，将应用负载靠拢在部分节点，这非常有利于K8S集群节点的自动扩缩容功能。
Proportion	Proportion调度算法是使用queue的概念，用来控制集群总资源的分配比例。每一个queue分配到的集群资源比例是一定的。举例来说，有3个团队，共享一个集群上的资源池：A团队最多使用总集群的40%，B团队最多使用30%，C团队最多使用30%。如果投递的作业量超过团队最大可用资源，就需要排队。

5 总结

Valcano目前启动 3 个容器，其中volcano-scheduler 容器占用3G内存，占用较多内存，安装较快，没有相应的UI界面，通过自定义资源实现容器工作流，目前没有对应的SDK 或接口可以操作该自定义资源，目前该框架还未接入模型云框架中。

三，综合比较

	Kubeflow-pipeline	vocalno
安装	容器较多，需替换镜像	启动容器较少
接口调用	可通过http接口启动	无
UI界面	可通过界面查看容器运行情况	无
Yaml数量	1个	2个
Yaml文件编写	可通过python脚本自动生成	手动编写
接入情况	模型云平台已接入	无