Enabling the service catalog is a Technology Preview feature only.
To opt-in during installation, see Advanced Installation.
When developing microservices-based applications to run on cloud native platforms, there are many ways to provision different resources and share their coordinates, credentials, and configuration, depending on the service provider and the platform.
To give developers a more seamless experience, OKD includes a service catalog, an implementation of the Open Service Broker API (OSB API) for Kubernetes. This allows users to connect any of their applications deployed in OKD to a wide variety of service brokers.
The service catalog allows cluster administrators to integrate multiple platforms using a single API specification. The OKD web console displays the service classes offered by brokers in the service catalog, allowing users to discover and instantiate those services for use with their applications.
As a result, service users benefit from ease and consistency of use across different types of services from different providers, while service providers benefit from having one integration point that gives them access to multiple platforms.
The design of the service catalog follows this basic workflow:
New terms in the following are defined further in Concepts and Terminology.
|A cluster administrator registers one or more service brokers with their OKD cluster. This can be done automatically during installation for some default-provided service brokers or manually.
|Each service broker specifies a set of service classes and variations of those services (service plans) to OKD that should be made available to users.
|Using the OKD web console or CLI, users discover the services that are available. For example, a service class may be available that is a database-as-a-service called BestDataBase.
|A user chooses a service class and requests a new instance of their own. For
example, a service instance may be a BestDataBase instance named
|A user links, or binds, their service instance to a set of pods (their
application). For example, the
my_db service instance may be bound to the
user’s application called
This infrastructure allows a loose coupling between applications running in OKD and the services they use. This allows the application that uses those services to focus on its own business logic while leaving the management of these services to the provider.
A service broker is a server that conforms to the OSB API specification and manages a set of one or more services. The software could be hosted within your own OKD cluster or elsewhere.
Cluster administrators can create
Broker API resources representing service
brokers and register them with their OKD cluster. This allows
cluster administrators to make new types of managed services using that service
broker available within their cluster.
Broker resource specifies connection details for a service broker and the
set of services (and variations of those services) to OKD that
should then be made available to users.
apiVersion: servicecatalog.k8s.io/v1alpha1 kind: Broker metadata: name: BestCompanySaaS spec: url: http://bestdatabase.example.com
Also synonymous with "service" in the context of the service catalog, a service
class is a type of managed service offered by a particular broker. Each time a
new broker resource is added to the cluster, the service catalog controller
connects to the corresponding service broker to obtain a list of service
offerings. A new
ServiceClass resource is automatically created for each.
OKD also has a core concept called services, which are separate Kubernetes resources related to internal load balancing. These resources are not to be confused with how the term is used in the context of the service catalog and OSB API.
apiVersion: servicecatalog.k8s.io/v1alpha1 kind: ServiceClass metadata: name: smallDB brokerName: BestDataBase plans: [...]
A service plan is represents tiers of a service class. For example, a service class may expose a set of plans that offer varying degrees of quality-of-service (QoS), each with a different cost associated with it.
A service instance is a provisioned instance of a service class. When a user wants to use the capability provided by a service class, they can create a new instance.
When a new
Instance resource is created, the service catalog controller
connects to the appropriate service broker and instructs it to provision the
apiVersion: servicecatalog.k8s.io/v1alpha1 kind: Instance metadata: name: my_db spec: serviceClassName: smallDB
The term application refers to the OKD deployment artifacts, for example pods running in a user’s project, that will use a service instance.
Credentials are information needed by an application to communicate with a service instance.
A service binding is a link between a service instance and an application. These are created by cluster users who wish for their applications to reference and use a service instance.
Upon creation, the service catalog controller creates a Kubernetes secret
containing connection details and credentials for the service instance. Such
secrets can be mounted into pods as usual. There is also integration with
PodPresets, which allow you to express how the secret should be consumed, and
in which pods.
apiVersion: servicecatalog.k8s.io/v1alpha1 kind: Binding metadata: name: myBinding spec: secretName: mySecret <pod_selector_labels>