接触 Service Catalog 随记 （一）

开始接触 Service Catalog，... ...

Service Catalog 基本知识：

 

Service Catalog:

Service Catalog lets you provision cloud services directly from the comfort of native Kubernetes tooling. This project is in incubation to bring integration with service brokers to the Kubernetes ecosystem via the Open Service Broker API.

The Service Catalog integrates with the Open Service Broker API (OSB API) to translate the Kubernetes resource model into OSB API calls to a service broker.

It has the following high level features:

• Service Catalog users can register service brokers with Kubernetes
• Service Catalog can fetch the services and plans (called the catalog) from each service broker, and make it available to Kubernetes users
• Kubernetes users can request a new service from a broker by submitting a ServiceInstance resource to Service Catalog
• Kubernetes users can link an application (i.e. one or more Pods) to a service by creating a new ServiceBinding resource

These features provide a loose-coupling between Applications running in Kubernetes and services that they use.

Generally, the services that applications use are external (i.e. "black box") to the Kubernetes cluster. For example, applications may decide to use a cloud database service.

Using Service Catalog and the appropriate service broker, application developers can focus on their own business logic, leave development and management of the service to someone else, and leave provisioning to the Service Catalog and broker.

【个人理解&注释】：Service Catalog 重要的是提供这样的功能，实现通过 Open Service Broker API，调用Service Broker，而Service Broker是由服务提供方提供的（第三方），从而外部应用或k8s内部的应用从k8s平台上获得k8s外部（一般情况是外部）提供的某种服务，相对来说是对接，例如：云平台提供的某种数据库等，而数据库服务的提供方可能不在k8s平台的容器里；

Terminology【术语】

• Application: Kubernetes uses the term "service" in a different way than Service Catalog does, so to avoid confusion the term Application will refer to the Kubernetes deployment artifact that will use a ServiceInstance.
• ClusterServiceBroker: a Kubernetes resource that Service Catalog recognizes. This resource tells Service Catalog to fetch the catalog of a new broker, and merge the new catalog into the existing ClusterServiceClasses andClusterServicePlans (see below). This resource is global - it doesn't have a namespace.
• ClusterServiceClass: a Kubernetes resource that Service Catalog generates. After a user submits a ClusterServiceBroker, Service Catalog fetches the broker's catalog and merges the new catalog entries into ClusterServiceClasses in Kubernetes. Each ClusterServiceClass has one or more ClusterServicePlans (see below). This resource is global - it doesn't have a namespace.
• ClusterServicePlan: a Kubernetes resource that Service Catalog generates. After a user submits a ClusterServiceBroker, Service Catalog fetches the broker's catalog and merges the new catalog entries into ClusterServiceClasses andClusterServicePlans. Plans indicate variations on each ClusterServiceClass like cost, capacity, or quality of services (QoS). This resource is global - it doesn't have a namespace.
• ServiceInstance: a Kubernetes resource that Service Catalog recognizes. A Kubernetes user may submit a ServiceInstance to provision a new instance of a service. The details of the service and the plan are listed in the resource, and ServiceCatalog passes that information to the broker that can provision the service. This resource is not global - it has a namespace.
• ServiceBinding: a Kubernetes resource that Service Catalog recognizes. A Kubernetes user may submit a ServiceBindingto indicate their intent for their application to reference and use a ServiceInstance. Generally, a ServiceBinding will get credentials and a hostname that the application can use to talk to the service. After Service Catalog gets these credentials, it writes them into a Kubernetes Secret.
• Credentials: after Service Catalog receives the binding response, it writes the response data into a Kubernetes Secret. This is the information needed for an application to talk to the service itself, and we call it "Credentials."

【个人理解&注释】：Service Catalog，就是为了“对接”。这里的Plan大概如我们所谓的“套餐”（比如说数据库的配置），这里的Class像产品平台类，某一类只是代表我可以提供数据库服务，具体什么样的数据库服务，你要看这一类里的Plan“套餐”，这里的Instance就是Instance了，但应该是指Service Catalog这边的概念，不是真正的数据库实例（Database Instance），只是一个实例目录的映射，这样的配置的数据库套餐（Plan）里有几个Instance可以供选择或申请，Binding就是你申请了其中的某个Instance（获得了使用权，比如连接信息，身份验证信息等等）真正地在这个绑定后实例（Service Instance）与提供方的数据库实例（Database Instance）做了一对一的绑定和mapping，Credentials就是指这Instance Binding的信息，但应不是具体数据库里面某个连接用户的Credentials信息。

 

Open Service Broker API:

The Open Service Broker API project allows developers, ISVs, and SaaS vendors a single, simple, and elegant way to deliver services to applications running within cloud native platforms such as Cloud Foundry, OpenShift, and Kubernetes. The project includes individuals from Fujitsu, Google, IBM, Pivotal, Red Hat and SAP.

• Define and evolve the Open Service Broker API as a specification, using a clear release process to support any downstream implementations
• Create a conformance test suite to verify both consumer and producer behaviors
• Advocate broad industry adoption in support of the end user community

【个人理解&注释】：ISV （Independent Software Vendor 独立软件开发商？应该是。）

 

High level architecture of Service Catalog:

Service Catalog has two basic building blocks: an API server and a controller. This design is similar to the design of Kubernetes itself (in fact, Service Catalog borrows a lot of code from Kubernetes to implement this design).

API Server

The API Server is an HTTPS RESTful front-end for etcd (we can implement more storage backends, but we haven't done so)

Users and the Service Catalog controller interact with the API server (via the Kubernetes API aggregator to perform CRUDoperations on Service Catalog resources (the ones listed in the previous section). For example, when a user runs kubectl get clusterservicebroker, they will be talking to the Service Catalog API server to get the list of ClusterServiceBroker resources.

The current version of all Service Catalog API resources is v1beta1. You can see the structure of each resource in detail atpkg/apis/servicecatalog/v1beta1/types.go.

Controller

The Service Catalog controller implements the behaviors of the service-catalog API. It monitors the API resources (by watching the stream of events from the API server) and takes the appropriate actions to reconcile the current state with the user's desired end state.

For example, if a user creates a ClusterServiceBroker, the Service Catalog API server will store the resource and emit an event. The Service Catalog controller will pick up the event and request the catalog from the broker listed in the resource.

【个人理解&注释】：Controller来实现API Server的Event。

待续  ... ...