云计算-云原生OAM概念

OAM

OAM,open application model是阿里巴巴和微软共同开发的云原生应用规范模型。它使用来解决一个完整的面向业务场景的应用的问题。是一个标准的、基础设施 无关的跨云应用部署模型。有以下几个特性：

• 应用为先。一个应用的交付与部署应该是自包含的，其中的各类操作行为应该作为应用定义的一部分，这些内容与实际基础设施无关。
• 清晰和可扩展性。定义一套开放标准，可以模块化整个应用交付流程，根据个 人需要将这些模块自由组装，达成自己想要的结果。
• 云服务供应商无关。定义的开放标准应该是一套更高级别的抽象，可以跨本地 集群、跨云服务供应商，不会被锁定到任何一个厂商的底座

OAM规范遵循以下原则

• 关注点分离：根据功能和行为来定义模型，以此划分不同角色的职责，
• 平台中立：OAM 的实现不绑定到特定平台；
• 优雅：尽量减少设计复杂性；
• 复用性：可移植性好，同一个应用程序可以在不同的平台上不加改动地执行；
• 不作为编程模型：OAM 提供的是应用程序模型，描述了应用程序的组成和组件的拓扑结构，而不关注应用程序的具体实现。

OAM的基本对象

• Component：OAM 中最基础的对象，该配置与基础设施无关，定义负载实例的运维特性。例如一个微服务 workload 的定义。
• TraitDefinition：一个组件所需的运维策略与配置，例如环境变量、Ingress、AutoScaler、Volume 等。(注意：该对象在 apiVersion: core.oam.dev/v1alpha1 中的名称为 Trait)。
• ScopeDefinition：多个 Component 的共同边界。可以根据组件的特性或者作用域来划分 Scope，一个 Component 可能同时属于多个 Scope。
• ApplicationConfiguration：将 Component(必须)、Trait(必须)、Scope(非必须)等组合到一起形成一个完整的应用配置。

OAM的工作原理

OAM Spec 定义了云原生应用的规范(使用一些 CRD 定义)， KubeVela 可以看做是 OAM 规范的解析器，将应用定义翻译为 Kubernetes 中的资源对象。可以将上图分为三个层次：

• 汇编层：即人工或者使用工具来根据 OAM 规范定义汇编出一个云原生应用的定义，其中包含了该应用的工作负载和运维能力配置。
• 转义层：汇编好的文件将打包为 YAML 文件，由 KubeVela 或其他 OAM 的实现将其转义为 Kubernetes 或其他云服务(例如 Istio)上可运行的资源对象。
• 执行层：执行经过转义好的云平台上的资源对象并执行资源配置。

参考管官网

•  OAM 官方网站 - oam.dev

kubevela

OAM应用，主要通过kubevela项目来实现

kubevela项目地址  模块定义(Definition) | KubeVela

核心概念

KubeVela 是一个开箱即用的现代化应用交付与管理平台，它使得应用在面向混合云环境中的交付更简单、快捷。使用 KubeVela 的软件开发团队，可以按需使用云原生能力构建应用，随着团队规模的发展、业务场景的变化扩展其功能，一次构建应用，随处运行。

KubeVela 的核心是将应用部署所需的所有组件和各项运维动作，描述为一个统一的、与基础设施无关的“部署计划”，进而实现在混合环境中标准化和高效率的应用交付。这使得最终用户无需关注底层细节，就可以使用丰富的扩展能力，并基于统一的概念自助式操作。

每一个应用部署计划都由四个部分组成，分别是组件，运维能力，部署策略和工作流

登录后复制

apiVersion: core.oam.dev/v1beta1 kind: Application metadata:   name: <name> spec:   components:     - name: <component name>       type: <component type>       properties:         <parameter values>       traits:         - type: <trait type>           properties:             <traits parameter values>     - name: <component name>       type: <component type>       properties:         <parameter values>   policies:   - name: <policy name>     type: <policy type>     properties:       <policy parameter values>   workflow:     - name: <step name>       type: <step type>       properties:         <step parameter values>   

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.
• 20.
• 21.
• 22.
• 23.
• 24.
• 25.
• 26.
• 27.
• 28.

这个 Application 对象会引用 component、trait、policy 以及 workflow step 的类型，这些类型背后是平台构建者(运维团队)维护的可编程模块。可以看到，这种抽象的方式是高度可扩展、可定制的。

• 组件(Component): 组件定义一个应用包含的待交付制品(二进制、Docker 镜像、Helm Chart...)或云服务。我们认为一个应用部署计划部署的是一个微服务单元，里面主要包含一个核心的用于频繁迭代的服务，以及一组服务所依赖的中间件集合(包含数据库、缓存、云服务等)，一个应用中包含的组件数量应该控制在约 15 个以内。
• 运维特征(Trait): 运维特征是可以随时绑定给待部署组件的、模块化、可拔插的运维能力，比如：副本数调整(手动、自动)、数据持久化、 设置网关策略、自动设置 DNS 解析等。
• 应用策略(Policy): 应用策略负责定义指定应用交付过程中的策略，比如多集群部署的差异化配置、资源放置策略、安全组策略、防火墙规则、SLO 目标等。
• 工作流步骤(Workflow Step): 工作流由多个步骤组成，允许用户自定义应用在某个环境的交付过程。典型的工作流步骤包括人工审核、数据传递、多集群发布、通知等。

基于k8s安装

要求，

• Kubernetes cluster >= v1.19 && <= v1.26

登录后复制

curl-fsSl https://kubevela.io/script/install.sh | bash vela install

• 1.
• 2.

VelaUX 是 KubeVela 的仪表板。 它是在你的集群中运行的 Web 应用程序。 你可以使用浏览器访问它。 如果你不使用 KubeVela 的 UI 控制台，这是可选的

部署应用

在k8s上部署应用举例

登录后复制

apiVersion: core.oam.dev/v1beta1 kind: Application metadata:   name: app-with-k8s-objects   namespace: default spec:   components:     - name: k8s-demo-service       properties:         objects:           - apiVersion: apps/v1             kind: Deployment             metadata:               name: nginx             spec:               replicas: 2               selector:                 matchLabels:                   app: nginx               strategy:                 type: Recreate               template:                 metadata:                   labels:                     app: nginx                 spec:                   containers:                     - image: nginx                       name: nginx                       ports:                         - containerPort: 80           - apiVersion: v1             kind: Service             metadata:               annotations:                 service.beta.kubernetes.io/aws-load-balancer-type: nlb               labels:                 app: nginx               name: nginx               namespace: default             spec:               externalTrafficPolicy: Local               ports:                 - name: http                   port: 80                   protocol: TCP                   targetPort: 80               selector:                 app: nginx               type: LoadBalancer       type: k8s-objects   policies:     - name: topology-default       type: topology       properties:         clusters: ['local']         namespace: default     - name: topology-production       type: topology       properties:         clusters: ['local']         namespace: production   workflow:     steps:       - name: deploy2default         properties:           policies: ['topology-default']         type: deploy       - name: suspend         type: suspend       - name: deploy2production         properties:           policies: ['topology-production']         type: deploy

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.
• 20.
• 21.
• 22.
• 23.
• 24.
• 25.
• 26.
• 27.
• 28.
• 29.
• 30.
• 31.
• 32.
• 33.
• 34.
• 35.
• 36.
• 37.
• 38.
• 39.
• 40.
• 41.
• 42.
• 43.
• 44.
• 45.
• 46.
• 47.
• 48.
• 49.
• 50.
• 51.
• 52.
• 53.
• 54.
• 55.
• 56.
• 57.
• 58.
• 59.
• 60.
• 61.
• 62.
• 63.
• 64.
• 65.
• 66.
• 67.
• 68.
• 69.
• 70.
• 71.
• 72.
• 73.
• 74.

登录后复制

#部署应用 $ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml  #执行审核 $ vela workflow resume app-with-k8s-objects 

• 1.
• 2.
• 3.
• 4.
• 5.

这里没有使用 velaux 插件，而是是在商业k8s平台上可以更加简洁直观的看到OAM状态

总结

OAM是一种全新的K8S业务交付方式，但是目前还不上主流，目前应用的不多