基于 KubeVela 的机器学习实践
Posted CNCF
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了基于 KubeVela 的机器学习实践相关的知识，希望对你有一定的参考价值。
作者：Tianxin Dong，KubeVela 团队
在机器学习浪潮迸发的当下，AI 工程师除了需要训练、调试自己的模型之外，还需要将模型进行部署上线，从而验证模型的效果（当然，有的时候，这部分工作由 AI 系统工程师来完成）。这一部分工作对于 AI 工程师们来说是繁琐、且消耗额外精力的。
而在云原生时代，我们的模型训练和模型服务也通常在云上进行。这样做不仅提高了可扩展性，还能够提升资源的利用率。这对于需要消耗大量计算资源的机器学习场景来说，是十分有效的。
但是 AI 工程师要想使用云原生的能力通常比较困难。随着时间的推移，云原生的概念已经越来越复杂。想要在云原生之上部署一个简单的模型服务，可能对于 AI 工程师来说，需要额外学习数种概念：比如 Deployment、Service、Ingress 等。
而 KubeVela 作为一个简单、易用、且高可扩展的云原生应用管理工具，能让开发人员方便快捷地在 Kubernetes 上定义与交付应用，无需了解任何底层云原生基础设施相关的细节。KubeVela 拥有着丰富的可扩展性，其 AI 插件提供了模型训练、模型服务、A/B 测试等功能，覆盖了 AI 工程师的基本需求，能够帮助 AI 工程师快速在云原生环境中进行模型训练和模型服务。
本文主要介绍如何使用 KubeVela 的 AI 插件，来帮助工程师更便捷地完成模型训练及模型服务。
中找到所有的源码和 YAML 文件。如果你想使用在这个例子中预训练的模型，文件夹中的style-model.yaml 和 color-model.yaml 会将模型复制到 PVC 中。和 jupyter-notebook 两个组件类型， 模型服务中包含 model-serving 这个组件类型。可以通过 vela show 命令来查看这三个组件中的具体参数。你也可以选择查阅 进行模型训练。
仅仅是训练模型很难看出效果，我们修改一下这个 YAML 文件，将模型服务放到模型训练的步骤之后。同时，因为模型服务会直接启动模型，而模型的输入输出不太直观（ndarray 或者 Tensor），因此，我们再部署一个测试服务来调用服务，并将结果转换成图像。
部署如下 YAML 文件：
来查看应用的状态：$ vela ls
training-serving demo-training model-training running healthy Job Succeeded 2022-03-02 17:26:40 +0800 CST
├─ demo-serving model-serving running healthy Available 2022-03-02 17:26:40 +0800 CST
└─ demo-rest-serving webservice running healthy Ready:1/1 2022-03-02 17:26:40 +0800 CST可以看到，应用已经正常启动。通过
vela status <app-name> --endpoint来查看应用的服务地址。$ vela status training-serving --endpoint
+---------+-----------------------------------+---------------------------------------------------+
| CLUSTER | REF(KIND/NAMESPACE/NAME) | ENDPOINT |
+---------+-----------------------------------+---------------------------------------------------+
| | Service/default/demo-rest-serving | tcp://47.251.10.177:3333 |
| | Service/vela-system/ambassador | http://47.251.36.228/seldon/default/demo-serving |
| | Service/vela-system/ambassador | https://47.251.36.228/seldon/default/demo-serving |
+---------+-----------------------------------+---------------------------------------------------+该应用有三个服务地址，第一个是我们的测试服务的地址，第二个和第三都是原生模型的地址。我们可以调用测试服务来查看模型的效果：测试服务会读取图像的内容，并将其转成
Tensor并请求模型服务，最后将模型服务返回的Tensor转成图像返回。我们选择一张黑白的女性图片作为输入：
请求后，可以看到，输出了一张彩色图片：
查看模型服务的地址：
$ vela status color-serving --endpoint
+---------+------------------------------------+----------------------------------------------------------+
| CLUSTER | REF(KIND/NAMESPACE/NAME) | ENDPOINT |
+---------+------------------------------------+----------------------------------------------------------+
| | Service/vela-system/ambassador | http://47.251.36.228/seldon/default/color-model-serving |
| | Service/vela-system/ambassador | https://47.251.36.228/seldon/default/color-model-serving |
| | Service/default/color-rest-serving | tcp://47.89.194.94:3333 |
+---------+------------------------------------+----------------------------------------------------------+使用一张黑白的城市图片请求模型：
可以看到，第一次请求的结果如下。虽然天空和地面都被渲染成彩色了，但是城市本身还是黑白的：
再次请求，可以看到，这次请求的结果中，天空、地面和城市都被渲染成了彩色：
通过对不同版本的模型进行流量分发，可以帮助我们更好地对模型结果进行判断。
中带有style: transfer的请求，转发到风格迁移的模型。同时，使这个风格迁移的模型与彩色化的模型共用一个地址。注：风格迁移的模型来源于 查看模型服务的地址：
$ vela status color-style-ab-serving --endpoint
+---------+---------------------------------+-------------------------------------------------------+
| CLUSTER | REF(KIND/NAMESPACE/NAME) | ENDPOINT |
+---------+---------------------------------+-------------------------------------------------------+
| | Service/vela-system/ambassador | http://47.251.36.228/seldon/default/color-ab-serving |
| | Service/vela-system/ambassador | https://47.251.36.228/seldon/default/color-ab-serving |
| | Service/vela-system/ambassador | http://47.251.36.228/seldon/default/style-ab-serving |
| | Service/vela-system/ambassador | https://47.251.36.228/seldon/default/style-ab-serving |
| | Service/default/ab-rest-serving | tcp://47.251.5.97:3333 |
+---------+---------------------------------+-------------------------------------------------------+这个应用中，两个服务各自有两个地址，但是第二个
style-ab-serving的模型服务地址是无效的，因为这个模型服务已经被指向了color-ab-serving的地址中。同样，我们通过请求测试服务来查看模型效果。首先，在不加 header 的情况下，图像会从黑白变为彩色：
我们添加一个海浪的图片作为风格渲染：
我们为本次请求加上
style: transfer的 Header，可以看到，城市变成了海浪风格：
我们还可以使用一张水墨画的图片作为风格渲染：
可以看到，这次城市变成了水墨画风格：
总结
通过 KubeVela 的 AI 插件，可以帮助你更便捷地进行模型训练与模型服务。
除此之外，通过与 KubeVela 的结合，我们还能将测试完效果的模型通过 KubeVela 的多环境功能，下发到不同的环境中，从而实现模型的灵活部署。
参考资料[1] KubeVela Samples: https://github.com/oam-dev/samples/tree/master/11.Machine_Learning_Demo
[2]KubeVela AI 插件文档: https://kubevela.io/zh/docs/next/reference/addons/ai
[3]emilwallner/Coloring-greyscale-images: https://github.com/emilwallner/Coloring-greyscale-images
[4]TensorFlow Hub: https://tfhub.dev/google/magenta/arbitrary-image-stylization-v1-256/2
点击【阅读原文】阅读网站原文。
CNCF概况（幻灯片）
扫描二维码联系我们！
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请长按以下二维码进行关注。
BizWorks 应⽤平台基于 KubeVela 的实践
前⾔
BizWorks与KubeVela的合作始于1.0.5版本，BizWorks在1.0.5版本上完成了关键技术验证并且在1.2.5版 本上基础上扩展了BizWorks的应⽤部署和运维能⼒。通过近⼀年多的深度合作，BizWorks通过 KubeVela解决了⼀些痛点和诉求，同时基于KubeVela功能和特性也沉淀了⼀些实践，本⽂将分别通过介 绍BizWorks在KubeVela使⽤场景来讲述如何探索和实践云原⽣时代新⼀代PaaS平台持续交付能⼒的落地。
⼀、BizWorks介绍
BizWorks(https://bizworks.aliyun.com/)是⼀体化的阿⾥云原⽣应⽤的开发和运营平台，内置阿⾥巴巴 业务中台构建的最佳技术实践。产品主要包括：业务建模平台、业务应⽤平台、演练压测平台、能⼒运 营平台、⼀体化运⾏和运维平台。BizWorks提供的产品能⼒（图1-1），普遍适⽤于企业云原⽣应⽤⾼ 效开发以及企业业务能⼒沉淀和复⽤的场景。
图 1-1 BizWorks业务架构
BizWorks⼀体化运⾏和运维平台提供⼀站式的应⽤⽣命周期管理、运⾏托管和运维管控能⼒，⽀持多云 适配，因此应⽤的⽣命周期管理是不可或缺的，其中CICD作为应⽤持续演进的关键⽅式对客户产品发布 以及升级迭代扮演者⾄关重要的⻆⾊。
CI（持续集成）主要包括中台类应⽤、低代码类轻应⽤、托管类应⽤、集成类应⽤的构建和物料产出， 为客户透出个性化流⽔线能⼒，可以依据⽤户实际需求编排符合业务需求的流⽔线，也可以直接使⽤业 界沉淀的通⽤流⽔线产品。
CD（持续交付/持续部署）主要包括上述⼏类应⽤构建制品部署上线以及运维，为客户提供核⼼的部署 操作能⼒，⽤户可以基于内置的部署引擎完成应⽤的部署，同时也可以接⼊其他部署产品，例如EDAS。
本⽂将主要讲述探索如何使⽤KubeVela在BizWorks⼀体化运⾏和运维平台应⽤部署中落地。
⼆、应⽤交付的需求与落地
2.1 需求背景
BizWorks对于应⽤交付的需求主要包括两个思考，第⼀个是在云原⽣技术背景下，应⽤交付应该基于云 原⽣技术架构进⾏设计，因为采⽤的应⽤交付技术选型要能够⽀持相应的技术组件诉求；第⼆个是从业 务需求出发，当前应⽤交付配置⾯临碎⽚化的境况，包括环境配置、资源规格配置、持久化配置、⽹络 ⼆、应⽤交付的需求与落地 2.1 需求背景 3 路由配置等，同时对于应⽤交付制品类型也不尽相同。为了满⾜上述的需求，BizWorks选择使⽤ KubeVela来实现应⽤的持续交付，保证客户环境交付终态的稳定性和可靠性。
2.2 应⽤部署架构
⽬前Bizworks⽀持四种类型的业务应⽤，集成了部分开源或阿⾥云的中间件组件，其部分能⼒主要是通 过使⽤KebeVela的Application、Component、Trait以及WorkFlow来实现（如图2-1）。在KubeVela Component基础上BizWorks定义⾃⼰的⽆状态组件（stateless-component）、有状态组件（stafulcomponent）、组装⽹络（advanced-ingress-trait）等，然后通过KubeVela来屏蔽不同云⼚商或 Kubernetes底座的复杂性和差异性，构成了当前BizWorks的应⽤部署架构。
图 2-1 BizWork应⽤部署业务架构
2.2 碎⽚化配置的痛点与解决
对于平台来说提供的功能如果具有可扩展和灵活性的话，可以为平台增强现有能⼒和推出更好体验的功 能点带来强⼤的帮助。但是由于平台⾯对的使⽤者背景和诉求各不相同，为了能尽可能满⾜⼤多数场景 需求可能会导致配置化内容变得多⽽且散乱，这是当时⾯临的碎⽚化配置痛点。BizWorks的解决⽅案是 借助KubeVela丰富和强⼤的插件和运维特征补丁功能，⾸先KubeVela的拥有很多常⻅的插件，例如分批 发布、fluxcd等，并且也内置了很多可⽤性⾼的运维特征补丁，例如标签、注解、init-container、 ingress等。如果没有定制化需求的话，使⽤KubeVela⾃带的插件和运维特征补丁基本就可以满⾜需求；
如果需要针对平台⾃身能⼒进⾏定制的话也是可以的，这⾥以⾃定义运维特征补丁为例，介绍下 BizWorks如何实现⾃定义功能。
BizWorks应⽤在发布时，可以⽀持⽤户⾃⼰配置⽹络路由（如图2-2），因此就需要⽀持同时⽣效多个 ingress和service的配置。我们在KubeVela内置的ingress运维特征基础上进⾏了改进，⽀持批量传⼊声 明的⽹络路由配置，然后通过BizWorks以⾃定义运维特征的⽅式下发到KubeVela（相关cue定义⻅下⽅ 示例代码），最终⽣效到集群中。
"bizworks-ingress-comp-1-22":
type: "trait"
annotations:
description: "Enable public web traffic for the component, the ingress
API matches K8s v1.20+."
attributes:
podDisruptive: false
template:
outputs:
// trait template can have multiple outputs in one trait
if parameter.route != _|_
for _, v in parameter.route
"service-\\(v.serviceName)":
apiVersion: "v1"
kind: "Service"
metadata:
name: v.serviceName
spec:
selector: "app.oam.dev/component": context.name
if v.serviceType != _|_
type: v.serviceType
ports: [
port: v.servicePort
protocol: v.serviceProtocolType
targetPort: v.port
,
]
if v["ingressName"] != _|_
"ingress-\\(v.ingressName)":
apiVersion: "networking.k8s.io/v1"
kind: "Ingress"
metadata:
name: v.ingressName
annotations:
if !v.classInSpec
"kubernetes.io/ingress.class": v.class
if v.annotations != _|_
for _, t in v.annotations
"\\(t.name)": t.value
spec:
if v.classInSpec
ingressClassName: v.class
if v["ingressProtocolType"] == "HTTPS"
tls: [
hosts: [
v.domain,
]
secretName: v.secretName
]
rules: [
host: v.domain
http:
paths: [
path: v.path
pathType: "ImplementationSpecific"
backend: service:
name: v.serviceName
port: number: v.servicePort
,
]
]
parameter:
route: [...
// +usage=Specify the port your server want to expose
port?: int
// +usage=Specify the protocol your service want to expose
serviceProtocolType?: string
// +usage=Specify the name your service want to expose
serviceName?: string
// +usage=Specify the port your service want to expose
servicePort?: int
// +usage=Specify the type your service want to expose
serviceType?: string
// +usage=Specify the type your ingress want to expose
ingressProtocolType?: string
// +usage=Specify the name your ingress want to expose
ingressName?: string
// +usage=Specify the domain you want to expose
domain?: string
// +usage=Specify the path you want to expose
path?: string
// +usage=Specify the tls secret you want to use
secretName?: string
annotations?: [...
name: string
value: string
]
// +usage=Specify the class of ingress to use
class: *"nginx" | string
// +usage=Set ingress class in '.spec.ingressClassName' instead of
'kubernetes.io/ingress.class' annotation.
classInSpec: *false | bool
]
图2-2 BizWorks应⽤⽹络路由配置
2.4 实践案例
⾸先以⼀个⽆状态组件应⽤发布为例，介绍如何使⽤KubeVela完成应⽤发布计划。BizWorks继承OAM 设计理念，将应⽤作为⼀个交付的整体，其内部由不同类型的组件构成，并且组件可以通过绑定⾃定义 运维特征补丁。应⽤内的组件可以按照⾃⼰的发布计划⾃⾏发布，并且组件之间产⽣的⼯作负载和⽹络 拓扑不会彼此影响，具体⻅图2-3.
图 2-3 BizWorks应⽤发布计划
BizWorks还⽀持通过helm chart来部署复杂结构的应⽤组件，并且和⽆状态组件⼀样，⽀持⼀个应⽤下 同时发布多个helm类型的组件。如图2-4所示，模版中⼼提供了helm chart类型模版的上传、更新、下 载、删除的功能，然后通过平台定义的helm类组件完成模版组件的部署、回滚和删除操作。
图2-4 BizWorks helm chart应⽤发布
2.5 成果与收益
- 具备了基础的部署和运维能⼒
- 借助KubeVelaRollout，应⽤平台具备的基础的部署和运维能⼒，能够完全平台化覆盖应⽤实例的⽣命周期，运维⼈⼒成本降低50%，公有云场景消除了产品间来回切换的成本
- 灵活的特征机制，为应⽤平台提供了便利的路由配置能⼒
- ⼀键搭建测试环境的快捷功能
- 基于KubeVela的fluxcdAddon和应⽤平台的模版中⼼，⽤户可以快速的搭建和释放⼀套测试环境，由原来正常3-6个⼩时缩减为15分钟左右就可以完整搭建
- 应⽤模型统⼀
- KubeVela相较于其他开源CD产品最⼤的优势，是其开放应⽤模型OAM，声明式构建需要的资 源，对于有多云部署和应⽤配置统⼀的产品有很⼤的帮助，配置统⼀后运维⼈员不需要收集各 种格式的资源申请，完全可以通过平台化配置和OAM模型完成声明式资源创建，这部分效率⼏ 乎提升100%
此外，借助KubeVela的CD能⼒，BizWorks⽬前管理的集群和Application数量已经初具规模。其中公有 云⽀撑50+集群，总计300+应⽤；专有云⽀撑10+局点，当前最⼤局点⽀撑10+集群，130+应⽤。
三、未来规划
为了更好的⽀持后续平台能⼒的扩展和增强，BizWorks在可预⻅的近期会继续与KubeVela开展深度合 作，⼤致规划包括：
- 可视化分批发布，基于Kruise Rollout和KubeVela，⽀持⽆状态组件以及helm chart
- 弹性伸缩，兼容ACK和Kubernetes原⽣HPA策略
- 社区贡献，⾃定义的definition转化为KubeVela的addon
- ⾦丝雀发布，⽀持更好的流量控制和灰度策略
本文为阿里云原创内容，未经允许不得转载。
以上是关于基于 KubeVela 的机器学习实践的主要内容，如果未能解决你的问题，请参考以下文章