1. Service catalog introduction
The service directory is a directory that lists all services. Users can browse the catalog and set up service instances listed in the catalog themselves, without having to deal with pods, services, configmaps and other resources required for the service to run. This sounds similar to custom web assets.
The service catalog does not add custom resources to the api server of each service type, but introduces four general API resources into it:
- A ClusterServiceBroker, describing an (external) system that can provide services
- A ClusterServiceClass describing a provisionable service type
- A ServiceInstance, an instance of the configured service
- A ServiceBinding that represents the binding between a set of clients (pods) and a ServiceInstance
The cluster administrator creates a ClusterServiceBroker resource for each service broker that needs to provide their services in the cluster. Next, kubernetes gets the list of services they can provide from the service proxy and creates a ClusterServiceClass resource for each of them. When a user provisions a service, they first need to create a ServiceInstance resource, and then create a ServiceBinding to bind that ServiceInstance to their pod. Next, the Alisma pod is injected with a Secret that contains the credentials and other data needed to connect to the configured ServiceInstance.
2. Introduction of service directory API server and controller manager
Similar to core kubernetes, the service directory is also a distributed system consisting of three components:
- Service Catalog API Server
- etcd as storage
- A controller manager that runs all controllers
The resource numbers related to the four service directories introduced before are created by publishing the YAML/JSON list to the API server. The API server will then store them in its own etcd instance, or use the CRD in the main API server as an alternative storage mechanism (in which case no additional etcd instance is required)
The controller itself does not provide the requested service, but leaves it to an external service proxy, which registers it by creating a ServiceBroker resource in the service catalog API.
3. Service proxy and OpenServiceBroker API
A cluster administrator can register one or more external ServiceBrokers in the service catalog. At the same time, each broker must implement the OpenServiceBroker API.
Introduction to OpenService Broker API
Through the OpenServiceBroker API, the service directory can communicate with the broker through the API. This simple REST API can provide the following functions:
Use GET /v2/catalog to retrieve the list of services
Configure service instance (PUT /v2/service_instances/:id)
update service instance (PATH/v2/service_instaces/:id)
Binding service instance (PUT /v2/service_instances/:id/service_bindings/:binding_id)
Unbind instance (DELETE /v2/service_instances/:id/service_bindings/:binding_id)
Cancel service instance configuration (DELETE /v2/service_instances/:id)
Register an agent in the service catalog
Cluster administrators can register brokers by publishing a ServiceBroker resource manifest to the Service Catalog API
A ClusterServiceBroker manifest: database-broker.yaml
apiVersion：servicecatalog.k8s.io/v1alpha1
metadata:
name:database-broker
spec:
url:http://database-osbapi.myorganizations.org
The code listing above describes a virtual agent that can provide different types of databases. After an administrator creates a ClusterServiceBroker resource, a controller in the Service Catalog Controller Manager connects to the URL specified in the resource and retrieves a list of services that this broker can provide.
After the list of services is retrieved, a ClusterServiceClass resource is created for each service. Each ClusterServiceClass resource describes a provisionable service. Each ClusterServiceClass has one or more service schemes associated with it. Users can choose from different plans depending on the level of service they require.
List available services in the cluster
$kubectl get serviceclasses
4. Provision of services and use of services
Provide services
To pre-allocate a database, all you need to do is create a ServiceInstance resource
ServiceInstance列表：database-instance.yaml
apiVersion:servicecatalog.k8s.io/v1alpha1
kind:ServiceInstance
metadata:
name:my-postgres-db
spec:
clusterServiceClassName:postgres-database
clusterServicePlanName:free
parameters:
init-db-args:--data-checksums
Create a ServiceInstance named my-postgres-db as above, specify the ClusterServiceClass, and select the scheme. It is also necessary to specify a clear broker and the parameters required by the ClusterServiceClass.
Once this resource is created, the service catalog asks the agent to which the ClusterServiceClass belongs to provision the service, passing it the ClusterServiceClass of your choice, the plan name, and any parameters specified.
What to do next with this information is entirely up to the agent.
Check the status of the created my-postgres-db ServiceInstance to check if the service has been successfully provisioned.
$kubectl get instance my-postgres-db -o yaml
Bind service instance
If you want to use the configured ServiceInstance in the pod, you can create a binding resource, as shown in the code list below
ServiceBinding：my-postgres-db-binding.yaml
apiVersion:servicecatalog.k8s.io/v1alpha1
kind:ServiceBinding
metadata:
name:my-postgres-db-binding
spec:
instanceRef:
name:my-postgres-db
secretName:postgres-secret
The above code defines a ServiceBinding resource named my-postgres-db-binding, which refers to the previously created my-postgres-db service instance, and also names a secret.
When submitting a ServiceBinding resource from the previous list to the Service Catalog API server, the controller again contacts the database proxy and creates a binding for the previously configured ServiceInstance. In response, at this point the proxy returns the credentials and other data needed to link to the database. The Service Catalog then creates a new Secret with the name specified in the ServiceBinding resource and stores all data in the Secret.
Use the newly created Secret in the client pod
Secrets created by the service catalog system can be loaded into pods so that secrets can read their contents and use them to connect to configured service instances.
A Secret holding credentials to connect to the service instance
$kubectl get secret postgres-secret -o yaml
apiVersion:v1
data:
host:<base64-encoded hostname of the database>
username:<base64-encoded username>
password:<base64-encoded password>
kind:Secret
metadata:
name:postgres-secret
namespace:default
...
type:Opaque
5. Unbind and unconfigure
Service bindings are no longer needed and can be removed in the same way as other resources
$kubectl delete servicebinding my-postgres-db-binding
At this point, the service catalog controller will delete the key and notify the agent to unbind, while the service instance will still be running. Therefore, you can create a new service binding.
If the database instance is no longer needed, the service instance resource can be deleted as well
$kubectl delete serviceinstance my-postgres-db
After the ServiceInstance resource is deleted, the service catalog performs a deconfigure operation on the service proxy. Also, although the consequences of deconfiguration are up to the agent, you should tell the agent to shut down the postgresSQL database instance that was created when the service instance was provisioned
6. What does the service catalog bring us
Service providers can expose services in any kubernetes cluster by registering a proxy in that cluster.