本文讲的是Kubernetes服务目录的设计【编者的话】OpenShift 3.6新版本包括新的服务目录和服务中介技术预演版。它们是基于Kubernetes的孵化项目Kubernetes Service Catalog project。服务目录通过Open Service Broker API集成服务中介，由服务中介管理服务的创建和管理；这篇文章将深入介绍服务目录的设计。
【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开，具体内容包括：持续集成与持续交付（CI/CD）概览；持续集成系统介绍；客户端与服务端的 CI/CD 实践；开发流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及实践经验分享等。
服务目录是基于Kubernetes的Open Service Broker API实现。 它包括如下功能：
这种底层机制允许在Kubernetes中运行的应用程序与它们使用的服务之间松耦合。 服务中介是一个黑盒实体，可以运行在Kubernetes外。 服务中介允许应用专注于自己的业务逻辑，将服务的管理交给服务中介。
本文档不会详细介绍OSB API的工作原理，相关信息请参阅： Open Service Broker API 。 本文的其余部分假设读者熟悉OSB API规范的基本概念。
请注意，该项目的当前状态并不完全支持设计中所述的所有内容，但我们从目标开始，然后指出当前项目状态，通过 [DIFF] 标记不同。
作为服务目录的核心，与Kubernetes核心一样，它是一个API服务器和一个控制器。 API服务器是用于存储组件HTTP（REST）RESTful的前端。系统的用户及系统的其他组件与API服务器进行交互，以便在服务目录资源模型上执行CRUD类型的操作。与Kubernetes本身一样，kubectl命令行工具可用于与服务目录资源模型进行交互。
服务目录API服务器后面的存储组件可以是 etcd 或 第三方资源 （TPRs）。 rest.storage接口抽象正在使用的特定持久存储设备。当使用etcd时，etcd的实例将与Kubernetes的etcd实例不同，这意味着，服务目录将具有与Kubernetes不同的持久存储。当使用TPRs时，这些资源将被存储在Kubernetes中，因此不需要单独的持久存储。
[DIFF] 到目前为止，API服务器只能使用etcd作为其持久存储。在不久的将来，API服务器的rest.storage接口将添加对TPRs的支持。
服务目录资源模型在pkg/apis/servicecatalog/types.go的文件中定义，模型的初始（当前）版本在pkg/apis/servicecatalog/v1alpha1/中。到目前为止，只有一个版本的模型，但随着时间的推移，将会创建其他版本，每个版本都将有自己的pkg/apis/servicecatalog /的子目录中。
控制器是服务目录的大脑。它监视资源模型（通过API服务器上watches接口），并根据其检测到的更改采取适当的操作。
要了解服务目录资源模型，最好通过一个典型的工作流程：
broker.yaml内容如下：
创建中介资源后，服务目录控制器将收到数据存储区添加资源的事件。然后，控制器将查询服务中介（指定的URL）以获取可用服务列表。然后，每个服务都将创建一个相应的服务资源：
请注意，每个服务可以有一个或多个与之相关联的计划。
用户可以查询可用服务列表：
instance.yaml内容如下：
在实例资源内可以指定使用的计划。允许用户指定他们想使用的服务的变体 - 可能是基于QoS的服务类型变体。
一旦Instance资源被创建，控制器会与指定的服务中介协商来创建一个所需服务的新的实例。
有两种创建方式： 同步和异步 。
对于同步操作，向服务中介发出请求，并且在成功完成请求（200 OK）后，服务实例可以被应用使用。
一些服务中介支持异步方式。当控制器向服务中介发出create/update/deprovision请求时，服务中介以202 ACCEPTED响应，并提供GET请求端点：GET /v2/service_instances/<service_instance_id>/last_operation，控制器可以轮询请求状态。
服务中介为每个last_operation请求发送返回一个last_operation字段。轮询请求的状态为“in_progress”时，控制器将继续轮询。控制器会考虑轮询请求的最大超时，并将停止轮询并将创建标记为失败。
虽然服务实例正在进行异步操作，但控制器必须确保没有其他操作（提供，取消，更新，绑定，取消绑定）。
binding.yaml内容如下所示：
控制器，接到新的Binding资源通知后，将与服务中介通信，为指定的服务实例创建一个新的绑定。从服务中介返回的Binding对象中有一组凭据。这些凭据包含应用程序与服务实例通信所需的所有信息。例如，它可能包括以下内容：
OSB API规范不要求在凭据中显示什么属性，因此需要应用了解返回的指定数据以及如何正确使用它们。这通常通过阅读服务的文档来完成。
凭证不会存储在服务目录的数据存储中。相反，它们将作为秘密存储在Kubenetes中，并且将Secret的引用保存在Binding资源中。如果未指定Binding的Spec.SecretName，则控制器将使用Binding Name属性作为Secret的名称。
绑定不需要与服务实例位于相同的Kubenetes命名空间中。允许跨应用和命名空间共享服务实例。
除了Secret之外，控制器还将在Kubernetes中创建一个 Pod注入策略（PIP） 资源。有关更多信息，请参阅PIP提案，但简而言之，PIP定义了在创建Pod时如何修改Pod的规范以包含其他卷和环境变量。特别地，服务目录将使用PIPs来允许应用程序所有者指示Secret应该如何提供给其Pods。例如，他们可以定义一个PIP来指示Secret安装到Pod中。或者Secret的名称/值应该被暴露为环境变量。
PIP将使用标签选择器来指示哪些Pod将被修改。例如：
定义一个PIP，添加一个名为DB_PORT的环境变量，值为6379，所有具有Role标签的Pods都具有此前端值。
最终，OSB API规范将希望有关于凭证的额外元数据，以指出哪些字段被认为是“Secret”，哪些不是。当该支持可用时，期望将非Secret信息放入ConfigMap而取代Secret。
一旦Secret提供给应用Pods中，那么应用代码就可以使用该信息与服务实例进行通信。
删除绑定也将自动删除与之相关联的Secret或ConfigMaps。
不同的方面：
原文链接：Design of the Service Catalog（翻译：范彬）
===============================================================
【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开，具体内容包括：持续集成与持续交付（CI/CD）概览；持续集成系统介绍；客户端与服务端的 CI/CD 实践；开发流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及实践经验分享等。
服务目录是基于Kubernetes的Open Service Broker API实现。 它包括如下功能：
- 服务中介注册到Kubernetes上；
- 服务中介指定一组服务（或这些服务的变体），提供给Kubernetes用户；
- Kubernetes用户可以发现可用的服务；
- Kubernetes用户可以请求新的服务实例；
- Kubernetes用户可以链接服务实例到一组Pods上；
这种底层机制允许在Kubernetes中运行的应用程序与它们使用的服务之间松耦合。 服务中介是一个黑盒实体，可以运行在Kubernetes外。 服务中介允许应用专注于自己的业务逻辑，将服务的管理交给服务中介。
术语
- 应用（Application）：服务目录中的服务与Kubernetes中的“服务”是不同的。为避免混淆，我们使用“应用”表示Kubernetes的服务实例；
- 绑定或服务绑定（Binding）：服务实例和应用之间的链接。它表示应用引用和使用特定服务实例的意图；
- 中介或服务中介（Broker）：一个实体，用于管理一组或多个服务，可以通过网络端点访问服务中介；
- 凭证（Credentials）：应用与服务实例通信所需的信息；
- 实例或服务实例（Instance）：服务的实现称为服务实例；
- 服务类或服务（Service Class）：服务中介提供的一种服务类型；
- 计划或服务计划（Plan）：服务类型的变体。例如，服务可以暴露一组计划，它们提供不同程度的服务质量（QoS）；
Open Service Broker API
服务目录是 Open Service Broker API （OSB API）的兼容实现。 OSB API规范是 Cloud Foundry Service Broker API 的演进。本文档不会详细介绍OSB API的工作原理，相关信息请参阅： Open Service Broker API 。 本文的其余部分假设读者熟悉OSB API规范的基本概念。
服务目录设计
服务目录的设计如下图所示：
请注意，该项目的当前状态并不完全支持设计中所述的所有内容，但我们从目标开始，然后指出当前项目状态，通过 [DIFF] 标记不同。
作为服务目录的核心，与Kubernetes核心一样，它是一个API服务器和一个控制器。 API服务器是用于存储组件HTTP（REST）RESTful的前端。系统的用户及系统的其他组件与API服务器进行交互，以便在服务目录资源模型上执行CRUD类型的操作。与Kubernetes本身一样，kubectl命令行工具可用于与服务目录资源模型进行交互。
服务目录API服务器后面的存储组件可以是 etcd 或 第三方资源 （TPRs）。 rest.storage接口抽象正在使用的特定持久存储设备。当使用etcd时，etcd的实例将与Kubernetes的etcd实例不同，这意味着，服务目录将具有与Kubernetes不同的持久存储。当使用TPRs时，这些资源将被存储在Kubernetes中，因此不需要单独的持久存储。
[DIFF] 到目前为止，API服务器只能使用etcd作为其持久存储。在不久的将来，API服务器的rest.storage接口将添加对TPRs的支持。
服务目录资源模型在pkg/apis/servicecatalog/types.go的文件中定义，模型的初始（当前）版本在pkg/apis/servicecatalog/v1alpha1/中。到目前为止，只有一个版本的模型，但随着时间的推移，将会创建其他版本，每个版本都将有自己的pkg/apis/servicecatalog /的子目录中。
控制器是服务目录的大脑。它监视资源模型（通过API服务器上watches接口），并根据其检测到的更改采取适当的操作。
要了解服务目录资源模型，最好通过一个典型的工作流程：
服务中介注册
在应用使用服务之前，服务中介首先向Kubernetes平台注册。服务中介管理服务，我们首先通过创建Broker实例来注册服务中介：broker.yaml内容如下：
创建中介资源后，服务目录控制器将收到数据存储区添加资源的事件。然后，控制器将查询服务中介（指定的URL）以获取可用服务列表。然后，每个服务都将创建一个相应的服务资源：
请注意，每个服务可以有一个或多个与之相关联的计划。
用户可以查询可用服务列表：
创建服务实例
在使用服务之前，必须创建一个新的实例。创建一个新的Instance资源：instance.yaml内容如下：
在实例资源内可以指定使用的计划。允许用户指定他们想使用的服务的变体 - 可能是基于QoS的服务类型变体。
一旦Instance资源被创建，控制器会与指定的服务中介协商来创建一个所需服务的新的实例。
有两种创建方式： 同步和异步 。
对于同步操作，向服务中介发出请求，并且在成功完成请求（200 OK）后，服务实例可以被应用使用。
一些服务中介支持异步方式。当控制器向服务中介发出create/update/deprovision请求时，服务中介以202 ACCEPTED响应，并提供GET请求端点：GET /v2/service_instances/<service_instance_id>/last_operation，控制器可以轮询请求状态。
服务中介为每个last_operation请求发送返回一个last_operation字段。轮询请求的状态为“in_progress”时，控制器将继续轮询。控制器会考虑轮询请求的最大超时，并将停止轮询并将创建标记为失败。
虽然服务实例正在进行异步操作，但控制器必须确保没有其他操作（提供，取消，更新，绑定，取消绑定）。
使用服务实例
在使用服务实例之前，必须将其绑定到应用程序。这意味着应用和服务实例之间的链接或使用意图必须建立。创建一个新的Binding资源：binding.yaml内容如下所示：
控制器，接到新的Binding资源通知后，将与服务中介通信，为指定的服务实例创建一个新的绑定。从服务中介返回的Binding对象中有一组凭据。这些凭据包含应用程序与服务实例通信所需的所有信息。例如，它可能包括以下内容：
- 服务实例的URL
- 用户ID和密码来访问服务实例
OSB API规范不要求在凭据中显示什么属性，因此需要应用了解返回的指定数据以及如何正确使用它们。这通常通过阅读服务的文档来完成。
凭证不会存储在服务目录的数据存储中。相反，它们将作为秘密存储在Kubenetes中，并且将Secret的引用保存在Binding资源中。如果未指定Binding的Spec.SecretName，则控制器将使用Binding Name属性作为Secret的名称。
绑定不需要与服务实例位于相同的Kubenetes命名空间中。允许跨应用和命名空间共享服务实例。
除了Secret之外，控制器还将在Kubernetes中创建一个 Pod注入策略（PIP） 资源。有关更多信息，请参阅PIP提案，但简而言之，PIP定义了在创建Pod时如何修改Pod的规范以包含其他卷和环境变量。特别地，服务目录将使用PIPs来允许应用程序所有者指示Secret应该如何提供给其Pods。例如，他们可以定义一个PIP来指示Secret安装到Pod中。或者Secret的名称/值应该被暴露为环境变量。
PIP将使用标签选择器来指示哪些Pod将被修改。例如：
定义一个PIP，添加一个名为DB_PORT的环境变量，值为6379，所有具有Role标签的Pods都具有此前端值。
最终，OSB API规范将希望有关于凭证的额外元数据，以指出哪些字段被认为是“Secret”，哪些不是。当该支持可用时，期望将非Secret信息放入ConfigMap而取代Secret。
一旦Secret提供给应用Pods中，那么应用代码就可以使用该信息与服务实例进行通信。
删除服务实例
与Kubernetes中的资源一样，可以通过对资源执行HTTP DELETE来删除服务目录资源。 但是，请注意，有相关的绑定存在时，服务实例不能被删除。 换句话说，在删除服务实例之前，必须先删除其所有绑定。 删除具有绑定的实例将失败并产生错误。删除绑定也将自动删除与之相关联的Secret或ConfigMaps。
当前设计
上述各节描述了服务目录的当前设计。 但是，有些尚未到位，代码不一定与之对齐。 目前的设计实际上更像是这样：
不同的方面：
- API服务器只能使用etcd作为其持久存储。
- API服务器没有连接到控制器，这意味着它并没有被实际作为运行系统的一部分。 只是通过与API服务器通信完成资源的创建和存储。
- 可以使用Kubernetes的API服务器创建服务目录资源的TPRs版本是当前系统的工作方式。 然后，控制器将与Kubernetes中API服务器进行通信，并监视服务目录资源的TPRs版本，采取一切适当的措施。
原文链接：Design of the Service Catalog（翻译：范彬）
===============================================================
译者介绍：范彬，从事微服务、Docker和Kubernetes容器技术等方面的工作。可以关注译者的微信公众号：范范米饭。
原文发布时间为：2017-08-15
本文作者：范彬
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：Kubernetes服务目录的设计
