模块定义（X-Definition）

    KubeVela 是完全可编程的，它可以轻松的根据你的需求实现原地定制和扩展。

    最终用户使用的 OAM 模型 应用部署计划 Application 中，有很多声明“类型的字段”，如组件类型、运维特征类型、应用策略类型、工作流节点类型等，这些类型实际上就是 OAM 模型的模块定义（X-Definition），这些模块在 KubeVela 中全部都是基于 的可编程模块。

    当前 OAM 模型支持的模块定义（X-Definition）包括组件定义（ComponentDefinition），运维特征定义（TraitDefinition）、应用策略定义（PolicyDefinition），工作流节点定义（WorkflowStepDefinition）等，随着系统演进，OAM 模型未来可能会根据场景需要进一步增加新的模块定义。

    组件定义（ComponentDefinition）的设计目标是允许平台管理员将任何类型的可部署制品封装成待交付的“组件”。只要定义好之后，这种类型的组件就可以被用户在部署计划（Application）中引用、实例化并交付出去。

    常见的组件类型包括 Helm Chart 、Kustomize 目录、一组 Kubernetes YAML文件、容器镜像、云资源 IaC 文件、或者 CUE 配置文件模块等等。组件供应方对应真实世界中的角色，一般就是第三方软件的分发者（ISV）、DevOps 团队的工程师、或者你自己建设的 CI 体系生成的代码包和镜像。

    组件定义是可以被共享和复用的。比如一个阿里云 RDS组件类型，最终用户可以在不同的应用中选择同样的 阿里云 RDS 组件类型，实例化成不同规格、不同参数配置的云数据库实例。

    让我们来看一下组件定义的框架格式：

    除了基本的“组件定义名称”和“功能描述说明”以外，组件定义的核心是 .spec 下面的两部分，一部分是工作负载类型；另一部分是组件描述。

    • 工作负载类型（对应.spec.workload）字段为系统指明了一个组件背后对应的工作负载类型。它有两种定义方式，一种如例子中显示的，填写 .spec.workload.definition 的具体资源组和资源类型名称。另一种方法则是填写一个工作负载类型的名称。对于背后的工作负载类型不明确的组件定义，可以填写一个特殊的工作负载类型 autodetects.core.oam.dev，表示让 KubeVela 自动发现背后的工作负载。
    1. apiVersion: core.oam.dev/v1beta1
    3. kind: ComponentDefinition
    5. ...
    7. spec:
    9.   workload: # 工作负载类型
    11.     type: <工作负载类型名称>
    13.   ...

    工作负载类型名称对应了一个“工作负载定义”的引用，“工作负载定义”的原理会在下一个小节介绍。两种写法的区别在于第一种直接写工作负载的资源组和类型，如果背后没有工作负载定义，会自动生成。而指定“工作负载类型名称”则可以做校验，限制组件定义只能针对系统中已经存在的工作负载类型做抽象。

    • 组件描述（对应.spec.schematic）定义了组件的详细信息。该部分目前支持 cue 和 两种描述方式。

    具体抽象方式和交付方式的编写可以查阅对应的文档，这里以一个完整的例子介绍组件定义的工作流程。

    1. apiVersion: core.oam.dev/v1beta1
    3. kind: ComponentDefinition
    5. metadata:
    7.   name: helm
    9.   namespace: vela-system
    11.   annotations:
    13.     definition.oam.dev/description: "helm release is a group of K8s resources from either git repository or helm repo"
    15. spec:
    17.   workload:
    19.     type: autodetects.core.oam.dev
    21.   schematic:
    23.     cue:
    25.       template: |
    27.         output: {
    29.           apiVersion: "source.toolkit.fluxcd.io/v1beta1"
    31.           metadata: {
    33.             name: context.name
    35.           }
    37.           if parameter.repoType == "git" {
    39.             kind: "GitRepository"
    41.             spec: {
    43.               url: parameter.repoUrl
    45.               ref:
    47.                 branch: parameter.branch
    49.               interval: parameter.pullInterval
    51.             }
    53.           }
    55.           if parameter.repoType == "helm" {
    57.             kind: "HelmRepository"
    59.             spec: {
    61.               interval: parameter.pullInterval
    63.               url:      parameter.repoUrl
    65.               if parameter.secretRef != _|_ {
    67.                 secretRef: {
    69.                   name: parameter.secretRef
    71.                 }
    73.               }
    75.             }
    77.           }
    79.         }
    84.         outputs: release: {
    86.           apiVersion: "helm.toolkit.fluxcd.io/v2beta1"
    88.           kind:       "HelmRelease"
    90.           metadata: {
    92.             name: context.name
    94.           }
    96.           spec: {
    98.             interval: parameter.pullInterval
    100.             chart: {
    102.               spec: {
    104.                 chart:   parameter.chart
    106.                 version: parameter.version
    108.                 sourceRef: {
    110.                   if parameter.repoType == "git" {
    111.                     kind: "GitRepository"
    113.                   }
    115.                   if parameter.repoType == "helm" {
    117.                     kind: "HelmRepository"
    119.                   }
    121.                   name:      context.name
    123.                   namespace: context.namespace
    125.                 }
    129.               }
    131.             }
    133.             if parameter.targetNamespace != _|_ {
    135.               targetNamespace: parameter.targetNamespace
    137.             }
    139.             if parameter.values != _|_ {
    141.               values: parameter.values
    143.             }
    145.           }
    147.         }
    152.         parameter: {
    154.           repoType: "git" | "helm"
    156.           // +usage=The Git or Helm repository URL, accept HTTP/S or SSH address as git url.
    158.           repoUrl: string
    160.           // +usage=The interval at which to check for repository and relese updates.
    162.           pullInterval: *"5m" | string
    164.           // +usage=1.The relative path to helm chart for git source. 2. chart name for helm resource
    166.           chart: string
    168.           // +usage=Chart version
    170.           version?: string
    172.           // +usage=The Git reference to checkout and monitor for changes, defaults to master branch.
    174.           branch: *"master" | string
    176.           // +usage=The name of the secret containing authentication credentials for the Helm repository.
    178.           secretRef?: string
    180.           // +usage=The namespace for helm chart
    182.           targetNamespace?: string
    184.           // +usage=Chart version
    186.           value?: #nestedmap
    188.         }
    193.         #nestedmap: {
    195.           ...
    197.         }
    • 其中 definition.oam.dev/description 对应的字段就描述了这个组件类型的功能是启动一个 helm chart。
    • .spec.workload 字段，填写的是autodetects.core.oam.dev表示让用户自动发现这个 helm chart 组件背后的工作负载。
    • .spec.schematic.cue.template字段描述了基于 CUE 的抽象模板，输出包含2个对象，其中一个输出是根据 helm repo 托管的制品形态决定的，如果是用的helm官方的模式托管的则是生成 HelmRepository 对象，git模式推广的就是生成GitRepository 对象，另一个输出的对象是 HelmRelease 包含了这个 helm 的具体参数。 其中 parameter 列表则是暴露给用户填写的全部参数。

    运维特征定义（TraitDefinition）

    运维特征定义（TraitDefinition）为组件提供了一系列可被按需绑定的运维动作，这些运维动作通常都是由平台管理员提供的运维能力，它们为这个组件提供一系列的运维操作和策略，比如添加一个负载均衡策略、路由策略、或者执行弹性扩缩容、灰度发布策略等等。

    绑定一个运维特征实际上就是在 Application 的 components[*].traits 数组中添加一个元素，其中 .triats[*].type 指定的类型名称，就是平台中的运维特征定义，而 .triats[*].properties 就是一系列运维特征的参数字段。与组件定义类似，这里的运维特征可以是 KubeVela 内置的，也可以是平台管理员后续扩展的，都是平等的对象。同样的，运维特征定义中也允许通过不同的抽象方式定义模板指定运维功能。

    运维特征定义的格式和字段作用如下：

    从上述运维特征的格式和功能中我们可以看到，运维特征定义提供了一系列运维能力和组件之间衔接的方式，使得相同功能的运维功能可以适配到不同的组件中。具体的字段功能如下所示：

    • 运维特征能够适配的工作负载名称列表（.spec.appliesToWorkloads）,可缺省字段，字符串数组类型，申明这个运维特征可以用于的工作负载类型，填写的是工作负载的 CRD 名称，格式为 <resources>.<api-group>
    • 与该运维特征冲突的其他运维特征名称列表（.spec.conflictsWith）,可缺省字段，字符串数组类型，申明这个运维特征与哪些运维特征冲突，填写的是运维特征名称的列表。
    • 特征描述（对应.spec.schematic）字段定义了具体的运维动作。目前主要通过 来实现，同时也包含一系列诸如patch-trait这样的高级用法。
    • 运维特征对应的 Kubernetes 资源定义（.spec.definition字段），可缺省字段，如果运维能力通过 Kubernetes 的 CRD 方式提供可以填写，其中 apiVersion 和 kind 分别描述了背后对应的 Kubernetes 资源组和资源类型。
    • 运维能力中对于工作负载对象的引用字段路径（.spec.workloadRefPath字段），可缺省字段，运维能力中如果涉及到工作负载的引用，可以填写这样一个路径地址（如操作弹性扩缩容的 对象，就可以填写spec.scaleTargetRef），然后 KubeVela 会自动将工作负载的实例化引用注入到运维能力的实例对象中。
    • 运维能力的参数更新会不会引起底层资源（pod）重启（.spec.podDisruptive字段），可缺省字段，bool 类型，主要用于向用户标识 trait 的更新会不会导致底层资源（pod）的重启。这个标识通常可以提醒用户，改动这样一个trait可能应该再结合一个灰度发布，以免大量资源重启引入服务不可用和其他风险。
    • 是否由该运维特征管理工作负载（.spec.manageWorkload）,可缺省字段，bool 类型，设置为 true 则标识这个运维特征会负责工作负载的创建、更新、以及资源回收，通常是灰度发布的运维特征会具备这个能力。
    • 该运维特征是否不计入版本变化的计算（.spec.skipRevisionAffect）,可缺省字段，bool 类型，设置为 true 则标识这个运维特征的修改不计入版本的变化，即用户在应用中纯粹修改这个运维特征的字段不会触发应用本身的版本变化。
    • 运维能力是否感知组件版本的变化（.spec.revisionEnabled）字段，可缺省字段，bool 类型，设置为 true 表示组件会生成的资源后缀会带版本后缀。

    让我们来看一个实际的例子：

    1. apiVersion: core.oam.dev/v1beta1
    3. kind: TraitDefinition
    5. metadata:
    7.   annotations:
    9.     definition.oam.dev/description: "configure k8s Horizontal Pod Autoscaler for Component which using Deployment as worklaod"
    11.   name: hpa
    13. spec:
    15.   appliesToWorkloads:
    17.     - deployments.apps
    19.   workloadRefPath: spec.scaleTargetRef
    21.   schematic:
    23.     cue:
    25.       template: |
    27.         outputs: hpa: {
    29.           apiVersion: "autoscaling/v2beta2"
    31.           kind:       "HorizontalPodAutoscaler"
    33.           spec: {
    36.             maxReplicas: parameter.max
    38.             metrics: [{
    40.               type: "Resource"
    42.               resource: {
    44.                 name: "cpu"
    46.                 target: {
    48.                   type:               "Utilization"
    50.                   averageUtilization: parameter.cpuUtil
    52.                 }
    54.               }
    56.             }]
    58.           }
    60.         }
    62.         parameter: {
    64.           min:     *1 | int
    66.           max:     *10 | int
    68.           cpuUtil: *50 | int
    70.         }

    如上所示，这个运维特征的名字叫 hpa，一经注册，最终用户在 Application 的组件类型（components[*].traits[*].type）字段就可以填写这个类型，将这个运维特征作用在对应的组件上。

    从字段和参数中我们可以看到这个运维特征的功能是为 Kubernetes Deployment 这类工作负载的组件提供弹性扩缩容的能力。这个运维特征只能用于 Kubernetes Deployment，同时 KubeVela 在实例化运维能力（即这个 HPA 对象）时会为 spec.scaleTargetRef 字段自动注入工作负载（Deployment 对象）的引用。最后 .spec.schematic.cue.template字段描述了基于 CUE 的抽象模板，定义了输出是一个 Kubernetes 的 HorizontalPodAutoscaler 结构，模板中的 parameter 定义了用户可以使用的参数，包括最大最小值和 CPU 的利用率。

    应用策略定义与运维特征定义类似，区别在于运维特征作用于单个组件，而应用策略是作用于整个应用整体（多个组件）。它可以为应用提供全局的策略定义，常见的包括全局安全策略（如 RBAC权限、审计、秘钥管理）、应用洞察（如 应用的 SLO 管理等）。

    其格式如下所示：

    1. apiVersion: core.oam.dev/v1beta1
    3. kind: PolicyDefinition
    5. metadata:
    7.   name: <应用策略定义名称>
    9.   annotations:
    11.     definition.oam.dev/description: <功能描述说明>
    13. spec:
    15.   schematic:  # 策略描述
    17.     cue: 
    19.       template: <CUE 格式模板>

    目前应用策略定义仅包含 CUE 格式模板一个字段，包含了应用策略输出的对象以及对应的参数，其 CUE 编写的格式与组件定义的 CUE 模板格式一致。一个具体的例子如下所示：

    主要介绍其中的策略描述部分，基于 CUE 格式，输出一个 EnvBinding 对象，其参数就是 engine 和 envs 两个，其中 envs 是一个结构体数组，具体的结构体类型和其中的参数由 #Env 指定，这里面的 CUE 语法与组件定义的 CUE 语法一致。

    工作流节点定义（WorkflowStepDefinition）

    工作流节点的字段相对简单，除了基本的名称和功能以外，其主要的功能都在 CUE 的模板中配置。KubeVela 在工作流模板中内置了大量的操作，具体可以通过工作流文档学习如何使用和编写。

    1. apiVersion: core.oam.dev/v1beta1
    3. kind: WorkflowStepDefinition
    5. metadata:
    7.   name: <工作流节点定义名称>
    9.   annotations:
    11.     definition.oam.dev/description: <功能描述说明>
    13. spec:
    15.   schematic:  # 节点描述
    17.     cue: 
    19.       template: <CUE 格式模板>

    一个实际的工作流节点定义如下所示：

    1. apiVersion: core.oam.dev/v1beta1
    3. kind: WorkflowStepDefinition
    5. metadata:
    7.   name: apply-component
    9. spec:
    11.   schematic:
    13.     cue:
    15.       template: |
    17.         import ("vela/op")
    19.         parameter: {
    21.            component: string
    23.         }
    28.         // load component from application
    30.         component: op.#Load & {
    32.            component: parameter.component
    34.         }
    39.         // apply workload to kubernetes cluster
    41.         apply: op.#ApplyComponent & {
    43.            component: parameter.name
    45.         }
    50.         // wait until workload.status equal "Running"
    52.         wait: op.#ConditionalWait & {
    54.            continue: apply.status.phase =="Running"
    56.         }

    例子中的工作流主要通过引入vela/op 这个内置的 KubeVela 包完成一系列动作，包括数据载入、资源创建以及状态检查。整体这个工作流就完成了 KubeVela 组件的创建、并且查看组件状态是否在正常运行这一功能。

    工作负载定义（WorkloadDefinition）是组件的一种系统级特征，它不是用户所关心的字段，而是作为元数据被 OAM 系统本身进行检查、验证和使用。

    其格式如下所示：

    • 其中 .spec.definitionRef.name 描述了 Kubernetes 资源的名称，其格式与 CRD（Custom Resource Definition）名称一致，是 <resources>.<api group>。
    • .spec.podSpecPath 定义了包含 Kubernetes Pod 字段的工作负载对应的 Pod 字段路径。
    • .spec.revisionLabel 定义了工作负载的版本化标签

    除此之外，未来需要 OAM 模型中需要的引入的其他的针对 Kubernetes 资源类型特征的约定，也会作为字段加入到工作负载定义中。

    抽象背后的标准协议

    应用一经创建，KubeVela 就会为创建的资源打上一系列的标签，这些标签包含了应用的版本、名称、类型等。通过这些标准协议，应用的组件和运维能力之间就可以进行协作。具体的元数据列表如下所示：

    这些元数据可以帮助应用部署以后的运维能力正常运作，比如灰度发布组件在应用更新时根据标签进行灰度发布等，同时这些标签也保证了 KubeVela 被其他系统集成时的正确性。

    模块定义中可以通过 context 变量获得一些运行时的上下文信息，具体的列表如下，其中作用范围表示该 Context 变量能够在哪些模块定义中使用：

    同时，在工作流系统当中，由于 context 要作用于应用级，与上述用法有很大不同。我们单独对其进行介绍：

    最后请注意，在本节介绍的所有的模块化定义概念，都只需要平台的管理员在希望对 KubeVela 进行功能扩展时了解，最终用户对这些概念不需要有任何感知。