如何解析OAM v1alpha2 新版的平衡標(biāo)準(zhǔn)與可擴(kuò)展性，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

創(chuàng)新互聯(lián)，為您提供重慶網(wǎng)站建設(shè)、網(wǎng)站制作、網(wǎng)站營(yíng)銷推廣、網(wǎng)站開(kāi)發(fā)設(shè)計(jì)，對(duì)服務(wù)柔性防護(hù)網(wǎng)等多個(gè)行業(yè)擁有豐富的網(wǎng)站建設(shè)及推廣經(jīng)驗(yàn)。創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司成立于2013年,提供專業(yè)網(wǎng)站制作報(bào)價(jià)服務(wù),我們深知市場(chǎng)的競(jìng)爭(zhēng)激烈，認(rèn)真對(duì)待每位客戶，為客戶提供賞心悅目的作品。 與客戶共同發(fā)展進(jìn)步，是我們永遠(yuǎn)的責(zé)任！

目前 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ù)用的窘境。

下面言歸正傳，讓我們來(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: 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": "/tupian/20230522/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.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. 這里對(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)一步選擇；

1. 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.RedisCluster
  workloadSettings:
    engineVersion: 1.0
    region: cn

// 老版本，僅對(duì)比使用
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

這樣的好處很明顯：

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

2. 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.RedisCluster
  parameters:
  - name: engineVersion
    type: string
  workloadSettings:
    - name: engineVersion
      type: string
      fromParam: engineVersion

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

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

這個(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/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 是個(gè)數(shù)組，每個(gè)元素定義了參數(shù)和對(duì)應(yīng) 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。

主要改動(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: engineVersion
      type: string
      description: engine version
      fromParam: 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/v1alpha2
    kind: Server
    spec:
   ...

主要改動(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: 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 來(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: 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

主要改動(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_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)]"

主要改動(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: 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"

下一步計(jì)劃

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

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

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

常見(jiàn) FAQ

1. 我們?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)景下的功能。

1. 現(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)。

關(guān)于如何解析OAM v1alpha2 新版的平衡標(biāo)準(zhǔn)與可擴(kuò)展性問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道了解更多相關(guān)知識(shí)。

網(wǎng)站欄目：如何解析OAMv1alpha2新版的平衡標(biāo)準(zhǔn)與可擴(kuò)展性-創(chuàng)新互聯(lián)
網(wǎng)頁(yè)鏈接：http://jinyejixie.com/article24/egeje.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、ChatGPT、動(dòng)態(tài)網(wǎng)站、App開(kāi)發(fā)、關(guān)鍵詞優(yōu)化、網(wǎng)站營(yíng)銷

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)