BizWorks与KubeVela的合作始于1.0.5版本,BizWorks在1.0.5版本上完成了关键技术验证并且在1.2.5版 本上基础上扩展了BizWorks的应⽤部署和运维能⼒。通过近⼀年多的深度合作,BizWorks通过 KubeVela配置碎片化的痛点和规范化的诉求,同时基于KubeVela功能和特性也沉淀了⼀些实践,本⽂通过介绍BizWorks在KubeVela使⽤场景来讲述如何探索和实践云原⽣时代新⼀代PaaS平台持续交付能⼒的落地。
BizWorks(https://bizworks.aliyun.com/)是⼀体化的阿⾥云原⽣应⽤的开发和运营平台,内置阿⾥巴巴 业务中台构建的最佳技术实践。产品主要包括:业务建模平台、业务应⽤平台、演练压测平台、能⼒运 营平台、⼀体化运⾏和运维平台。BizWorks提供的产品能⼒(图1-1),普遍适⽤于企业云原⽣应⽤⾼ 效开发以及企业业务能⼒沉淀和复⽤的场景。
图 1-1 BizWorks业务架构
BizWorks⼀体化运⾏和运维平台提供⼀站式的应⽤⽣命周期管理、运⾏托管和运维管控能⼒,⽀持多云 适配,因此应⽤的⽣命周期管理是不可或缺的,其中CICD作为应⽤持续演进的关键⽅式对客户产品发布 以及升级迭代扮演者着关重要的⻆⾊。
CI(持续集成)主要包括中台类应⽤、低代码类轻应⽤、托管类应⽤、集成类应⽤的构建和物料产出, 为客户透出个性化流⽔线能⼒,可以依据⽤户实际需求编排符合业务需求的流⽔线,也可以直接使⽤业 界沉淀的通⽤流⽔线产品。
CD(持续交付/持续部署)主要包括上述⼏类应⽤构建制品部署上线以及运维,为客户提供核⼼的部署 操作能⼒,⽤户可以基于内置的部署引擎完成应⽤的部署,同时也可以接⼊其他部署产品,例如EDAS。
本⽂将主要讲述探索如何使⽤KubeVela在BizWorks⼀体化运⾏和运维平台应⽤部署中落地。
BizWorks对于应⽤交付的需求主要包括两个思考,第⼀个是在云原⽣技术背景下,应⽤交付应该基于云 原⽣技术架构进⾏设计,因此采⽤的应⽤交付技术选型要能够⽀持相应的技术组件诉求;第⼆个是从业 务需求出发,当前应⽤交付配置⾯临碎⽚化的境况,包括环境配置、资源规格配置、持久化配置、⽹络 ⼆、应⽤交付的需求与落地 2.1 需求背景 3 路由配置等,同时对于应⽤交付制品类型也不尽相同。为了满⾜上述的需求,BizWorks选择使⽤ KubeVela来实现应⽤的持续交付,保证客户环境交付终态的稳定性和可靠性。
⽬前Bizworks⽀持四种类型的业务应⽤,集成了部分开源或阿⾥云的中间件组件,其部分能⼒主要是通 过使⽤KubeVela的Application、Component、Trait以及WorkFlow来实现(如图2-1)。在KubeVela Component基础上BizWorks定义⾃⼰的⽆状态组件(stateless-component)、有状态组件(stateful-component)、组装⽹络(advanced-ingress-trait)等,然后通过KubeVela来屏蔽不同云⼚商或 Kubernetes底座的复杂性和差异性,构成了当前BizWorks的应⽤部署架构。
图 2-1 BizWork应⽤部署业务架构
对于平台来说提供的功能如果具有可扩展和灵活性的话,可以为平台增强现有能⼒和推出更好体验的功 能点带来强⼤的帮助。但是由于平台⾯对的使⽤者背景和诉求各不相同,为了能尽可能满⾜⼤多数场景 需求可能会导致配置化内容变得多⽽且散乱,这是当时⾯临的碎⽚化配置痛点。借助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应⽤⽹络路由配置
⾸先以⼀个⽆状态组件应⽤发布为例,介绍如何使⽤KubeVela完成应⽤发布计划。BizWorks继承OAM 设计理念,将应⽤作为⼀个交付的整体,其内部由不同类型的组件构成,并且组件可以通过绑定⾃定义运维特征补丁实现多种组合搭配。应⽤内的组件可以按照⾃⼰的发布计划⾃⾏发布,并且组件之间产⽣的⼯作负载和⽹络 拓扑不会彼此影响,具体⻅图2-3.
图 2-3 BizWorks应⽤发布计划
BizWorks还⽀持通过helm chart来部署复杂结构的应⽤组件,并且和⽆状态组件⼀样,⽀持⼀个应⽤下 同时发布多个helm类型的组件。如图2-4所示,模版中⼼提供了helm chart类型模版的上传、更新、下 载、删除的功能,然后通过平台定义的helm类组件完成模版组件的部署、回滚和删除操作。
图2-4 BizWorks helm chart应⽤发布
- 借助KubeVela Rollout,应⽤平台具备了基础的部署和运维能⼒,能够完全平台化覆盖应⽤实例的⽣命周期,运维⼈⼒成本降低50%,公有云场景消除了产品间来回切换的成本
- 灵活的特征机制,为应⽤平台提供了便利的路由配置能⼒
- 基于KubeVela的fluxcd Addon和应⽤平台的模版中⼼,⽤户可以快速的搭建和释放⼀套测试环境,完整搭建由正常3-6小时缩减为15分钟左右
- KubeVela相较于其他开源CD产品最⼤的优势,是其开放应⽤模型OAM的理念,声明式构建需要的资 源,对于有多云部署和应⽤配置统⼀的产品有很⼤的帮助,配置统⼀后运维⼈员不需要收集各 种格式的资源申请,完全可以通过平台化配置和OAM模型完成声明式资源创建,这部分效率⼏ 乎提升100%
为了更好的⽀持后续平台能⼒的扩展和增强,BizWorks在可预⻅的近期会继续与KubeVela开展深度合 作,⼤致规划包括:
本文为阿里云原创内容,未经允许不得转载。