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

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

前言

經過 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<br />加入郵件列表: https://groups.google.com/forum/#!forum/oam-dev

加入社區週會: Bi-weekly, Tuesdays 10:30AM PST

加入釘釘討論羣:

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」