![0.png](https://ucc.alicdn.com/pic/developer-ecology/7f8e9fe441b4469fa93321f18136240a.png)

作者：鄧洪超  阿里巴巴應用交付專家

# 前言
透過 K8s，使用者能夠自定義基礎設施，可以平行的替換或改造平臺的已有功能，而非只能侷限在平臺提供的能力之上構建。但正是這樣的“白盒化”體驗，正在為越來越多的研發和運維帶來“太複雜”的困擾。

從 Kubernetes 到“以應用為中心”的美好未來之間，全世界的 PaaS 工程師其實都在期待一項全新的技術能夠彌補這之間的鴻溝。阿里雲原生應用平臺團隊的做法是，透過為應用“建模”的方式來解決這個問題，這也正是 [Open Application Model (OAM) ](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487043&idx=1&sn=088457a1dccd6578290c9291a968bf16&chksm=fae5058ccd928c9a618c2763c8dcf74348e2198ba532a1095f0d9292da44f8d1b2a9f8cf4342&scene=21#wechat_redirect)開源專案得以建立的重要目的。

# 阿里巴巴的容器化之旅

![1.png](https://ucc.alicdn.com/pic/developer-ecology/33b210e96d67404889cc49f3927158b7.png)

阿里巴巴的容器化之旅始於 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.png](https://ucc.alicdn.com/pic/developer-ecology/3e1ac6369fd047bf92d65e1437fc25b4.png)

## 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）。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/4aa46ba94ca24fc083869249b40aacf2.png)

2019 年 10 月，阿里巴巴宣佈聯合微軟共同推出[開放應用模型專案（Open Application Model - OAM）](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487043&idx=1&sn=088457a1dccd6578290c9291a968bf16&chksm=fae5058ccd928c9a618c2763c8dcf74348e2198ba532a1095f0d9292da44f8d1b2a9f8cf4342&scene=21#wechat_redirect)。

所謂“應用模型”，其實是一個專門用來對雲原生應用本身和它所需運維能力進行定義與描述的標準開源規範。所以對於 Kubernetes 來說，OAM 即是一個標準的“應用定義”專案（類比已經不再活躍的 Kubernetes Application CRD 專案），同時也是一個專注於封裝、組織和管理 Kubernetes 中各種“運維能力”、以及連線“運維能力”與“應用”的平臺層專案。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/798069eba7c3444c92bd56266639c604.png)

在 OAM 中，一個應用程式包含三個核心理念：
第一個核心理念是組成應用程式的服務元件（Component），它包含微服務、資料庫、雲服務等；
第二個核心理念是描述應用程式運維特徵（Trait）的集合，例如，彈性伸縮和 Ingress 等功能。它們對應用程式的執行至關重要，但在不同環境中其實現方式各不相同；
最後，為了將這些描述轉化為具體的應用例項，運維人員使用應用配置（Application Configuration）來組合元件和相應的特徵，以構建可部署的應用交付例項。

如上圖所示，我們可以看到開發人員定義了元件 (Component) 來描述服務單元。然後運維人員定義運維特徵 (Trait)，並將其附加到前面的元件上，最後構成 OAM 可交付物 -- ApplicationConfiguration。在圖中最下方，底層的基礎設施資源將透過 OAM 平臺呈現。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/4df7da2427ed474fbf37f585a823c7af.png)

那麼 OAM 如何解決上述三個 Kuberntes API 的問題？首先，OAM 隱藏了底層基礎架構細節（例如，是雲還是物聯網），專注於應用層抽象，提供以應用為中心的資源模型。其次，OAM 劃分了應用交付路徑上的開發、運維、基礎架構三種角色，分離了關注點，讓流程更加清晰和易於管理。第三，K8s 定義了基礎架構的可移植抽象，而 OAM 站在 K8s 的肩膀上，提供了可移植的應用層抽象，讓同一個應用可以跨平臺執行。

OAM 還定義了一組核心工作負載/運維特徵/應用範疇，作為應用程式交付平臺的基石。並且，這些核心規範有一個[開源實現 -- Crossplane](https://github.com/crossplane/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://github.com/oam-dev/spec)<br>加入郵件列表: [https://groups.google.com/forum/#!forum/oam-dev](https://groups.google.com/forum/)

加入社群週會: [Bi-weekly, Tuesdays 10:30AM PST](https://calendar.google.com/calendar?cid=dDk5YThyNGIwOWJyYTJxajNlbWI0a2FvdGtAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ)

加入釘釘討論群:

![6.png](https://ucc.alicdn.com/pic/developer-ecology/8935ba3bd8174bceafe0f0d6dfa75620.png)

![3 群直播海報.png](https://ucc.alicdn.com/pic/developer-ecology/24d18b9d67e24412a46f2c82e69f3a15.png)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

阿里巴巴如何改善開發人員在 K8s 上的體驗？

相關文章