Service Catalog与Kubernetes-InfoQ



 写点什么

云原生应用程序除了可以部署在 Kubernetes 中，还可以使用云托管服务。与 Kubernetes 的声明性对象配置模型类似，带有 Service Catalog 的 Open Service Broker API 提供了一种声明性的方式来描述跨平台或跨云的托管服务依赖项。

关键要点

Kubernetes 的声明性对象配置模型是编配器最有趣的功能之一。
Kubernetes 的用户通常需要在他们的应用程序中使用云托管服务。
Service Catalog 是一个声明性的 Kubernetes API 扩展，用于发现和使用云托管服务。
Service Catalog 实现了 Open Service Broker API，这是一个用于定义服务的标准规范。
Azure、AWS 和 GCP 都为自己的服务提供了 Service Broker 实现。

在过去几年中，“云原生基础设施”和“云原生应用程序”这两个术语被广泛用于描述一种新的软件范式，这种范式专注于某种基础设施和应用程序的设计、实现和部署，认为它们将会使用由公有云或私有云供应商提供的各种技术。这些应用程序通常遵循微服务架构，可以打包成容器，并使用云供应商提供的一些托管服务，如对象存储、数据库或发布和订阅队列。

随着越来越多的应用程序被打包成容器，需要使用编配器来部署它们。Kubernetes 迅速成为这个云原生领域中最受欢迎的容器编配器之一。

Kubernetes 之所以能够取得成功，其中一个因素要归功于它的声明性对象配置模型。在这个模型中，开发人员或者集群管理员使用 Kubernetes 对象描述来描述他们希望在集群中看到的状态，Kubernetes 将执行所需的操作，以便从当前状态转移到预期状态。这不同于通过向 Kubernetes API 发送命令动作来告诉它该做什么。如果 Kubernetes 出现故障，它会进行“自我治愈”（例如 pod 崩溃）。Kubernetes 将意识到当前状态与预期状态不一致，就会执行所需的操作来返回到预期状态。

不过，部署在 Kubernetes 上的云原生应用程序将从使用云托管服务中受益。有了云托管服务，开发人员就可以专注于能够提供业务价值的应用程序领域，并充分利用云供应商提供的基础设施组件。在将 Kubernetes 服务与云托管服务相结合时，最好要保持相同的声明性模型，并能够将完整的应用程序（包括它所依赖的服务）描述为一组 Kubernetes 对象。

自启动 Kubernetes 项目以来，社区一直在寻找这种跨平台/跨云的解决方案。Open Service Broker API 和 Service Catalog 是采用最为广泛的解决方案之一。

Open Service Broker API 和 Service Catalog

Open Service Broker API（OSBAPI）是一种标准规范，云供应商用它来定义服务并提供访问和管理这些服务的通用 API。OSBAPI 最初是为 Cloud Foundry 而定义的，但很快由 Kubernetes 和 Openshift 项目提供支持，目前由一个项目委员会进行维护，委员会成员来自不同的公司。Service Catalog是一个实现了这个标准的 Kubernetes API 扩展，目前是一个 Kubernetes 孵化器项目，目前的 API 版本为 v1beta1。

Service Catalog API 定义了一组类来描述服务提供者及其提供的各种服务。它还定义了一些对象，用于将 Kubernetes 应用程序连接到不同服务实例。

Service Broker

这个对象定义了一个服务提供者。Service Catalog 只定义 Kubernetes 对象，而不是代理本身的实现，后者取决于服务提供者。对象的定义只需要提供一个与代理进行通信的端点和一些连接到端点 URL 的授权信息。

Service Class

这个对象抽象出服务的概念。例如，如果 Azure 代理被部署在集群中，Azure MySQL 就成为一个 Service Class。Service Broker 将为集群用户提供一到多个这种类。

Service Plan

公共云供应商提供的服务通常有几层。例如，有些层可以包含只配备一个 CPU 核心和 1GB RAM 的小型实例（适合用于开发和测试），和配备了四个内核和 16GB 内存的大实例（适用于生产环境）。每个 Service Class 都有一个或多个 Service Plan。

Service Instance

当一个应用程序需要特定服务（数据库、对象存储等）时，它可以通过创建 Service Instance 对象从 Service Broker 请求特定的 Service Plan 实例。然后，Service Catalog 控制器将与 Service Broker 端点通信，以便配置新的服务实例。

Service Binding

这个对象抽象了将应用程序连接到 Service Instance 的操作。在请求 Service Binding 时，Service Broker 将返回一个新的 Service Binding 和一个 Kubernetes Secret，其中包含了连接信息，应用程序可以使用这些信息连接到所请求的服务。

当前状态

Service Catalog 是一个 Kubernetes 孵化器项目，目前版本为 0.1.38，API 版本为 v1beta1。从这些版本号可以看出这个项目还不稳定，目前由Kubernetes特别兴趣小组（SIG）负责管理。项目仍处在开发阶段，项目提供的 Kubernetes 控制器尚未稳定，经常发生崩溃，导致 API 服务器处于不容易恢复的状态。

在启动 Service Catalog 项目时，Kubernetes 还没有定制资源定义（Custom Resource Definitions，CRD）的概念，这是一种无需编写自己的 API 服务器就可以扩展 Kubernetes API 的方法。相反，Service Catalog 实现了聚合的 API 服务器，需要从头开始编写一个 API 服务器并维护代码。使用 CRD 将允许 Service Catalog 只拥有控制器实现，并从通用 API 机制和 CRD 工具的改进中获益。目前，Service Catalog SIG 正在内部讨论是否要在 API 推出稳定版之前将项目迁移到 CRD。

Service Catalog 获得了来自 Azure、IBM、谷歌和其他组织的支持。除了为核心项目做出贡献外，一些主要的公共云还遵循 Open Service Broker API 为其云服务实现了 Service Broker：

Azure。Azure 维护了一个用于 Kubernetes 的 Service Broker，直接作为服务运行在 Kubernetes 集群上。它的维护很活跃，并提供了良好的文档。它支持多种 Azure 服务，从数据库到物联网事件中心。
GCP。谷歌为 GCP 服务提供了自己的 Service Broker 实现。这个文档提供了一组入门示例。
AWS。Amazon Web Services 提供与 Kubernetes、Openshift 和 Cloud Foundry 兼容的 AWS Service Broker。因为实现还很新，所以还没有很详细的文档。

未来和替代方案

Open Service Broker API/Service Catalog 有可能会成为一个得到良好支持的标准，用于从 Kubernetes 部署多云服务，遵循具有 Kubernetes API 扩展的声明性模型。OSBAPI 由独立的项目管理委员会管理，Service Catalog 项目由 SIG（Kubernetes 项目的一部分）管理，并从 IBM、Azure、谷歌和其他组织的开发人员那里获得支持。尽管如此，自首次发布以来已经过去了一年半，但尚未得到广泛采用，所以社区要努力克服这些限制。

Service Catalog 目前不适用于真正的多云解决方案，其中一个原因是连接服务的方式取决于 Service Broker 和特定服务的实现。例如，绑定 Azure MySQL 实例时创建的秘钥 schema 与绑定 Google Cloud SQL 实例时创建的秘钥 schema 不同。由于这两种 schema 不一样，开发人员将无法让应用程序连接到通用的 Service Catalog MySQL 实例（并决定以后使用哪个云），或者无法轻松地从一个云迁移到另一个云而无需重写 Kubernetes 的 manifest。在意识到这些限制后，SIG 小组（定义如何在 Kubernetes 中部署和管理应用程序的小组）提出了一个叫作“Portable Service Definitions”的 Kubernetes 增强建议（KEP）。这个 KEP 试图提供一种方法来定义请求外部服务（例如 MySQL 数据库）的常用方法。这个定义对于任意 MySQL 服务来说都是通用的，不需要考虑是哪个云提供的服务。有了这个功能，开发人员在开发应用程序时只需要知道它需要外部的 MySQL 实例，但不需要事先知道是哪些云会提供这些服务。

另一个问题是 Service Catalog API 服务器及其控制器的稳定性。如前所述，API 服务器及其控制器目前相当不稳定。Service Catalog 社区正在讨论是否要转向 CRD，这可能会进一步延迟稳定版本的发布，因为它几乎需要完全重写。然而，从长远来看，这样做是有益的，因为 Kubernetes 在 CRD 以及与之相关的工具上投入越来越多。

Service Broker 的不同实现（每个都由不同的开发人员开发和管理）也使得开发人员很难在不了解每个代理及其不同的实现和文档的情况下使用它们。Kubernetes 以外的一些社区正在创建具有类似目标的项目：提供声明性 API 来请求和管理 Kubernetes 之外的服务。其中的一个项目Crossplane提供了一个通用的 API，在不需要考虑服务提供者的情况下向服务发出请求。开发人员可以将他们的应用程序定义为需要某种服务，而不需要知道是哪个云提供该服务。在将一个或多个云供应商部署到集群中时，这将由集群管理员来决定。