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 ClusterServiceBroker resource is added to the cluster,
the service catalog controller connects to the corresponding broker server to
obtain a list of service offerings. A new ClusterServiceClass resource 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 ServiceInstance resource 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 Secret containing connection details and credentials for the
service represented by the ServiceInstance. Such 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