工作负载类型

工作负载类型由平台提供，以便用户可以检查平台并了解有哪些工作负载类型可供使用。

https://github.com/oam-dev/spec/blob/master/4.workload_types.md

使用工作负载类型在组件模型部分有所涉及，但这里要描述工作负载类型的定义。

工作负载类型是特定组件定义的关键特征。工作负载类型由平台提供，以便用户可以检查平台并了解有哪些工作负载类型可供使用。请注意，工作负载类型对终端用户是不可扩展的（只对平台运营商）。因此，不允许终端用户创建新的工作负载类型。

工作负载的定义

工作负载类型以 WorkloadDefinition 的形式呈现，除了可发现性的目的，工作负载定义还带有特征信息，提示平台如何将特征附加到引用该工作负载类型的特定组件上（即适用于特征系统的特性）。

顶层属性

以下是提供工作负载定义顶层信息的属性。

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 model
kind string Y 必须是 WorkloadDefinition
metadata Metadata Y 实体元数据。
spec Spec Y 工作负载定义的规范。

Spec

Attribute Type Required Default Value Description
definitionRef DefinitionRef Y 平台中工作负载能力的标识符。

DefinitionRef

Attribute Type Required Default Value Description
name string N 工作负载能力的名称标识符。与 apiVersion 和 kind 相互排斥。
apiVersion string N 工作负载能力的API版本。
kind string N 工作负载能力的类型

工作负载类型的特点

在工作负载定义中保留的 metadata.labels 是用来表示工作负载类型的区别特征的。

这些特征将被应用于特征系统(traits system)的特性。

Label Type Explain
workload.oam.dev/replicable boolean 它们是否可以复制（replicable）。如果不是，则不可以指定复制或扩展的特征。
workload.oam.dev/daemonized boolean 它们是否是守护型的（daemonized）。对于守护进程类型，如果工作负载退出，这被认为是一个故障，系统必须修复它。对于非daemonized类型，如果没有报告错误，退出被认为是成功。
workload.oam.dev/exposed boolean 它们是否被暴露，即有一个具有稳定名称的网络流量的服务端点。拥有服务端点的工作负载类型需要一个带有DNS名称的虚拟IP地址（VIP），以代表组件的整体，可在其网络范围内寻址，并可以分配流量路由特征。
workload.oam.dev/podspecable boolean 该工作负载是否可以由Kubernetes PodSpec解决。如果是，实现可以通过利用PodSpec结构来操纵工作负载，而不是对工作负载的模式不闻不问。

工作负载类型的分类

工作量类型有几个类别。

官方维护的工作负载类型

官方维护的工作负载类型必须是在 oam.dev 组中。

下面是一个官方维护的工作负载类型的例子：

kind: WorkloadDefinition
metadata:
  name: Server
spec:
  definitionRef:
    name: containerizedworkloads.core.oam.dev

该工作负载类型的规范:

Name Category Schema Exposed Replicable Daemonized
Server Core ContainerizedWorkload Yes Yes Yes

扩展工作负载类型

每个OAM运行时都可以在这个分组之外定义自己的工作负载类型，它们将被视为一种扩展的工作负载类型。扩展工作负载类型的名称和模式完全由OAM的实施者决定。

下面是一个扩展工作负载的例子:

kind: WorkloadDefinition
metadata:
  name: redis.cache.aliyun.com
spec:
  definitionRef:
    name: redis.cache.aliyun.com # this is an extended workload type

对于扩展的工作负载类型，建议采用以下约定:

  • 使用 Group/Version/Kind 来唯一地识别工作负载能力。
  • 该名称遵循 Group, Version, Kind 中描述的格式。
  • WorkloadDefinition 的 name 与它所指向的 name 相同。

比如说:

kind: WorkloadDefinition
metadata:
  name: schema.example.com
spec:
  definitionRef:
    name: schema.example.com

组件和工作负载类型的关系

简而言之，组件是对工作负载类型的封装，预先定义了面向用户的示意图。组件需要明确声明其工作负载类型，以便OAM系统正常工作，也就是说，OAM特性系统将检查这个工作负载类型信息，以验证某个特性是否可以附加到这个组件。

下面的例子可能也有助于更好地解释它们之间的关系。

  • 一个Web服务组件，封装了一个Kubernetes Deployment +一个Service。

    • 在这种情况下，app/v1.Deployment是这个组件的工作负载类型。

  • 一个封装了Kubernetes Deployment的后端工作者组件。

    • 在这种情况下，apps/v1.Deployment仍然是该组件的工作负载类型。

  • 模板化 Kubernetes Deployment的Helm图+Ingress也是一个组件。

    • apps/v1.Deployment是该组件的工作负载类型。

concepts

从另一个角度来看，ComponentDefinition 总是由某些组件提供者或软件构建者定义，而 WorkloadDefinition 作为一种平台能力，总是由基础设施运营商维护。因此，OAM平台通常拥有数量非常有限的工作负载定义，而且它们不会有很大的变化，但总是有无数的组件定义由不同的供应商和用户维护。