kubernetes之service catalog

参考：https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/

Service Catalog是kubernetes的一种API扩展，方便kubernetes集群内部应用访问集群外部、由第三方管理、提供的服务，如由云供应商提供的数据库服务。Service Catalog通过Service Brokers使集群内应用能够列出外部服务、提供实例、将集群内应用与实例绑定，使集群内应用不必关心外部服务的实现、管理细节。总结起来就是Service Broker代表外部服务，集群内应用通过Service Catalog使用Service Broker。

Example use case

假如集群内应用的开发者想要使用一个消息队列，但又不想关心消息队列的方方面面，即纯粹只是作为消费者而不是提供者。正好，有一个云服务供应商，通过它们的service broker提供此种类型的服务供外部用户使用。这里又出现了"service broker"一词，但这里的意思与上文应该不同，这里指的应该是云服务商的"service broker"，代表的是云服务商内部想要提供给外部使用的服务。由些可见，想要让集群内服务被集群外实例使用，也要提供"service broker"。

集群管理员通过设置Service Catalog，由它负责与云服务供应商的service broker通信、提供服务实例，而集群内的应用通过Service Catalog使用外部服务。这样，集群内应用无需关系外部服务的实现细节、管理等。

Architecture

首先要明确，Service Catalog通过Open service broker API与外部service broker通信，而不是随意的其它什么东西。Service Catalog扮演中间人角色，负责在集群内应用与外部服务之间协商如实例初始化、认证等相关操作，注意它的角色：中间人。

那么Service Catalog是怎么实现的呢？Kubernetes是高度可配置、可扩展的平台，Service Catalog就是通过扩展实现。包含两个方面，一个是对apiserver的扩展，Service Catalog本身就是一个扩展的apiserver。另外一个方面是管理控制器控制，是对kubernetes控制管理面的扩展，总之是通过扩展实现。另外需要提供额外的etcd存储，也就是说Service Catalog并没有完全使用Kubernetes的etcd。它也使用从1.7版本开始可用的aggregation layger表示API。

API Resources

要使用Service Catalog需要先安装servicecatalog.k8s.io API，它提供了如下可使用的kubernetes资源：

• ClusterServiceBroker：这类资源由集群管理员根据所有使用的外部服务创建、管理。表示集群内的service broker，负责封装低层通信有关的细节。
• ClusterServiceClass：由外部service broker管理、提供的服务。当ClusterServiceBroker被创建时，Service Catalog控制器连接外部service broker，并且获取由外部service broker管理的可用的外部服务列表，然后为每个外部服务创建相应的ClusterServiceClass。
• ClusterServicePlan：由外部服务提供的特殊offering。例如，拥有不同可用计划的外部服务，如免费层或者付费层，或者不同配置选项，如SSD或者其它类型存储。同样它也是在ClusterServiceBroker时自动创建，分别为每个外部服务的每个服务可用计划创建ClusterServicePlan。总结一下就是相同的服务，但是它可能有不同的可用计划，如免费版本、付费版本、普通存储、SSD存储等，它负责管理的应该是外部服务的可选、可配置特性等。
• ServiceInstance：代表ClusterServiceClass的外部服务实例。注意，实例仍然由集群管理员创建，给集群内的应用使用。当它被创建时，由Service Catalog控制器负责与外部的service broker交互、协商，指挥外部service提供实例。
• ServiceBinding：表示访问外部服务实例证书，由集群管理员创建，然后想要访问外部服务的应用可将其mount到pod上。
  

Authentication

Service Catalog支持两种认证方式，应该就是ServiceBinding支持的认证方式：

扫描二维码关注公众号，回复： 2236610 查看本文章

• Basic (username/password)
• OAuth 2.0 Bearer Token，由以上场景可以看出，这种认证方式比较合适、灵活，但是有一定的复杂性。
  

Usage

集群管理员通过Service Catalog API管理、实例化外部服务并提供给内部应用使用，涉及如下几个步骤：

1. 从外部service broker列出可用的外部服务及其可用计划。
2. 提供外部服务实例。
3. 绑定外部服务，返回链接建立时用到的证书。
4. 将证书映射进内部应用。
   

Listing managed services and Service Plans

首先，集群管理员要在servicecatalog.k8s.io组内创建ClusterServiceBroker，其中包含连接外部service broker endpoint必需信息如URL等，所以说ClusterServiceBroker负责与外部service broker的通信细节。

以下是ClusterServiceBroker示例：

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ClusterServiceBroker
metadata:
  name: cloud-broker
spec:
  # Points to the endpoint of a service broker. (This example is not a working URL.)
  url:  https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default
  #####
  # Additional values can be added here, which may be used to communicate
  # with the service broker, such as bearer token info or a caBundle for TLS.
  #####

以下是获取可用外部服务与可用计划的顺序图：

1. 一旦ClusterServiceBroker被创建，自动触发获取外部服务的调用。
2. 外部service broker返回外部可能服务、可用计划列表。
3. 集群管理员通过如下命令列出所有的外部可用服务：

kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName

输出内容格式如下：

SERVICE NAME                           EXTERNAL NAME

4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468   cloud-provider-service

...                                    ...

如下命令输出服务可用计划：

kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName

输出内容格式如下：

PLAN NAME                              EXTERNAL NAME

86064792-7ea2-467b-af93-ac9694d96d52   service-plan-name

...                                    ...

Provisioning a new instance

集群管理员创建ServiceInstance实现化外部服务，以下是示例：

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
  name: cloud-queue-instance
  namespace: cloud-apps
spec:
  # References one of the previously returned services
  clusterServiceClassExternalName: cloud-provider-service
  clusterServicePlanExternalName: service-plan-name
  #####
  # Additional parameters can be added here,
  # which may be used by the service broker.
  #####

以下序列图展示实例化涉及到的步骤：

1. 当集群管理员创建ServiceInstance，Service Catalog负责命令外部service broker创建实例。
2. 外部service broker创建实例并返回HTTP应答。
3. 集群管理员查看应答以确认实例是否创建成功。
   

Binding to a managed service

创建完实例后，集群管理员必需执行绑定操作，以取得建立连接时需要用到的证书、服务账号等供集群内应用使用，以下是示例：

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
  name: cloud-queue-binding
  namespace: cloud-apps
spec:
  instanceRef:
    name: cloud-queue-instance
  #####
  # Additional information can be added here, such as a secretName or
  # service account parameters, which may be used by the service broker.
  #####

以下是绑定到服务实例的序列图：

1. 当创建ServiceBinding后，Service Catalog自动向外部server broker发起调用，以获取访问外部实例所必须的信息。
2. 外部服务实例允许特定的服务账号访问。
3. 外部service broker返回访问服务必需的内部信息。信息内容依赖于外部服务，不同外部服务各不相同。

Mapping the connection credentials

绑定后，访问外部服务所需要的证书、必需信息以加密的形式保存在集群内，并且可被应用使用，直接用来访问外部服务。注意这里是直接访问，没有经过任何代理。

Pod configuration File

将访问外部服务所需的证书、其它信息映射到应用，其中一种方法是配置Pod。

下例描述如何将服务账号、证书映射到应用。sa-key存储在volume provider-cloud-key中。应用将此volume mount到/var/secrets/provider/key.json路径下。环境变量PROVIDER_APPLICATION_CREDENTIALS表示文件路径。

...
    spec:
      volumes:
        - name: provider-cloud-key
          secret:
            secretName: sa-key
      containers:
...
          volumeMounts:
          - name: provider-cloud-key
            mountPath: /var/secrets/provider
          env:
          - name: PROVIDER_APPLICATION_CREDENTIALS
            value: "/var/secrets/provider/key.json"

下例展示将加密值映射到环境变量：

...
          env:
          - name: "TOPIC"
            valueFrom:
                secretKeyRef:
                   name: provider-queue-credentials
                   key: topic

由本文可以看出，以Service Catalog的方式使用外部服务，关键点有两个，其一是外部service broker的编写，这个由外部的服务供应商解决。其二就是在集群内部如何通过命令行，或者是直接调用Open service broker API管理外部服务，其它都是常规操作。有点像远程过程调用，最终提供了一种访问外部服务的方法。

参考：sample service brokers