The service-catalog project is in incubation to bring integration with service brokers to the Kubernetes ecosystem via the Open Service Broker API.
A service broker is an endpoint that manages a set of software offerings called services. The end-goal of the service-catalog project is to provide a way for Kubernetes users to consume services from brokers and easily configure their applications to use those services, without needing detailed knowledge about how those services are created or managed.
As an example:
Most applications need a datastore of some kind. The service-catalog allows Kubernetes applications to consume services like databases that exist somewhere in a simple way:
The user asks for a new instance of that service to be provisioned
Provisioning means that the broker somehow creates a new instance of a service. This could mean basically anything that results in a new instance of the service becoming available. Possibilities include: creating a new set of Kubernetes resources in another namespace in the same Kubernetes cluster as the consumer or a different cluster, or even creating a new tenant in a multi-tenant SaaS system. The point is that the consumer doesn’t have to be aware of or care at all about the details.
The user requests a binding to use the service instance in their application
Credentials are delivered to users in normal Kubernetes secrets and contain information necessary to connect to and authenticate to the service instance.
The service catalog API has five main concepts:
The remaining four concepts all map directly to new Kubernetes resource types that are provided by the service catalog API.
ClusterServiceBroker: An in-cluster representation of a broker server. A resource of this type encapsulates connection details for that broker server. These are created and managed by cluster operators who wish to use that broker server to make new types of managed services available within their cluster.
ClusterServiceClass: A type of managed service offered by a particular broker. Each time a new
ClusterServiceBrokerresource is added to the cluster, the service catalog controller connects to the corresponding broker server to obtain a list of service offerings. A new
ClusterServiceClassresource will automatically be created for each.
ServiceInstance: A provisioned instance of a
ClusterServiceClass. These are created by cluster users who wish to make a new concrete instance of some type of managed service to make that available for use by one or more in-cluster applications. When a new
ServiceInstanceresource is created, the service catalog controller will connect to the appropriate broker server and instruct it to provision the service instance.
ServiceBinding: Expresses intent to use a
ServiceInstance. These are created by cluster users who wish for their applications to make use of a
ServiceInstance. Upon creation, the service catalog controller will create a Kubernetes
Secretcontaining connection details and credentials for the service represented by the
Secrets can be used like any other– mounted into a container’s file system or injected into a container as environment variables.
These concepts and resources are the building blocks of the service catalog.
See Resources for details on each Service Catalog resource (or type).Create an Issue Edit this Page