作者：鄧洪超 阿里巴巴應用交付專家
前言
通過 K8s，用戶能夠自定義基礎設施，可以平行的替換或改造平臺的已有功能，而非只能侷限在平臺提供的能力之上構建。但正是這樣的“白盒化”體驗，正在爲越來越多的研發和運維帶來“太複雜”的困擾。
從 Kubernetes 到“以應用爲中心”的美好未來之間，全世界的 PaaS 工程師其實都在期待一項全新的技術能夠彌補這之間的鴻溝。阿里雲原生應用平臺團隊的做法是，通過爲應用“建模”的方式來解決這個問題，這也正是 Open Application Model (OAM) 開源項目得以創建的重要目的。
阿里巴巴的容器化之旅
阿里巴巴的容器化之旅始於 2013 年。在 Docker 誕生之前，阿里巴巴基於 lxc 的容器引擎研發了容器技術 T4，用於在裸機上部署和管理應用程序。
2017 年, 阿里巴巴內部孵化了類似於 K8s 的容器編排引擎 Sigma 作爲資源統一層，用於管理內部機器池，平均利用率達到 40％。
2018 年，Sigma 重新設計並遷移成兼容 K8s API，阿里巴巴重新編寫了自定義控制器和調度算法，並向暴露聲明式 API 給用戶試用。
2019 年底，阿里巴巴中的大多數應用都在 K8s 上運行，並且在 K8s 之上構建了數十個原生框架，構築 K8s 生態系統。而 2019 年的 雙11 活動不僅僅是商業上的成功，更是 K8s 基礎設施可以支持如此大規模的有力證明。
在解決了 K8s 中的規模化和穩定性問題之後，我們開始面臨一個新的挑戰：K8s API 過於複雜，開發人員很難學習。
導致 K8s API 複雜的 3 個原因
K8s API 之所以複雜，主要有以下三個主要原因：
1. K8s 缺乏以“應用”爲中心的資源模型
K8s 中沒有“應用”的概念，只有鬆散耦合的基礎架構資源。部署應用需要編寫 Pod、設置網絡和存儲之類的基礎設施資源，非常底層。然而，對於開發人員來說，他們不想配置這些複雜的底層資源信息，他們想從開發層面指定應用部署規範，例如具有自動擴容、監控、Ingress 等功能的無狀態服務組件。我們需要提供更高層級的應用層抽象和以應用程序爲中心的資源模型，以彌合部署應用程序和配置之間的差距。
2. K8s API 中沒有分離開發和運維的關注點
其次，K8s API 中沒有分離開發和運維的關注點。從上圖可以看出，K8s 將所有屬於不同角色的字段封裝在一個 API 中。例如，開發人員僅需指定容器映像、端口和運行狀況檢查；運維人員則負責配置副本大小、滾動更新策略、存儲卷訪問模式等。
對於 K8s API 來說這樣的聲明是沒有問題的。K8s 意在公開基礎架構功能，並用於構建其他平臺。因此，它需要包含所有內容，並提供多合一的 API。但是，我們發現多合一 API 不適合寫應用程序的終端用戶。在 K8s API 之上，我們需要區分角色、將開發和運維的關注點分離開。
3. 在 K8s 上沒有可移植的應用抽象定義
K8s 定義了使用基礎資源的標準方法。但是如上所述，部署應用程序需要網絡接入、監控、日誌等。我們需要對那些應用程序操作接口進行標準化，實現可移植的應用層抽象。
OAM 開啓下一代雲原生 DevOps 技術革命
針對上述 K8s API 過於複雜、開發人員難學習的問題，這裏來介紹一下由阿里巴巴聯合微軟在社區推出的用於構建和交付雲原生應用的標準規範 – 開放應用程序模型 OAM（Open Application Model）。
2019 年 10 月，阿里巴巴宣佈聯合微軟共同推出開放應用模型項目（Open Application Model - OAM）。
所謂“應用模型”，其實是一個專門用來對雲原生應用本身和它所需運維能力進行定義與描述的標準開源規範。所以對於 Kubernetes 來說，OAM 即是一個標準的“應用定義”項目（類比已經不再活躍的 Kubernetes Application CRD 項目），同時也是一個專注於封裝、組織和管理 Kubernetes 中各種“運維能力”、以及連接“運維能力”與“應用”的平臺層項目。
在 OAM 中，一個應用程序包含三個核心理念：
第一個核心理念是組成應用程序的服務組件（Component），它包含微服務、數據庫、雲服務等；
第二個核心理念是描述應用程序運維特徵（Trait）的集合，例如，彈性伸縮和 Ingress 等功能。它們對應用程序的運行至關重要，但在不同環境中其實現方式各不相同；
最後，爲了將這些描述轉化爲具體的應用實例，運維人員使用應用配置（Application Configuration）來組合組件和相應的特徵，以構建可部署的應用交付實例。
如上圖所示，我們可以看到開發人員定義了組件 (Component) 來描述服務單元。然後運維人員定義運維特徵 (Trait)，並將其附加到前面的組件上，最後構成 OAM 可交付物 – ApplicationConfiguration。在圖中最下方，底層的基礎設施資源將通過 OAM 平臺呈現。
那麼 OAM 如何解決上述三個 Kuberntes API 的問題？首先，OAM 隱藏了底層基礎架構細節（例如，是雲還是物聯網），專注於應用層抽象，提供以應用爲中心的資源模型。其次，OAM 劃分了應用交付路徑上的開發、運維、基礎架構三種角色，分離了關注點，讓流程更加清晰和易於管理。第三，K8s 定義了基礎架構的可移植抽象，而 OAM 站在 K8s 的肩膀上，提供了可移植的應用層抽象，讓同一個應用可以跨平臺運行。
OAM 還定義了一組核心工作負載/運維特徵/應用範疇，作爲應用程序交付平臺的基石。並且，這些核心規範有一個開源實現 – Crossplane。Crossplane 提供了讓用戶擴展其功能的機制。例如 Crossplane core 提供的 ContainerizedWorkload，在容器中運行應用程序並管理應用程序的生命週期。
此外，我們還可以添加更多工作負載（例如 FaaS）以運行無服務器功能，或者添加運維特性（例如 CronHPA）來定義 CronJob 類型的 HPA 策略。OAM 以標準的聲明方式在單個平臺中管理應用交付能力和流程。當模塊化的 Workload 和 Trait 越來越多，就會形成組件市場。而 OAM 就像是這個組件市場的管理者，處理組件之間的關係，把許多組件集成起來變成一個產品交付給用戶。OAM 加持下的 PaaS，可以像樂高積木一樣靈活組裝底層能力、運維特徵、以及開發組件。使得應用管理變得統一，功能卻更加強大！
結語
以上我們討論了 OAM 的背景、動機和架構細節。值得注意的是，OAM 項目是開源中立、由社區驅動的。該規範和實現得到包括 Alibaba、Microsoft、Upbound 在內的開放社區的支持。我們歡迎更多的人蔘與其中，共同定義雲原生應用交付的未來。
您可以在 github repos 上貢獻：https://github.com/oam-dev/spec
加入郵件列表: https://groups.google.com/forum/#!forum/oam-dev
加入社區週會: Bi-weekly, Tuesdays 10:30AM PST
加入釘釘討論羣:
“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”