BizWorks應⽤平臺基於KubeVela的實踐

前⾔

BizWorks與KubeVela的合作始於1.0.5版本，BizWorks在1.0.5版本上完成了關鍵技術驗證並且在1.2.5版 本上基礎上擴充套件了BizWorks的應⽤部署和運維能⼒。透過近⼀年多的深度合作，BizWorks透過 KubeVela解決了配置碎片化的痛點和規範化的，同時基於KubeVela功能和特性也沉澱了⼀些實踐，本⽂透過介紹BizWorks在KubeVela使⽤場景來講述如何探索和實踐雲原⽣時代新⼀代PaaS平臺持續交付能⼒的落地。

⼀、BizWorks介紹

BizWorks()是⼀體化的阿⾥雲原⽣應⽤的開發和運營平臺，內建阿⾥巴巴 業務中臺構建的最佳技術實踐。產品主要包括：業務建模平臺、業務應⽤平臺、演練壓測平臺、能⼒運 營平臺、⼀體化運⾏和運維平臺。BizWorks提供的產品能⼒（圖1-1），普遍適⽤於企業雲原⽣應⽤⾼ 效開發以及企業業務能⼒沉澱和復⽤的場景。

圖 1-1 BizWorks業務架構

BizWorks⼀體化運⾏和運維平臺提供⼀站式的應⽤⽣命週期管理、運⾏託管和運維管控能⼒，⽀持多雲 適配，因此應⽤的⽣命週期管理是不可或缺的，其中CICD作為應⽤持續演進的關鍵⽅式對客戶產品釋出 以及升級迭代扮演著⾄關重要的⻆⾊。

CI（持續整合）主要包括中臺類應⽤、低程式碼類輕應⽤、託管類應⽤、整合類應⽤的構建和物料產出， 為客戶透出個性化流⽔線能⼒，可以依據⽤戶實際需求編排符合業務需求的流⽔線，也可以直接使⽤業 界沉澱的通⽤流⽔線產品。

CD（持續交付/持續部署）主要包括上述⼏類應⽤構建制品部署上線以及運維，為客戶提供核⼼的部署 操作能⼒，⽤戶可以基於內建的部署引擎完成應⽤的部署，同時也可以接⼊其他部署產品，例如EDAS。  

本⽂將主要講述探索如何使⽤KubeVela在BizWorks⼀體化運⾏和運維平臺應⽤部署中落地。

⼆、應⽤交付的需求與落地

2.1 需求背景

BizWorks對於應⽤交付的需求主要包括兩個思考，第⼀個是在雲原⽣技術背景下，應⽤交付應該基於雲 原⽣技術架構進⾏設計，因此採⽤的應⽤交付技術選型要能夠⽀持相應的技術元件訴求；第⼆個是從業 務需求出發，當前應⽤交付配置⾯臨碎⽚化的境況，包括環境配置、資源規格配置、持久化配置、⽹絡路由配置等，同時對於應⽤交付製品型別也不盡相同。為了滿⾜上述的需求，BizWorks選擇使⽤ KubeVela來實現應⽤的持續交付，保證客戶環境交付終態的穩定性和可靠性。

2.2 應⽤部署架構

⽬前Bizworks⽀持四種型別的業務應⽤，整合了部分開源或阿⾥雲的中介軟體元件，其部分能⼒主要是通 過使⽤KubeVela的Application、Component、Trait以及WorkFlow來實現（如圖2-1）。在KubeVela Component基礎上BizWorks定義⾃⼰的⽆狀態元件（stateless-component）、有狀態元件（stateful-component）、組裝⽹絡（advanced-ingress-trait）等，然後透過KubeVela來遮蔽不同雲⼚商或 Kubernetes底座的複雜性和差異性，構成了當前BizWorks的應⽤部署架構。

圖 2-1 BizWork應⽤部署業務架構

2.3 碎⽚化配置的痛點與解決

對於平臺來說提供的功能如果具有可擴充套件和靈活性的話，可以為平臺增強現有能⼒和推出更好體驗的功 能點帶來強⼤的幫助。但是由於平臺⾯對的使⽤者背景和訴求各不相同，為了能儘可能滿⾜⼤多數場景 需求可能會導致配置化內容變得多⽽且散亂，這是當時⾯臨的碎⽚化配置痛點。藉助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 ingressAPI matches K8s v1.20+."attributes: {podDisruptive: false}}template: {outputs: {// trait template can have multiple outputs in one traitif parameter.route != _|_ {for _, v in parameter.route {"service-\(v.serviceName)": {apiVersion: "v1"kind: "Service"metadata:name: v.serviceNamespec: {selector: "app.oam.dev/component": context.nameif v.serviceType != _|_ {type: v.serviceType}ports: [{port: v.servicePortprotocol: v.serviceProtocolTypetargetPort: v.port},]}}if v["ingressName"] != _|_ {"ingress-\(v.ingressName)": {apiVersion: "networking.k8s.io/v1"kind: "Ingress"metadata: {name: v.ingressNameannotations: {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.domainhttp: {paths: [{path: v.pathpathType: "ImplementationSpecific"backend: service: {name: v.serviceNameport: number: v.servicePort}},]}}]}}}}}}parameter: {route: [...{// +usage=Specify the port your server want to exposeport?: int// +usage=Specify the protocol your service want to exposeserviceProtocolType?: string// +usage=Specify the name your service want to exposeserviceName?: string// +usage=Specify the port your service want to exposeservicePort?: int// +usage=Specify the type your service want to exposeserviceType?: string// +usage=Specify the type your ingress want to exposeingressProtocolType?: string// +usage=Specify the name your ingress want to exposeingressName?: string// +usage=Specify the domain you want to exposedomain?: string// +usage=Specify the path you want to exposepath?: string// +usage=Specify the tls secret you want to usesecretName?: stringannotations?: [...{name: stringvalue: string}]// +usage=Specify the class of ingress to useclass: *"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 成果與收益

• 具備了基礎的部署和運維能⼒  

    - 藉助KubeVela Rollout，應⽤平臺具備了基礎的部署和運維能⼒，能夠完全平臺化覆蓋應⽤例項的⽣命週期，運維⼈⼒成本降低50%，公有云場景消除了產品間來回切換的成本  

    - 靈活的特徵機制，為應⽤平臺提供了便利的路由配置能⼒  

• ⼀鍵搭建測試環境

    - 基於KubeVela的fluxcd Addon和應⽤平臺的模版中⼼，⽤戶可以快速的搭建和釋放⼀套測試環境， 完整搭建由正常3-6小時縮減為15分鐘左右

• 應⽤模型統⼀

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

三、未來規劃

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

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

若有收穫，點個贊吧～❤️