阿里巴巴如何改善开发人员在K8s上的体验？

做者：邓洪超  阿里巴巴应用交付专家

前言

经过 K8s，用户可以自定义基础设施，能够平行的替换或改造平台的已有功能，而非只能局限在平台提供的能力之上构建。但正是这样的“白盒化”体验，正在为愈来愈多的研发和运维带来“太复杂”的困扰。

从 Kubernetes 到“以应用为中心”的美好将来之间，全世界的 PaaS 工程师其实都在期待一项全新的技术可以弥补这之间的鸿沟。阿里云原生应用平台团队的作法是，经过为应用“建模”的方式来解决这个问题，这也正是Open Application Model (OAM) 开源项目得以建立的重要目的。

阿里巴巴的容器化之旅

阿里巴巴的容器化之旅始于 2013 年。在 Docker 诞生以前，阿里巴巴基于 lxc 的容器引擎研发了容器技术 T4，用于在裸机上部署和管理应用程序。

2017 年, 阿里巴巴内部孵化了相似于 K8s 的容器编排引擎 Sigma 做为资源统一层，用于管理内部机器池，平均利用率达到 40％。

2018 年，Sigma 从新设计并迁移成兼容 K8s API，阿里巴巴从新编写了自定义控制器和调度算法，并向暴露声明式 API 给用户试用。

2019 年末，阿里巴巴中的大多数应用都在 K8s 上运行，而且在 K8s 之上构建了数十个原生框架，构筑 K8s 生态系统。而 2019 年的 双11 活动不只仅是商业上的成功，更是 K8s 基础设施能够支持如此大规模的有力证实。

在解决了 K8s 中的规模化和稳定性问题以后，咱们开始面临一个新的挑战：K8s API 过于复杂，开发人员很难学习。

致使 K8s API 复杂的 3 个缘由

K8s API 之因此复杂，主要有如下三个主要缘由：

1. K8s 缺少以“应用”为中心的资源模型 

K8s 中没有“应用”的概念，只有松散耦合的基础架构资源。部署应用须要编写 Pod、设置网络和存储之类的基础设施资源，很是底层。然而，对于开发人员来讲，他们不想配置这些复杂的底层资源信息，他们想从开发层面指定应用部署规范，例如具备自动扩容、监控、Ingress 等功能的无状态服务组件。咱们须要提供更高层级的应用层抽象和以应用程序为中心的资源模型，以弥合部署应用程序和配置之间的差距。

2. K8s API 中没有分离开发和运维的关注点

其次，K8s API  中没有分离开发和运维的关注点。从上图能够看出，K8s 将全部属于不一样角色的字段封装在一个 API 中。例如，开发人员仅需指定容器映像、端口和运行情况检查；运维人员则负责配置副本大小、滚动更新策略、存储卷访问模式等。

对于 K8s API 来讲这样的声明是没有问题的。K8s 意在公开基础架构功能，并用于构建其余平台。所以，它须要包含全部内容，并提供多合一的 API。可是，咱们发现多合一 API 不适合写应用程序的终端用户。在 K8s API 之上，咱们须要区分角色、将开发和运维的关注点分离开。

3. 在 K8s 上没有可移植的应用抽象定义

K8s 定义了使用基础资源的标准方法。可是如上所述，部署应用程序须要网络接入、监控、日志等。咱们须要对那些应用程序操做接口进行标准化，实现可移植的应用层抽象。

OAM 开启下一代云原生 DevOps 技术革命

针对上述 K8s API 过于复杂、开发人员难学习的问题，这里来介绍一下由阿里巴巴联合微软在社区推出的用于构建和交付云原生应用的标准规范 -- 开放应用程序模型 OAM（Open Application Model）。

2019 年 10 月，阿里巴巴宣布联合微软共同推出开放应用模型项目（Open Application Model - OAM）。

所谓“应用模型”，实际上是一个专门用来对云原生应用自己和它所需运维能力进行定义与描述的标准开源规范。因此对于 Kubernetes 来讲，OAM 便是一个标准的“应用定义”项目（类比已经再也不活跃的 Kubernetes Application CRD 项目），同时也是一个专一于封装、组织和管理 Kubernetes 中各类“运维能力”、以及链接“运维能力”与“应用”的平台层项目。

在 OAM 中，一个应用程序包含三个核心理念：
第一个核心理念是组成应用程序的服务组件（Component），它包含微服务、数据库、云服务等；
第二个核心理念是描述应用程序运维特征（Trait）的集合，例如，弹性伸缩和 Ingress 等功能。它们对应用程序的运行相当重要，但在不一样环境中其实现方式各不相同；
最后，为了将这些描述转化为具体的应用实例，运维人员使用应用配置（Application Configuration）来组合组件和相应的特征，以构建可部署的应用交付实例。

如上图所示，咱们能够看到开发人员定义了组件 (Component) 来描述服务单元。而后运维人员定义运维特征 (Trait)，并将其附加到前面的组件上，最后构成 OAM 可交付物 -- ApplicationConfiguration。在图中最下方，底层的基础设施资源将经过 OAM 平台呈现。

那么 OAM 如何解决上述三个 Kuberntes API 的问题？首先，OAM 隐藏了底层基础架构细节（例如，是云仍是物联网），专一于应用层抽象，提供以应用为中心的资源模型。其次，OAM 划分了应用交付路径上的开发、运维、基础架构三种角色，分离了关注点，让流程更加清晰和易于管理。第三，K8s 定义了基础架构的可移植抽象，而 OAM 站在 K8s 的肩膀上，提供了可移植的应用层抽象，让同一个应用能够跨平台运行。

OAM 还定义了一组核心工做负载/运维特征/应用范畴，做为应用程序交付平台的基石。而且，这些核心规范有一个开源实现 -- Crossplane。Crossplane 提供了让用户扩展其功能的机制。例如 Crossplane core 提供的 ContainerizedWorkload，在容器中运行应用程序并管理应用程序的生命周期。
此外，咱们还能够添加更多工做负载（例如 FaaS）以运行无服务器功能，或者添加运维特性（例如 CronHPA）来定义 CronJob 类型的 HPA 策略。OAM 以标准的声明方式在单个平台中管理应用交付能力和流程。当模块化的 Workload 和 Trait 愈来愈多，就会造成组件市场。而 OAM 就像是这个组件市场的管理者，处理组件之间的关系，把许多组件集成起来变成一个产品交付给用户。OAM 加持下的 PaaS，能够像乐高积木同样灵活组装底层能力、运维特征、以及开发组件。使得应用管理变得统一，功能却更增强大！

结语

以上咱们讨论了 OAM 的背景、动机和架构细节。值得注意的是，OAM 项目是开源中立、由社区驱动的。该规范和实现获得包括 Alibaba、Microsoft、Upbound 在内的开放社区的支持。咱们欢迎更多的人参与其中，共同定义云原生应用交付的将来。