雲原生 DevOps，模型化應用交付能力很重要！

阿里巴巴雲原生發表於2021-11-11
dev模型

撰稿：溪洋
稽核校對：天元、海珠
編輯&排版：雯燕

雲原生正在成為企業業務創新和解決規模化挑戰的加速器。

雲原生帶來的變革絕不限於基礎設施和應用架構等技術層面，更是對於研發理念、交付流程和 IT 組織方式的變革，也在推進企業 IT 組織、流程和文化的變革。在雲原生架構漸為普及的背後， DevOps 文化及其支撐其落地實踐的自動化工具與平臺能力，發揮了關鍵的價值。

雲原生帶來的研發與運維協作介面

相較於雲原生，DevOps 並不是什麼新鮮的事情，其實踐早已深入企業現代應用程式架構。DevOps 強調團隊間的溝通和快速反饋，通過構建自動化的持續交付（Continuous Delivery）及流水線的應用釋出方式，達到快速響應業務需求、交付產品和提高交付質量的目的。隨著容器技術在企業的規模化應用，雲端計算可程式設計基礎設施和 Kubernetes 宣告式的 API 等能力加速了開發和運維角色的融合。

雲原生的大勢所趨使上雲成為企業標配，圍繞雲原生去定義下一代研發平臺成為必然，也倒逼著 IT 組織方式進一步發生變化——新的平臺工程團隊開始浮現。在這樣的背景下，如何在雲原生的環境下更高效地實踐 DevOps 成為一個新的課題和訴求。

1.png

下一代 DevOps 平臺演進趨勢

伴隨著 Kubernetes 生態從底層到應用層能力的逐步完善，平臺工程團隊可以更方便地基於業務場景和終端使用者實際需求來構建不同的應用平臺，卻也為上層應用開發者帶來了挑戰和困擾。

Kubernetes 生態本身的能力池固然豐富，但是社群裡卻並沒有一個可擴充套件的、方便快捷的方式，為雲原生架構下混合、分散式的部署環境引入一致的上層抽象來為應用交付進行建模。應用交付過程上層抽象能力的缺失，使 Kubernetes 的複雜性無法做到嚮應用開發人員遮蔽。

下圖展示了一個雲原生下的 DevOps 流水線的典型流程。首先是程式碼的開發，程式碼託管到 Github，再接入單元測試的工具 Jenkins，此時基本研發已完成。再接著到映象的構建，涉及到配置、編排等。雲原生中可以用 HELM 打包應用。打包好的應用部署到各個環境中。但整個過程中會面臨很多挑戰。

2.png

首先，在不同的環境需要不同的運維能力。其次，配置的過程中要建立雲上資料庫，需要另外開啟一個控制檯來建立資料庫。還需要配置負載均衡。在應用啟動以後還需要配置額外的功能，包括日誌、策略、安全防護等等。可以發現，雲資源和 DevOps 平臺體驗是割裂的，裡面充斥著藉助外部平臺建立的過程。這對新手來說是非常痛苦的。

在容器出現之前的傳統的 DevOps 模式需要不同的流程和工作流。容器技術是以 DevOps 的視角構建的。抽象的容器所提供的功能會影響我們如何看待 DevOps，因為隨著微服務的出現，傳統的架構開發將發生變化。這意味著要遵循在 Kubernetes 上執行容器的最佳實踐，並將 DevOps 的理念向 GitOps、DevSecOps 擴充套件，使雲原生下的 DevOps 更加高效、安全、穩定、可靠。

OAM（Open Application Model） 試圖提供一種雲原生應用的建模語言，以實現研發和運維的視角分離，使 Kubernetes 的複雜性無需透傳至研發，運維通過提供模組化、可移植、可擴充套件的特性元件，支撐各種複雜的應用交付場景，從而實現雲原生應用交付的敏捷性和平臺無關性。其在 Kubernetes 上的完整實現 KubeVela，已經被業界認為是構建下一代持續交付方式及 DevOps 實踐的核心工具。

3.png

最近，阿里雲在 2021 雲棲大會上釋出了雲效應用交付平臺 AppStack ，旨在進一步加速企業雲原生 DevOps 規模化落地。據云效應用交付平臺 AppStack 研發團隊介紹，其在設計之初就全面支援原生 Kubernetes 和 OAM/KubeVela ，以實現對應用部署架構無繫結、無侵入，使企業不用擔心遷移以及技術改造成本。這也標誌著 KubeVela 正在成為雲原生時代應用交付領域的重要基石。

基於 KubeVela，構建以應用為中心的交付系統

4.png

在雲原生理念迅速普及的今天，混合環境部署（混合雲/多雲/分散式雲/邊緣）已經成為了大多數企業應用、SaaS 服務、應用持續交付平臺的必然選擇，而云原生技術的發展趨勢也正在朝著“一致的、跨雲、跨環境的的應用交付”不斷邁進。

5.png

KubeVela 作為一個開箱即用、面向現代微服務架構的應用交付與管理平臺，已經正式釋出 1.1 版本。在此版本中，KubeVela 更加聚焦面向混合環境的應用交付流程，帶來了多叢集交付、交付流程定義、灰度釋出、公有云資源接入等多個開箱即用的能力和更加友好的使用者體驗，幫助開發者從“靜態配置、模板、膠水程式碼”的初級階段，直接升級至“自動化、宣告式、統一模型、天然面向多環境”的下一代以工作流為核心的交付體驗當中。

基於 KubeVela，使用者可以非常輕鬆地處理以下場景：

多環境、多叢集應用交付

面向 Kubernetes 的多環境、多叢集交付已是一個標準性需求。從 1.1 版本開始，KubeVela 不僅實現了多叢集的應用交付，並且既可以獨立工作直接納管多個叢集，也可以整合 OCM、Karmada 等各類多叢集管理工具來進行更復雜的交付動作。在多叢集交付策略的基礎上，使用者還可以通過定義 Workflow 來控制交付到不同叢集的順序、條件等工作流步驟。

定義交付工作流（Workflow）

Workflow 的具體使用場景則很多，比如在多環境應用交付場景中，使用者可以定義不同的環境交付的順序和前置條件等 。KubeVela 的工作流是面向 CD 過程的，同時也是宣告式的，所以它既可以作為 CD 系統直接同 CI 系統（比如 Jenkins 等）對接，也可以嵌入到現有 CI/CD 體系中作為增強和補充，落地方式非常靈活。

在模型上，Workflow 是由一系列 Step 組成的，而在實現上，每一個 Step 則是一個獨立的能力模組，由其具體的型別和引數來決定其具體步驟的能力。在 1.1 版本中，KubeVela 內建的 Step 已經比較豐富，也非常容易擴充套件，幫助使用者輕鬆對接已有的平臺能力，做到無縫遷移。

以應用為中心的雲資源交付

KubeVela 的設計是從“以應用為中心”的視角出發，因此可以幫助開發者以完全 Serverless 的方式更好、更方便的管理雲資源，而不是疲於應付各種不同的雲產品和控制檯。在實現上，KubeVela 內建整合了 Terraform 來作為雲資源的編排工具，並且能夠以統一的應用模型支援各個雲廠商上百種不同型別雲服務的部署、繫結和管理。

在使用上，目前 KubeVela 將雲資源分為以下三類：

  • 作為元件：比如資料庫、中介軟體、SaaS 服務等。比如 KubeVela 中的 Alibaba-RDS 服務就屬於這種
  • 作為運維特徵：比如日誌分析、監控視覺化、監控報警等服務
  • 作為應用執行基礎設施：比如 Kubernetes 託管叢集、SLB 負載均衡、NAS檔案儲存服務等

更容易落地的 GitOps 持續交付實踐

KubeVela 作為一個宣告式的應用交付控制平面，天然就可以以 GitOps 的方式進行使用（可單獨使用，也可配合 ArgoCD 等工具），並且能夠為 GitOps 場景提供更多端到端的能力和增強、幫助 GitOps 理念以更加親民和解決實際問題的方式在企業中落地。這些能力包括：

  • 定義應用交付工作流（CD 流水線）
  • 處理部署過程中的各種依賴關係和拓撲結構
  • 在現有各種 GitOps 工具的語義之上提供統一的上層抽象，簡化應用交付與管理過程
  • 統一進行雲服務的宣告、部署和服務繫結
  • 提供開箱即用的交付策略（金絲雀、藍綠髮布等）
  • 提供開箱即用的混合環境/多叢集部署策略（放置規則、叢集過濾規則、跨環境Promotion 等）
  • 在多環境交付中提供 Kustomize 風格的 Patch 來描述部署差異，而使用者無需學習任何 Kustomize 本身的細節
  • ……

KubeVela 1.2 版本即將重磅釋出

持續打造天然面向混合環境的企業應用作業系統、讓開發者享受交付應用的過程，這是 Kubevela 專案的目標和願景。在接下來的 1.2 版本，KubeVela 將帶來以應用為中心的控制皮膚 UI，實現便捷的企業應用組裝、分發、交付流程，提供給開發者更簡單的應用交付體驗，同時覆蓋邊緣應用交付等更多的使用場景。

6.png

KubeVela 1.2 版本將在 2021 年 12 月舉辦的 KubeCon China 上重磅釋出，敬請持續關注 KubVela 社群以及阿里巴巴雲原生動態！

您可以通過如下方式瞭解更多關於 KubeVela 以及 OAM 專案的細節：

1）專案程式碼庫：
github.com/oam-dev/kubevela
歡迎 Star/Watch/Fork！

2）專案官方主頁與文件：
kubevela.io/
從 1.1 版本開始，已提供中文、英文文件，更多語言文件歡迎開發者進行翻譯。

3）專案釘釘群：23310022；Slack：CNCF #kubevela Channel

4）加入微信群：請先掃碼新增以下 maintainer 微訊號，表明進入 KubeVela 使用者群：
7.png

相關文章