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
网友评论