作者 | 孫健波（天元）阿里云技術(shù)專家

導(dǎo)讀：OAM Spec 經(jīng)歷了近 3 個(gè)月的迭代，v1alpha2?版本終于發(fā)布啦！新版本在堅(jiān)持 OAM Spec 平臺(tái)無(wú)關(guān)的基礎(chǔ)上，整體變得更 Kubernetes 友好化，很大程度上平衡了標(biāo)準(zhǔn)與可擴(kuò)展性，更好的支持 CRD。如果你已經(jīng)編寫(xiě)了現(xiàn)成的 CRD Operator，可以平滑的接入到 OAM 體系中，并且享受到 OAM 模型的紅利。

目前 OAM 已經(jīng)成為了包括阿里、微軟、Upbond、諧云等多家公司構(gòu)建云產(chǎn)品的核心架構(gòu)。他們通過(guò) OAM 構(gòu)建了“以應(yīng)用為中心”、用戶友好化的 Kubernetes PaaS；充分發(fā)揮 OAM 的標(biāo)準(zhǔn)化與可擴(kuò)展性，實(shí)現(xiàn) OAM 核心 Controller 的同時(shí)，快速接入了已有的 Operator 能力；通過(guò) OAM 橫向打通多個(gè)模塊，破除了原有 Operator 彼此孤立、無(wú)法復(fù)用的窘境。

• 了解 OAM 的背景及由來(lái)，可以參考《深度解讀！阿里統(tǒng)一應(yīng)用管理架構(gòu)升級(jí)的教訓(xùn)與實(shí)踐》；

• OAM 能為終端用戶帶來(lái)哪些價(jià)值？可以參考《OAM 深入解讀：OAM 為云原生應(yīng)用帶來(lái)哪些價(jià)值？》

下面言歸正傳，讓我們來(lái)看一下 v1alpha2 到底做了哪些改動(dòng)？

主要改動(dòng)說(shuō)明

為了方便大家閱讀，這里只羅列了最主要的改動(dòng)點(diǎn)，一些細(xì)節(jié)還是以上游 OAM Spec Github 倉(cāng)庫(kù)為準(zhǔn)。

術(shù)語(yǔ)說(shuō)明

• CRD（Custom Resource Definition）：在 OAM 中說(shuō)的 CRD 是一種泛指的自定義資源描述定義。在 K8s 的 OAM 實(shí)現(xiàn)中可以完全對(duì)應(yīng) K8s 的 CRD，在非 K8s 的實(shí)現(xiàn)中，OAM 的 CRD 需要包含 APIVersion/Kind 并且能夠描述字段進(jìn)行校驗(yàn)；

• CR （Custom Resource），OAM 中的 CR 是 CRD 的一個(gè)實(shí)例，是符合 CRD 中字段格式定義的一個(gè)資源描述。在 K8s 的 OAM 實(shí)現(xiàn)中可以完全對(duì)應(yīng) K8s 的 CR，在 非 K8s 的實(shí)現(xiàn)中，可以需要對(duì)齊?APIVersion/Kind? 和字段格式定義。

主要改動(dòng) 1 使用 Reference 模型定義 Workload、Trait 和 Scope

v1alpha1 原先的方式是這樣的：

// 老版本，僅對(duì)比使用 apiVersion: core.oam.dev/v1alpha1 kind: WorkloadType metadata:name: OpenFaaSannotations:version: v1.0.0description: "OpenFaaS a Workload which can serve workload running as functions" spec:group: openfaas.comversion: v1alpha2names:kind: Functionsingular: functionplural: functionsworkloadSettings: |{"$schema": "http://json-schema.org/draft-07/schema#","type": "object","required": ["name", "image"],"properties": {"name": {"type": "string","description": "the name to the function"},"image": {"type": "string","description": "the docker image of the function"}}}

在原先的模式中，group/version/kind 分別是字段，spec 的校驗(yàn)通過(guò) jsonschema 表示，整體的格式實(shí)際上類似 CRD，但不完全一致。

新版 v1alpha2 中徹底改為了引用模型，通過(guò) WorkloadDefinition? TraitDefinition? ScopeDefinition 的形式，描述了一個(gè)引用關(guān)系。可以直接引用一個(gè) CRD，name 就是 CRD 的名稱。對(duì)于非 K8s 的 OAM 實(shí)現(xiàn)來(lái)說(shuō)，這里的名字則是一個(gè)索引，可以找到類似 CRD 的校驗(yàn)文件，校驗(yàn)文件中包含 apiVersion 和 kind，以及相應(yīng)的 schema 校驗(yàn)。

• Workload

apiVersion: core.oam.dev/v1alpha2 kind: WorkloadDefinition metadata:name: containerisedworkload.core.oam.dev spec:definitionRef:# Name of CRD. name: containerisedworkload.core.oam.dev

• Trait

apiVersion: core.oam.dev/v1alpha2 kind: TraitDefinition metadata:name: manualscalertrait.core.oam.dev spec:appliesToWorkloads:- containerizedworkload.core.oam.devdefinitionRef:name: manualscalertrait.core.oam.dev

• Scope

apiVersion: core.oam.dev/v1alpha2 kind: ScopeDefinition metadata:name: networkscope.core.oam.dev spec:allowComponentOverlap: truedefinitionRef:name: networkscope.core.oam.dev

注意：

這里對(duì)于 K8s 的 OAM 實(shí)現(xiàn)來(lái)說(shuō)，name 就是 K8s 里面 CRD 的 name，由 <plural-kind>.<group> 組成。社區(qū)的最佳實(shí)踐是一個(gè) CRD 只有一個(gè) version 在集群中運(yùn)行，一般新 version 都會(huì)向前兼容，升級(jí)時(shí)都一次性替換到最新 version。如果確實(shí)有 2 個(gè) version 同時(shí)存在的場(chǎng)景，用戶也可以通過(guò) kubectl get crd <name> 的方式進(jìn)一步選擇；

Definition 這一層不面向 end user，主要給平臺(tái)實(shí)現(xiàn)使用，對(duì)于非 K8s 實(shí)現(xiàn)來(lái)說(shuō)，如果存在多個(gè) version 的場(chǎng)景，OAM 的實(shí)現(xiàn)平臺(tái)可以給終端用戶展示不同 version 的選擇。

主要改動(dòng) 2 直接嵌入 K8s CR 作為 Component 和 Trait 實(shí)例

原先的方式在 Workload 和 Trait 層面我們都只把 CR 的 spec 部分拿出來(lái)，分別放在 workloadSettings 和 properties 字段里。

這樣的方式雖然已經(jīng)可以“推導(dǎo)”出 K8s CR，但是不利于 K8s 生態(tài)內(nèi)的 CRD 接入，需要換種格式重新定義一遍 spec。

// 老版本，僅對(duì)比使用 apiVersion: core.oam.dev/v1alpha1 kind: ComponentSchematic metadata:name: rediscluster spec:workloadType: cache.crossplane.io/v1alpha1.RedisClusterworkloadSettings:engineVersion: 1.0region: cn // 老版本，僅對(duì)比使用 apiVersion: core.oam.dev/v1alpha1 kind: ApplicationConfiguration metadata:name: custom-single-appannotations:version: v1.0.0description: "Customized version of single-app" spec:variables:components:- componentName: frontendinstanceName: web-front-endparameterValues:traits:- name: manual-scalerproperties:replicaCount: 5

現(xiàn)在的方式則直接嵌入 CR，可以看到，在 workload 和 trait 字段下面是完整的 CR 描述。

apiVersion: core.oam.dev/v1alpha2 kind: Component metadata:name: example-server spec:prameters:- name: xxxfieldPaths: - "spec.osType"workload:apiVersion: core.oam.dev/v1alpha2kind: Serverspec:osType: linuxcontainers:- name: my-cool-serverimage:name: example/very-cool-server:1.0.0ports:- name: httpvalue: 8080env:- name: CACHE_SECRET apiVersion: core.oam.dev/v1alpha2 kind: ApplicationConfiguration metadata:name: cool-example spec:components:- componentName: example-servertraits:- trait:apiVersion: core.oam.dev/v1alpha2kind: ManualScalerTraitspec:replicaCount: 3

這樣的好處很明顯：

可以很容易的對(duì)接現(xiàn)有 K8s 體系里的 CRD，甚至包括 K8s 原生的 Deployment （作為自定義 workload 接入）等資源；

K8s CR 層面的字段定義是成熟的，解析和校驗(yàn)也完全交由 CRD 體系。

這里大家注意到 traits 下面是 []trait{CR} 而不是 []CR? 的結(jié)構(gòu)，多了一層看似無(wú)用的 trait 字段，主要由如下 2 個(gè)原因：

• 為后續(xù)在 trait 這個(gè)維度做擴(kuò)展留下空間，比如可能的編排（ ordering ） 等。
• 非 K8s 體系在這一層可以不嚴(yán)格按照 CR 的寫(xiě)法來(lái)，完全自定義，不綁定 K8s 描述格式。

主要改動(dòng) 3 參數(shù)傳遞使用 jsonPath 替換原先的 fromParam

研發(fā)能夠留出字段給運(yùn)維覆蓋，一直是 OAM 很重要的功能。

體現(xiàn)在 OAM Spec 的流程上就是：研發(fā)在 Component 里面定義 parameter，運(yùn)維在 AppConfig 里面通過(guò) parameterValue 去覆蓋對(duì)應(yīng)的參數(shù)。

最初的參數(shù)傳遞，是在每個(gè)字段后面有個(gè) fromParam? 字段，對(duì)于支持了自定義 schema 后，這樣的方式顯然是無(wú)法覆蓋所有場(chǎng)景的：

// 老版本，僅對(duì)比使用 apiVersion: core.oam.dev/v1alpha1 kind: ComponentSchematic metadata:name: rediscluster spec:workloadType: cache.crossplane.io/v1alpha1.RedisClusterparameters:- name: engineVersiontype: stringworkloadSettings:- name: engineVersiontype: stringfromParam: engineVersion

后來(lái)我們?cè)?jīng)提議過(guò)這樣的方案：

// 老版本，僅對(duì)比使用 apiVersion: core.oam.dev/v1alpha1 kind: ComponentSchematic metadata:name: rediscluster spec:workloadType: cache.crossplane.io/v1alpha1.RedisClusterparameters:- name: engineVersiontype: stringworkloadSettings:engineVersion: "[fromParam(engineVersion)]"

這個(gè)方案最大的問(wèn)題是 靜態(tài)的 IaD (Infrastructure as Data) 里面加入了動(dòng)態(tài)的函數(shù)，給理解和使用帶來(lái)了復(fù)雜性。

經(jīng)過(guò)多方面的討論，在新方案里我們通過(guò) JsonPath 的形式描述要注入的參數(shù)位置，在用戶理解上保證了 AppConfig 是靜態(tài)的。

apiVersion: core.oam.dev/v1alpha2 kind: Component metadata:name: example-server spec:workload:apiVersion: core.oam.dev/v1alpha2kind: Serverspec:containers:- name: my-cool-serverimage:name: example/very-cool-server:1.0.0ports:- name: httpvalue: 8080env:- name: CACHE_SECRETvalue: cacheparameters:- name: instanceNamerequired: truefieldPaths:- ".metadata.name"- name: cacheSecretrequired: truefieldPaths:- ".workload.spec.containers[0].env[0].value"

fieldPaths 是個(gè)數(shù)組，每個(gè)元素定義了參數(shù)和對(duì)應(yīng) Workload 里的字段。

apiVersion: core.oam.dev/v1alpha2 kind: ApplicationConfiguration metadata:name: my-app-deployment spec:components:- componentName: example-serverparameterValues:- name: cacheSecretvalue: new-cache

在 AppConfig 中還是走 parameterValues 去覆蓋 Component 中的 parameter。

主要改動(dòng) 4 ComponentSchematic 名稱改為 Component

原先組件這個(gè)概念叫 ComponentSchematic，這樣命名的主要原因是里面混了一些語(yǔ)法描述和選擇，比如針對(duì) Core Workload（ container）和針對(duì)擴(kuò)展 Workload （ workloadSettings ），寫(xiě)法上不一樣的，container?里是定義具體的參數(shù)，workloadSettings?更像是 schema（參數(shù)怎么填的說(shuō)明）。v1alpha1 版本的 WorkloadSetting 還融入了 type/description之類的，更顯得模棱兩可。

// 老版本，僅對(duì)比使用 apiVersion: core.oam.dev/v1alpha1 kind: ComponentSchematic metadata:name: rediscluster spec:containers:...workloadSettings:- name: engineVersiontype: stringdescription: engine versionfromParam: engineVersion...

在 v1alpha2 版本中，組件這個(gè)概念改為 Component，明確為 Workload 的實(shí)例，所有語(yǔ)法定義都是在WorkloadDefinition 中引用的實(shí)際 CRD 定義的。

在 K8s 實(shí)現(xiàn)中，WorkloadDefinition 就是引用 CRD ，Component.spec.workload 里就是寫(xiě) CRD 對(duì)應(yīng)的實(shí)例 CR。

apiVersion: core.oam.dev/v1alpha2 kind: Component metadata:name: example-server spec:workload:apiVersion: core.oam.dev/v1alpha2kind: Serverspec:...

主要改動(dòng) 5 Scope 由 CR 單獨(dú)創(chuàng)建，不再由 AppConfig 創(chuàng)建

v1alpha1 中的 Scope 是由 AppConfig 創(chuàng)建的，從例子中可以看出，本質(zhì)上它也是個(gè) CR，可以“推導(dǎo)”創(chuàng)建出 CR來(lái)。但是由于 Scope 的定位是可以容納不同 AppConfig 中的 Component，且 Scope 本身并非一個(gè) App，所以使用 AppConfig 創(chuàng)建 Scope 一直是不太合適的。

// 老版本，僅對(duì)比使用 apiVersion: core.oam.dev/v1alpha1 kind: ApplicationConfiguration metadata:name: my-vpc-network spec:variables:- name: networkNamevalue: "my-vpc"scopes:- name: networktype: core.oam.dev/v1alpha1.Networkproperties:network-id: "[fromVariable(networkName)]"subnet-ids: "my-subnet1, my-subnet2"

v1alpha2 新版本全面使用 CR 來(lái)對(duì)應(yīng)實(shí)例，為了讓 Scope 的概念更清晰，更方便對(duì)應(yīng)不同類型的 Scope，將 Scope 拿出來(lái)直接由 ScopeDefinition 定義的 CRD 對(duì)應(yīng)的 CR 創(chuàng)建。例子如下所示：

apiVersion: core.oam.dev/v1alpha2 kind: ScopeDefinition metadata:name: networkscope.core.oam.dev spec:allowComponentOverlap: truedefinitionRef:name: networkscope.core.oam.dev apiVersion: core.oam.dev/v1alpha2 kind: NetworkScope metadata:name: example-vpc-networklabels:region: us-westenvironment: production spec:networkId: cool-vpc-networksubnetIds:- cool-subnetwork- cooler-subnetwork- coolest-subnetworkinternetGatewayType: nat

在 AppConfig 中使用 scope 引用如下所示:

apiVersion: core.oam.dev/v1alpha2 kind: ApplicationConfiguration metadata:name: custom-single-appannotations:version: v1.0.0description: "Customized version of single-app" spec:components:- componentName: frontendscopes:- scopeRef:apiVersion: core.oam.dev/v1alpha2kind: NetworkScopename: my-vpc-network- componentName: backendscopes:- scopeRef:apiVersion: core.oam.dev/v1alpha2kind: NetworkScopename: my-vpc-network

主要改動(dòng) 6 移除 Variable 列表和 [fromVariable()] 動(dòng)態(tài)函數(shù)

v1alpha1 版本中有 Variable 是為了 AppConfig 里開(kāi)源引用一些公共變量減少冗余，所以加入了 Variable 列表。但實(shí)踐來(lái)看，減少的冗余并沒(méi)有明顯減少 OAM?spec 的復(fù)雜性，相反，增加動(dòng)態(tài)的函數(shù)顯著增加了復(fù)雜性。

另一方面，fromVariable 這樣的能力完全可以通過(guò) helm template/ kustomiz 等工具來(lái)做，由這些工具渲染出完整的 OAM spec，再進(jìn)行使用。

所以這里 variables 列表和相關(guān)的 fromVariable 均去掉，并不影響任何功能。

// 老版本，僅對(duì)比使用 apiVersion: core.oam.dev/v1alpha1 kind: ApplicationConfiguration metadata:name: my-app-deployment spec:variables:- name: VAR_NAMEvalue: SUPPLIED_VALUEcomponents:- componentName: my-web-app-componentinstanceName: my-app-frontentparameterValues:- name: ANOTHER_PARAMETERvalue: "[fromVariable(VAR_NAME)]"traits:- name: ingressproperties:DATA: "[fromVariable(VAR_NAME)]"

主要改動(dòng) 7 用 ContainerizedWorkload 替代原來(lái)的六種核心 Workload

因?yàn)楝F(xiàn)在已經(jīng)統(tǒng)一用 WorkloadDefinition 定義 Workload，Component 變成了實(shí)例，所以原先的六種核心Workload 實(shí)際上都變成了同一個(gè) WorkloadDefinition，字段描述完全一樣，唯一的不同是對(duì) trait 約束和訴求不一樣。因此原先的六種核心 Workload 的 spec，統(tǒng)一修改為一種名為 ContainerizedWorkload 的 Workload 類型。

同時(shí)，這里計(jì)劃要通過(guò)增加 policy 這樣的概念，來(lái)讓研發(fā)表達(dá)對(duì)運(yùn)維策略的訴求，即 Component 中可以表達(dá)希望增加哪些 trait。

apiVersion: core.oam.dev/v1alpha2 kind: WorkloadDefinition metadata:name: containerizedworkloads.core.oam.dev spec:definitionRef:name: containerizedworkloads.core.oam.dev

一個(gè)使用 ContainerizedWorkload?示例：

apiVersion: core.oam.dev/v1alpha2 kind: Component metadata:name: frontendannotations:version: v1.0.0description: "A simple webserver" spec:workload:apiVersion: core.oam.dev/v1alpha2kind: ContainerizedWorkloadmetadata:name: sample-workloadspec:osType: linuxcontainers:- name: webimage: example/charybdis-single:latest@@sha256:verytrustworthyhashresources:cpu:required: 1.0memory:required: 100MBenv:- name: MESSAGEvalue: defaultparameters:- name: messagedescription: The message to display in the web app. required: truetype: stringfieldPaths:- ".spec.containers[0].env[0].value"

下一步計(jì)劃

應(yīng)用級(jí)別的組件間參數(shù)傳遞和依賴關(guān)系（workflow）；

Policy 方案，便于研發(fā)在?Component 對(duì) trait 提出訴求；

Component 增加版本的概念，同時(shí)給出 OAM 解決應(yīng)用版本發(fā)布相關(guān)方式。

常見(jiàn) FAQ

我們?cè)衅脚_(tái)改造為 OAM 模型實(shí)現(xiàn)需要做什么？

對(duì)于原先是 K8s 上的應(yīng)用管理平臺(tái)，接入改造為 OAM 實(shí)現(xiàn)可以分為兩個(gè)階段：

• 實(shí)現(xiàn) OAM ApplicationConfiguration Controller（簡(jiǎn)稱 AppConfig Controller），這個(gè) Controller 同時(shí)包含 OAM 的 Component、WorkloadDefinition、TraitDefinition、ScopeDefinition 等 CRD。AppConfig Controller 根據(jù) OAM AppConfig 中的描述，拉起原有平臺(tái)的 CRD Operator；
• 逐漸將原先的 CRD Operator 根據(jù)關(guān)注點(diǎn)分離的思想，分為 Workload 和 Trait。同時(shí)接入和復(fù)用 OAM 社區(qū)中更多的 Workload、Trait，豐富更多場(chǎng)景下的功能。

現(xiàn)有的 CRD Operator 為接入 OAM 需要做什么改變？

現(xiàn)有的 CRD Operator** 功能上可以平滑接入 OAM 體系，比如作為一個(gè)獨(dú)立擴(kuò)展 Workload 接入。但是為了更好的讓終端用戶體會(huì)到 OAM 關(guān)注點(diǎn)分離的好處，我們強(qiáng)烈建議 CRD Operator 根據(jù)研發(fā)和運(yùn)維不同的關(guān)注點(diǎn)分離為不同的 CRD，研發(fā)關(guān)注的 CRD 作為 Workload 接入 OAM，運(yùn)維關(guān)注的 CRD 作為 Trait 接入 OAM。

目前，OAM 規(guī)范和模型實(shí)際已解決許多現(xiàn)有問(wèn)題，但它的路程才剛剛開(kāi)始。OAM 是一個(gè)中立的開(kāi)源項(xiàng)目，我們歡迎更多的人參與其中，共同定義云原生應(yīng)用交付的未來(lái)。

參與方式：

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

• 通過(guò) Gitter 直接參與討論
• OAM 開(kāi)源實(shí)現(xiàn)地址
• 點(diǎn)擊 star 一下

作者簡(jiǎn)介

孫健波（花名：天元）阿里云技術(shù)專家，是 OAM 規(guī)范的主要制定者之一，致力于推動(dòng)云原生應(yīng)用標(biāo)準(zhǔn)化。同時(shí)也在阿里巴巴參與大規(guī)模云原生應(yīng)用交付與應(yīng)用管理相關(guān)工作。團(tuán)隊(duì)誠(chéng)邀應(yīng)用交付、Serverless、PaaS 領(lǐng)域的專家加入，歡迎聯(lián)系? jianbo.sjb AT alibaba-inc.com

招人啦！

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

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

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

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

總結(jié)

以上是生活随笔為你收集整理的OAM v1alpha2 新版：平衡标准与可扩展性的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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