OAM 的全称为开放应用模型(Open Application Model),由阿里巴巴宣布联合微软共同推出。
OAM 本质是为了解耦K8S中现存的形形色色的资源,让每个角色的关注点更为集中和专注。
举个例子,我们在生产环境中部署了Deployment资源,其中容器的image,健康检查,资源请求开发人员一般会了然于胸,但涉及到Pod副本数、PV、PVC、网络带宽、网络策略、对外负载配置等,一般的开发人员根本无从下手。
为什么会无从下手?原因很简单,正常的开发人员根本不会有这些内容的权限,而且绝大部分开发人员没有公司资源的监控数据,无法对应用所使用的资源进行平衡。最简单的情况,如果开放了CPU、内存、共享存储大小、网络带宽的上限配置,我相信很多人一上来就设置为8C,16GB,100GB,100MB这样奢侈配置,实际的集群资源能支持几个这样的应用呢?
所以这类的事情更适合应用运维人员去做,当然应用运维的人员也需要一定的水准。应用运维人员可以根据监控和告警按需的对CPU、内存、共享存储、网络等资源进行弹性伸缩,甚至可以从监控数据中发现一定的规律配置自动的程序来进行自动扩缩容,例如HPA、CronHPA。
在 OAM 体系中大致分了三个角色,分别为:
各个角色之间的服务关系为:基础设施运维人员 < 应用运维人员 < 业务研发人员。
与角色对应的也同样的有三个核心内容,分别为:
OAM 从资源角度上就隔离了不同角色所关心的内容,而不再将这些内容混杂在一起。 整体示意图如下:
由于OAM是一个新的概念,所以社区的文档目前比较混乱,下面列出还在活动并在维护的几个仓库。
截至目前的版本
https://github.com/oam-dev/spec
支持的OAM规范:1.0.0-alpha2 https://github.com/crossplane/oam-kubernetes-runtime
可以理解为非OAM Runtime必须实现的OAM插件和扩展 https://github.com/oam-dev/catalog
该库提供了以下内容:
这边列出一些容易被误导的仓库,大家遇到了可以跳过查阅,避免绕弯路。
实现了 OAM 规范 1.0.0-alpha1 https://github.com/oam-dev/rudr
被 oam-kubernetes-runtime 替代 https://github.com/crossplane/addon-oam-kubernetes-local
helm repo add oam https://github.com/oam-dev/crossplane-oam-sample/tree/master/archives/
kubectl create namespace oam-system
helm install crossplane --namespace oam-system oam/crossplane-oam
# sample_application_config.yaml
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
name: example-component
spec:
workload:
apiVersion: core.oam.dev/v1alpha2
kind: ContainerizedWorkload
spec:
containers:
- name: my-nginx
image: nginx:1.16.1
resources:
limits:
memory: "200Mi"
ports:
- containerPort: 4848
protocol: "TCP"
env:
- name: WORDPRESS_DB_PASSWORD
value: ""
parameters:
- name: instance-name
required: true
fieldPaths:
- metadata.name
- name: image
fieldPaths:
- spec.containers[0].image
---
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
name: example-appconfig
spec:
components:
- componentName: example-component
parameterValues:
- name: instance-name
value: example-appconfig-workload
- name: image
value: nginx:latest
traits:
- trait:
apiVersion: core.oam.dev/v1alpha2
kind: ManualScalerTrait
metadata:
name: example-appconfig-trait
spec:
replicaCount: 3
$ kubectl apply -f samples/sample_application_config.yaml
component.core.oam.dev/example-component created
applicationconfiguration.core.oam.dev/example-appconfig created
$ kubectl get manualscalertraits.core.oam.dev
NAME AGE
example-appconfig-trait 4s
$ kubectl get containerizedworkloads.core.oam.dev
NAME AGE
example-appconfig-workload 58s
$ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
example-appconfig-workload-deployment 3/3 3 3 114s
可以看到,通过Component和Trait、ApplicationConfiguration的抽象,开发人员和运维人员所关心的内容不再混合在一起,变得更为清晰。
受限于篇幅的原因,本文简单介绍了 OAM 概念并实践了一个简单的基于 OAM 概念的应用程序样本,还没有完全发挥 OAM 的能力。 下一节将会详解如何一步一步使用kubebuilder为OAM添加一个基于Cron表达式定时伸缩的Train。
小伙伴们可以前往:https://github.com/oam-dev/catalog/pull/44 查看该 Train 的 PR 情况。 CronHPATrain 目前已被 oam-dev catalog 接收并合并。