Kubernetes实践中OAM应用为中心的解决方案
本篇文章为大家展示了Kubernetes实践中OAM应用为中心的解决方案，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。
OAM 模型的价值
针对上述用户的诉求，我们一个个来看 OAM 是如何满足的，同时也能看出 OAM 在其中发挥的价值。
云原生化
OAM 应用定义是声明式的，即面向终态的，它的格式与 K8s 的 API 一致，可以与 K8s 的 CRD 无缝对接，直接作为 Custom Resource 的 Object 部署到 K8s；
OAM 应用定义是自包含的，通过 OAM 定义的描述可以找到包含一个应用生命周期中方方面面所有的信息。
如下图所示，你可以看到运行 OAM 的一个应用配置，使用 K8s 的 API spec，完整包含了一个应用方方面面的资源。
平台无关、运行时无关
OAM 应用定义并不限定你底层的平台和实际运行时，你完全可以运行在 K8s 以外的平台，不管是 ECS、Docker、又或是 FaaS (Serverless)，自然也不存在厂商锁定的问题。如果你的应用满足 Serverless 的条件，那么针对该应用的 OAM 描述，天然就可以运行在支持 OAM 规范的 Serverless 运行时。
在支持 OAM 的不同环境中，你便可以使用统一的应用描述，打造无差别的应用交付。就如下图所示，对应用户，他们只要描述统一的应用配置，便可以在不同的环境达到一致的应用体验。
OAM(Open Application Model) 正是这样一个以应用为中心的 K8s API 分层模型：
从研发的角度，他操作和关注的 API 对象叫 Component；
从运维的角度，模块化的运维能力封装就是 Trait，而运维可以通过 App Config 将 Component 和 Trait 自由组合，最终实例化成一个运行的应用；
K8s 团队本身则仍然基于 K8s 的原生 API 迭代这一层能力。
针对研发时常抱怨的 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应用为中心的解决方案，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注行业资讯频道。
