阿里巴巴如何改善開(kāi)發(fā)人員在 K8s 上的體驗(yàn)？

作者：鄧洪超 阿里巴巴應(yīng)用交付專家

前言

通過(guò) K8s，用戶能夠自定義基礎(chǔ)設(shè)施，可以平行的替換或改造平臺(tái)的已有功能，而非只能局限在平臺(tái)提供的能力之上構(gòu)建。但正是這樣的“白盒化”體驗(yàn)，正在為越來(lái)越多的研發(fā)和運(yùn)維帶來(lái)“太復(fù)雜”的困擾。

從 Kubernetes 到“以應(yīng)用為中心”的美好未來(lái)之間，全世界的 PaaS 工程師其實(shí)都在期待一項(xiàng)全新的技術(shù)能夠彌補(bǔ)這之間的鴻溝。阿里云原生應(yīng)用平臺(tái)團(tuán)隊(duì)的做法是，通過(guò)為應(yīng)用“建?！钡姆绞絹?lái)解決這個(gè)問(wèn)題，這也正是 Open Application Model (OAM) 開(kāi)源項(xiàng)目得以創(chuàng)建的重要目的。

阿里巴巴的容器化之旅

阿里巴巴的容器化之旅始于 2013 年。在 Docker 誕生之前，阿里巴巴基于 lxc 的容器引擎研發(fā)了容器技術(shù) T4，用于在裸機(jī)上部署和管理應(yīng)用程序。

2017 年, 阿里巴巴內(nèi)部孵化了類似于 K8s 的容器編排引擎 Sigma 作為資源統(tǒng)一層，用于管理內(nèi)部機(jī)器池，平均利用率達(dá)到 40％。

2018 年，Sigma 重新設(shè)計(jì)并遷移成兼容 K8s API，阿里巴巴重新編寫了自定義控制器和調(diào)度算法，并向暴露聲明式 API 給用戶試用。

2019 年底，阿里巴巴中的大多數(shù)應(yīng)用都在 K8s 上運(yùn)行，并且在 K8s 之上構(gòu)建了數(shù)十個(gè)原生框架，構(gòu)筑 K8s 生態(tài)系統(tǒng)。而 2019 年的 雙11 活動(dòng)不僅僅是商業(yè)上的成功，更是 K8s 基礎(chǔ)設(shè)施可以支持如此大規(guī)模的有力證明。

在解決了 K8s 中的規(guī)?；头€(wěn)定性問(wèn)題之后，我們開(kāi)始面臨一個(gè)新的挑戰(zhàn)：K8s API 過(guò)于復(fù)雜，開(kāi)發(fā)人員很難學(xué)習(xí)。

導(dǎo)致 K8s API 復(fù)雜的 3 個(gè)原因

K8s API 之所以復(fù)雜，主要有以下三個(gè)主要原因：

1. K8s 缺乏以“應(yīng)用”為中心的資源模型

K8s 中沒(méi)有“應(yīng)用”的概念，只有松散耦合的基礎(chǔ)架構(gòu)資源。部署應(yīng)用需要編寫 Pod、設(shè)置網(wǎng)絡(luò)和存儲(chǔ)之類的基礎(chǔ)設(shè)施資源，非常底層。然而，對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，他們不想配置這些復(fù)雜的底層資源信息，他們想從開(kāi)發(fā)層面指定應(yīng)用部署規(guī)范，例如具有自動(dòng)擴(kuò)容、監(jiān)控、Ingress 等功能的無(wú)狀態(tài)服務(wù)組件。我們需要提供更高層級(jí)的應(yīng)用層抽象和以應(yīng)用程序?yàn)橹行牡馁Y源模型，以彌合部署應(yīng)用程序和配置之間的差距。

2. K8s API 中沒(méi)有分離開(kāi)發(fā)和運(yùn)維的關(guān)注點(diǎn)

其次，K8s API 中沒(méi)有分離開(kāi)發(fā)和運(yùn)維的關(guān)注點(diǎn)。從上圖可以看出，K8s 將所有屬于不同角色的字段封裝在一個(gè) API 中。例如，開(kāi)發(fā)人員僅需指定容器映像、端口和運(yùn)行狀況檢查；運(yùn)維人員則負(fù)責(zé)配置副本大小、滾動(dòng)更新策略、存儲(chǔ)卷訪問(wèn)模式等。

對(duì)于 K8s API 來(lái)說(shuō)這樣的聲明是沒(méi)有問(wèn)題的。K8s 意在公開(kāi)基礎(chǔ)架構(gòu)功能，并用于構(gòu)建其他平臺(tái)。因此，它需要包含所有內(nèi)容，并提供多合一的 API。但是，我們發(fā)現(xiàn)多合一 API 不適合寫應(yīng)用程序的終端用戶。在 K8s API 之上，我們需要區(qū)分角色、將開(kāi)發(fā)和運(yùn)維的關(guān)注點(diǎn)分離開(kāi)。

3. 在 K8s 上沒(méi)有可移植的應(yīng)用抽象定義

K8s 定義了使用基礎(chǔ)資源的標(biāo)準(zhǔn)方法。但是如上所述，部署應(yīng)用程序需要網(wǎng)絡(luò)接入、監(jiān)控、日志等。我們需要對(duì)那些應(yīng)用程序操作接口進(jìn)行標(biāo)準(zhǔn)化，實(shí)現(xiàn)可移植的應(yīng)用層抽象。

OAM 開(kāi)啟下一代云原生 DevOps 技術(shù)革命

針對(duì)上述 K8s API 過(guò)于復(fù)雜、開(kāi)發(fā)人員難學(xué)習(xí)的問(wèn)題，這里來(lái)介紹一下由阿里巴巴聯(lián)合微軟在社區(qū)推出的用于構(gòu)建和交付云原生應(yīng)用的標(biāo)準(zhǔn)規(guī)范 — 開(kāi)放應(yīng)用程序模型 OAM（Open Application Model）。

2019 年 10 月，阿里巴巴宣布聯(lián)合微軟共同推出 開(kāi)放應(yīng)用模型項(xiàng)目（Open Application Model - OAM）。

所謂“應(yīng)用模型”，其實(shí)是一個(gè)專門用來(lái)對(duì)云原生應(yīng)用本身和它所需運(yùn)維能力進(jìn)行定義與描述的標(biāo)準(zhǔn)開(kāi)源規(guī)范。所以對(duì)于 Kubernetes 來(lái)說(shuō)，OAM 即是一個(gè)標(biāo)準(zhǔn)的“應(yīng)用定義”項(xiàng)目（類比已經(jīng)不再活躍的 Kubernetes Application CRD 項(xiàng)目），同時(shí)也是一個(gè)專注于封裝、組織和管理 Kubernetes 中各種“運(yùn)維能力”、以及連接“運(yùn)維能力”與“應(yīng)用”的平臺(tái)層項(xiàng)目。

在 OAM 中，一個(gè)應(yīng)用程序包含三個(gè)核心理念：
第一個(gè)核心理念是組成應(yīng)用程序的服務(wù)組件（Component），它包含微服務(wù)、數(shù)據(jù)庫(kù)、云服務(wù)等；
第二個(gè)核心理念是描述應(yīng)用程序運(yùn)維特征（Trait）的集合，例如，彈性伸縮和 Ingress 等功能。它們對(duì)應(yīng)用程序的運(yùn)行至關(guān)重要，但在不同環(huán)境中其實(shí)現(xiàn)方式各不相同；
最后，為了將這些描述轉(zhuǎn)化為具體的應(yīng)用實(shí)例，運(yùn)維人員使用應(yīng)用配置（Application Configuration）來(lái)組合組件和相應(yīng)的特征，以構(gòu)建可部署的應(yīng)用交付實(shí)例。

如上圖所示，我們可以看到開(kāi)發(fā)人員定義了組件 (Component) 來(lái)描述服務(wù)單元。然后運(yùn)維人員定義運(yùn)維特征 (Trait)，并將其附加到前面的組件上，最后構(gòu)成 OAM 可交付物 — ApplicationConfiguration。在圖中最下方，底層的基礎(chǔ)設(shè)施資源將通過(guò) OAM 平臺(tái)呈現(xiàn)。

那么 OAM 如何解決上述三個(gè) Kuberntes API 的問(wèn)題？首先，OAM 隱藏了底層基礎(chǔ)架構(gòu)細(xì)節(jié)（例如，是云還是物聯(lián)網(wǎng)），專注于應(yīng)用層抽象，提供以應(yīng)用為中心的資源模型。其次，OAM 劃分了應(yīng)用交付路徑上的開(kāi)發(fā)、運(yùn)維、基礎(chǔ)架構(gòu)三種角色，分離了關(guān)注點(diǎn)，讓流程更加清晰和易于管理。第三，K8s 定義了基礎(chǔ)架構(gòu)的可移植抽象，而 OAM 站在 K8s 的肩膀上，提供了可移植的應(yīng)用層抽象，讓同一個(gè)應(yīng)用可以跨平臺(tái)運(yùn)行。

OAM 還定義了一組核心工作負(fù)載/運(yùn)維特征/應(yīng)用范疇，作為應(yīng)用程序交付平臺(tái)的基石。并且，這些核心規(guī)范有一個(gè) 開(kāi)源實(shí)現(xiàn) — Crossplane。Crossplane 提供了讓用戶擴(kuò)展其功能的機(jī)制。例如 Crossplane core 提供的 ContainerizedWorkload，在容器中運(yùn)行應(yīng)用程序并管理應(yīng)用程序的生命周期。
此外，我們還可以添加更多工作負(fù)載（例如 FaaS）以運(yùn)行無(wú)服務(wù)器功能，或者添加運(yùn)維特性（例如 CronHPA）來(lái)定義 CronJob 類型的 HPA 策略。OAM 以標(biāo)準(zhǔn)的聲明方式在單個(gè)平臺(tái)中管理應(yīng)用交付能力和流程。當(dāng)模塊化的 Workload 和 Trait 越來(lái)越多，就會(huì)形成組件市場(chǎng)。而 OAM 就像是這個(gè)組件市場(chǎng)的管理者，處理組件之間的關(guān)系，把許多組件集成起來(lái)變成一個(gè)產(chǎn)品交付給用戶。OAM 加持下的 PaaS，可以像樂(lè)高積木一樣靈活組裝底層能力、運(yùn)維特征、以及開(kāi)發(fā)組件。使得應(yīng)用管理變得統(tǒng)一，功能卻更加強(qiáng)大！

結(jié)語(yǔ)

以上我們討論了 OAM 的背景、動(dòng)機(jī)和架構(gòu)細(xì)節(jié)。值得注意的是，OAM 項(xiàng)目是開(kāi)源中立、由社區(qū)驅(qū)動(dòng)的。該規(guī)范和實(shí)現(xiàn)得到包括 Alibaba、Microsoft、Upbound 在內(nèi)的開(kāi)放社區(qū)的支持。我們歡迎更多的人參與其中，共同定義云原生應(yīng)用交付的未來(lái)。

您可以在 github repos 上貢獻(xiàn)： https://github.com/oam-dev/spec
加入郵件列表: https://groups.google.com/forum/#!forum/oam-dev

加入社區(qū)周會(huì): Bi-weekly, Tuesdays 10:30AM PST

加入釘釘討論群:

“ 阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的技術(shù)圈?！?/p>