指南)
把部署應用寫成一份 YAMLKubeVela 深度實戰(zhàn)指南【免費下載鏈接】kubevelaThe Modern Application Platform.項目地址: https://gitcode.com/gh_mirrors/ku/kubevelaKubeVela 是一個把應用交付做成聲明式工作流的現(xiàn)代化應用平臺它基于 Open Application ModelOAM一種描述應用如何組成、如何部署的開放標準讓你能用一份 YAML 描述清楚應用由哪些組件構(gòu)成、按什么順序發(fā)布、發(fā)到哪些集群其余交給控制器去執(zhí)行。這篇文章會從一次真實的部署經(jīng)歷講起帶你理解 KubeVela 的核心設(shè)計并親手跑通安裝、部署、版本回滾與生產(chǎn)調(diào)優(yōu)的全過程。從一個部署翻車的夜晚說起想象一下這個場景你維護著一個前后端分離的微服務(wù)應用上線前要手動執(zhí)行十幾條命令——先改數(shù)據(jù)庫、再起后端、等健康檢查通過、最后切流量到前端。操作多、依賴強、順序錯一步就翻車。你試著把這些步驟寫進 CI 腳本結(jié)果腳本越寫越長環(huán)境一換就要大改。這正是 KubeVela 要解決的問題。它把部署流程本身變成了一種可編程、可版本化的資源你描述最終要長成什么樣和按什么順序長KubeVela 負責讓集群變成那樣。第一步用 5 分鐘把平臺跑起來準備一個 Kubernetes 集群KubeVela 的控制器本質(zhì)上是運行在 Kubernetes 里的一個 Operator即一種盯住自定義資源并自動調(diào)諧的程序所以你需要一個可用的集群任意主流發(fā)行版都可以kubectl cluster-info # 確認集群可達 kubectl get nodes # 確認節(jié)點就緒 helm version # 確認 Helm 3 已安裝用 Helm 安裝控制平面控制平面組件統(tǒng)一部署在kubevela-system命名空間helm repo add kubevela https://charts.kubevela.io/stable helm repo update helm install kubevela kubevela/kubevela \ --namespace kubevela-system \ --create-namespace \ --wait裝完后看一眼 Pod 是否全部 Runningkubectl get pods -n kubevela-system安裝 CLIvelaCLI 不是必需品但它能讓你用幾條命令完成查看狀態(tài)、對比版本、跟蹤工作流等操作強烈建議裝上curl -fsSl https://kubevela.io/script/install.sh | bash vela version想從源碼構(gòu)建的同學可以 clone 倉庫后自行編譯倉庫地址https://gitcode.com/gh_mirrors/ku/kubevelaCLI 入口在 references/cli/控制器入口在 cmd/core/main.go。平臺就緒后我們來寫第一份應用描述。能力一一份 YAML說清應用長什么樣KubeVela 用Application資源核心類型定義在 apis/core.oam.dev/v1beta1/application_types.go把組件、運維能力和發(fā)布策略打包在一起。來看倉庫自帶的最小示例docs/examples/application/application-sample.yamlapiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: application-sample spec: components: - name: myweb type: worker # 用系統(tǒng)內(nèi)置的 worker 組件類型 properties: image: busybox cmd: [sleep, 1000] traits: # 運維能力副本、邊車、服務(wù)暴露 - type: scaler properties: replicas: 10 - type: sidecar properties: name: sidecar-test image: nginx - type: kservice properties: http: server: 80提交即部署vela up -f docs/examples/application/application-sample.yaml這條命令背后發(fā)生了什么可以結(jié)合這張圖理解 KubeVela 在 CI/CD 鏈路里的位置——左側(cè) CI 產(chǎn)出代碼和配置中間是 KubeVela 的**渲染Render→ 編排Orchestrate→ 部署Deploy**三段式流水線右側(cè)是各類目標環(huán)境這里有個新手容易困惑的點type: webservice、type: scaler這些類型是誰定義的答案是定義類資源——ComponentDefinition組件定義和TraitDefinition運維能力定義。它們把如何把參數(shù)渲染成 Deployment / Service / Ingress的邏輯封裝起來這也是 KubeVela 可擴展性的根基。安裝時系統(tǒng)已經(jīng)預置了一批內(nèi)置定義可以用vela component list和vela trait list查看。能力二部署順序交給工作流而不是祈禱多組件應用往往有嚴格的上線順序先數(shù)據(jù)庫、再后端、最后前端。手寫腳本維護這種順序很痛苦而 KubeVela 把它變成了spec.workflow里的一段聲明。倉庫里的依賴示例docs/examples/workflow/depends-on-app/app.yaml演示了步驟之間的依賴寫法apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: kruise spec: components: - name: kruise type: helm properties: chart: ./charts/kruise/v0.9.0 repoType: git workflow: steps: - name: check-flux type: depends-on-app # 先確認另一個應用已就緒 properties: name: fluxcd namespace: vela-system - name: apply-kruise type: apply-component # 再執(zhí)行真正的部署 properties: component: kruise工作流步驟由WorkflowStepDefinition定義見 apis/core.oam.dev/v1beta1/workflow_step_definition.go內(nèi)置了apply-component、deploy2env、health-check、notification、read-object等常用步驟還可以用 CUE 或 shell 腳本自定義步驟。執(zhí)行內(nèi)部是控制器—工作流管理器—任務(wù)管理器三層的閉環(huán)落到日常操作上工作流給開發(fā)體驗帶來的變化是步驟失敗會自動重試重試次數(shù)可在 Helm values 里配置卡住時可以暫停從容排查而不是直接回滾每一步的進度和日志可查vela workflow status app、vela workflow logs app --step step支持條件分支、超時、步驟分組對應示例見 docs/examples/workflow/app-with-if/ 和 docs/examples/workflow/step-group/。如果你做金絲雀發(fā)布工作流配合rollout與canary-traffic兩個 trait可以在不寫任何腳本的情況下完成分批放量與灰度流量切換完整示例就在 docs/examples/workflow/canary-rollout/。能力三每次發(fā)布都有快照回滾不再靠翻 Git 記錄KubeVela 每次應用變更都會生成一個ApplicationRevision應用修訂版本它把當時的組件定義、運維能力定義、工作流定義連同參數(shù)一起做成快照。所以回滾到某個歷史版本意味著把當時整套定義原樣重放而不是只換鏡像——這比 GitOps 工具通常做的內(nèi)容回滾更徹底。日常操作vela revision list microservices-demo # 查看版本歷史 vela revision get microservices-demo # 查看某個版本的詳細信息倉庫里對應的版本管理設(shè)計文檔在 docs/examples/application/versioning.md。版本保留數(shù)量由 Helm 參數(shù)applicationRevisionLimit控制默認只留 2 個生產(chǎn)環(huán)境建議調(diào)大以留足回滾余量后面會講。能力四一套配置鋪到多集群多云多集群部署在 KubeVela 里不是高級功能而是平臺的一等公民。通過topology策略聲明目標集群通過override策略按集群差異化調(diào)整參數(shù)KubeVela 會自動完成分發(fā)apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: example-app spec: components: - name: express-server type: webservice properties: image: crccheck/hello-world port: 8000 policies: - type: topology name: topology properties: clusters: [cluster-1, cluster-2]常見的測試環(huán)境驗證 → 預發(fā)灰度 → 生產(chǎn)放量漸進式發(fā)布本質(zhì)上就是多套topologyoverride策略的組合配合工作流按階段執(zhí)行。多集群的參考架構(gòu)圖在 docs/examples/multicluster/ref-arch.jpg相關(guān)策略實現(xiàn)位于 pkg/policy/。能力五0.5C1G 的輕量底座 無限擴展KubeVela 的整個控制平面可以只跑一個 Pod、占用約 0.5 核 1G 內(nèi)存卻足以管理上千個應用——這得益于它把大多數(shù)邏輯放在了定義層控制器本體保持精簡。擴展有兩條路定義擴展用 CUE 語言一種配置即代碼的描述語言編寫自定義組件/運維能力/工作流步驟寫入ComponentDefinition等定義資源。倉庫的 CUE 模板目錄在 vela-templates/definitions/里面能看到內(nèi)置定義的寫法。插件擴展通過vela addon生態(tài)安裝現(xiàn)成能力vela addon list # 查看可用插件 vela addon enable observability # 一鍵啟用監(jiān)控面板再疊加一層角色分離視角就更清楚這套設(shè)計的價值了平臺工程師定義怎么部署應用開發(fā)者只聲明我要什么兩者各司其職互不阻塞。生產(chǎn)落地照抄這 5 個調(diào)優(yōu)項就夠了前面聊的是能力這一段聊上線前必須改的東西。KubeVela 的 Helm values 集中在 charts/vela-core/values.yaml下面幾個參數(shù)請務(wù)必按生產(chǎn)環(huán)境調(diào)整1. 版本保留數(shù)別讓回滾無票可買applicationRevisionLimit: 10 # 默認只有 2上線前調(diào)大到 10 左右 definitionRevisionLimit: 52. 并發(fā)與同步跟著集群規(guī)模走concurrentReconciles: 8 # 控制器并發(fā)調(diào)諧數(shù)默認 4 controllerArgs: reSyncPeriod: 5m # 定期重新同步周期需要更快的狀態(tài)收斂可調(diào)小3. 失敗處理暫停而不是默默重試到天荒地老workflow: enableSuspendOnFailure: true # 失敗即暫停方便現(xiàn)場排查 step: errorRetryTimes: 5 # 默認 10 次可按需調(diào)小4. 資源配額從夠用到穩(wěn)resources: requests: cpu: 250m memory: 256Mi limits: cpu: 500m memory: 1Gi5. 大規(guī)模場景分片架構(gòu)當應用規(guī)模大到單控制器吃緊時KubeVela 支持主從分片master 實例負責各類定義和調(diào)度多個 slave 實例各自分管一組應用通過shard-id劃分實現(xiàn)水平擴展分片設(shè)計文檔在 design/vela-core/vela-core-sharding-arch.jpg 同目錄配合featureGates如applyOnce、enableInMemoryWorkflowContext還能進一步壓性能。這些開關(guān)在 pkg/features/controller_features.go 里都有定義按需開啟即可。踩坑備忘三個高頻問題的一線排查思路Pod 一直 Pending 或反復重啟先kubectl describe pod name -n ns看事件再查資源配額kubectl describe resourcequota最后看容器日志定位應用層問題。大多數(shù)時候不是 KubeVela 的問題而是資源或鏡像的問題。工作流步驟卡在 Running用vela workflow status app確認卡在哪一步再vela workflow logs app --step step看該步日志如果開啟了失敗暫停先檢查是不是上一步的條件依賴沒滿足。多集群里某個集群沒部署上先vela cluster list確認集群注冊與心跳正常再針對該集群查看應用狀態(tài)與資源配額。注意topology策略里集群名必須與注冊名完全一致。要點清單核心心智KubeVela 把部署從命令/腳本抽象成了聲明式資源你描述最終狀態(tài)與順序平臺負責變成現(xiàn)實。一份 YAML 交付Application聚合組件、trait、工作流、策略vela up一條命令完成渲染-編排-部署。工作流是靈魂步驟依賴、失敗重試、暫?；謴?、金絲雀發(fā)布都在這層實現(xiàn)別再寫膠水腳本了。版本快照兜底每次變更生成ApplicationRevision回滾是整套定義重放比只改鏡像更可靠。多集群是標配topologyoverride策略解決跨集群分發(fā)與差異化配置。輕量但可擴展0.5C1G 起步CUE 定義與 addon 插件兩條擴展路徑。上線前必調(diào)applicationRevisionLimit、concurrentReconciles、enableSuspendOnFailure、資源配額四個參數(shù)先改到位。下一步建議先在測試集群把 docs/examples/ 下的示例逐個跑一遍尤其是 canary-rollout 和 multicluster然后嘗試用 CUE 寫一個自己的組件定義體會定義一次、處處復用最后按本文的調(diào)優(yōu)清單走一遍生產(chǎn)化檢查。等你對渲染-編排-部署的閉環(huán)有手感之后再去看 design/ 目錄下的設(shè)計文檔會發(fā)現(xiàn)每一篇都能讀懂了?！久赓M下載鏈接】kubevelaThe Modern Application Platform.項目地址: https://gitcode.com/gh_mirrors/ku/kubevela創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 把“部署應用“寫成一份 YAML：KubeVela 深度實戰(zhàn)指南
把部署應用寫成一份 YAMLKubeVela 深度實戰(zhàn)指南【免費下載鏈接】kubevelaThe Modern Application Platform.項目地址: https://gitcode.com/gh_mirrors/ku/kubevelaKubeVela 是一個把應用交付做成聲明式工作流的現(xiàn)代化應用平臺它基于 Open Application ModelOAM一種描述應用如何組成、如何部署的開放標準讓你能用一份 YAML 描述清楚應用由哪些組件構(gòu)成、按什么順序發(fā)布、發(fā)到哪些集群其余交給控制器去執(zhí)行。這篇文章會從一次真實的部署經(jīng)歷講起帶你理解 KubeVela 的核心設(shè)計并親手跑通安裝、部署、版本回滾與生產(chǎn)調(diào)優(yōu)的全過程。從一個部署翻車的夜晚說起想象一下這個場景你維護著一個前后端分離的微服務(wù)應用上線前要手動執(zhí)行十幾條命令——先改數(shù)據(jù)庫、再起后端、等健康檢查通過、最后切流量到前端。操作多、依賴強、順序錯一步就翻車。你試著把這些步驟寫進 CI 腳本結(jié)果腳本越寫越長環(huán)境一換就要大改。這正是 KubeVela 要解決的問題。它把部署流程本身變成了一種可編程、可版本化的資源你描述最終要長成什么樣和按什么順序長KubeVela 負責讓集群變成那樣。第一步用 5 分鐘把平臺跑起來準備一個 Kubernetes 集群KubeVela 的控制器本質(zhì)上是運行在 Kubernetes 里的一個 Operator即一種盯住自定義資源并自動調(diào)諧的程序所以你需要一個可用的集群任意主流發(fā)行版都可以kubectl cluster-info # 確認集群可達 kubectl get nodes # 確認節(jié)點就緒 helm version # 確認 Helm 3 已安裝用 Helm 安裝控制平面控制平面組件統(tǒng)一部署在kubevela-system命名空間helm repo add kubevela https://charts.kubevela.io/stable helm repo update helm install kubevela kubevela/kubevela \ --namespace kubevela-system \ --create-namespace \ --wait裝完后看一眼 Pod 是否全部 Runningkubectl get pods -n kubevela-system安裝 CLIvelaCLI 不是必需品但它能讓你用幾條命令完成查看狀態(tài)、對比版本、跟蹤工作流等操作強烈建議裝上curl -fsSl https://kubevela.io/script/install.sh | bash vela version想從源碼構(gòu)建的同學可以 clone 倉庫后自行編譯倉庫地址https://gitcode.com/gh_mirrors/ku/kubevelaCLI 入口在 references/cli/控制器入口在 cmd/core/main.go。平臺就緒后我們來寫第一份應用描述。能力一一份 YAML說清應用長什么樣KubeVela 用Application資源核心類型定義在 apis/core.oam.dev/v1beta1/application_types.go把組件、運維能力和發(fā)布策略打包在一起。來看倉庫自帶的最小示例docs/examples/application/application-sample.yamlapiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: application-sample spec: components: - name: myweb type: worker # 用系統(tǒng)內(nèi)置的 worker 組件類型 properties: image: busybox cmd: [sleep, 1000] traits: # 運維能力副本、邊車、服務(wù)暴露 - type: scaler properties: replicas: 10 - type: sidecar properties: name: sidecar-test image: nginx - type: kservice properties: http: server: 80提交即部署vela up -f docs/examples/application/application-sample.yaml這條命令背后發(fā)生了什么可以結(jié)合這張圖理解 KubeVela 在 CI/CD 鏈路里的位置——左側(cè) CI 產(chǎn)出代碼和配置中間是 KubeVela 的**渲染Render→ 編排Orchestrate→ 部署Deploy**三段式流水線右側(cè)是各類目標環(huán)境這里有個新手容易困惑的點type: webservice、type: scaler這些類型是誰定義的答案是定義類資源——ComponentDefinition組件定義和TraitDefinition運維能力定義。它們把如何把參數(shù)渲染成 Deployment / Service / Ingress的邏輯封裝起來這也是 KubeVela 可擴展性的根基。安裝時系統(tǒng)已經(jīng)預置了一批內(nèi)置定義可以用vela component list和vela trait list查看。能力二部署順序交給工作流而不是祈禱多組件應用往往有嚴格的上線順序先數(shù)據(jù)庫、再后端、最后前端。手寫腳本維護這種順序很痛苦而 KubeVela 把它變成了spec.workflow里的一段聲明。倉庫里的依賴示例docs/examples/workflow/depends-on-app/app.yaml演示了步驟之間的依賴寫法apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: kruise spec: components: - name: kruise type: helm properties: chart: ./charts/kruise/v0.9.0 repoType: git workflow: steps: - name: check-flux type: depends-on-app # 先確認另一個應用已就緒 properties: name: fluxcd namespace: vela-system - name: apply-kruise type: apply-component # 再執(zhí)行真正的部署 properties: component: kruise工作流步驟由WorkflowStepDefinition定義見 apis/core.oam.dev/v1beta1/workflow_step_definition.go內(nèi)置了apply-component、deploy2env、health-check、notification、read-object等常用步驟還可以用 CUE 或 shell 腳本自定義步驟。執(zhí)行內(nèi)部是控制器—工作流管理器—任務(wù)管理器三層的閉環(huán)落到日常操作上工作流給開發(fā)體驗帶來的變化是步驟失敗會自動重試重試次數(shù)可在 Helm values 里配置卡住時可以暫停從容排查而不是直接回滾每一步的進度和日志可查vela workflow status app、vela workflow logs app --step step支持條件分支、超時、步驟分組對應示例見 docs/examples/workflow/app-with-if/ 和 docs/examples/workflow/step-group/。如果你做金絲雀發(fā)布工作流配合rollout與canary-traffic兩個 trait可以在不寫任何腳本的情況下完成分批放量與灰度流量切換完整示例就在 docs/examples/workflow/canary-rollout/。能力三每次發(fā)布都有快照回滾不再靠翻 Git 記錄KubeVela 每次應用變更都會生成一個ApplicationRevision應用修訂版本它把當時的組件定義、運維能力定義、工作流定義連同參數(shù)一起做成快照。所以回滾到某個歷史版本意味著把當時整套定義原樣重放而不是只換鏡像——這比 GitOps 工具通常做的內(nèi)容回滾更徹底。日常操作vela revision list microservices-demo # 查看版本歷史 vela revision get microservices-demo # 查看某個版本的詳細信息倉庫里對應的版本管理設(shè)計文檔在 docs/examples/application/versioning.md。版本保留數(shù)量由 Helm 參數(shù)applicationRevisionLimit控制默認只留 2 個生產(chǎn)環(huán)境建議調(diào)大以留足回滾余量后面會講。能力四一套配置鋪到多集群多云多集群部署在 KubeVela 里不是高級功能而是平臺的一等公民。通過topology策略聲明目標集群通過override策略按集群差異化調(diào)整參數(shù)KubeVela 會自動完成分發(fā)apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: example-app spec: components: - name: express-server type: webservice properties: image: crccheck/hello-world port: 8000 policies: - type: topology name: topology properties: clusters: [cluster-1, cluster-2]常見的測試環(huán)境驗證 → 預發(fā)灰度 → 生產(chǎn)放量漸進式發(fā)布本質(zhì)上就是多套topologyoverride策略的組合配合工作流按階段執(zhí)行。多集群的參考架構(gòu)圖在 docs/examples/multicluster/ref-arch.jpg相關(guān)策略實現(xiàn)位于 pkg/policy/。能力五0.5C1G 的輕量底座 無限擴展KubeVela 的整個控制平面可以只跑一個 Pod、占用約 0.5 核 1G 內(nèi)存卻足以管理上千個應用——這得益于它把大多數(shù)邏輯放在了定義層控制器本體保持精簡。擴展有兩條路定義擴展用 CUE 語言一種配置即代碼的描述語言編寫自定義組件/運維能力/工作流步驟寫入ComponentDefinition等定義資源。倉庫的 CUE 模板目錄在 vela-templates/definitions/里面能看到內(nèi)置定義的寫法。插件擴展通過vela addon生態(tài)安裝現(xiàn)成能力vela addon list # 查看可用插件 vela addon enable observability # 一鍵啟用監(jiān)控面板再疊加一層角色分離視角就更清楚這套設(shè)計的價值了平臺工程師定義怎么部署應用開發(fā)者只聲明我要什么兩者各司其職互不阻塞。生產(chǎn)落地照抄這 5 個調(diào)優(yōu)項就夠了前面聊的是能力這一段聊上線前必須改的東西。KubeVela 的 Helm values 集中在 charts/vela-core/values.yaml下面幾個參數(shù)請務(wù)必按生產(chǎn)環(huán)境調(diào)整1. 版本保留數(shù)別讓回滾無票可買applicationRevisionLimit: 10 # 默認只有 2上線前調(diào)大到 10 左右 definitionRevisionLimit: 52. 并發(fā)與同步跟著集群規(guī)模走concurrentReconciles: 8 # 控制器并發(fā)調(diào)諧數(shù)默認 4 controllerArgs: reSyncPeriod: 5m # 定期重新同步周期需要更快的狀態(tài)收斂可調(diào)小3. 失敗處理暫停而不是默默重試到天荒地老workflow: enableSuspendOnFailure: true # 失敗即暫停方便現(xiàn)場排查 step: errorRetryTimes: 5 # 默認 10 次可按需調(diào)小4. 資源配額從夠用到穩(wěn)resources: requests: cpu: 250m memory: 256Mi limits: cpu: 500m memory: 1Gi5. 大規(guī)模場景分片架構(gòu)當應用規(guī)模大到單控制器吃緊時KubeVela 支持主從分片master 實例負責各類定義和調(diào)度多個 slave 實例各自分管一組應用通過shard-id劃分實現(xiàn)水平擴展分片設(shè)計文檔在 design/vela-core/vela-core-sharding-arch.jpg 同目錄配合featureGates如applyOnce、enableInMemoryWorkflowContext還能進一步壓性能。這些開關(guān)在 pkg/features/controller_features.go 里都有定義按需開啟即可。踩坑備忘三個高頻問題的一線排查思路Pod 一直 Pending 或反復重啟先kubectl describe pod name -n ns看事件再查資源配額kubectl describe resourcequota最后看容器日志定位應用層問題。大多數(shù)時候不是 KubeVela 的問題而是資源或鏡像的問題。工作流步驟卡在 Running用vela workflow status app確認卡在哪一步再vela workflow logs app --step step看該步日志如果開啟了失敗暫停先檢查是不是上一步的條件依賴沒滿足。多集群里某個集群沒部署上先vela cluster list確認集群注冊與心跳正常再針對該集群查看應用狀態(tài)與資源配額。注意topology策略里集群名必須與注冊名完全一致。要點清單核心心智KubeVela 把部署從命令/腳本抽象成了聲明式資源你描述最終狀態(tài)與順序平臺負責變成現(xiàn)實。一份 YAML 交付Application聚合組件、trait、工作流、策略vela up一條命令完成渲染-編排-部署。工作流是靈魂步驟依賴、失敗重試、暫?；謴?、金絲雀發(fā)布都在這層實現(xiàn)別再寫膠水腳本了。版本快照兜底每次變更生成ApplicationRevision回滾是整套定義重放比只改鏡像更可靠。多集群是標配topologyoverride策略解決跨集群分發(fā)與差異化配置。輕量但可擴展0.5C1G 起步CUE 定義與 addon 插件兩條擴展路徑。上線前必調(diào)applicationRevisionLimit、concurrentReconciles、enableSuspendOnFailure、資源配額四個參數(shù)先改到位。下一步建議先在測試集群把 docs/examples/ 下的示例逐個跑一遍尤其是 canary-rollout 和 multicluster然后嘗試用 CUE 寫一個自己的組件定義體會定義一次、處處復用最后按本文的調(diào)優(yōu)清單走一遍生產(chǎn)化檢查。等你對渲染-編排-部署的閉環(huán)有手感之后再去看 design/ 目錄下的設(shè)計文檔會發(fā)現(xiàn)每一篇都能讀懂了?！久赓M下載鏈接】kubevelaThe Modern Application Platform.項目地址: https://gitcode.com/gh_mirrors/ku/kubevela創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考