原标题:深度解读!阿里统一应鼡管理架构升级的教训与实践
从 2019 年初开始阿里巴巴云原生应用平台团队开始逐步在整个阿里经济体内,基于标准应用定义与交付模型进荇应用管理产品与项目统一架构升级的技术工作
事实上,早在 2018 年末当 Kubernetes 项目正式成为阿里巴巴的应用基础设施底盘之后,阿里内部以及阿里云产品线在应用管理领域的碎片化问题就开始日渐凸显出来
尤其是在云原生生态日新月异的今天,阿里巴巴与阿里云的应用管理产品架构(包括阿里内部 PaaS 和云上 PaaS 产品)如何以最佳姿态拥抱云原生生态、如何以最高效的技术手段借助生态日新月异的能力构建出更强大嘚 PaaS 服务,而不是重复造轮子甚至和生态“背道而驰”很快就成为了阿里团队亟待解决的重要技术难题。
但棘手的是这个问题并不是简單把 PaaS 迁移或者集成到 Kubernetes 上来就能够解决的:PaaS 与 Kubernetes 之间,从来就没有存在这样一条清晰的分界线可是 Kubernetes 本身又并不是面向最终用户设计的。
如何既让全公司的研发和运维充分享受云原生技术体系革新带来的专注力与生产力提升又能够让现有 PaaS 体系无缝迁移、接入到 Kubernetes 大底盘当中,还偠让新的 PaaS 体系把 Kubernetes 技术与生态的能力和价值最大程度的发挥出来而不是互相“屏蔽”甚至“打架”?这个“既要、又要、还要”的高标准偠求才是解决上述 “Kubernetes vs PaaS”
在 2019 年 10 月,阿里巴巴宣布联合微软共同推出开放应用模型项目(Open Application Model - OAM)正是阿里进行自身应用管理体系标准化与统一架构升级过程中,逐步演进出来的一项关键技术
所谓“应用模型”,其实是一个专门用来对云原生应用本身和它所需运维能力进行定义與描述的标准开源规范所以对于 Kubernetes 来说,OAM 即是一个标准的“应用定义”项目(类比已经不再活跃的 Kubernetes Application CRD 项目)同时也是一个专注于封装、组織和管理 Kubernetes 中各种“运维能力”、以及连接“运维能力”与“应用”的平台层项目。而通过同时提供“定义应用”和“组织管理应用的运维能力”这两大核心功能OAM 项目自然成为了阿里巴巴进行统一应用架构升级和构建下一代 PaaS/Serverless 过程中“当仁不让”的关键路径。
此外OAM 模型并不負责应用和能力的具体实现,从而确保了它们都是由 Kubernetes 本身直接提供的 API 原语和控制器实现所以, OAM 也成为了当前阿里构建 Kubernetes 原生 PaaS 的一项主要手段
在 OAM 中,一个应用程序包含三个核心理念:
- 第一个核心理念是组成应用程序的组件(Component)它可能包含微服务集合、数据库和云负载均衡器;
- 第二个核心理念是描述应用程序运维特征(Trait)的集合,例如弹性伸缩和 Ingress 等功能。它们对应用程序的运行至关重要但在不同环境中其实现方式各不相同;
- 最后,为了将这些描述转化为具体的应用程序运维人员使用应用配置(Application Configuration)来组合组件和相应的特征,以构建应部署的应用程序的具体实例
阿里巴巴在 OAM 这个项目中融入了大量互联网规模场景中管理 Kubernetes 集群和公共云产品方面的实际经验,特别是阿里从原先不计其数的内部应用 CRD 转向基于 OAM 的标准应用定义过程中的诸多收获作为工程师,我们从过去的失败和错误中吸取教训不断开拓创新、發展壮大。
在本文中我们将会详细分享 OAM 项目背后的动机和推动力,希望能够帮助更多人更好地了解这个项目
这是一个典型的 Kubernetes 自定义资源(CRD),可以直接安装使用
但是,当我们把这些功能交付出去应用运维人员开始使用诸如 CronHPA 等自定义插件时,他们很快就遇到麻烦了:
Trait 采用了规范与实现分离的设计同样一个 Trait 的 spec,可以被不同平台不同环境完全基于不同的技术来实现通过引用的方式,实现层既可以对接箌一个已有实现的 CRD也可以对接到一个统一描述的中间层,底下可插拔的对接不同的具体实现考虑到 K8s 中的一个特定的能力比如 Ingress 可能有多達几十种实现,这种规范与实现分离的思想会非常有用Trait 提供了统一的描述,可帮助应用运维人员准确理解和使用能力
在 OAM 中,ApplicationConfiguration 控制器必須保证这些 Trait 之间的兼容性如果不能满足要求,应用的部署就会立刻失败所以,当运维人员将上述 YAML 提交给 Kubernetes 时由于“Trait 冲突”,OAM 控制器将會报告部署失败这就使得应用运维人员能够提前知道有运维能力冲突,而不是在部署失败后大惊失色
总的来说,我们团队不提倡提供冗长的维护规范和运维指南(它们根本无法防止应用运维人员出错)我们倾向于是使用 OAM Trait 来对外暴露基于 Kubernetes 的可发现和可管理的运维能力。這使我们的应用运维人员能够“快速失败”并满怀信心地组合运维能力来构建无冲突的应用运维解决方案,这就像玩“乐高积木”一样簡单
Kubernetes 的 API 对象特性管理器并不关心自己的使用者到底是运维还是研发。这意味着任何人都可能对一个 Kubernetes API 对象特性管理器中的任何字段负责這也称为“all-in-one”的 API,它使得新手很容易上手
但是,当具有不同关注点的多个团队必须在同一个 Kubernetes 集群上展开协作时特别是当应用运维人员囷业务研发人员需要在相同 API 对象特性管理器上展开协作时,all-in-one API 缺点就会凸显出来
- Trait SecurityPolicy —— 供运维人员使用,用于将安全策略规则应用于 Component请注意,运维人员还可以修改 Trait 列表以绑定更多 Trait例如,“Canary Deployment Trait ”意味着这个应用程序在后期升级过程中遵循金丝雀发布策略
实质上,ApplicationConfiguration 的主要功能就是让应用运维人员(或系统)了解和使用业务研发人员传达的信息,然后自由的为 Component 组合绑定不同的运维能力以相应实现其最终的运维目的
综上所述,我们使用 OAM 的主要目标是解决应用程序管理中的以下问题:
- 如何在 Kubernetes 中构建可发现、可组合和可管理的运维能力;
- 如何使 Kubernetes 中嘚多个参与方围绕同一个 API 对象特性管理器准确有效地协作
所以说,对于阿里巴巴来说OAM 其实是阿里巴巴 Kubernetes 团队提出的一种 Application CRD 规范,从而使得所有参与者可以采用结构化的标准方法来定义应用程序及其运维能力
阿里巴巴开发 OAM 的另一个强大动力,则是在混合云和多环境中进行软件分发与交付随着 Google Anthos 和 Microsoft Arc 的出现,我们已然看到 Kubernetes 正成为新的 Android并且云原生生态系统的价值正迅速转移到应用层的趋势。我们将在以后讨论这┅主题
本文中的实际使用案例由阿里云原生团队和蚂蚁金服共同提供。
目前OAM 规范和模型实际已解决许多现有问题,但它的路程才刚刚開始例如,我们正在研究使用 OAM 处理组件依赖关系、在 OAM 中集成 Dapr 工作负载等
我们期待在 OAM 规范及其 K8s 实现方面与社区展开协作。OAM 是一个中立的開源项目其所有贡献者都应遵循非营利性基金会的 CLA。
目前阿里巴巴团队正在上游贡献和维护这套技术,如果大家有什么问题或者反馈也非常欢迎与我们在上游或者钉钉联系。
本文为阿里云内容未经允许不得转载。