大家都知道，应用开放模型 Open Application Model（OAM） 将应用的工作负载（Workload）分为三种 —— 核心型、标准型和扩展型，这三者的主要区别在于一个 OAM 平台对于具体某一类工作负载进行实现的自由度不同。其中，OAM 社区中目前唯一一个核心工作负载是 Containerized Workload，它用来描述一个基于容器的工作负载，可以理解为是 Kubernetes Deployment 的简化版（去掉了 PodSecurityPolicy 等大量与业务研发无关的字段）。

不过，很多读者可能会有疑问：对于 Kubernetes 内置的工作负载 OAM 是否还能直接支持呢？

答案当然是肯定的，而且这是 OAM 作为 Kubernetes 原生的应用定义模型的默认能力。

下面，本文就以 Deployment 为例，介绍如何使用 OAM 基于 Kubernetes 的内置工作负载来定义和管理云原生应用。

示例准备

基于 GitHub FoodTrucks （旧金山美味街边小吃地图应用）项目，构建镜像 zzxwill/foodtrucks-web:0.1.1，加上依赖的 Elasticsearch 镜像，在默认情况下，它的 Deployment 描述文件 food-truck-deployment.yaml 如下所示：

apiVersion: apps/v1
kind: Deployment
metadata:
name: food-trucks-deployment
labels:

app: food-trucks

spec:
selector:

matchLabels:
  app: food-trucks

template:

metadata:
  labels:
    app: food-trucks
spec:
  containers:
  - name: food-trucks-web
    image: zzxwill/foodtrucks-web:0.1.1
    env:
    - name: discovery.type
      value: single-node
    ports:
    - containerPort: 5000
  - name: es
    image: docker.elastic.co/elasticsearch/elasticsearch:6.3.2
    ports:
    - containerPort: 9200
    - containerPort: 9300

如果将上述 yaml 文件提交到 Kubernetes 集群，通过 port-forward 可以通过浏览器查看效果：

定义 Component 与 Workload

在 OAM 中， 一个应用是由多个 Component（组件）构成的，而一个 Component 里的核心字段，就是 Workload（工作负载）。

所以说，像 Kubernetes Deployment、StatefulSet 等内置的工作负载，其实天生就可以被定义为 OAM Component 中的 Workload。比如下面这个 sample-deployment-component.yaml 文件，可以看到，.spec.workload 的内容，就是一个 Deployment，也就是 food-truck-deployment.yaml 里定义的 Deployment。

接下来，我们就将上述 OAM Component 提交到 Kubernetes 集群验证一下。

部署这个应用

在 OAM 中，我们需要编写一个应用配置 ApplicationConfiguration 来组织所有的 OAM Component。由于只有一个 Component，本例中的 sample-applicationconfiguration.yaml 非常简单，如下所示：

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
name: example-deployment-appconfig
spec:
components:

• componentName: example-deployment

提交 OAM Component 和 ApplicationConfiguration YAML 文件给 Kubernetes：

✗ kubectl apply -f sample-deployment-component.yaml
component.core.oam.dev/example-deployment created
✗ kubectl apply -f sample-applicationconfiguration.yaml
applicationconfiguration.core.oam.dev/example-deployment-appconfig created

不过，如果这个时候你查看 example-deployment-appconfig 的执行情况，会发现如下报错：

✗ kubectl describe applicationconfiguration example-deployment-appconfig
Name: example-deployment-appconfig
...
Status:
Conditions:

Message:               cannot apply components: cannot apply workload "food-trucks-deployment": cannot get object: deployments.apps "food-trucks-deployment" is forbidden: User "system:serviceaccount:crossplane-system:crossplane" cannot get resource "deployments" in API group "apps" in the namespace "default"
Reason:                Encountered an error during resource reconciliation
...

这是因为 OAM 的 Kubernetes 插件权限不足导致的，所以不要忘记设置合理的 ClusterRole 和 ClusterRoleBinding。

提交如下的授权文件 rbac.yaml，ApplicationConfiguration 可以执行成功。

继续查看 deployments，并设置端口转发：

通过 http://127.0.0.1:5000 就可以在旧金山美味街边小吃地图里找到汉堡包的店了：

什么时候使用 Deployment ？

看到这里，大家可能会有另一个疑问，那么我什么时候该使用 Deployment、什么时候该使用 ContainerizedWorkload 来作为 OAM 的工作负载呢？

**其实，Deployment 和 ContainerizedWorkload 的主要区别，在于抽象程度不同。
**

简单说，如果你的用户希望看到一个极简的、没有一些”乱七八糟“字段的 Deployment 的话；或者，你希望对你的用户屏蔽掉 Deployment 里面与用户无关的字段（比如：不想允许研发自行设置 PodSecurityPolicy），那你就应该给用户暴露 ContainerizedWorkload。这时候，这个工作负载需要的运维操作和策略，则是由另一个 OAM 对象 Traits（运维特征） 来定义的，比如 ManualScalerTrait。这种“关注点分离”的做法，也是 OAM 提倡的最佳实践。

反之，如果你的用户对 Deployment 里的各种运维、安全相关的字段并不排斥，你也不需要对用户屏蔽掉这些字段，那你大可以直接暴露 Deployment 出去。这个工作负载需要的其他运维能力，依然可以通过 OAM Traits 来提供。

为什么使用 OAM Component 来定义应用？

你有可能还有另外一个疑问，既然 OAM Component 里面的 Workload 就是 Kubernetes 里的各种 API 对象，那么使用 OAM 模型来定义应用又有哪些好处呢？

这就要说到 OAM 带来的好处了，相信大家在基于 Kubernetes 构建应用平台的时候，一定遇到过一系列的难题，比如依赖管理、版本控制、灰度发布等等，另一方面，应用平台为了跟云资源结合起来，纯粹使用 K8s 原生的 Workload 是做不到的。

而通过 OAM ，你不仅可以将云资源与应用统一描述，OAM 实现框架还将帮你解决了依赖管理、版本控制、灰度发布等一系列难题。这些我们将在后续的文章中为大家介绍。

本文转自<阿里巴巴云原生技术圈>——阿里巴巴云原生小助手