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

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

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

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

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

下面言歸正傳，讓我們來看一下 v1alpha2 到底做了哪些改動？

主要改動說明

為了方便大家閱讀，這里只羅列了最主要的改動點，一些細節(jié)還是以上游 OAM Spec Github 倉庫為準。

術(shù)語說明

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

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

主要改動 1 使用 Reference 模型定義 Workload、Trait 和 Scope

v1alpha1 原先的方式是這樣的：

// 老版本，僅對比使用 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 的校驗通過 jsonschema 表示，整體的格式實際上類似 CRD，但不完全一致。

新版 v1alpha2 中徹底改為了引用模型，通過 WorkloadDefinition? TraitDefinition? ScopeDefinition 的形式，描述了一個引用關(guān)系?？梢灾苯右靡粋€ CRD，name 就是 CRD 的名稱。對于非 K8s 的 OAM 實現(xiàn)來說，這里的名字則是一個索引，可以找到類似 CRD 的校驗文件，校驗文件中包含 apiVersion 和 kind，以及相應(yīng)的 schema 校驗。

• 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

注意：

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

Definition 這一層不面向 end user，主要給平臺實現(xiàn)使用，對于非 K8s 實現(xiàn)來說，如果存在多個 version 的場景，OAM 的實現(xiàn)平臺可以給終端用戶展示不同 version 的選擇。

主要改動 2 直接嵌入 K8s CR 作為 Component 和 Trait 實例

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

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

// 老版本，僅對比使用 apiVersion: core.oam.dev/v1alpha1 kind: ComponentSchematic metadata:name: rediscluster spec:workloadType: cache.crossplane.io/v1alpha1.RedisClusterworkloadSettings:engineVersion: 1.0region: cn // 老版本，僅對比使用 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

這樣的好處很明顯：

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

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

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

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

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

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

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

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

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

后來我們曾經(jīng)提議過這樣的方案：

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

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

經(jīng)過多方面的討論，在新方案里我們通過 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 是個數(shù)組，每個元素定義了參數(shù)和對應(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。

主要改動 4 ComponentSchematic 名稱改為 Component

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

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

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

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

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

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

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

// 老版本，僅對比使用 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 來對應(yīng)實例，為了讓 Scope 的概念更清晰，更方便對應(yīng)不同類型的 Scope，將 Scope 拿出來直接由 ScopeDefinition 定義的 CRD 對應(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

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

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

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

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

// 老版本，僅對比使用 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)]"

主要改動 7 用 ContainerizedWorkload 替代原來的六種核心 Workload

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

同時，這里計劃要通過增加 policy 這樣的概念，來讓研發(fā)表達對運維策略的訴求，即 Component 中可以表達希望增加哪些 trait。

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

一個使用 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"

下一步計劃

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

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

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

常見 FAQ

我們原有平臺改造為 OAM 模型實現(xiàn)需要做什么？

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

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

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

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

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

參與方式：

• 釘釘掃碼進入 OAM 項目中文討論群

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

作者簡介

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

招人啦！

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

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

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

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

總結(jié)

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

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