手机网站制作软件,彩票代理平台,江苏工程建设信息网官网,漫画网站怎么做作者 | 周正喜 阿里云技术专家 爱好云原生#xff0c;深度参与 OAM 社区
大家都知道#xff0c;应用开放模型 Open Application Model#xff08;OAM#xff09; 将应用的工作负载#xff08;Workload#xff09;分为三种 —— 核心型、标准型和扩展型#xff0c;这三…
作者 | 周正喜 阿里云技术专家 爱好云原生深度参与 OAM 社区
大家都知道应用开放模型 Open Application ModelOAM 将应用的工作负载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 defaultReason: Encountered an error during resource reconciliation...
这是因为 OAM 的 Kubernetes 插件权限不足导致的所以不要忘记设置合理的 ClusterRole 和 ClusterRoleBinding。
提交如下的授权文件 rbac.yamlApplicationConfiguration 可以执行成功。
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 来提供。
为什么使用 OAM Component 来定义应用
你有可能还有另外一个疑问既然 OAM Component 里面的 Workload 就是 Kubernetes 里的各种 API 对象那么使用 OAM 模型来定义应用又有哪些好处呢
这就要说到 OAM 带来的好处了相信大家在基于 Kubernetes 构建应用平台的时候一定遇到过一系列的难题比如依赖管理、版本控制、灰度发布等等另一方面应用平台为了跟云资源结合起来纯粹使用 K8s 原生的 Workload 是做不到的。
而通过 OAM 你不仅可以将云资源与应用统一描述OAM 实现框架还将帮你解决了依赖管理、版本控制、灰度发布等一系列难题。这些我们将在后续的文章中为大家介绍。
了解更多和贡献
除了 Deployment 之外OAM 社区还有很多 Kubernetes 内置工作负载比如 StatefulSet以及阿里巴巴开源工作负载 OpenKruise 的各种实例欢迎查阅和贡献。
为了深入参与 OAM 贡献也非常欢迎加入阿里巴巴云原生应用平台团队。
工作职位Kubernetes/Serverless/PaaS/应用交付等领域专家 P7-P8 。工作年限建议 P7 三年起P8 五年起具体看实际能力。工作地点 国内北京杭州深圳海外旧金山湾区、西雅图岗位包含架构师、技术专家、全栈工程师等。
简历立刻回复2~3 周出结果简历投递jianbo.sjb AT alibaba-inc.com
课程推荐
为了更多开发者能够享受到 Serverless 带来的红利这一次我们集结了 10 位阿里巴巴 Serverless 领域技术专家打造出最适合开发者入门的 Serverless 公开课让你即学即用轻松拥抱云计算的新范式——Serverless。
点击即可免费观看课程https://developer.aliyun.com/learning/roadmap/serverless “阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践做最懂云原生开发者的公众号。” 原文链接 本文为云栖社区原创内容未经允许不得转载。
