温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

Kubernetes实践中OAM应用为中心的解决方案

发布时间:2021-12-06 10:35:11 来源:亿速云 阅读:187 作者:柒染 栏目:大数据

本篇文章为大家展示了Kubernetes实践中OAM应用为中心的解决方案,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。

OAM 模型的价值

针对上述用户的诉求,我们一个个来看 OAM 是如何满足的,同时也能看出 OAM 在其中发挥的价值。

云原生化

  • OAM 应用定义是声明式的,即面向终态的,它的格式与 K8s 的 API 一致,可以与 K8s 的 CRD 无缝对接,直接作为 Custom Resource 的 Object 部署到 K8s;

  • OAM 应用定义是自包含的,通过 OAM 定义的描述可以找到包含一个应用生命周期中方方面面所有的信息。

如下图所示,你可以看到运行 OAM 的一个应用配置,使用 K8s 的 API spec,完整包含了一个应用方方面面的资源。

Kubernetes实践中OAM应用为中心的解决方案

平台无关、运行时无关

OAM 应用定义并不限定你底层的平台和实际运行时,你完全可以运行在 K8s 以外的平台,不管是 ECS、Docker、又或是 FaaS (Serverless),自然也不存在厂商锁定的问题。如果你的应用满足 Serverless 的条件,那么针对该应用的 OAM 描述,天然就可以运行在支持 OAM 规范的 Serverless 运行时。
Kubernetes实践中OAM应用为中心的解决方案

在支持 OAM 的不同环境中,你便可以使用统一的应用描述,打造无差别的应用交付。就如下图所示,对应用户,他们只要描述统一的应用配置,便可以在不同的环境达到一致的应用体验。

OAM(Open Application Model) 正是这样一个以应用为中心的 K8s API 分层模型:

  • 从研发的角度,他操作和关注的 API 对象叫 Component;

  • 从运维的角度,模块化的运维能力封装就是 Trait,而运维可以通过 App Config 将 Component 和 Trait 自由组合,最终实例化成一个运行的应用;

  • K8s 团队本身则仍然基于 K8s 的原生 API 迭代这一层能力。

Kubernetes实践中OAM应用为中心的解决方案

针对研发时常抱怨的 K8s API 太复杂,我们通过关注点分离,区分使用者面对的 API 来解决,同时提供了几种核心的 Workload,让研发只需要填写少数几个字段就可以完成组件的定义;针对复杂应用定义,我们通过扩展的 Workload,允许研发对接 CRD Operator 的方式对接自定义 Workload。

针对运维需要的模块化封装运维能力和全局管理的需求,OAM 模型通过 Trait 来提供。

Trait 是运维能力的体现,不同的 Trait 也对应了不同类型的运维能力,如日志收集 Trait、负载均衡 Trait、水平扩缩容 Trait 等等;同时 OAM 本身就提供了一个全局管理的标准,OAM 模型的实现层可以轻松针对 OAM 定义里的种种 Trait 描述进行管理和检查。

针对云资源,OAM 向上也提供了统一的 API,也是通过关注点分为三类:

  • 一类是研发关注的云资源,如数据库 RDS、对象存储 OSS 等,通过扩展 Workload 接入;

  • 另一类是运维关注的云资源,如负载均衡 SLB 等,通过 Trait 接入;

  • 最后一类也是运维关注的云资源,但是可能包含多个应用之间的联动关系,如虚拟专有网络 VPC 等,通过应用的 Scope 接入。Scope 则是 OAM 中管理多应用联动关系的概念。

可以看到,OAM 通过统一的一套标准,解决了我们今天提到的所有难题。让我们继续深入到 OAM 中看看不同的概念具体是什么。

上述内容就是Kubernetes实践中OAM应用为中心的解决方案,你们学到知识或技能了吗?如果还想学到更多技能或者丰富自己的知识储备,欢迎关注亿速云行业资讯频道。

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI