QCon演講實錄（上）：多雲環境下應用管理與交付實踐

作者：阿里雲大數據基礎工程技術團隊——郭耀星

大家上午好！我是來自阿里雲大數據基礎工程技術團隊的郭耀星，花名雪堯。今天我很高興能夠來到QCon，與大家分享我的經驗和心得。在當前的多雲環境中，作為運維支撐團隊，如何在分裂嚴重、存在多個不同環境的異構Kubernetes底座情況下，高效率地管理與交付業務應用，是一個值得探討的話題。

在開始正式分享之前，先做一個簡單的自我介紹，我是 17 年武漢大學畢業，之後一直在阿里雲的計算平台大數據基礎工程技術團隊，從事大數據運維平台的研發工作，也算是見證了大數據運維平台持續迭代演進的過程。

在我剛入職之後，我負責過多個運維中台服務的開發和建設。後來隨着大數據架構從物理機向雲化轉變，我逐步開始從事容器化相關的改造，再到現在完全是雲原生的天下。在這個過程中，我主導了我們這邊的 ABM，也就是大數據運維平台，在專有云及公共雲上，幾十個應用從物理機到 on K8S 的轉型，這個過程很痛苦，但也以此為契機，沉澱出了一套多雲環境下的雲原生下應用管理與交付的服務以及相對應的實踐經驗，期望在接下來的時間裏與大家分享。

今天我分享的內容主要有四個部分：

---

• 多雲環境應用管理與交付痛點
• 理論先行：OAM
• 多雲環境交付實踐 - 微服務 / 大數據產品 / SREWorks開源社區
• 關鍵能力實現與解析：AppManager (OAM Runtime)

---

首先來介紹多雲環境下應用管理與交付的痛點，然後看在這些痛點之上，我們為什麼選擇了 OAM 作為我們的理論模型，以及基於這套理論模型，我們在多個業務場景下的實踐經驗，最後是我們自己研發的這套 AppManager 服務關鍵能力的實現方案與解析。

多雲環境應用管理與交付痛點

痛點 1 – 多雲環境下的 K8s 底座適配問題

首先是第一部分，多雲環境下，應用管理與交付的痛點是什麼？

由於在統一底層基礎架構細節方面的出色表現，K8S 已經成為企業多雲管理的事實基礎。但單服務商的單 K8S 集羣真的滿足需求麼？

答案是否定的，作為基礎設施的運維，我們會和形形色色的 K8S 集羣打交道。有當前已有的各個廠商提供的公共雲 K8S 集羣，也有專有云版本部署在網絡隔離機房環境下的 K8S 集羣，以及單獨拿出來做日常開發測試的 K8S 集羣等等。除此之外，在阿里的內部場景還有更多的虛擬 K8S 集羣，比如 Flink 全託管場景等。

一般來説，大家常見的訴求是：

• 需要物理隔離，避免業務間相互影響。儘管 K8S 自身提供了 Namespace 級別的隔離，你可以設置每個 Namespace 各自使用的 CPU 和內存，甚至可以使用 Network Policy 配置不同 Namespace 的網絡連通性，但這些仍然不徹底，企業還是需要一個更加徹底的物理隔離環境，以此避免業務之間的互相影響。
• 需要混合雲。混合雲場景下，企業希望可以選擇多個公有云廠商和私有云解決方案，避免受限於單一雲廠商，或降低一定成本。
• 需要應用異地多活。部署業務多個副本到不同 region 集羣，避免單個 region 的斷電造成應用的不可用情況，實現不把雞蛋放在同一個籃子目的。
• 需要環境分離。為了區分開發測試生產環境，把這些環境部署到不同的集羣。
• 需要一定的集羣拓展性來突破單一集羣的容量上限。

當然從純粹的多集羣視角來看，目前方案有 Federation V1 / Federation V2 / OCM 等解決方案，還有多個 kubeconfig 直連的方式。不過這塊不是本次討論的重點，這裏並不討論多集羣的問題，而是討論異構 K8S 底座，多集羣方案可以看做是異構 K8S 底座方案的一個子集。

所以最後重點是：如何在一個分裂的非常嚴重的，位於多個不同環境的異構 K8S 底座下，高效率的進行應用管理與交付。

痛點 2 – 研發與運維的訴求衝突

我們團隊自身其實定位於運維平台開發，上面會有兩類角色，一類是研發，一類是 SRE。在更小規模的公司體量下，運維開發和 SRE 會歸為一體，對研發提供運維平台及服務。

當一個人的時候，我們推崇全棧工程師，DevOps。但隨着規模和體量越來越大，一定會出現很多責任田，歸屬到不同的團隊和不同的人。

在上述演進的過程中，研發和運維之間的矛盾會愈發凸顯：在研發及產品視角，瘋狂迭代瘋狂上功能才能拿下用户拿下市場；在運維視角，不動線上不做變更就不會出問題。

痛點 3 – 研發與運維的分工衝突

在物理機/ECS時代，我們自身控制着從下到上的整個鏈路。為了調和上述矛盾，我們制定了各種各樣的變更規範，開發了各式各樣的變更工具和流程，當然也吵過了很多的架。

那麼在雲原生的浪潮之下，Kubernetes 統一了底層的基礎設施，減少了大部分的底層運維工作，大家開玩笑説全部變成了 YAML 工程師。但還是有一個很重要的問題沒有解決，就是：YAML怎麼寫？誰來寫？如何交付到目標 K8S 集羣？

過去的兩年多的時間裏，上面這些問題實實在在地擺在了我們團隊的面前，在當前的定位與場景下，要支持專有云、公共雲、集團內部、開源社區等環境下的形形色色各式各樣的 K8S 集羣上面的服務託管與交付。

理論先行：OAM

古時候有兵馬未動，糧草先行。這裏我們是代碼未動，理論先行。先説一下我們為什麼會選擇 OAM(Open Application Model) 作為我們解決問題的理論基礎。

我們上面討論了多種多樣的痛點後，基本可以總結下面幾點：

• 一個是開發者花費了太多的時間在基礎設施的細節中。機器從哪來，網絡環境怎麼樣，中間件資源/DNS/負載均衡怎麼生成，集團內部的服務怎麼適配到公共雲/專有云各個底座上等等。或者更進一步，每個開發者都是 Yaml 工程師，哪怕都是 K8S，但每個底座讓你提交的 YAML 都不一樣。
• 另外一個是可擴展性低。有越來越多的平台 or 底座在嘗試去支撐各種類型需求的業務，但一般來説，應用本身對於平台的訴求會很快超越平台的能力。
• 還有云服務供應商綁定。當選擇了一個固定的底座後，應用交付的方方面面將會打上這個底座的烙印，當想嘗試轉到另一個底座的時候難於登天。
• 最後是隨着團隊規模的膨脹，研發、運維、平台人員之間開始各種相互踩腳，溝通和協調的成本也越來越高。

OAM 針對上述痛點提出了以下幾個觀點：

• 應用為先：一個應用的交付與部署應該是自包含的，其中的各類操作行為應該作為應用定義的一部分，這些內容與實際基礎設施無關。
• 清晰和可擴展性：定義一套開放標準，可以模塊化整個應用交付流程，根據個人需要將這些模塊自由組裝，達成自己想要的結果。
• 雲服務供應商無關：定義的開放標準應該是一套更高級別的抽象，可以跨本地集羣、跨雲服務供應商，不會被鎖定到任何一個廠商的底座。

OAM 通過一系列概念的定義，完成了對一個應用的抽象，實現了角色職責的分離，將應用交付這件事情與底座解耦，使得跨雲快速交付應用成為可能。開發同學也不再關心底座實現細節，只關心自己的應用模型即可。OAM 的誕生，旨在定義雲原生應用標準。

接下來我們簡單介紹下 OAM 中的部分概念：

一個 Application，也就是上圖中最外面的藍框，代表一個應用，是包含多個組件 Component 的，這裏的組件就是我們日常交付的最小業務單元，也就是上圖中的淺綠色部分，比如一個微服務、一個 Job、一個 Helm 包等。那麼組件 Component 的內部是由藍色的 Workload 和深綠色的 Trait 組成的。Workload 就是工作負載類型，描述了當前 Component 是誰，而 Trait 則定義了當前組件的運維屬性，比如我需要給這個微服務加個 200G 存儲，加一條網關路由，限制多少 CPU 內存資源，或者更復雜一點，當 Pod 漂移後 IP 變動了去做一些外部數據維護的事情。上面我描述的這些都可以用 Trait 來抽象及描述。

上面説的這幾個概念，都是面向終態的，和 K8S 自身的面向終態的邏輯是一致的，我只需要聲明式的寫出我希望的實際交付後的應用的樣子，而不需要關心內部是怎麼 Reconcile（調和） 去實現的。

除此之外，還有工作流 Workflow 和應用執行策略 Policy 的概念作為補充，他們是面向過程的，用於解決單純的面向終態的聲明方式無法覆蓋的交付過程控制，比如人工審核、回滾、多集羣發佈等等。

我認為 OAM 模型帶給我們的最大影響是，我們需要時時刻刻將“關注點分離”這個事情作為最大的準則，簡單來説就是明確人員分工。這裏面有三個角色：

• 第一個角色是應用開發人員，也就是寫業務代碼的同學，他們只需要負責組件 Component 的定義，比如我是什麼類型的服務，鏡像怎麼構建，需要哪些參數來啟動運行。
• 第二個角色是應用運維人員，他們定義上面講到的運維特徵，也就是 Trait，並將應用開發人員定義好的 Component 和這些 Trait 綁定到一起，輔以 Policy + Workflow，來生成最終交付的 Application YAML，並提交到 Runtime 實現，去維護整個應用的生命週期。
• 最後一個角色是基礎設施運維人員，他們去控制整個平台有哪些 Workload 可供上面兩類角色使用，以及維護整個平台層面的穩定性。

當然在實際實踐的過程中，根據團隊規模，有可能一人身兼數職，但隨着團隊規模的擴大，按上面的描述進行團隊的分工，可以最大限度的降低溝通協作的成本，提高應用管理與交付的效率及穩定性。

多雲環境交付實踐

終於講完了理論，我們接下來進入實踐環節。

先簡要描述下我們的團隊所面臨的業務場景，有四大塊，分別是專有云、公共雲、集團內部還有開源社區：

• 專有云：將 ABM 交付到各個客户現場環境中，依賴統一的阿里專有云 K8s 底座。大部分的客户環境是網絡隔離的，不出差到現場的情況下，只能拍照一來一回解決問題。
• 公共雲：交付各個阿里大數據產品到公共雲 ACK 集羣上(資源集羣 or 業務集羣)，多 Region，為雲上客户提供服務。
• 集團內部：部署各個大數據產品到集團內部 K8S 集羣上，多 Region，為集團內部各業務方提供服務；另外還需要將我們自身交付到 OXS(阿里雲內核區域)K8s 公共集羣中 (權限受限)。
• 開源社區：交付 SREWorks 到各類用户自建的集羣下以及各大廠商公共雲。

產品形態

面對上面所説的複雜多雲環境，我們最終設計的產品架構如下：

大家可以看到，我們針對於多雲下的應用管理和交付場景，自研了一套基於 OAM 模型的 AppManager 服務，可以認為是一套 OAM 模型的 Java Runtime 實現。它作為應用引擎，提供了很多能力，涵蓋構建、部署、製品管理、工作流引擎、插件、多雲支持、多環境支持、狀態感知等等，提供底層能力並向上暴露 API。在此之上，我們針對三個場景提供了對應的用户界面，並對實際用户提供服務。

• 首先是企業應用管理：各類開源/自有應用的雲原生部署方案，可擴展各種組件類型，讓使用者可以一鍵部署複雜應用支撐業務。
• 之後是運維應用管理，這裏會細分一下：
• • 第一類是使用前端低代碼模式構建的運維應用配置，能夠被快速嵌入集成運維中台能力。此類應用無實際後端，均為純粹的應用配置集合。
  • 第二類是使用微服務類型構建的運維應用，能夠識別並託管上面説的的應用配置，實現對應的運維中台能力。
• 最後是大數據應用管理，對應開源場景 SREWorks 下的企業應用管理。在內部我們通過該系統實現阿里雲上的所有大數據產品的交付、售賣及管控能力。

為了更好的和外部互動，我們開源了 SREWorks，作為一整套數智化運維的解決方案，也就是上圖中的 AppManager + 企業應用管理 + 運維應用管理，期望能為大家提供開箱即用的雲原生應用 & 資源交付的運維平台。大家感興趣的可以去 Github 上進一步瞭解，一會兒會單獨介紹。其中，AppManager 和我們內部使用的是同一套代碼和分支，一直保持着和開源社區的同步；企業應用管理和運維應用管理經過一定剪裁和開源適配；而大數據應用管理因為涉及阿里雲上各個大數據產品的交付、售賣及管控細節，暫不開源。

微服務

接下來我們針對不同的業務類型來看一下整體的流程：

首先是最簡單的微服務，通過 AppManager，研發的同學配置好自己的倉庫和 Dockerfile，就可以自動構建出來對應的鏡像，以及包裝後的製品——微服務組件包，多個微服務組件包最終打包為一個獨立帶版本的應用包。

之後是 SRE 同學入場，通過選擇研發同學提供的製品，配合自己配置的一系列交付參數，比如部署到哪些目標集羣、需要針對每個集羣設置什麼參數、加上哪些運維特徵 Trait、配置什麼策略、用什麼工作流來編排、如何監測感知應用運行狀態等等，這些最終生成了一份 Application 的 Yaml 文件，提交到 AppManager 運行。之後會由 AppManager 解析上述 YAML 並按要求交付到各個環境中，完成整個多雲環境下的應用交付過程。

另外在右下角這類專有云隔離環境下，我們還支持了離線包交付，方便在網絡隔離的環境下仍然簡單高效的交付全部的應用。

大數據產品

接下來看阿里雲上售賣的大數據雲產品的場景：

大數據產品因為業務特性複雜，有大量的動態渲染及相互依賴關係，所以目前採用了我們內部自研的 AbmChart 組件類型來承載，還有通用的 Helm/Kustomize 兩種形態，但不管採用哪種形態，都是 Component，在流程上和剛才並沒有什麼不同，都是構建、打包、交付、監測。只不過組件類型的內部處理流程較為複雜，以及交付的目標集羣及形態多樣化。

SREWorks開源社區

最後是 SREWorks 開源社區，SREWorks 是我們團隊對SRE理念的工程實踐的一套開源產品。通過抽象通用運維模型，實現五大核心價值場景，包括智能化運維、數據化運維、雲原生 DevOps、雲原生運維開發、多雲管理。支撐“質量、成本、效率、安全”的運維需求，提供“交付、監控、管理、控制、運營、服務”全生命週期能力支撐。

統一管控方案

看完了應用管理及交付的流程，之後我們來看一下統一管控的方案：

因為是多雲環境，所以會需要一箇中心環境 AppManager 服務來作為整體的管控，也就是中心綠色的部分。

我們把每一個網絡隔離或用途隔離的環境稱為一個單元 Unit，單元內自成一體，對外無任何依賴。

每個單元需要部署一個 AppManager 作為這個單元自己的管控，並負責自己這個單元下所有應用的交付動作。中心 AppManager 只負責向各個單元 AppManager 下發命令即可。

在這個管控架構下，我們目前有幾種類型的單元，每個單元可以非常靈活地適配其底座架構部署。

鑑於本次演講篇幅比較長，我們將演講稿分為了上下兩篇文章。在這上篇中，我們已經對多雲管理有了一個基本的瞭解。在下篇中，我們將更深入地解析多雲管理的關鍵能力：AppManager。