PaaS平台的服务目录(二): Service Catalog in K8S/OpenShift Origin

Service Catalog(服务目录)是Kubernetes社区的孵化项目Kubernetes Service Catalog Project,旨在接入和管理第三方提供的Service Broker,使kubernetes上托管的应用可以使用service broker所代理的外部服务。

本文将介绍Service Catalog的架构以及如何在OpenShift Origin环境中部署和使用Service Catalog。


Service Catalog技术原理

Service Catalog项目是基于k8s的OSB API实现,为k8s提供了如下功能:

- 注册第三方提供的Service Broker到k8s

- 将Service Broker所代理的服务(或者服务的变体),提供给k8s的用户

- k8s用户可以发现可用的服务

- k8s用户可以请求创建新的服务实例

- k8s用户可以将服务实例绑定到一组pod上面

Service Catalog的架构如下所示:

图1

Service Catalog由API Server和Controller这两个基本的组件构成,设计上与K8S的其它组件是类似的:

- API Server,API Server是用于存储组件的HTTP RESTFul前端,用户与Controller通过与API Server交互来完成对Service Catalog资源的GRUD操作;例如,用户在命令行执行kubectl get clusterservicebroker时,就是通过Service Catalog API server来获取ClusterServiceBroker资源的列表;API Server后端的存储目前只支持etcd,但是在设计上是完全解耦的,API Server的rest.storage接口抽象未来会添加对第三方资源(TPRs)的支持(Github Issues);

- Controller,Controller实现了Service Catalog的行为,它监控API资源的变化(通过不断watch来自API server的事件流),并采取相应的动作使API资源的当前状态与用户期望的最终状态相一致;例如,当用户创建一个ClusterServiceBroker资源时,API Server将在Etcd里存入一个资源并产生一个事件,然后Controller将接受这个事件并从该资源所指向的Service Broker中请求Catalog信息;

Service Catalog为k8s增加了如下的API Resources:

- ClusterServiceBroker, 代表Service Broker,封装了broker的连接信息

- ClusterServiceClass, 代表特定Service Broker所提供的服务;当增加一个新的ClusterServiceBroker资源到集群时,service catalog的controller会连接Service Broker并获取可用服务的列表

- ClusterServicePlan,代表服务的套餐,其定义了服务的SLA,一个服务可以有多个套餐;当增加一个ClusterServiceBroker资源到集群时,service catalog会创建一个ClusterServicePlan资源来适配对应的每一个服务的所有可用服务套餐(Service Plan)

- ServiceInstance,代表一个服务实例;当一个ServiceInstance资源被创建时,Service Catalog Controller会连接对应的Service Broker并命令broker去创建一个新的服务实例

- ServiceBinding,代表服务实例与应用(Application)的一次绑定;创建之后,Service Catalog Controller会创建一个包含服务实例的连接与认证信息的Kubernetes Secret,并挂载到应用的pod上

Service Catalog的API Resources与Application及Service Broker的关系见下图:

图2

OpenShift Origin从3.6版本开始提供Service Catalog的Technical Preview版本(对应k8s 1.6.3上的alpha版本), 用户可以在自己的PaaS环境中试用Service Catalog特性。

下面将以OpenShift Origin 3.6为基础,讨论如何使用Service Catalog。


在OpenShift Origin环境启用Service Catalog

OpenShift Origin3.6的默认部署不会启用Service Catalog,需要用户在部署集群时在OpenShift Origin的Ansible hosts文件里进行显式指定,具体配置(写在在[OSEv3:vars]下面)如下:

openshift_enable_service_catalog=true openshift_service_catalog_image_prefix=openshift/origin- openshift_service_catalog_image_version=v3.6.0

集群部署完成之后,可以在OpenShift Origin Console上看到Service Catalog页面,里面列出了即集群中所有Service Broker所提供的所有服务的图标(启用Service Catalog之后,OpenShift Origin会默认启动由OpenShift官方提供Template Service Broker,它提供了一些诸如.NET/Ruby/Python运行时环境,Redis, MongoDB之类的通用服务):

图3(可以看到OC的页面提示Technical Preview Enable)

对于已经部署好的OpenShift集群,可以修改hosts文件之后重新执行ansible-playbook命令开启Service Catalog。


通过Service Catalog管理外部服务

在OpenShift 3.6中,可以通过oc create命令创建Service Catalog相关的资源:

- 创建service broker

oc create -f ./broker.yml

Service Broker的资源定义模版如下:

apiVersion: servicecatalog.k8s.io/v1alpha1

kind: Broker

metadata:

  name: <broker name> //Service Broker的名字

spec:

  url: <broker URL> //Service Broker的endpoint, catalog通过它来连接Service Broker

  authInfo:

    basicAuthSecret:

      kind: Secret

      namespace: <namespace name> //添加Service Broker的namespace

      name: <secret name> //存储Service Broker认证信息的k8s secret name

- 查看已经注册的service broker

图4

添加Service Broker之后就可以在OpenShift Origin Console的Service Catalog页面(参见图3)看到新注册的Service Broker所提供的服务的图标;也可以在后台用oc命令(oc get serviceclass)查看新注册的Service Broker所提供的服务的列表。

- 创建服务实例

oc create -f ./instance.yml

Service Instance的资源定义模版如下:

apiVersion: servicecatalog.k8s.io/v1alpha1

kind: Instance

metadata:

  name: <service instance name> //创建的Service Instance名称

  namespace: <namespace name> //创建Service Instance的namespace

spec:

  serviceClassName: <service class name> //Service Instance的服务名,即创建的是何种服务的实例

  planName: <service plan name> //服务的套餐名,规定了服务实例的SLA

  parameters:

    xxx: xxx  //传给Service Broker的provision参数列表

- 查看服务实例

图5

- 绑定服务实例

oc create -f ./binding.yml

Service binding的资源定义模版如下:

apiVersion: servicecatalog.k8s.io/v1alpha1

kind: Binding

metadata:

    name: <binding name> //绑定名

spec:

    instanceRef:

        name: <service instance name> //服务实例名

    secretName: <secret name> //存储服务实例连接和认证信息的k8s secret名

    labels:

        app: <application name> //需要绑定服务实例的应用名

    parameters:

        user_name: baikai //传给Service Broker的binding参数列表

- 删除绑定

oc delete -f ./instance.yml

- 删除服务实例

oc delete -f ./binding.yml

上述服务实例的创建,绑定,解绑定和删除,也可以通过OpenShift Origin Console进行操作,例如服务实例的绑定:

图6

值得注意的是,Service Catalog社区在2017年10月才支持service instance update(即OSB API的Patch接口), 并在Service Catalog临时版本v.0.0.24中合入(请参见github issue: Support updates to Instances)。目前OpenShift Origin 3.6 底层k8s采用1.6.3版本,尚未合入该patch,所以OpenShift Origin 3.6的Service Catalog所创建的服务实例不能进行扩容等更新操作。


Service Catalog REST API

在k8s的1.6.x版本中,Service Catalog的REST API如下:

(目前在1.6.x/1.7上的Service Catalog尚为alpha版本,与k8s 1.8上的beta版本的API以及部分Resource的命名方式略有区别)

- 创建服务实例

Route:

POST /apis/servicecatalog.k8s.io/v1alpha1/namespaces/<namespace name>/instances

Request header:

"Authorization: Bearer <user token>"

(在OpenShift Origin环境中,可以用过oc whoami -t命令获取当前用户的token)

Request Body:

{

    "apiVersion": "servicecatalog.k8s.io/v1alpha1",

    "kind": "Instance",

    "metadata": {

        "generateName": <service instance name>,

        "namespace": <namespace name>

    },

    "spec": {

        "parameters": {

            // service instance parameters list

        },

        "planName": <plan name>,

        "serviceClassName": <service class name>

    }

}

(Service Catalog各API的request body与命令行创建Service Instance时用户提供的描述资源的yaml文件中字段一致,只是形式从ymal变成json罢了 :-) )

调用示例:

图7

- 获取服务实例列表

Route:

GET /apis/servicecatalog.k8s.io/v1alpha1/namespaces//instances

Request header:

"Authorization: Bearer <user token>"

(在OpenShift Origin环境中,可以用过oc whoami -t命令获取当前用户的token)

调用示例:

图8(items里就是当前namespace里所有service instance的列表)

- 绑定服务实例

Route:

POST /apis/servicecatalog.k8s.io/v1alpha1/namespaces/<namespace>/bindings

Request header:

"Authorization: Bearer <user token>"

(在OpenShift Origin环境中,可以用过oc whoami -t命令获取当前用户的token)

Request body:

{

    "apiVersion": "servicecatalog.k8s.io/v1alpha1",

    "kind": "Binding",

    "metadata": {

            "generateName": <binding name>

    },

    "spec": {

        "instanceRef": {

            "name": <service instance name to binding>

        },

        "parameters": {

           //binding parameters list

        },

        "secretName": <secret to store service instance credentials>,

        "labels": {

            //label selector to get pod

        }

    }

}

调用示例:

图9

- 获取服务实例绑定列表

Route:

GET /apis/servicecatalog.k8s.io/v1alpha1/namespaces/<namespace name>/binding 

Request header:

"Authorization: Bearer <user token>"

(在OpenShift Origin环境中,可以用过oc whoami -t命令获取当前用户的token)

调用示例:

图10(items里就是当前namespace里所有binding的列表)

- 删除绑定

Route:

DELETE /apis/servicecatalog.k8s.io/v1alpha1/namespaces/<namespace name>/bindings/<binding name>

Request header:

"Authorization: Bearer <user token>"

(在OpenShift Origin环境中,可以用过oc whoami -t命令获取当前用户的token)

调用示例:

图11

- 删除服务实例

Route:

DELETE /apis/servicecatalog.k8s.io/v1alpha1/namespaces/<namespace name>/instances/<service instance name>

Request header:

"Authorization: Bearer <user token>"

(在OpenShift Origin环境中,可以用过oc whoami -t命令获取当前用户的token)

调用示例:

图12

结论

目前Service Catalog项目尚处于k8s社区的孵化阶段,特性在不断的迭代和完善,API以及Resource的名称也在演化中,距离稳定和生产可用还有一段距离。在版本发布方面,k8s社区的1.6/1.7 release对应的service catalog的alpha版本,1.8 release对应service catalog的beta版本。

推荐大家去试用k8s的Service Catalog特性,通过Service Catalog把自己项目所需要依赖的服务集成到k8s环境中,这也是未来k8s社区主推的第三方服务管理方式。


参考

Service Catalog发布计划:kubernetes Service Catalog Project Roadmap

Service Catalog官方文档:Service Catalog docs

OpenShift官方文档:OpenShift Service Catalog

推荐阅读更多精彩内容