云原生应用程序除了可以部署在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，在不需要考虑服务提供者的情况下向服务发出请求。开发人员可以将他们的应用程序定义为需要某种服务，而不需要知道是哪个云提供该服务。在将一个或多个云供应商部署到集群中时，这将由集群管理员来决定。

结论

Kubernetes中的Service Catalog需要克服当前的一些限制才能被广泛应用于生产环境。与此同时，Kubernetes社区内外也在创建其他项目，作为Service Catalog和Open Service Broker API的补充或竞争对手。

关于作者

Ara Pulido是一名工程经理，拥有10年多与开源公司一起工作的经验。目前，她负责管理Bitnami的Kubernetes和站点可靠性工程（SRE）团队。她是经过认证的Kubernetes管理员。

查看英文原文：https://www.infoq.com/articles/service-catalog-kubernetes

创作场景

Service Catalog 与 Kubernetes