前言
原始人工部署的痛點
Kubectl直連Kubernetes集羣API，命令行操作Deployment、Service等資源完成應用手動部署，會逐漸暴露出一些問題：
- 學習成本高：開發者需要學習理解大量Kubernetes資源對象Deployment、Service、Ingress、ConfigMap等概念。
- 配置漂移：不同人員可能通過不同方式部署運維，例如手寫YAML進行apply操作、臨時修改配置進行patch/edit操作，沒有統一入口和規範，造成系統配置漂移。
- 缺乏權限和審計能力：直接使用Kubectl操作k8s集羣，企業很難做到細粒度權限控制以及完整的操作審計。
- 部署運維過程不可追溯：配置修改和應用部署往往是即時操作，一旦出現問題，很難追溯是誰在什麼時間修改了哪些配置。
傳統DevOps的痛點：
- 流程碎片化：開發、測試、運維各自為政，靠CI/CD工具鏈硬串聯。
- 複雜度外溢：運維團隊要維護Gitlab、Jenkins、GitLabRunner、ArgoCD、HelmChart等多套工具。
- 不可控的體驗：不同團隊的自動化腳本和流程不統一，新人入職學習成本高。
- 缺乏穩定的審計與可追溯性：流水線日誌、變更記錄分散，難以形成統一的安全合規視圖。
DevOps已死，更加註重用户體驗的平台工程才是未來。
DevOps過度依賴工具鏈、強調個人能力、缺乏標準化平台化支撐，長期難以擴展。
平台工程（Platform Engineering）就是為企業開發團隊提供標準化、可複用、可自助的內建能力平台（Internal Developer Platform）也稱IDP ，IDP把DevOps的複雜性封裝起來，讓業務團隊專注於業務邏輯而非工具維護、工具的使用。
平台工程核心價值：
- 一套平台解決開發運維問題：統一管理CI/CD、鏡像倉庫、環境配置、部署策略。
- 標準化接口：團隊通過 API 或自助 UI 就能完成部署、發佈、監控，而無需瞭解底層細節。
- 可追溯與審計：所有流水線、配置變更、資源使用都被平台統一記錄。
- 擴展性強：平台能力模塊化，可接入雲廠商服務、SaaS、內部工具。
- 解放生產力：開發團隊不必重複做DevOps工具維護，業務開發效率提升明顯。
小結
DevOps強調流程和工具，而平台工程強調能力和自助服務。
未來企業的發展趨勢是：把DevOps的複雜性封裝進一個可自助使用的平台，讓開發團隊專注於業務創新，而不是代碼開發完成後如何通過流水線發佈。
運維管理平台通過對底層資源編排能力進行封裝，提供應用部署、擴縮容、網絡與存儲管理、權限控制、審計、CI/CD等功能，從而實現運維流程的自動化和平台化；
一、CD持續部署方式
運維管理平台實現應用自動化部署主要有以下2種實現路徑：
1.平台驅動部署
如果更注重用户體驗和部署效率，可以採用類似VelaUX的部署方式。
平台將應用配置（OAM 模型）持久化到數據庫中，在用户發起部署時，平台直接調用KubeVela完成應用發佈。這種模式前後端交互簡單、部署速度快，更適合平台化操作。
2.Git驅動部署
如果更關注部署過程的可追溯性、審計能力以及企業合規要求，則可以採用GitOps模式。
在這種模式下，代碼倉庫作為唯一的事實源（Single Source of Truth），所有應用配置和變更都通過Git提交完成，由GitOps控制器（例如 ArgoCD）持續同步到Kubernetes集羣，從而實現可追溯、可審計、可審批的部署流程。
二、GitOps概念
GitOps是一種以Git代碼倉庫為唯一可信源的雲原生應用交付與運維模式。
GitOps利用Kubernetes、Terraform等平台的聲明式API特性與DevOps實踐相結合，通過在Git倉庫中統一定義系統的期望狀態，由GitOps控制器（如ArgoCD/FluxCD）持續監聽、同步並校準系統狀態，確保實際運行環境始終與Git倉庫中定義的狀態保持一致。
GitOps並不依賴於具體工具（如 GitLab或ArgoCD/FluxCD），而在於部署流程是否滿足以下原則：
- 以代碼倉庫作為唯一事實源
- 能夠自動執行
- 並且能完整追蹤操作與變更。
例如，將OAM應用信息存儲在Gitea中，一旦PR合併觸發ArgoWorkflows流水線執行，將OAM應用配置更新到KubeVela管控集羣，這種交付方式同樣符合GitOps風格。
| 工具 | 優勢 | 適合 OAM 場景嗎？ |
|---|---|---|
| Argo Workflows | 流水線 + 任務編排 → 一次性執行 Workflow | ❌ 不適合管理持續狀態，需要額外邏輯做差異檢測和修復 |
| Argo CD | 原生GitOps控制器 → 持續同步 Git → K8s，自動矯正差異 | ✅ 非常適合 OAM 應用管理，Git 倉庫就是唯一事實源，集羣狀態始終與 Git 保持一致 |
通過GitOps這種部署方式，可以實現基礎設施與雲原生應用的：
-
自動化部署
-
可追溯變更
-
可審計流程
-
環境一致性
三、平台工程融合GitOps
在現代平台工程體系中，平台UI充當統一門面，成為用户操作系統的唯一入口，而Git倉庫依然承擔系統狀態唯一事實源（Source of Truth）的角色。
平台工程封裝DevOps複雜性，解決開發者體驗問題，GitOps解決系統配置強一致性問題，兩者正在融合為現代雲原生交付體系。
1.KubeVela實現GitOps持續部署流程
KubeVela基於OAM開放應用模型，屏蔽了Kubernetes底層複雜的資源、調度、運維細節。
KubeVela以應用為中心提供統一的聲明式定義與管控能力，極大簡化了雲原生應用的交付與管理成本，讓研發人員只需要關注應用本身，而非複雜的基礎設施細節。
KubeVela內置GitOps控制器工具插件FluxCD，也可以實現GitOps持續部署流程。
在GitOps最佳實踐中，應用代碼倉庫（App Code Repo）和 KubeVela配置倉庫（KubeVela Config Repository）在Git倉庫分開存儲，可以讓代碼和部署配置解耦；
運維/SRE
運維/SRE直接維護KubeVela配置倉庫。
開發人員
CI/CD大致流程如下：
- CI工具（GitLab-CI/Jenkins/ArgoWorkflows）完成源代碼集成和鏡像構建，推送Docker鏡像至鏡像倉庫（Harbor/JFrog Artifactory）
- KubeVela監聽（watch）到鏡像倉庫中鏡像版本變化，自動更新鏡像到KubeVela配置倉庫。
- KubeVela又監聽（watch）到KubeVela配置倉庫的內容變化， 自動從KubeVela配置倉庫pull最新鏡像同步更新到Kubernetes集羣。
2.平台工程融合GitOps
GitOps持續交付的默認用户入口是Git客户端，這要求用户掌握Git的基本操作。
但在實際場景中，運維平台的用户不僅包括開發和運維工程師，還會涉及產品經理等不熟悉Git客户端的角色。
這時，內部開發者平台（IDP）就可以在GitOps之上封裝關鍵抽象層，將GitOps的底層流程封裝成直觀易用的UI界面，讓所有用户羣體都能通過可視化操作完成持續部署。
平台工程融合GitOps後自動化交付流程大致如下：
- 前端提交JSON格式的OAM配置；
- 後端保存JSON格式的OAM到關係型數據庫方便前端回顯；
- 後端根據JSON數據生成YAML文件並提交到KubeVela配置倉庫，如果前端發起更新OAM配置請求，後端重新生成同名新內容的yaml文件覆蓋原內容；
- YAML文件由代碼倉庫統一存儲和管理；
- ArgoCD監聽YAML文件變更將最新KubeVela配置同步更新到K8s集羣；
- KubeVela負責OAM配置渲染、Workflow執行與應用部署，並輸出事件日誌；
- 日誌採集服務統一收集管控集羣的事件與日誌上傳到ClickHouse數據庫；
- 前端通過輪詢後端接口，從ClickHouse獲取並展示完整的應用部署事件和運行日誌；
參考
