关于后端:BizWorks应⽤平台基于KubeVela的实践

4次阅读

共计 5237 个字符，预计需要花费 14 分钟才能阅读完成。

简介：BizWorks 与 KubeVela 的单干始于 1.0.5 版本，BizWorks 在 1.0.5 版本上实现了关键技术验证并且在 1.2.5 版本上根底上扩大了 BizWorks 的利用部署和运维能力。通过近一年多的深度单干，BizWorks 通过 KubeVela 解决了一些痛点和诉求，同时基于 KubeVela 性能和个性也积淀了一些实际，本文将别离通过介绍 BizWorks 在 KubeVela 应用场景来讲述如何摸索和实际云原生时代新一代 PaaS 平台继续交付能力的落地。前⾔ 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 ⾦丝雀公布，⽀持更好的流量管制和灰度策略

原文链接：https://click.aliyun.com/m/10…

本文为阿里云原创内容，未经容许不得转载。

正文完