OAM深入解读：使用OAM定义与管理Kubernetes内置Workload

头图.png

作者 | 周正喜阿里云技术专家爱好云原生，深度参与 OAM 社区

大家都知道，应用开放模型 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-deploymentlabels:app: food-trucks
spec:selector:matchLabels:app: food-truckstemplate:metadata:labels:app: food-trucksspec:containers:- name: food-trucks-webimage: zzxwill/foodtrucks-web:0.1.1env:- name: discovery.typevalue: single-nodeports:- containerPort: 5000- name: esimage: docker.elastic.co/elasticsearch/elasticsearch:6.3.2ports:- 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 可以执行成功。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: deployment-clusterrole-poc
rules:
- apiGroups:- appsresources:- deploymentsverbs:- "*"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: oam-food-trucks
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deployment-clusterrole-poc
subjects:- kind: ServiceAccountnamespace: crossplane-systemname: crossplane

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

✗ kubectl get deployments
NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
food-trucks-deployment           1/1     1            1           2m20s
✗ kubectl port-forward deployment/food-trucks-deployment 5000:5000
Forwarding from 127.0.0.1:5000 -> 5000
Forwarding from [::1]:5000 -> 5000
Handling connection for 5000
Handling connection for 5000

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

什么时候使用 Deployment ？

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

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

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

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