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

創(chuàng)新互聯(lián)公司專注于沿河企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,電子商務(wù)商城網(wǎng)站建設(shè)。沿河網(wǎng)站建設(shè)公司,為沿河等地區(qū)提供建站服務(wù)。全流程按需求定制開發(fā)，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)

前言

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

從 Kubernetes 到“以應(yīng)用為中心”的美好未來之間，全世界的 PaaS 工程師其實(shí)都在期待一項全新的技術(shù)能夠彌補(bǔ)這之間的鴻溝。阿里云原生應(yīng)用平臺團(tuán)隊的做法是，通過為應(yīng)用“建模”的方式來解決這個問題，這也正是 Open Application Model (OAM) 開源項目得以創(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è)計并遷移成兼容 K8s API，阿里巴巴重新編寫了自定義控制器和調(diào)度算法，并向暴露聲明式 API 給用戶試用。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)語

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

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

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

加入釘釘討論群:

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

標(biāo)題名稱：阿里巴巴如何改善開發(fā)人員在K8s上的體驗(yàn)？-創(chuàng)新互聯(lián)
文章來源：http://weahome.cn/article/dhssse.html