使用 Crossplane 构建自己的 PaaS：Kubernetes、OAM 和核心工作流

本文要点

• 很多企业想要构建自己的云平台，通常由内部基础设施和云供应商组成。

• 尽管 Kubernetes 没有提供完整的开箱即用的平台即服务（PaaS）体验，但其定义良好的 API、清晰的抽象和全面的扩展点让它成为完美的基础组件。

• Crossplane 是一个开源的云控制平面，工程师可以直接用它来管理基于从 Kubernetes 的基础设施和云服务。这个控制平面为用户交互提供了单个入口点，可以在其中执行策略，应用防护和审计。

• 可以使用 k8s 的资源定义（CRD）和 YAML 来配置基础设施，也可以通过完善的工具（如 kubectl）或 Kubernetes API 本身来管理基础设施，并遵循一些工作流最佳实践（如 GitOps）。

• 开放应用模型（Open Application Model，OAM）规范描述了一种模型，它定义了核心软件交付角色，并规定了明确的职责范围：​​开发人员、应用程序运维人员和基础设施运维人员。Crossplane 是 Kubernetes 规范的实现。

最近，InfoQ 采访了 Upbound 创始人兼首席执行官 Bassam Tabbara，讨论了如何构建跨多个云供应商和内部基础设施的应用程序平台。

采访从探讨企业在平台上部署应用程序开始。目前，Kubernetes 是很多“云原生”平台的基础。尽管 Kubernetes 并未提供完整的开箱即用的平台即服务（PaaS）体验，但其定义良好的 API、清晰的抽象和全面的扩展点让它成为完美的基础组件。

Tabbara 还讨论了Crossplane，这是一个开源项目，工程师可以直接用它来管理基于 Kubernetes 的基础设施和云服务。这种“跨多云控制平面”是基于 Kubernetes 的声明式配置原语构建的，工程师可以自定义基础设施，以便利用已有的 k8s 工具链。采访内容还涵盖了开放应用模型（OAM），并探讨了 Crossplane 如何成为以团队为中心的标准的 Kubernetes 实现。

每个工程团队都需要一个平台

很多企业想要构建自己的云平台，通常由内部基础设施和云供应商组成。这些企业的领导者认识到，最小化部署摩擦并减少应用程序的交付时间，同时又能提供安全性，可以提升竞争优势。这些团队还认识到，成功的企业通常都需要将现有的“遗留”应用程序和基础设施包含在平台中。很多公司还希望支持多个公共云供应商，目标是避免被锁定、套利成本或实施灾难恢复策略。

企业内的平台团队通常希望为应用程序开发人员和运维人员提供自助服务，但他们也希望平台保持适当的安全性、合规性和监管能力。所有的大型公共云供应商，例如 Amazon Web Service（AWS）、Microsoft Azure 和 Google Cloud Platform（GCP）都通过控制平面提供服务。控制平面由用户界面（UI）、命令行接口（CLI）和应用程序编程接口（API）组成，平台团队和运维人员用它们来配置和部署基础设施服务的基础“数据平面”。尽管云控制平面的实现通常是分布式的，但对于最终用户来说是集中式的。控制平面为用户交互提供了单个入口点，可以在其中执行策略，应用防护和审计。

应用程序开发人员通常希望获得类似平台即服务（PaaS）的体验来定义和部署应用程序，就像Zimki、Heroku和Cloud Foundry之类的开创者一样。通过简单的“git push heroku master”命令来部署应用程序是一种功能强大且毫不​​费力的方法。应用程序运维人员和站点可靠性工程（SRE）团队希望能够轻松地组装、运行和维护应用程序及其配置。

Tabbara 说，这些需要企业购买 PaaS，如果选择不当，其维护成本可能会很高：

“现代商业 PaaS 通常可以满足企业 80％的场景需求，这意味着基础设施团队必须创建额外的平台资源来满足其他 20％的需求。”

构建 PaaS 风格的体验

构建 PaaS 平台并不容易，它需要时间和技能，而且定义和实现满足所有相关角色要求的技术是一项巨大的挑战。谷歌的内部平台有数千名训练有素的工程师，Netflix 拥有庞大的专家团队，他们专注于内部 PaaS 的创建和维护，甚至连 Shopify 这种规模较小的公司也有专门的平台团队。技术抽象的范围很广，从“最低公分母”(Libcloud 和 OpenStack 所采用的)一直到提供通用工作流程和完整的云特定配置（HashiCorp Terraform 或 Pulumi）。传统 PaaS 抽象在云领域也很常见，但通常是特定于供应商，例如 GCP App Engine，AWS Elastic Beanstalk 或 Azure Service Fabric。

很多企业选择 Kubernetes 作为构建平台的基础。但是，正如 Tabbara 在 Twitter 上指出的那样，这可能需要大量的前期投入，再加上 80％的应用场景挑战，可能会陷入“PaaS困境”：

“PaaS 的困境——你的 PaaS 完成了我想要的 80％，而我的 PaaS 花费了 80％的时间来维护 Kubernetes”。

Tabbara 表示，开源 Crossplane 项目旨在成为一种通用的多云控制平面，用于构建定制的 PaaS 体验。

Crossplane 是“跨”云“控制平面”的融合。我们想用一个名词来命名这个实体，它负责连接不同云提供商，并充当跨云控制平面。“cross”表示“跨云”，“plane”表示“控制平面”。

在 Kubernetes 风格原语基础上构建配置，并提供现成的基础设施组件和用于共享其他资源的注册表，减轻了基础设施和应用程序运维人员的负担。另外，通过提供封装了关键基础设施抽象的 API，可以将平台运维人员（在“API 层”之下工作的人）与应用程序开发人员和运维人员（在“ API 层”之上工作的人）之间的关注点分开。

“开发人员可以定义工作负载，不需要担心实现细节、环境约束或策略。由管理员来定义环境细节和策略。这可以实现更高的可重用性，并降低复杂性。”

Crossplane：通过 Kubernetes 来控制基础设施

Crossplane 作为一个 Kubernetes附加组件，通过提供和管理云基础设施、服务和应用程序来扩展集群能力。Crossplane 使用 Kubernetes 风格的声明式和 API 驱动式配置来控制本地或云端的基础设施。通过这种方式，我们可以使用自定义资源定义（CRD）和 YAML 来配置基础设施，还可以通过完善的工具（如 kubectl）或 Kubernetes API 本身来实现管理。Kubernetes 还允许使用RBAC或策略来定义安全控制（使用开放策略代理，OPA）。

作为 Crossplane 的一部分，可以配置一个 Kubernetes 资源控制器负责管理资源的生命周期：配置、健康检查、伸缩、故障转移，并主动对偏离配置的外部变更做出响应。Crossplane 与持续交付（CD）管道集成在一起，因此应用程序基础设施配置存储在单个控制集群中。团队可以使用GitOps等云原生 CD 最佳实践来创建、跟踪和批准变更。Crossplane 让应用程序和基础设施配置可以共存于同一个 Kubernetes 集群中，从而降低了工具链和部署管道的复杂性。

清晰的抽象、角色使用以及“上下分界线”方法很大程度上借鉴了开放应用模型的原理。

OAM：以团队为中心构建云原生应用程序的标准

开放式应用程序模型（OAM）规范最初由微软、阿里巴巴和 Upbound 创建，它描述了一种模型，开发人员负责定义应用程序组件，应用程序运维人员负责创建这些组件的实例并为其分配应用程序配置，而基础设施运维人员则负责声明、安装和维护平台上可用的基础服务。Crossplane 是 Kubernetes 规范的实现。

借助 OAM，平台构建者可以通过“组件”、“特征”和“范围”的格式提供可重复使用的模块。平台可以将它们打包在预定义的应用程序配置文件中。用户可以通过选择配置文件来选择如何运行应用程序，例如，具有高 SLO 的微服务应用程序、具有持久卷的有状态应用程序或具有水平自动伸缩功能的事件驱动功能。

OAM规范文档提供了一个案例，探讨了典型的应用程序交付生命周期。

1. 开发人员创建一个 Web 应用程序；

2. 应用程序运维人员将部署该应用程序的实例，并为其配置属性，例如自动缩放；

3. 基础设施运维人员决定使用哪种基础技术进行部署和运维。

为了交付应用程序，应用程序开发人员将程序的每个单独组件描述为 Component YAML。该文件封装了工作负载以及运行它所需的信息。

在应用程序运维方面，应用程序运维人员为开发人员的组件设置参数值，并在 ApplicationConfiguration YAML 中配置属性，例如副本大小、自动伸缩策略、入口点和流量路由规则。在 OAM 中，这些属性被称为特征。编写和部署 ApplicationConfiguration 等效于部署应用程序。底层平台将为已经定义好的工作负载创建实时实例，并根据 ApplicationConfiguration 规范将配置属性附加到工作负载上。

基础设施运维人员负责声明、安装和维护平台上可用的基础服务。例如，基础设施运维人员可能会在公开服务时选择特定的负载均衡器或者可确保数据是全局加密的自定义数据库配置。

一个典型的 Crossplane 工作流

为了更加具体一点，我们来看一个典型的 Crossplane 工作流程——从项目的安装到使用。

首先，安装Crossplane，并创建一个 Kubernetes 集群。 接下来，安装 Provider 并配置凭据。基础设施原语可以来自任意一个供应商，例如 GCP、AWS、Azure、阿里巴巴和自定义本地部署。

平台运维人员使用声明性 YAML 定义、组合和发布自己的基础设施资源，从而将自己的基础设施 CRD 添加到 Kubernetes API 中，供应用程序使用。

应用程序开发人员发布应用程序组件，应用服务及其基础设施的基本、建议或可选属性。

应用程序运维人员将基础设施组件和应用程序组件、规范配置联系在一起，然后运行应用程序。

结论

Kubernetes 被作为很多“云原生”平台的基础，因此，对于企业来说，在团队与平台交互方式以及如何组装基础组件这两方面的投入是至关重要的。正如 Nicole Forsgren 博士等人所说的那样，最小化交付周期（从构想到产生价值）和提高部署频率与搞绩效的组织息息相关。平台在这里起着至关重要的作用。

Crossplane 是一个不断发展的项目，随着社区的扩展，正在寻求越来越多的反馈。工程团队可以访问Crossplane网站开始使用这个开源项目，并在 Crossplane Slack 中提供反馈。

作者介绍：

Daniel Bryant 在 Datawire 担任产品架构师，在 InfoQ 担任新闻板块经理，并在 QCon London 担任主席。他目前的技术专长集中在“DevOps”工具、云/容器平台和微服务实现。Daniel 是伦敦 Java 社区（LJC）的负责人，为多个开源项目做出了贡献，为 InfoQ、O’Reilly 和 DZone 等知名技术网站撰写文章，并定期在 QCon、JavaOne 和 Devoxx 等国际技术大会上演讲。

原文链接：

Build Your Own PaaS with Crossplane: Kubernetes, OAM, and Core Workflows