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

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

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

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

主要改動說明

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

術語說明

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

• CR （Custom Resource），OAM 中的 CR 是 CRD 的一個實例，是符合 CRD 中字段格式定義的一個資源描述。在 K8s 的 OAM 實現中可以完全對應 K8s 的 CR，在 非 K8s 的實現中，可以需要對齊 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 實現來說，這里的名字則是一個索引，可以找到類似 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

注意：

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

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

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

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

這樣的方式雖然已經可以“推導”出 K8s CR，但是不利于 K8s 生態內的 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

現在的方式則直接嵌入 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

這樣的好處很明顯：

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

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

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

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

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

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

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

體現在 OAM Spec 的流程上就是：研發在 Component 里面定義 parameter，運維在 AppConfig 里面通過 parameterValue 去覆蓋對應的參數。

最初的參數傳遞，是在每個字段后面有個 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

后來我們曾經提議過這樣的方案：

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

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

經過多方面的討論，在新方案里我們通過 JsonPath 的形式描述要注入的參數位置，在用戶理解上保證了 AppConfig 是靜態的。

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 是個數組，每個元素定義了參數和對應 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 里是定義具體的參數，workloadSettings 更像是 schema（參數怎么填的說明）。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 實現中，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 單獨創建，不再由 AppConfig 創建

v1alpha1 中的 Scope 是由 AppConfig 創建的，從例子中可以看出，本質上它也是個 CR，可以“推導”創建出 CR來。但是由于 Scope 的定位是可以容納不同 AppConfig 中的 Component，且 Scope 本身并非一個 App，所以使用 AppConfig 創建 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 創建。例子如下所示：

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()] 動態函數

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

另一方面，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

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

同時，這里計劃要通過增加 policy 這樣的概念，來讓研發表達對運維策略的訴求，即 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"

下一步計劃

1. 應用級別的組件間參數傳遞和依賴關系（ workflow）；

2. Policy 方案，便于研發在 Component 對 trait 提出訴求；

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

常見 FAQ

1. 我們原有平臺改造為 OAM 模型實現需要做什么？

對于原先是 K8s 上的應用管理平臺，接入改造為 OAM 實現可以分為兩個階段：

• 實現 OAM ApplicationConfiguration Controller（簡稱 AppConfig Controller），這個 Controller 同時包含 OAM 的 Component、WorkloadDefinition、TraitDefinition、ScopeDefinition 等 CRD。AppConfig Controller 根據 OAM AppConfig 中的描述，拉起原有平臺的 CRD Operator；

• 逐漸將原先的 CRD Operator 根據關注點分離的思想，分為 Workload 和 Trait。同時接入和復用 OAM 社區中更多的 Workload、Trait，豐富更多場景下的功能。

1. 現有的 CRD Operator 為接入 OAM 需要做什么改變？

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

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

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