*作者：* *靖立明*

## 前言

BizWorks 與 KubeVela 的合作始於 1.0.5 版本，BizWorks 在 1.0.5 版本上完成了關鍵技術驗證並且在 1.2.5 版本上基礎上擴充套件了 BizWorks 的應用部署和運維能力。透過近一年多的深度合作，BizWorks 透過 KubeVela 解決了一些痛點和訴求，同時基於 KubeVela 功能和特性也沉澱了一些實踐，本文將分別透過介紹 BizWorks 在 KubeVela 使用場景來講述如何探索和實踐雲原生時代新一代 PaaS 平臺持續交付能力的落地。

## BizWorks 介紹

BizWorks(<https:></https:>)是一體化的阿里雲原生應用的開發和運營平臺，內建阿里巴巴業務中臺構建的最佳技術實踐。產品主要包括：業務建模平臺、業務應用平臺、演練壓測平臺、能力運營平臺、一體化執行和運維平臺。BizWorks 提供的產品能力（圖1-1），普遍適用於企業雲原生應用高效開發以及企業業務能力沉澱和複用的場景。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c805a027fc3544baa1a2e15ae2556441~tplv-k3u1fbpfcp-zoom-1.image "1.png")

圖 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.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9bfc38f3ff4b42f094dc308ebc5fff38~tplv-k3u1fbpfcp-zoom-1.image "2.png")

圖 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
    }]
  }
}
```

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/216bad10787b444fa581214685fc4e87~tplv-k3u1fbpfcp-zoom-1.image "3.png")

圖 2-2 BizWorks 應用網路路由配置

### 實踐案例

首先以一個無狀態元件應用釋出為例，介紹如何使用 KubeVela 完成應用釋出計劃。BizWorks 繼承 OAM 設計理念，將應用作為一個交付的整體，其內部由不同型別的元件構成，並且元件可以透過繫結自定義運維特徵補丁。應用內的元件可以按照自己的釋出計劃自行釋出，並且元件之間產生的工作負載和網路拓撲不會彼此影響，具體見圖 2-3.

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b9072b84fdd0402baf6dbfb60a82246a~tplv-k3u1fbpfcp-zoom-1.image "4.png")

圖 2-3 BizWorks 應用釋出計劃

BizWorks 還支援透過 helm chart 來部署複雜結構的應用元件，並且和無狀態元件一樣，支援一個應用下同時釋出多個 helm 型別的元件。如圖 2-4 所示，模版中心提供了 helm chart 型別模版的上傳、更新、下載、刪除的功能，然後透過平臺定義的 helm 類元件完成模版元件的部署、回滾和刪除操作。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/675ee998627845c4906d5be28045834a~tplv-k3u1fbpfcp-zoom-1.image "5.png")

圖 2-4 BizWorks helm chart 應用釋出

### 成果與收益

-   具備了基礎的部署和運維能力

-   -   藉助 KubeVela Rollout，應用平臺具備的基礎的部署和運維能力，能夠完全平臺化覆蓋應用例項的生命週期，運維人力成本降低 50%，公有云場景消除了產品間來回切換的成本
    -   靈活的特徵機制，為應用平臺提供了便利的路由配置能力

-   一鍵搭建測試環境的快捷功能

基於 KubeVela 的 fluxcd Addon 和應用平臺的模版中心，使用者可以快速的搭建和釋放一套測試環境，由原來正常 3-6 個小時縮減為 15 分鐘左右就可以完整搭建

-   應用模型統一

KubeVela 相較於其他開源 CD 產品最大的優勢，是其開放應用模型 OAM，宣告式構建需要的資源，對於有多雲部署和應用配置統一的產品有很大的幫助，配置統一後運維人員不需要收集各種格式的資源申請，完全可以透過平臺化配置和 OAM 模型完成宣告式資源建立，這部分效率幾乎提升 100%

此外，藉助 KubeVela 的 CD 能力，BizWorks 目前管理的叢集和 Application 數量已經初具規模。其中公有云支撐 500+叢集，總計 數千個應用；專有云支撐 100+局點，當前最大局點支撐 100+叢集，數百個應用。

## 未來規劃

為了更好的支援後續平臺能力的擴充套件和增強，BizWorks 在可預見的近期會繼續與 KubeVela 開展深度合作，大致規劃包括：

-   視覺化分批發布，基於 Kruise Rollout和KubeVela，支援無狀態元件以及 helm chart
-   彈性伸縮，相容 ACK 和 Kubernetes 原生 HPA 策略
-   社群貢獻，自定義的 definition 轉化為 KubeVela 的 addon
-   金絲雀釋出，支援更好的流量控制和灰度策略

您可以透過如下材料瞭解更多關於 KubeVela 以及 OAM 專案的細節：

-   專案程式碼庫：github.com/oam-dev/kubevela 歡迎 Star/Watch/Fork！
-   專案官方主頁與文件：kubevela.io ，從 1.1 版本開始，已提供中文、英文文件，更多語言文件歡迎開發者進行翻譯。
-   專案釘釘群：23310022；Slack：CNCF #kubevela Channel
-   加入微信群：請先新增以下 maintainer 微訊號，表明進入 KubeVela 使用者群：

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/316688d163464de1a5ec26168e5583bb~tplv-k3u1fbpfcp-zoom-1.image "6.png")

戳[此處](https://kubevela.io/)：檢視 KubeVela 專案官網！！

BizWorks 應用平臺基於 KubeVela 的實踐

相關文章