OAM 创始团队：揭秘 OAM Kubernetes 实现核心原理
最新回答
沉醉不知归路
2026-10-22 09:53:18
OAM（Open Application Model）创始团队由阿里云和微软的专家组成，其 Kubernetes 实现核心原理是通过关注点分离的模型，提供标准化的应用定义与运维能力描述，实现应用在 Kubernetes 上的标准化交付与管理。
一、OAM 的起源与创始团队- 起源背景应用容器技术革新了软件打包与分发方式，但 Kubernetes 缺乏“应用”层面的抽象，仅提供“工作负载”原语（如 Deployment），导致云原生应用管理生态碎片化、学习门槛高。OAM 的诞生旨在解决“Kubernetes 里到底什么是应用”的问题。
- 创始团队由阿里云高级技术专家 Andy Shi 和技术专家 孙健波（天元） 与微软共同发起，联合 Crossplane 社区开发了 OAM 在 Kubernetes 上的标准实现。
- 角色划分
业务研发人员：定义和维护应用组件（Component），描述服务单元（如 PHP 容器、数据库实例）。
运维人员：定义运维特征（Trait），附加到组件上（如水平扩展策略 HPA）。
基础设施工程师：扩展工作负载类型（如 FaaS）或运维特性（如 CronHPA）。
- 协作流程组件与运维特征组合成 ApplicationConfiguration，作为 OAM 的可交付物，通过 Kubernetes 落实诉求。
- 应用组成OAM 将应用视为组件集合，包括：
组件：独立的服务单元（如容器、云服务）。
运维策略：如自动扩展、负载均衡等。
依赖关系：组件间的连接与交互。
- 示例一个电商网站应用可能包含 PHP 容器、数据库实例，以及 HPA 策略。
- 核心依赖库三方合作开发了 oam-kubernetes-runtime，作为 OAM 官方维护的基础组件，提供稳定的核心插件。
- 实现方式OAM 以原生插件形式运行在 Kubernetes 中，通过自定义资源（CRD）扩展 API，管理应用交付流程。
- 抽象层级提升业务研发人员无需关注底层资源（如声明式 API、控制器），直接操作高阶应用定义。
- 统一管理体验屏蔽基础设施差异，提供一致的云、边、端应用交付体验。
- 无缝接入云原生生态支持 Operator、FaaS 等云原生技术，避免传统 PaaS 的封闭性。
- 组件市场形成模块化 Workload 和 Trait 可灵活组合，形成可复用的组件市场。
- 平台无关性符合 OAM 规范的应用描述可在任何 Kubernetes 集群、Serverless 平台或边缘环境运行，无需修改。
- 标准化迁移现有平台可通过 API 对象灰度纳管，逐步迁移至 OAM 模型。
- 角色分离明确开发、运维、基础设施角色职责，简化流程管理。
- 统一应用交付如 Crossplane 项目通过 OAM 化，实现应用在混合云中的无缝迁移。
- 云服务管理能力标准化结合 Crossplane 的云服务抽象，OAM 统一了应用与云服务的定义。
- 社区活跃度
贡献者来自 AWS、腾讯、字节跳动等企业，社区 Issue/PR 参与度高。
阿里云 EDAS 等云服务已基于 OAM 实现内部标准化。
- 版本迭代
当前版本为 v1alpha2，计划发布 Beta 版，根据用户反馈持续演进。
- 国际化运作
通过社区会议、Gitter 讨论、开源实现地址（如 GitHub）推动协作。
核心 Maintainer 来自阿里云、微软和 Crossplane 项目。
- 资源链接Gitter 讨论室OAM 开源实现地址点击 Star 支持项目
- Andy Shi阿里云高级技术专家，阿里巴巴集团开发者布道师，专注云平台与网络基础架构。
- 孙健波（天元）阿里云技术专家，OAM 规范主要制定者之一，推动云原生应用标准化。
热门标签
