作者 |?李響、張磊

從 2019 年初開始，阿里巴巴云原生應(yīng)用平臺團(tuán)隊開始逐步在整個阿里經(jīng)濟(jì)體內(nèi)，基于標(biāo)準(zhǔn)應(yīng)用定義與交付模型進(jìn)行應(yīng)用管理產(chǎn)品與項目統(tǒng)一架構(gòu)升級的技術(shù)工作。

事實上，早在 2018 年末，當(dāng) Kubernetes 項目正式成為阿里巴巴的應(yīng)用基礎(chǔ)設(shè)施底盤之后，阿里內(nèi)部以及阿里云產(chǎn)品線在應(yīng)用管理領(lǐng)域的碎片化問題就開始日漸凸顯出來。

尤其是在云原生生態(tài)日新月異的今天，阿里巴巴與阿里云的應(yīng)用管理產(chǎn)品架構(gòu)（包括阿里內(nèi)部 PaaS 和云上 PaaS 產(chǎn)品），如何以最佳姿態(tài)擁抱云原生生態(tài)、如何以最高效的技術(shù)手段借助生態(tài)日新月異的能力構(gòu)建出更強(qiáng)大的 PaaS 服務(wù)，而不是重復(fù)造輪子甚至和生態(tài)“背道而馳”，很快就成為了阿里團(tuán)隊亟待解決的重要技術(shù)難題。

但棘手的是，這個問題并不是簡單把 PaaS 遷移或者集成到 Kubernetes 上來就能夠解決的：PaaS 與 Kubernetes 之間，從來就沒有存在這樣一條清晰的分界線，可是 Kubernetes 本身又并不是面向最終用戶設(shè)計的。

如何既讓全公司的研發(fā)和運維充分享受云原生技術(shù)體系革新帶來的專注力與生產(chǎn)力提升，又能夠讓現(xiàn)有 PaaS 體系無縫遷移、接入到 Kubernetes 大底盤當(dāng)中，還要讓新的 PaaS 體系把 Kubernetes 技術(shù)與生態(tài)的能力和價值最大程度的發(fā)揮出來，而不是互相“屏蔽”甚至“打架”？這個“既要、又要、還要”的高標(biāo)準(zhǔn)要求，才是解決上述 “Kubernetes vs PaaS” 難題的關(guān)鍵所在。

什么是“應(yīng)用模型”？

在 2019 年 10 月，阿里巴巴宣布聯(lián)合微軟共同推出開放應(yīng)用模型項目（Open Application Model - OAM），正是阿里進(jìn)行自身應(yīng)用管理體系標(biāo)準(zhǔn)化與統(tǒng)一架構(gòu)升級過程中，逐步演進(jìn)出來的一項關(guān)鍵技術(shù)。

所謂“應(yīng)用模型”，其實是一個專門用來對云原生應(yīng)用本身和它所需運維能力進(jìn)行定義與描述的標(biāo)準(zhǔn)開源規(guī)范。所以對于 Kubernetes 來說，OAM 即是一個標(biāo)準(zhǔn)的“應(yīng)用定義”項目（類比已經(jīng)不再活躍的 Kubernetes Application CRD 項目），同時也是一個專注于封裝、組織和管理 Kubernetes 中各種“運維能力”、以及連接“運維能力”與“應(yīng)用”的平臺層項目。而通過同時提供“定義應(yīng)用”和“組織管理應(yīng)用的運維能力”這兩大核心功能，OAM 項目自然成為了阿里巴巴進(jìn)行統(tǒng)一應(yīng)用架構(gòu)升級和構(gòu)建下一代 PaaS/Serverless 過程中“當(dāng)仁不讓”的關(guān)鍵路徑。

此外，OAM 模型并不負(fù)責(zé)應(yīng)用和能力的具體實現(xiàn)，從而確保了它們都是由 Kubernetes 本身直接提供的 API 原語和控制器實現(xiàn)。所以， OAM 也成為了當(dāng)前阿里構(gòu)建 Kubernetes 原生 PaaS 的一項主要手段。

在 OAM 中，一個應(yīng)用程序包含三個核心理念：

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

阿里巴巴在 OAM 這個項目中融入了大量互聯(lián)網(wǎng)規(guī)模場景中管理 Kubernetes 集群和公共云產(chǎn)品方面的實際經(jīng)驗，特別是阿里從原先不計其數(shù)的內(nèi)部應(yīng)用 CRD 轉(zhuǎn)向基于 OAM 的標(biāo)準(zhǔn)應(yīng)用定義過程中的諸多收獲。作為工程師，我們從過去的失敗和錯誤中吸取教訓(xùn)，不斷開拓創(chuàng)新、發(fā)展壯大。

在本文中，我們將會詳細(xì)分享 OAM 項目背后的動機(jī)和推動力，希望能夠幫助更多人更好地了解這個項目。

背景

1. 關(guān)于我們

我們是阿里巴巴的“基礎(chǔ)設(shè)施運維人員”，或者說 Kubernetes 團(tuán)隊。具體來說，我們負(fù)責(zé)開發(fā)、安裝和維護(hù)各種 Kubernetes 級別的功能。具體工作包括但不限于維護(hù)大規(guī)模的 K8s 集群、實現(xiàn)控制器/Operator，以及開發(fā)各種 K8s 插件。在公司內(nèi)部，我們通常被稱為“平臺團(tuán)隊（Platform Builder）”。

不過，為了與兄弟團(tuán)隊區(qū)分，即那些在我們之上基于 K8s 構(gòu)建的 PaaS 工程人員區(qū)分，我們在本文中將自稱為“基礎(chǔ)設(shè)施運維人員（Infra Operator）”。過去幾年里，我們已通過 Kubernetes 取得了巨大成功，并在使用過程中通過出現(xiàn)的問題獲取了寶貴的經(jīng)驗教訓(xùn)。

2. 我們管理各種 Kubernetes 集群

毫無疑問，我們?yōu)榘⒗锇桶碗娚虡I(yè)務(wù)維護(hù)著世界上最大、最復(fù)雜的 Kubernetes 集群，這些集群：

• 可縱向擴(kuò)展至 1 萬個節(jié)點；
• 運行 1 萬多種應(yīng)用程序；
• 在高峰期每天處理 10 萬次應(yīng)用部署。

同時，我們還協(xié)助支持著阿里云的 Kubernetes 服務(wù)（ACK），該服務(wù)類似于面向外部客戶的其他公有云 Kubernetes 產(chǎn)品，其中包含大量集群（約 1 萬個），不過通常均為小型或中型的集群。我們的內(nèi)部和外部客戶在工作負(fù)載管理方面的需求和用例非常多樣化。

3. 我們服務(wù)的對象是“運維”；而運維的服務(wù)對象是“研發(fā)”

與其他互聯(lián)網(wǎng)公司類似，阿里巴巴的技術(shù)棧由基礎(chǔ)設(shè)施運維人員、應(yīng)用運維人員和業(yè)務(wù)研發(fā)人員合作完成。業(yè)務(wù)研發(fā)和應(yīng)用運維人員的角色可以概括如下：

業(yè)務(wù)研發(fā)人員

以代碼形式傳遞業(yè)務(wù)價值。大多數(shù)業(yè)務(wù)研發(fā)都對基礎(chǔ)設(shè)施或 K8s 不甚了解，他們與 PaaS 和 CI 流水線交互以管理其應(yīng)用程序。業(yè)務(wù)研發(fā)人員的生產(chǎn)效率對公司而言價值巨大。

應(yīng)用運維人員

為業(yè)務(wù)研發(fā)人員提供有關(guān)集群容量、穩(wěn)定性和性能的專業(yè)知識，幫助業(yè)務(wù)研發(fā)人員大規(guī)模配置、部署和運行應(yīng)用程序（例如，更新、擴(kuò)展、恢復(fù)）。請注意，盡管應(yīng)用運維人員對 K8s 的 API 和功能具有一定了解，但他們并不直接在 K8s 上工作。在大多數(shù)情況下，他們利用 PaaS 系統(tǒng)為業(yè)務(wù)研發(fā)人員提供基礎(chǔ) K8s 功能。在這種情況下，許多應(yīng)用運維人員實際上也是 PaaS 工程人員。

總之，像我們這樣的基礎(chǔ)設(shè)施運維人員為應(yīng)用運維人員提供服務(wù)，他們隨之為業(yè)務(wù)研發(fā)人員提供服務(wù)。

合作問題

綜上所述，這三方顯然擁有不同的專業(yè)知識，但他們卻需要協(xié)調(diào)一致以確保順利工作。這在 Kubernetes 的世界里可能很難實現(xiàn)！

我們將在下面的章節(jié)中介紹不同參與方的痛點，但簡而言之，我們面臨的根本問題是不同參與方之間缺乏一種標(biāo)準(zhǔn)化的方法來進(jìn)行高效而準(zhǔn)確的交互。這會導(dǎo)致低效的應(yīng)用程序管理流程，甚至導(dǎo)致運行失敗。

而標(biāo)準(zhǔn)應(yīng)用模型正是我們解決此問題的關(guān)鍵方法。

基礎(chǔ)設(shè)施運維人員和應(yīng)用運維人員之間的交互

Kubernetes 具有高度的可擴(kuò)展性，使得基礎(chǔ)設(shè)施運維人員能夠隨心所欲地構(gòu)建自己的運維功能。但 Kubernetes 巨大的靈活性也是一把雙刃劍：這些功能的用戶（即應(yīng)用運維人員）會遇到一些棘手的問題。

舉例來說，在阿里巴巴，我們開發(fā)了 CronHPA CRD 以根據(jù) CRON 表達(dá)式擴(kuò)展應(yīng)用程序。當(dāng)應(yīng)用程序的水平擴(kuò)展策略希望在白天和晚上有所不同時，這非常有用。CronHPA 是一種可選功能，僅在集群中按需部署。

CronHPA 的 yaml 示例如下所示：

apiVersion: “app.alibaba.com/v1” kind: CronHPA metadata:name: cron-scaler spec:timezone: America/Los_Angelesschedule:- cron: ‘0 0 6 * * ?’minReplicas: 20maxReplicas: 25- cron: ‘0 0 19 * * ?’minReplicas: 1maxReplicas: 9template:spec:scaleTargetRef:apiVersion: apps/v1name: php-apachemetrics:- type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 50

這是一個典型的 Kubernetes 自定義資源（CRD），可以直接安裝使用。

但是，當(dāng)我們把這些功能交付出去，應(yīng)用運維人員開始使用諸如 CronHPA 等自定義插件時，他們很快就遇到麻煩了：

1. 這些 K8s 自定義功能的使用方法不明確。

應(yīng)用運維人員經(jīng)常抱怨這些插件功能的使用方法（也就是 spec） 分布的非常隨意。它有時位于 CRD 中，有時位于 ConfigMap 中，有時又位于某個隨機(jī)位置的配置文件中。此外，他們還感到非常困惑：為什么 K8s 中很多插件（例如，CNI 和 CSI 插件）的 CRD 并不是對應(yīng)的能力（例如：網(wǎng)絡(luò)功能和存儲功能）描述，而只是那些插件本身的安裝說明？

2. 很難確認(rèn) K8s 集群中是否存在某項具體能力。

應(yīng)用運維人員對某項運維能力是否已在集群中準(zhǔn)備就緒毫無把握，尤其是當(dāng)該能力是新開發(fā)的插件提供時更是如此?；A(chǔ)設(shè)施運維人員和應(yīng)用運維人員之間需要進(jìn)行多輪溝通，才能澄清這些問題。

除上述可發(fā)現(xiàn)性問題外，還有一個與可管理性相關(guān)的額外難題。

3. 運維能力之間的沖突可能會相當(dāng)麻煩。

K8s 集群中的運維能力之間的關(guān)系可以概括為以下三類：

• 正交 —— 能力彼此獨立。例如，Ingress 用于流量管理，持久性存儲用于存儲管理；
• 可組合 —— 多個能力可以協(xié)同應(yīng)用于同一應(yīng)用程序。例如，Ingress 和 Rollout：Rollout 升級應(yīng)用程序并控制 Ingress 以便實現(xiàn)漸進(jìn)式流量切換；
• 沖突 —— 多個能力不能應(yīng)用于同一應(yīng)用程序。例如，如果將 HPA 和 CronHPA 應(yīng)用于同一應(yīng)用程序，則會彼此沖突。

正交和可組合能力相對安全。然而，互相沖突的功能可能導(dǎo)致意外/不可預(yù)測的行為。

這里的問題在于， Kubernetes 很難事先向應(yīng)用運維人員發(fā)送沖突警告。因此，他們可能會對同一應(yīng)用程序使用彼此沖突的兩個運維能力。而當(dāng)實際發(fā)生沖突時，解決沖突會產(chǎn)生高昂的成本，在極端情況下，這些沖突會導(dǎo)致災(zāi)難性的故障。當(dāng)然，在管理平臺能力時，應(yīng)用運維人員顯然不希望面臨“頭頂懸著達(dá)摩克里斯之劍”的情況，因此希望找到一種更好的方法來提前避免沖突情況。

應(yīng)用運維人員如何發(fā)現(xiàn)和管理可能相互沖突的運維能力？換而言之，作為基礎(chǔ)設(shè)施運維人員，我們能否為應(yīng)用運維人員構(gòu)建可發(fā)現(xiàn)且易管理的運維能力呢？

OAM 中的運維特征（Trait）

在 OAM 中，我們通過“運維特征（Trait）”來描述和構(gòu)建具備可發(fā)現(xiàn)性和可管理性的平臺層能力。

這些平臺層能力實質(zhì)上是應(yīng)用程序的運維特征，而這正是 OAM 中“Trait”這個名稱的來歷。

1. 打造可發(fā)現(xiàn)的運維能力

在阿里的 K8s 集群中，大多數(shù) Trait 都由基礎(chǔ)設(shè)施運維人員定義，并使用 Kubernetes 中的自定義控制器實現(xiàn)，例如：

• Ingress
• Auto-scaler
• Volume-mounter
• Traffic-shifting、Security-policy 等

請注意， Trait 并不等同于 K8s 插件。比如：一個集群可具有多個網(wǎng)絡(luò)相關(guān) Trait ，如“動態(tài) QoS ?Trait ”、“帶寬控制 Trait ”和“流量鏡像 Trait ”，這些 Trait 均由一個 CNI 插件提供。

實際上， Trait 安裝在 K8s 集群中，并供應(yīng)用運維人員使用。將能力作為 Trait 呈現(xiàn)時，應(yīng)用運維人員使用簡單的 kubectl get 命令即可發(fā)現(xiàn)當(dāng)前集群支持的運維能力：

$ kubectl get traitDefinition NAME AGE cron-scaler 19m auto-scaler 19m

上面的示例顯示此集群支持兩種 “scaler” 能力。用戶可以將需要基于 CRON 的擴(kuò)展策略的應(yīng)用程序部署到該集群。

Trait 提供給定運維能力的結(jié)構(gòu)化描述。

這使應(yīng)用運維人員通過簡單的 kubectl describe 命令即可輕松準(zhǔn)確地理解特定能力，而不必深入研究其 CRD 或文檔。能力描述包括“此 Trait 適用于何種工作負(fù)載”和“它的使用方式”等。

例如，kubectl describe traitDefinition cron-scaler：

apiVersion: core.oam.dev/v1alpha2 kind: TraitDefinition metadata:name: cron-scaler spec:appliesTo:- core.oam.dev/v1alpha1.ContainerizedWorkloaddefinitionRef:name: cronhpas.app.alibaba.com

請注意，在 OAM 中， Trait 通過 definitionRef 引用 CRD 來描述其用法，同時也與 K8s 的 CRD 解耦。

Trait 采用了規(guī)范與實現(xiàn)分離的設(shè)計，同樣一個 Trait 的 spec，可以被不同平臺不同環(huán)境完全基于不同的技術(shù)來實現(xiàn)。通過引用的方式，實現(xiàn)層既可以對接到一個已有實現(xiàn)的 CRD，也可以對接到一個統(tǒng)一描述的中間層，底下可插拔的對接不同的具體實現(xiàn)?？紤]到 K8s 中的一個特定的能力比如 Ingress 可能有多達(dá)幾十種實現(xiàn)，這種規(guī)范與實現(xiàn)分離的思想會非常有用。Trait 提供了統(tǒng)一的描述，可幫助應(yīng)用運維人員準(zhǔn)確理解和使用能力。

2. 打造可管理的運維能力

應(yīng)用運維人員通過使用 ApplicationConfiguration（將在下一部分中詳細(xì)介紹），對應(yīng)用程序配置一個或多個已安裝的 Trait 。ApplicationConfiguration 控制器將處理 Trait 沖突（如果有）。

我們以此示例 ApplicationConfiguration 為例：

apiVersion: core.oam.dev/v1alpha2 kind: ApplicationConfiguration metadata:name: failed-example spec:components:- name: nginx-replicated-v1traits:- trait:apiVersion: core.oam.dev/v1alpha2kind: AutoScalerspec: minimum: 1maximum: 9- trait:apiVersion: app.alibabacloud.com/v1kind: CronHPAspec: timezone: "America/Los_Angeles"schedule: "0 0 6 * * ?"cpu: 50...

在 OAM 中，ApplicationConfiguration 控制器必須保證這些 Trait 之間的兼容性，如果不能滿足要求，應(yīng)用的部署就會立刻失敗。所以，當(dāng)運維人員將上述 YAML 提交給 Kubernetes 時，由于“Trait 沖突”，OAM 控制器將會報告部署失敗。這就使得應(yīng)用運維人員能夠提前知道有運維能力沖突，而不是在部署失敗后大驚失色。

總的來說，我們團(tuán)隊不提倡提供冗長的維護(hù)規(guī)范和運維指南（它們根本無法防止應(yīng)用運維人員出錯），我們傾向于是使用 OAM ?Trait 來對外暴露基于 Kubernetes 的可發(fā)現(xiàn)和可管理的運維能力。這使我們的應(yīng)用運維人員能夠“快速失敗”，并滿懷信心地組合運維能力來構(gòu)建無沖突的應(yīng)用運維解決方案，這就像玩“樂高積木”一樣簡單。

應(yīng)用運維人員和業(yè)務(wù)研發(fā)之間的交互

Kubernetes 的 API 對象并不關(guān)心自己的使用者到底是運維還是研發(fā)。這意味著任何人都可能對一個 Kubernetes API 對象中的任何字段負(fù)責(zé)。這也稱為“all-in-one”的 API，它使得新手很容易上手。

但是，當(dāng)具有不同關(guān)注點的多個團(tuán)隊必須在同一個 Kubernetes 集群上展開協(xié)作時，特別是當(dāng)應(yīng)用運維人員和業(yè)務(wù)研發(fā)人員需要在相同 API 對象上展開協(xié)作時，all-in-one API 缺點就會凸顯出來。

讓我們先來看一個簡單的 Deployment YAML 文件：

kind: Deployment apiVersion: extensions/v1beta1 metadata:name: nginx-deployment spec:replicas: 3selector:matchLabels:deploy: exampletemplate:metadata:labels:deploy: examplespec:containers:- name: nginximage: nginx:1.7.9securityContext:allowPrivilegeEscalation: false

在我們的集群中，應(yīng)用運維人員與業(yè)務(wù)研發(fā)人員需要面對面開會來填寫這個 yaml 文件。這種合作既耗時又復(fù)雜，但我們別無選擇。原因何在？

“抱歉，這個字段與我無關(guān)”

顯而易見，這里最直接的方法是讓業(yè)務(wù)研發(fā)人員自己填寫 Deployment yaml。但是，業(yè)務(wù)研發(fā)人員可能會發(fā)現(xiàn) Deployment 里的某些字段與他們的關(guān)注點沒有絲毫關(guān)聯(lián)。例如：

有多少業(yè)務(wù)研發(fā)人員知道 allowPrivilegeEscalation 是什么意思？

事實上，很少有業(yè)務(wù)研發(fā)人員知道，在生產(chǎn)環(huán)境里，這個字段務(wù)必要設(shè)置為 false （默認(rèn)是 true），才能確保應(yīng)用程序在宿主機(jī)中具有合理的權(quán)限。在實踐中，這個字段只能應(yīng)用運維人員配置。而現(xiàn)實是，一旦把整個 Deployment 暴露給業(yè)務(wù)研發(fā)填寫，這些字段最終就會淪為“猜謎游戲”，甚至完全被業(yè)務(wù)研發(fā)人員忽視。

這個字段到底是研發(fā)還是運維負(fù)責(zé)？

如果你了解 K8s 的話，就一定會發(fā)現(xiàn) K8s 中有大量的 API 字段很難說清楚到底是應(yīng)該由研發(fā)還是運維來填寫。

例如，當(dāng)業(yè)務(wù)研發(fā)人員設(shè)置 Deployment 的 replicas:3 時，他會假設(shè)該數(shù)字在應(yīng)用程序生命周期中固定不變。

但是，大多數(shù)業(yè)務(wù)研發(fā)人員并不知道 Kubernetes 的 HPA 控制器可以接管該字段，并可能會根據(jù) Pod 負(fù)載改變 replicas 的值。這種由系統(tǒng)自動化流程帶來的變更很容易導(dǎo)致問題：這意味著當(dāng)業(yè)務(wù)研發(fā)人員想要更改副本數(shù)時，他對 replicas 的修改可能根本不會生效。

在此種情況下，一個 Kubernetes 的 YAML 文件就不能表示工作負(fù)載的最終狀態(tài)，從業(yè)務(wù)研發(fā)人員角度而言，這非常令人困惑。我們曾嘗試使用 fieldManager 來處理此問題，但 fieldManager 進(jìn)行沖突解決的過程仍頗具挑戰(zhàn)性，因為我們很難弄清這些沖突方的修改目的。

“割裂研發(fā)與運維”能否解決上述問題？

如上所示，當(dāng)使用 K8s API 時，業(yè)務(wù)研發(fā)人員和運維人員的關(guān)注點會不可避免地被混在一起。這使得多個參與方可能很難基于同一個 API 對象展開協(xié)作。

此外，我們也發(fā)現(xiàn)，阿里內(nèi)部的很多應(yīng)用程序管理系統(tǒng)（如 PaaS）并不愿意暴露 K8s 的全部能力，顯然他們并不希望向業(yè)務(wù)研發(fā)人員暴露更多的 Kubernetes 概念。

對于上述問題，最簡單的解決方案是在業(yè)務(wù)研發(fā)人員和運維人員之間劃一條“明確的界限”。例如，我們可以僅允許業(yè)務(wù)研發(fā)人員設(shè)置 Deployment yaml 的一部分字段（這正是阿里很多 PaaS 曾經(jīng)采用的辦法）。但是，這種“割裂研發(fā)與運維”的解決方案可能并不奏效。

運維需要聽取業(yè)務(wù)研發(fā)人員的意見

在很多情況下，業(yè)務(wù)研發(fā)人員都希望運維人員聽取他們的一些關(guān)于運維的“意見”。

例如，假定業(yè)務(wù)研發(fā)人員為應(yīng)用程序定義了 10 個參數(shù)，然后他們發(fā)現(xiàn)應(yīng)用運維人員可能會覆蓋這些參數(shù)以適配不同的運行環(huán)境的差異。那么問題來了：業(yè)務(wù)研發(fā)如何才能做到僅允許運維人員修改其中特定的 5 個參數(shù)？

實際上，如果采用“割裂研發(fā)與運維”應(yīng)用管理流程，要傳達(dá)業(yè)務(wù)研發(fā)人員的運維意見將變得難上加難。這樣類似的例子有許多，業(yè)務(wù)研發(fā)人員可能希望表述很多關(guān)于他們的應(yīng)用程序的信息：

• 無法水平擴(kuò)展（即單一實例）；
• 是一個批處理作業(yè)，而不是長運行的服務(wù)；
• 需要最高級別的安全性等等。

上述所有這些請求都是合理的，因為只有業(yè)務(wù)研發(fā)人員才是最了解應(yīng)用程序的那個人。這就提出了一個我們亟待解決的重要問題：我們的 Kubernetes 能否既為業(yè)務(wù)研發(fā)和運維人員提供單獨的 API，同時又允許業(yè)務(wù)研發(fā)人員有效傳達(dá)自己對運維的訴求？

OAM 中的 Component?和 ApplicationConfiguration

在 OAM 中，我們從邏輯上對 K8s 的 API 對象進(jìn)行了拆分，并且做到了既使得業(yè)務(wù)研發(fā)人員能夠填寫屬于自己的那些字段，同時又能有條理地向運維人員傳達(dá)訴求。

定義你的應(yīng)用程序，而不是僅僅描述它。

1. Component

在 OAM 中，Component（組件） 就是一個完全面向業(yè)務(wù)研發(fā)人員設(shè)計的、用于定義應(yīng)用程序而不必考慮其運維詳細(xì)信息的載體。一個應(yīng)用程序包含一個或多個 Component 。例如，一個網(wǎng)站應(yīng)用可以由一個 Java web 組件和一個數(shù)據(jù)庫組件組成。

以下是業(yè)務(wù)研發(fā)人員為 Nginx 部署定義的 Component 示例：

OAM 中的 Component 包含兩個部分：

• 工作負(fù)載描述 —— 如何運行此 Component，以及它的運行內(nèi)容，實際上就是一個完整的 K8s CR；
• 可重寫參數(shù)列表 —— 研發(fā)通過這個字段表示該 Component 的哪些字段后續(xù)可以被運維或者系統(tǒng)覆蓋。

在 Component 中，workload 字段可以直接向運維人員傳達(dá)業(yè)務(wù)研發(fā)人員關(guān)于如何運行其應(yīng)用程序的說明。同時，OAM 圍繞容器應(yīng)用定義了一種核心工作負(fù)載 ContainerizedWorkload，涵蓋了云原生應(yīng)用程序的典型模式。

與此同時，OAM 可以通過定義擴(kuò)展工作負(fù)載來自由聲明用戶自己的工作負(fù)載類型。在阿里巴巴，我們在很大程度上依賴于擴(kuò)展工作負(fù)載來使業(yè)務(wù)研發(fā)人員定義阿里云服務(wù) Component ，例如，阿里云函數(shù)計算 Component 等。

請注意，在上面的示例中，業(yè)務(wù)研發(fā)人員不再需要設(shè)置副本數(shù)；因為這并不是他所關(guān)注的字段：他選擇讓 HPA 或應(yīng)用運維人員完全控制副本數(shù)的值。

總體來說，Component 允許業(yè)務(wù)研發(fā)人員使用自己的方式定義應(yīng)用程序的聲明式描述，但同時也為他/她提供了隨時向運維人員準(zhǔn)確傳達(dá)意見或信息的能力。這些信息包括對運維的訴求，例如，“如何運行此應(yīng)用程序”和“可重寫參數(shù)”。

2. ApplicationConfiguration

最終，通過引用 Component 名稱并對它綁定 Trait ，運維人員就可以使用 ApplicationConfiguration 來實例化應(yīng)用程序。

使用 Component 和 ApplicationConfiguration 的示例協(xié)作工作流：

• Kubernetes 里安裝了各種工作負(fù)載類型（workloadType）；
• 業(yè)務(wù)研發(fā)人員使用所選工作負(fù)載類型定義一個 component.yaml；
• 然后，應(yīng)用運維人員（或 CI / CD 系統(tǒng)）運行 kubectl apply -f component.yaml 來安裝此 Component；
• 應(yīng)用運維人員接下來使用 app-config.yaml 來定義 ApplicationConfiguration 以實例化應(yīng)用程序；
• 最后，應(yīng)用運維人員運行 kubectl apply -f app-config.yaml 以觸發(fā)整個應(yīng)用程序的部署。

這個 app-config.yaml 文件的內(nèi)容如下所示：

apiVersion: core.oam.dev/v1alpha1 kind: ApplicationConfiguration metadata:name: my-awesome-app spec:components:- componentName: nginxparameterValues:- name: connectionsvalue: 4096traits:- trait:apiVersion: core.oam.dev/v1alpha2kind: AutoScalerspec: minimum: 1maximum: 9- trait:apiVersion: app.aliaba.com/v1kind: SecurityPolicyspec: allowPrivilegeEscalation: false

我們來重點說明以上 ApplicationConfiguration YAML 中的一些詳細(xì)信息：

• parameterValues —— 供運維人員使用，用于將 connections 值重寫為 4096，在該組件中，該值最初為 1024。請注意，運維人員必須填寫整數(shù) 4096，而不是字符串 “4096”，因為此字段的 schema 已在 Component 中明確定義；

• Trait ?AutoScaler —— 供運維人員使用，用于將 autoscaler ?Trait （如 HPA）綁定給 Component 。因此，其副本數(shù)將完全由 autoscaler 控制；

• Trait SecurityPolicy —— 供運維人員使用，用于將安全策略規(guī)則應(yīng)用于 Component。請注意，運維人員還可以修改 Trait 列表以綁定更多 Trait。例如，“Canary Deployment Trait ”意味著這個應(yīng)用程序在后期升級過程中遵循金絲雀發(fā)布策略。

實質(zhì)上，ApplicationConfiguration 的主要功能，就是讓應(yīng)用運維人員（或系統(tǒng)）了解和使用業(yè)務(wù)研發(fā)人員傳達(dá)的信息，然后自由的為 Component 組合綁定不同的運維能力以相應(yīng)實現(xiàn)其最終的運維目的。

并不止是應(yīng)用管理

綜上所述，我們使用 OAM 的主要目標(biāo)是解決應(yīng)用程序管理中的以下問題：

• 如何在 Kubernetes 中構(gòu)建可發(fā)現(xiàn)、可組合和可管理的運維能力；
• 如何使 Kubernetes 中的多個參與方圍繞同一個 API 對象準(zhǔn)確有效地協(xié)作。

所以說，對于阿里巴巴來說，OAM 其實是阿里巴巴 Kubernetes 團(tuán)隊提出的一種 Application CRD 規(guī)范，從而使得所有參與者可以采用結(jié)構(gòu)化的標(biāo)準(zhǔn)方法來定義應(yīng)用程序及其運維能力。

阿里巴巴開發(fā) OAM 的另一個強(qiáng)大動力，則是在混合云和多環(huán)境中進(jìn)行軟件分發(fā)與交付。隨著 Google Anthos 和 Microsoft Arc 的出現(xiàn)，我們已然看到 Kubernetes 正成為新的 Android，并且云原生生態(tài)系統(tǒng)的價值正迅速轉(zhuǎn)移到應(yīng)用層的趨勢。我們將在以后討論這一主題。

本文中的實際使用案例由阿里云原生團(tuán)隊和螞蟻金服共同提供。

OAM 的未來

目前，OAM 規(guī)范和模型實際已解決許多現(xiàn)有問題，但它的路程才剛剛開始。例如，我們正在研究使用 OAM 處理組件依賴關(guān)系、在 OAM 中集成 Dapr 工作負(fù)載等。

我們期待在 OAM 規(guī)范及其 K8s 實現(xiàn)方面與社區(qū)展開協(xié)作。OAM 是一個中立的開源項目，其所有貢獻(xiàn)者都應(yīng)遵循非營利性基金會的 CLA。

目前，阿里巴巴團(tuán)隊正在上游貢獻(xiàn)和維護(hù)這套技術(shù)，如果大家有什么問題或者反饋，也非常歡迎與我們在上游或者釘釘聯(lián)系。

參與方式：

• 釘釘掃碼進(jìn)入 OAM 項目中文討論群

• 通過 Gitter 直接參與討論
• OAM 開源實現(xiàn)地址
• 點擊 star 一下

作者簡介
**李響，阿里云資深技術(shù)專家。**他在阿里巴巴從事集群管理系統(tǒng)工作，并協(xié)助推動阿里巴巴集團(tuán)內(nèi)的 Kubernetes 采用。在效力于阿里巴巴之前，李響曾是 CoreOS Kubernetes 上游團(tuán)隊的負(fù)責(zé)人。他還是 etcd 和 Kubernetes Operator 的創(chuàng)建者。

**張磊，阿里云高級技術(shù)專家。**他是 Kubernetes 項目的維護(hù)者之一。張磊目前在阿里的 Kubernetes 團(tuán)隊工作，其工作領(lǐng)域包括 Kubernetes 和云原生應(yīng)用管理系統(tǒng)。

有一個阿里團(tuán)隊需要你！

云原生應(yīng)用平臺誠邀?Kubernetes / Serverless / PaaS / 應(yīng)用交付領(lǐng)域?qū)＜?#xff08; P6-P8 ）加盟：

• 工作年限：建議 P6-7 三年起，P8 五年起，具體看實際能力；
• 工作地點：國內(nèi)（北京 / 杭州 / 深圳）；海外（舊金山灣區(qū) / 西雅圖）；
• 崗位包含：架構(gòu)師、技術(shù)專家、全棧工程師等。

簡歷立刻回復(fù)，2~3 周出結(jié)果，簡歷投遞：jianbo.sjb AT alibaba-inc.com。

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

總結(jié)

以上是生活随笔為你收集整理的深度解读！阿里统一应用管理架构升级的教训与实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。