您的位置: 首页 > 技术杂谈 > 正文

BizWorks 应用平台基于 KubeVela 的实践

2022-11-02 11:00 https://my.oschina.net/u/3874284/blog/5587552 阿里云云原生次阅读条评论

作者： 靖立明

前言

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 一体化运行和运维平台应用部署中落地。

应用交付的需求与落地

需求背景

BizWorks 对于应用交付的需求主要包括两个思考，第一个是在云原生技术背景下，应用交付应该基于云原生技术架构进行设计，因此采用的应用交付技术选型要能够支持相应的技术组件诉求；第二个是从业务需求出发，当前应用交付配置面临碎片化的境况，包括环境配置、资源规格配置、持久化配置、网络路由配置等，同时对于应用交付制品类型也不尽相同。为了满足上述的需求，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 类组件完成模版组件的部署、回滚和删除操作。