Service Catalog
最后更新于
最后更新于
服务目录（Service Catalog）是Kubernetes的扩展API，它使运行在Kubernetes集群中的应用程序可以轻松使用外部托管软件产品，例如由云提供商提供的数据存储服务。
它提供列表清单、提供(provision)和绑定(binding)来自服务代理（Service Brokers）的外部托管服务，而不需要关心如何创建或管理这些服务的详细情况。
由Open Service Broker API规范定义的Service broker是由第三方提供和维护的一组托管服务的端点(endpoint)，该第三方可以是AWS，GCP或Azure等云提供商。
托管服务可以是Microsoft Azure Cloud Queue，Amazon Simple Queue Service和Google Cloud Pub/Sub等，它们可以是应用可以使用的提供的各种软件。
通过Service Catalog，集群运营者可以浏览由Service Broker提供的托管服务列表，提供的托管服务实例，并与其绑定，使其可被Kubernetes集群中的应用程序所使用。
应用程序开发人员编写基于Kubernetes集群的应用程序，他们希望使用消息队列作为其应用程序的一部分。但是，他们不想自己配置和管理这个服务服务。恰好，有一家云提供商通过其服务代理(Service Broker)提供消息队列服务。
集群运营商可以设置Service Catalog并使用它与云提供商的Service Broker进行通信，以调配消息排队服务的实例并使其可用于Kubernetes集群内的应用程序。因此，应用程序开发人员不需要关心消息队列的实现细节或管理，可以简单地像服务一样使用它。
Service Catalog使用Open Service Broker API与Service Broker进行通信，充当Kubernetes API服务器的中介，发起供应并返回应用程序使用托管服务所需的凭据。
Service Catalog通过扩展API服务器和控制器实现，使用etcd进行存储。它还使用Kubernetes 1.7+中提供的聚合层来呈现其API。
Service Catalog安装servicecatalog.k8s.ioAPI并提供以以下Kubernetes资源：
ClusterServiceBroker：作为service broker的群集内代理，封装其服务器连接详细信息。这些由集群运营者创建和管理，希望使用broker服务在其集群中提供新类型的托管服务。
ClusterServiceClass：由特定service broker提供的托管服务。将新ClusterServiceBroker资源添加到群集时，Service catalog controller将连接到service broker以获取可用托管服务的列表清单。然后它会创建新的ClusterServiceClass资源，与每个托管服务相对应。
ClusterServicePlan：托管服务的特定产品。例如，托管服务可能有不同的可用套餐，例如免费套餐或付费套餐，或者可能有不同的配置选项，例如使用SSD存储或拥有更多资源。同向群集添加ClusterServiceClass一样，当添加一个新的ClusterServiceBroker时，Service Catalog会创建一个新的ClusterServicePlan资源，与每个托管服务可用的每个服务套餐对应。
ServiceInstance：一个提供好的ClusterServiceClass实例。这些是由集群运营者创建的托管服务的特定实例，供一个或多个集群内应用程序使用。当创建一个新的ServiceInstance资源时，Service Catalog controller连接到相应的服务代理并指示它提供服务实例。
ServiceBinding：访问ServiceInstance的凭据。由想让他们的应用利用ServiceInstance的集群集运营者创建。创建之后，Service Catalog controller将创建一个与此服务实例对应的Kubernetes的Secret，包含此服务实例的连接详细信息和凭证 ，可以挂载到Pod中。
Service Catalog 支持这些认证方法：
Basic (username/password)
群集运营者可以使用Service Catalog API资源来提供托管服务，并使其在Kubernetes群集中可用。涉及的步骤是：
列出Service Broker提供的托管服务清单和服务套餐。
提供托管服务的新实例。
绑定到托管服务，该服务返回连接凭证。
将连接凭证映射到应用程序中。
首先，群集运营者必须在servicecatalog.k8s.io群组内创建ClusterServiceBroker资源。此资源包含访问服务代理端点所需的URL和连接详细信息。
这是一个ClusterServiceBroker资源的例子：
以下是说明从一个service broker列出托管服务和套餐所涉及步骤的顺序图：
将ClusterServiceBroker资源添加到Service catalog中，它会触发对外部Service Broker的调用以获取可用服务的清单。
Service Broker返回可用托管服务的清单和服务套餐的列表，它们分别在本地缓存为ClusterServiceClass资源和ClusterServicePlan资源。
然后，集群运营者可以使用以下命令获取可用托管服务的清单：
它应该输出一个类似于以下格式的服务名称列表：
他们还可以使用以下命令查看可用的服务套餐：
它应该输出一个类似于以下格式的套餐名称列表：
集群运营者可以通过创建ServiceInstance资源来启动新实例的供应。
如下是一个ServiceInstance资源的例子：
以下序列图说明了提供一个新的托管服务的实例所涉及的步骤：
当ServiceInstance资源创建后，Service Catalog发起到外部service broker来提供服务的一个实例。
service broker创建托管服务的新实例并返回HTTP响应。
然后，群集运营者可以检查实例的状态，来确认它是否准备就绪。
在提供新实例后，群集运营者必须绑定到托管服务才能获取到应用程序使用服务所需的连接凭证和服务帐户详细信息。这是通过创建ServiceBinding资源完成的。
以下是一个ServiceBinding资源的例子：
以下序列图说明了绑定到托管服务实例所涉及的步骤：
在ServiceBinding创建后，Service Catalog给外部service broker发一个调用请求，获取与服务实例绑定所需的信息。
service broker为相应的服务帐户启用应用程序权限/角色。
service broker返回连接和访问托管服务实例所需的信息。根据不同的提供商和不同的服务，返回的信息可能在服务提供商和其管理服务之间有所不同。
绑定后，最后一步是将连接凭证和服务特定的信息映射到应用程序中。这些信息存储在secret中，应用程序可以用来访问并与托管服务连接。
执行此映射的一种方法是使用声明式Pod配置文件。
以下示例描述了如何将服务帐户凭证映射到应用程序中。被调用的sa-key密钥存储在名为provider-cloud-key的卷中，并且应用程序将此卷挂载到/var/secrets/provider/key.json。环境变量PROVIDER_APPLICATION_CREDENTIALS是从挂载文件的值映射而来的。
以下示例描述如何将secret值映射到应用程序环境变量。在此示例中，消息传递队列topic名称从名为provider-queue-credentials的secret的key topic值映射到环境变量TOPIC。
如果熟悉Helm Charts ，使用Helm将Service Catalog安装到Kubernetes集群中。或者，可以使用SC工具安装服务目录。
以上翻译自官方文档。
Kubernetes 1.7或更高版本的集群运行 API Aggregator，它位于core API Server前面的专用proxy服务器。
服务目录(Service Catalog)提供了一个位于API aggregator后面的API Server，因此可以用kubectl像平常一样与Service Catalog进行交互。
要了解更多关于API aggregation的信息，请参阅 Kubernetes文档。
本文档的其余部分详细介绍了如何：
在群集上设置Service Catalog
与Service Catalog API进行交互
Service Catalog需要Kubernetes v1.7或更高版本。您还需要 在主机上安装Kubernetes configuration file 。你需要这个文件，以便可以使用kubectl和 helm与群集通信。许多Kubernetes安装工具或云提供商会为你设置此配置文件。有关详细信息，请与您的工具或提供商联系。
kubectl版本大多数与Service Catalog系统的交互都是通过kubectl命令行界面实现的。与群集版本一样，Service Catalog需要kubectl版本1.7或更高版本。
首先，检查kubectl版本：
确保Kubernetes版本和kubectl版本均为1.7或更高。
如果需要升级客户端，请按照安装说明 获取新的kubectl二进制文件。
例如，运行以下命令以在Mac OS上获取最新的二进制文件：
您需要启用Kubernetes集群内的DNS。大多数常用的安装方法会为您自动配置群集内DNS：
大多数云提供商
使用Helm安装Service Catalog ，需要v2.7.0或更高版本。请参阅以下步骤进行安装。
如果尚未安装Helm，请下载helm CLI，然后运行helm init（这会将Helm的服务器端组件Tiller安装到Kubernetes群集中）。
如果已经安装了Helm，请运行helm version并确保客户端和服务器版本均为v2.7.0或更高。
如果不是， 请安装更新版本的helm CLI并运行helm init --upgrade。
有关安装的更多详细信息，请参阅 Helm安装说明。
Tiller是Helm的服务端组件。默认情况下， helm init将Tiller pod安装到kube-system名称空间中，并将Tiller配置为使用default服务帐户（service account）。
需要对Tiller进行配置cluster-admin权限，才能正确安装Service Catalog：
Service Catalog很容易通过 Helm chart 安装 。
此chart位于 chart repository 中。将此repository添加到本地计算机：
然后，确保repository已成功添加：
应该看到以下输出：
Kubernetes群集必须启用RBAC 才能使用Service Catalog。
与群集内DNS一样，许多安装方法都有对应启用RBAC的途径。
如果您正在使用Minikube，请使用以下命令启动群集：
如果使用hack/local-up-cluster.sh脚本，请使用以下命令启动群集：
许多云提供商为你启用了RBAC的新集群。有关详细信息，请查阅你的提供商的文档。
集群和Helm配置正确，安装Service Catalog很简单：
按照适用于操作系统的说明安装svcat。二进制文件可以单独使用，也可以作为kubectl插件使用。
下面的片段仅在当前会话的PATH添加一个路径。后续使用需要将它相应的路径永久添加到PATH中。
对应操作系统下载相应的二进制文件：
macOS: https://download.svcat.sh/cli/latest/darwin/amd64/svcat
Windows: https://download.svcat.sh/cli/latest/windows/amd64/svcat.exe
Linux: https://download.svcat.sh/cli/latest/linux/amd64/svcat
使二进制文件可执行。
将二进制文件移动到PATH相应的目录。
要将svcat用作插件，请在下载后运行以下命令：
当作为插件运行时，这些命令与添加全局kubectl配置标志相同。其中一个例外是，在插件模式下运行时不支持布尔标志，所以不要使用--flag,必须指定--flag=true。
