Kubernetes服务目录的设计

【编者的话】OpenShift 3.6新版本包括新的服务目录和服务中介技术预演版。它们是基于Kubernetes的孵化项目Kubernetes Service Catalog project。服务目录通过Open Service Broker API集成服务中介,由服务中介管理服务的创建和管理;这篇文章将深入介绍服务目录的设计。

服务目录是基于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规范的基本概念。

服务目录设计

服务目录的设计如下图所示:

Kubernetes服务目录的设计_第1张图片

请注意,该项目的当前状态并不完全支持设计中所述的所有内容,但我们从目标开始,然后指出当前项目状态,通过[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实例来注册服务中介:

kubectl create -f broker.yaml 

broker.yaml内容如下:

apiVersion: servicecatalog.k8s.io/v1alpha1 
kind: Broker 
metadata:   
name: BestDataBase 
spec:   
url: http://bestdatabase.com 

创建中介资源后,服务目录控制器将收到数据存储区添加资源的事件。然后,控制器将查询服务中介(指定的URL)以获取可用服务列表。然后,每个服务都将创建一个相应的服务资源:

apiVersion: servicecatalog.k8s.io/v1alpha1 
kind: ServiceClass 
metadata:   
name: smallDB   
brokerName: BestDataBase   
plans... 

请注意,每个服务可以有一个或多个与之相关联的计划。

用户可以查询可用服务列表:

kubectl get services 

创建服务实例

在使用服务之前,必须创建一个新的实例。创建一个新的Instance资源:

kubectl create -f instance.yaml

instance.yaml内容如下:

apiVersion: servicecatalog.k8s.io/v1alpha1 
kind: Instance 
metadata:   
name: johnsDB 
spec:   
serviceClassName: smallDB 

在实例资源内可以指定使用的计划。允许用户指定他们想使用的服务的变体 – 可能是基于QoS的服务类型变体。

一旦Instance资源被创建,控制器会与指定的服务中介协商来创建一个所需服务的新的实例。

有两种创建方式:同步和异步。

对于同步操作,向服务中介发出请求,并且在成功完成请求(200 OK)后,服务实例可以被应用使用。

一些服务中介支持异步方式。当控制器向服务中介发出create/update/deprovision请求时,服务中介以202 ACCEPTED响应,并提供GET请求端点:GET /v2/service_instances//last_operation,控制器可以轮询请求状态。

服务中介为每个last_operation请求发送返回一个last_operation字段。轮询请求的状态为“in_progress”时,控制器将继续轮询。控制器会考虑轮询请求的最大超时,并将停止轮询并将创建标记为失败。

虽然服务实例正在进行异步操作,但控制器必须确保没有其他操作(提供,取消,更新,绑定,取消绑定)。

使用服务实例

在使用服务实例之前,必须将其绑定到应用程序。这意味着应用和服务实例之间的链接或使用意图必须建立。创建一个新的Binding资源:

kubectl create -f binding.yaml 

binding.yaml内容如下所示:

apiVersion: servicecatalog.k8s.io/v1alpha1 
kind: Binding 
metadata:   
name: johnsBinding 
spec:   
secretName: johnSecret   
...Pod selector labels... 

控制器,接到新的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将被修改。例如:

kind: PodInjectionPolicy 
apiVersion: extensions/v1alpha1 
metadata:   
name: allow-database   
namespace: myns 
spec:   
selector:     
matchLabels:      
  role: frontend   
env:     
- name: DB_PORT       
  value: 6379 

定义一个PIP,添加一个名为DB_PORT的环境变量,值为6379,所有具有Role标签的Pods都具有此前端值。

最终,OSB API规范将希望有关于凭证的额外元数据,以指出哪些字段被认为是“Secret”,哪些不是。当该支持可用时,期望将非Secret信息放入ConfigMap而取代Secret。

一旦Secret提供给应用Pods中,那么应用代码就可以使用该信息与服务实例进行通信。

删除服务实例

与Kubernetes中的资源一样,可以通过对资源执行HTTP DELETE来删除服务目录资源。 但是,请注意,有相关的绑定存在时,服务实例不能被删除。 换句话说,在删除服务实例之前,必须先删除其所有绑定。 删除具有绑定的实例将失败并产生错误。

删除绑定也将自动删除与之相关联的Secret或ConfigMaps。

当前设计

上述各节描述了服务目录的当前设计。 但是,有些尚未到位,代码不一定与之对齐。 目前的设计实际上更像是这样:

Kubernetes服务目录的设计_第2张图片

不同的方面:

  • API服务器只能使用etcd作为其持久存储。
  • API服务器没有连接到控制器,这意味着它并没有被实际作为运行系统的一部分。 只是通过与API服务器通信完成资源的创建和存储。
  • 可以使用Kubernetes的API服务器创建服务目录资源的TPRs版本是当前系统的工作方式。 然后,控制器将与Kubernetes中API服务器进行通信,并监视服务目录资源的TPRs版本,采取一切适当的措施。

译者介绍:范彬,从事微服务、Docker和Kubernetes容器技术等方面的工作。可以关注译者的微信公众号:范范米饭。

Kubernetes服务目录的设计

你可能感兴趣的:(kubernetes)