特质
https://github.com/oam-dev/spec/blob/master/6.traits.md
特质(trait)是一种随意的运行时覆盖物，它用运维功能增强了组件工作负载实例。它为应用程序运维人员提供了一个机会，使他们能够对组件的配置做出具体的决定，而不必让组件提供者参与其中或破坏组件的封装。
例如， WordPress Helm 图表中向工作负载注入一个 sidecar 容器的
sidecar特性。
特质可以是适用于单个组件的分布式应用的任何配置，如流量路由规则（例如，负载平衡策略、网络入口路由、中断、速率限制）、自动扩展策略、升级策略等。
特质定义
本节是规范性的，因为特征是系统的可检查（可能是可共享）部分。所有特质必须可以用以下格式表示。
特征的定义与组件一样，都是用示意图(schematics)来定义的。与工作负载定义一样，每个特征定义都有一个 definitionRef，它是对定义该特征的配置选项的模式的引用。
顶层属性
特质的顶级属性定义了它的元数据、版本、种类和规格。
| Attribute | Type | Required | Default Value | Description |
|---|---|---|---|---|
apiVersion |
string |
Y | A string that identifies the version of the schema the object should have. The core types uses core.oam.dev/v1beta1 in this version of documentation. |
|
kind |
string |
Y | Must be TraitDefinition |
|
metadata |
Metadata |
Y | Information about the trait. | |
spec |
Spec |
Y | A specification for trait attributes. |
Spec
| Attribute | Type | Required | Default Value | Description |
|---|---|---|---|---|
appliesToWorkloads |
[]string |
* | 该特征所适用的工作负载类型特征的集合。如果该字段为空或未指定或指定为 "*"，则表示适用任何工作负载类型。特征必须至少适用于一个工作负载类型。这个属性必须至少包含一个值。 |
|
conflictsWith |
[]string |
N | 当应用于同一工作负载类型时，将与该特性冲突的特性列表。例如，“autoscaling” 可能与 “cron-autoscaling” 冲突。 | |
definitionRef |
DefinitionRef |
Y | 特质能力的标识符。 |
DefinitionRef
DefinitionRef identifies the trait capability, i.e. the trait implementation.
| Attribute | Type | Required | Default Value | Description |
|---|---|---|---|---|
name |
string |
N | 特质的名称标识符。与apiVersion和kind相互排斥。 |
|
apiVersion |
string |
N | API version of the trait. | |
kind |
string |
N | Kind of trait. |
建议使用 Group/Version/Kind 来唯一地识别特征能力。如果使用definitionRef.name，它必须包含可用于唯一标识的信息。
应用部分将详细描述用户如何将特征附加到组件上。
实现特性系统
警告：本节只针对OAM平台的实现者（即KubVela），如果你只对OAM的概念感兴趣，请随意跳过本节。
特质系统在本文档中被定义为运行时通过特质对组件实例应用和管理运维行为的方式。
该模型的运行时实现必须提供特性系统，以便将运维行为附加到组件实例上。
特征系统的规则和特性
特征应该在安装/升级时被应用到运行时中。特征不应该被 “懒惰地/lazily” 检查，而应该在持有特征的组件被创建时被检查。
当组件附加了一个以上的特性时，它必须:
- 按照定义的顺序应用特征
- 确定兼容性，如果特性的组合不能被满足，则失败。
特质是按顺序应用的，这样，如果某些特质集表达了依赖性（例如，在SSL之前必须设置ingress），这可以通过设置一个显式顺序来解决。
一个组件实例只能有一个任何给定特性类型的配置。
在所有特征配置完成之前，部署不应该被标记为完成。例如，如果Web服务器组件被部署为自动缩放器特性，那么在(a)Web服务器本身运行（由健康检查决定）和(b)自动缩放器特性运行（由底层平台决定）之前，Web服务器不应该被视为 “运行”。
组件可以指定多个特性；因此，运行时必须支持将零个或多个特性应用于一个组件。如果底层运行时不能满足所请求的特征，则运行时必须产生错误并停止部署。
没有机制可以明确地要求特性的组合。例如，一个特征（ssl）不能指定它要求另一个特征（ingress）应用于一个对象。然而，如果一个特征在没有另一个特征存在的情况下不能履行其契约，那么特征的实现就应该失败。一个系统可能支持这样一种机制，即一个特征（sslIngress）被两个独立的特征实现（ssl和ingress）不透明地支持着。
任何在运行时中可用的特性都必须在该运行时中实现。例如，在一个运行时中不能有一个用于自动缩放的特性，但没有实现该特性。
特质的类别
特质系统被设计成作为运行时运维能力的扩展点，同时也为组件提供通用的，在某些情况下是必要的运维功能。
特质的实现细节超出了本文档的范围。然而，为了使运行时能够实现任意特征，同时保持一定程度的通用性，以便在不同的运行时之间进行应用移植，特征被分为以下几类。
-
核心特质。该类别定义了一组类型名称为
core.oam.dev组的特性定义。这些特征提供了某些工作负载类型和组件特性运行所需的运维功能。运行时必须实现本模型中定义的这些特征。 -
标准特质。该类别定义了一组特征定义，其类型名称在
standard.oam.dev组中。这些特征提供了应用程序运维人员常用的运维功能，并由大多数运行时实现。建议运行时在提供与标准特性定义中所列功能相当的运维功能时，使用本模型中定义的标准特性定义。换句话说，如果运行时正在实现具有行为foo的特质，并且存在行为foo的标准特质定义，那么运行时应该使用标准foo特质定义。计划最大限度地提高其应用程序的可移植性的应用程序运营商应该在可用时使用这些特性定义。尽管这并不保证应用程序的可移植性，但它旨在提高跨运行时的可移植性。 -
扩展特质。该类别允许运行时定义自己的特质定义集，这些特质定义是该运行时在核心和标准特质定义之外所特有的。运行时可以选择用任何定义来实现这个类别中的任何一组特质。扩展特性类型的名称不得在
core.oam.dev或standard.oam.dev组中。
特质特征
一个单独的特质可以与特定的工作负载相联系（也可以适用于所有工作负载）。特质可以声明它适用于哪个工作负载。
本模型没有对特质的简单或复杂程度做出要求。有些特质可能会暴露出一组广泛的可配置的选项，而其他特质可能没有暴露出可配置的选项。也不要求特质像其基础技术那样详尽。例如，一个自动缩放技术的实现可以提供许多方法来确定一个组件何时应该缩放。但该特质可能只显示其中的几个。同样地，可以定义多个自动缩放特质（每个都有唯一的名称），每个特质暴露不同的可配置选项子集。或者一个大的特质可以暴露所有可能的自动缩放配置。
OAM平台的实现应使所有支持的特质都能以下面解释的格式被发现。