作者 | 周正喜? 阿里云技術(shù)專家? 愛好云原生，深度參與 OAM 社區(qū)

大家都知道，應(yīng)用開放模型 Open Application Model（OAM） 將應(yīng)用的工作負(fù)載（Workload）分為三種?—— 核心型、標(biāo)準(zhǔn)型和擴(kuò)展型，這三者的主要區(qū)別在于一個 OAM 平臺對于具體某一類工作負(fù)載進(jìn)行實(shí)現(xiàn)的自由度不同。其中，OAM 社區(qū)中目前唯一一個核心工作負(fù)載是?Containerized Workload，它用來描述一個基于容器的工作負(fù)載，可以理解為是 Kubernetes Deployment 的簡化版（去掉了 PodSecurityPolicy 等大量與業(yè)務(wù)研發(fā)無關(guān)的字段）。

不過，很多讀者可能會有疑問：對于 Kubernetes 內(nèi)置的工作負(fù)載 OAM 是否還能直接支持呢？

答案當(dāng)然是肯定的，而且這是 OAM 作為 Kubernetes 原生的應(yīng)用定義模型的默認(rèn)能力。

下面，本文就以 Deployment 為例，介紹如何使用 OAM 基于 Kubernetes 的內(nèi)置工作負(fù)載來定義和管理云原生應(yīng)用。

示例準(zhǔn)備

基于 GitHub?FoodTrucks?（舊金山美味街邊小吃地圖應(yīng)用）項(xiàng)目，構(gòu)建鏡像? zzxwill/foodtrucks-web:0.1.1，加上依賴的 Elasticsearch 鏡像，在默認(rèn)情況下，它的 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 中， 一個應(yīng)用是由多個 Component（組件）構(gòu)成的，而一個 Component 里的核心字段，就是 Workload（工作負(fù)載）。

所以說，像 Kubernetes Deployment、StatefulSet 等內(nèi)置的工作負(fù)載，其實(shí)天生就可以被定義為 OAM Component 中的 Workload。比如下面這個?sample-deployment-component.yaml?文件，可以看到，.spec.workload 的內(nèi)容，就是一個 Deployment，也就是 food-truck-deployment.yaml 里定義的 Deployment。

接下來，我們就將上述 OAM? Component 提交到 Kubernetes 集群驗(yàn)證一下。

部署這個應(yīng)用

在 OAM 中，我們需要編寫一個應(yīng)用配置 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 的執(zhí)行情況，會發(fā)現(xiàn)如下報錯：

? 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...

這是因?yàn)?OAM 的 Kubernetes 插件權(quán)限不足導(dǎo)致的，所以不要忘記設(shè)置合理的 ClusterRole 和 ClusterRoleBinding。

提交如下的授權(quán)文件?rbac.yaml，ApplicationConfiguration 可以執(zhí)行成功。

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

繼續(xù)查看 deployments，并設(shè)置端口轉(zhuǎn)發(fā)：

? 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 的工作負(fù)載呢？

其實(shí)，Deployment 和 ContainerizedWorkload 的主要區(qū)別，在于抽象程度不同。

簡單說，如果你的用戶希望看到一個極簡的、沒有一些”亂七八糟“字段的 Deployment 的話；或者，你希望對你的用戶屏蔽掉 Deployment 里面與用戶無關(guān)的字段（比如：不想允許研發(fā)自行設(shè)置 PodSecurityPolicy），那你就應(yīng)該給用戶暴露 ContainerizedWorkload。這時候，這個工作負(fù)載需要的運(yùn)維操作和策略，則是由另一個 OAM 對象 Traits（運(yùn)維特征） 來定義的，比如?ManualScalerTrait。這種“關(guān)注點(diǎn)分離”的做法，也是 OAM 提倡的最佳實(shí)踐。

反之，如果你的用戶對 Deployment 里的各種運(yùn)維、安全相關(guān)的字段并不排斥，你也不需要對用戶屏蔽掉這些字段，那你大可以直接暴露 Deployment 出去。這個工作負(fù)載需要的其他運(yùn)維能力，依然可以通過 OAM Traits 來提供。

為什么使用 OAM Component 來定義應(yīng)用？

你有可能還有另外一個疑問，既然 OAM Component 里面的 Workload 就是 Kubernetes 里的各種 API 對象，那么使用 OAM 模型來定義應(yīng)用又有哪些好處呢？

這就要說到 OAM 帶來的好處了，相信大家在基于 Kubernetes 構(gòu)建應(yīng)用平臺的時候，一定遇到過一系列的難題，比如依賴管理、版本控制、灰度發(fā)布等等，另一方面，應(yīng)用平臺為了跟云資源結(jié)合起來，純粹使用 K8s 原生的 Workload 是做不到的。

而通過 OAM ，你不僅可以將云資源與應(yīng)用統(tǒng)一描述，OAM 實(shí)現(xiàn)框架還將幫你解決了依賴管理、版本控制、灰度發(fā)布等一系列難題。這些我們將在后續(xù)的文章中為大家介紹。

了解更多和貢獻(xiàn)

除了 Deployment 之外，OAM 社區(qū)還有很多 Kubernetes 內(nèi)置工作負(fù)載（比如 StatefulSet）以及阿里巴巴開源工作負(fù)載 OpenKruise 的各種實(shí)例，歡迎查閱和貢獻(xiàn)。

為了深入?yún)⑴c OAM 貢獻(xiàn)，也非常歡迎加入阿里巴巴云原生應(yīng)用平臺團(tuán)隊(duì)。

• 工作職位：Kubernetes/Serverless/PaaS/應(yīng)用交付等領(lǐng)域?qū)＜?#xff08; P7-P8 ）。
• 工作年限：建議 P7 三年起，P8 五年起，具體看實(shí)際能力。
• 工作地點(diǎn)： 國內(nèi)：北京，杭州，深圳；海外：舊金山灣區(qū)、西雅圖
• 崗位包含：架構(gòu)師、技術(shù)專家、全棧工程師等。

簡歷立刻回復(fù)，2~3 周出結(jié)果，簡歷投遞：jianbo.sjb AT alibaba-inc.com

課程推薦

為了更多開發(fā)者能夠享受到 Serverless 帶來的紅利，這一次，我們集結(jié)了 10+ 位阿里巴巴 Serverless 領(lǐng)域技術(shù)專家，打造出最適合開發(fā)者入門的 Serverless 公開課，讓你即學(xué)即用，輕松擁抱云計算的新范式——Serverless。

點(diǎn)擊即可免費(fèi)觀看課程：https://developer.aliyun.com/learning/roadmap/serverless

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的公眾號。”

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的OAM深入解读：使用OAM定义与管理Kubernetes内置Workload的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。