如何解析OAM v1alpha2 新版的平衡標準與可擴展性

146次閱讀

共計 10462 個字符，預計需要花費 27 分鐘才能閱讀完成。

如何解析 OAM v1alpha2 新版的平衡標準與可擴展性，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

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

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

主要改動說明

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

術語說明

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

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

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

v1alpha1 原先的方式是這樣的：

//  老版本，僅對比使用
apiVersion: core.oam.dev/v1alpha1
kind: WorkloadType
metadata:
 name: OpenFaaS
 annotations:
 version: v1.0.0
 description:  OpenFaaS a Workload which can serve workload running as functions 
spec:
 group: openfaas.com
 version: v1alpha2
 names:
 kind: Function
 singular: function
 plural: functions
 workloadSettings: |
 {
  $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 的形式，描述了一個引用關系。可以直接引用一個 CRD，name 就是 CRD 的名稱。對于非 K8s 的 OAM 實現(xiàn)來說，這里的名字則是一個索引，可以找到類似 CRD 的校驗文件，校驗文件中包含 apiVersion 和 kind，以及相應的 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.dev
 definitionRef:
 name: manualscalertrait.core.oam.dev

Scope

apiVersion: core.oam.dev/v1alpha2
kind: ScopeDefinition
metadata:
 name: networkscope.core.oam.dev
spec:
 allowComponentOverlap: true
 definitionRef:
 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.RedisCluster
 workloadSettings:
 engineVersion: 1.0
 region: cn

//  老版本，僅對比使用
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
 name: custom-single-app
 annotations:
 version: v1.0.0
 description:  Customized version of single-app 
spec:
 variables:
 components:
 - componentName: frontend
 instanceName: web-front-end
 parameterValues:
 traits:
 - name: manual-scaler
 properties:
 replicaCount: 5

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

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
 name: example-server
spec:
 prameters:
 - name: xxx
 fieldPaths: 
 -  spec.osType 
 workload:
 apiVersion: core.oam.dev/v1alpha2
 kind: Server
 spec:
 osType: linux
 containers:
 - name: my-cool-server
 image:
 name: example/very-cool-server:1.0.0
 ports:
 - name: http
 value: 8080
 env:
 - name: CACHE_SECRET

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
 name: cool-example
spec:
 components:
 - componentName: example-server
 traits:
 - trait:
 apiVersion: core.oam.dev/v1alpha2
 kind: ManualScalerTrait
 spec:
 replicaCount: 3

這樣的好處很明顯：

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

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

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

為后續(xù)在 trait 這個維度做擴展留下空間，比如可能的編排（
ordering）等。

非 K8s 體系在這一層可以不嚴格按照 CR 的寫法來，完全自定義，不綁定 K8s 描述格式。

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

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

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

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

//  老版本，僅對比使用
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
 name: rediscluster
spec:
 workloadType: cache.crossplane.io/v1alpha1.RedisCluster
 parameters:
 - name: engineVersion
 type: string
 workloadSettings:
 - name: engineVersion
 type: string
 fromParam: engineVersion

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

//  老版本，僅對比使用
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
 name: rediscluster
spec:
 workloadType: cache.crossplane.io/v1alpha1.RedisCluster
 parameters:
 - name: engineVersion
 type: string
 workloadSettings:
 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/v1alpha2
 kind: Server
 spec:
 containers:
 - name: my-cool-server
 image:
 name: example/very-cool-server:1.0.0
 ports:
 - name: http
 value: 8080
 env:
 - name: CACHE_SECRET
 value: cache
 parameters:
 - name: instanceName
 required: true
 fieldPaths:
 -  .metadata.name 
 - name: cacheSecret
 required: true
 fieldPaths:
 -  .workload.spec.containers[0].env[0].value

fieldPaths 是個數(shù)組，每個元素定義了參數(shù)和對應 Workload 里的字段。

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
 name: my-app-deployment
spec:
 components:
 - componentName: example-server
 parameterValues:
 - name: cacheSecret
 value: 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: engineVersion
 type: string
 description: engine version
 fromParam: engineVersion
 ...

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

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

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

主要改動 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: networkName
 value:  my-vpc 
 scopes:
 - name: network
 type: core.oam.dev/v1alpha1.Network
 properties:
 network-id:  [fromVariable(networkName)] 
 subnet-ids:  my-subnet1, my-subnet2

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

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

apiVersion: core.oam.dev/v1alpha2
kind: NetworkScope
metadata:
 name: example-vpc-network
 labels:
 region: us-west
 environment: production
spec:
 networkId: cool-vpc-network
 subnetIds:
 - cool-subnetwork
 - cooler-subnetwork
 - coolest-subnetwork
 internetGatewayType: nat

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

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
 name: custom-single-app
 annotations:
 version: v1.0.0
 description:  Customized version of single-app 
spec:
 components:
 - componentName: frontend
 scopes:
 - scopeRef:
 apiVersion: core.oam.dev/v1alpha2
 kind: NetworkScope
 name: my-vpc-network
 - componentName: backend
 scopes:
 - scopeRef:
 apiVersion: core.oam.dev/v1alpha2
 kind: NetworkScope
 name: 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 列表和相關的 fromVariable 均去掉，并不影響任何功能。

//  老版本，僅對比使用
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
 name: my-app-deployment
spec:
 variables:
 - name: VAR_NAME
 value: SUPPLIED_VALUE
 components:
 - componentName: my-web-app-component
 instanceName: my-app-frontent
 parameterValues:
 - name: ANOTHER_PARAMETER
 value:  [fromVariable(VAR_NAME)] 
 traits:
 - name: ingress
 properties:
 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: frontend
 annotations:
 version: v1.0.0
 description:  A simple webserver 
spec:
 workload:
 apiVersion: core.oam.dev/v1alpha2
 kind: ContainerizedWorkload
 metadata:
 name: sample-workload
 spec:
 osType: linux
 containers:
 - name: web
 image: example/charybdis-single:latest@@sha256:verytrustworthyhash
 resources:
 cpu:
 required: 1.0
 memory:
 required: 100MB
 env:
 - name: MESSAGE
 value: default
 parameters:
 - name: message
 description: The message to display in the web app. 
 required: true
 type: string
 fieldPaths:
 -  .spec.containers[0].env[0].value

下一步計劃

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

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

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

常見 FAQ

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

對于原先是 K8s 上的應用管理平臺，接入改造為 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ù)關注點分離的思想，分為 Workload 和 Trait。同時接入和復用 OAM 社區(qū)中更多的 Workload、Trait，豐富更多場景下的功能。

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

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

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

關于如何解析 OAM v1alpha2 新版的平衡標準與可擴展性問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注丸趣 TV 行業(yè)資訊頻道了解更多相關知識。

正文完