Overview

The setup around a Crossplane Service Broker consists of three main components:

  • The Service Catalog is the entry-point for users who want to instantiate new services. Its interface is a well-defined REST-API which provides an overview over all available and all instantiated services. It connects to one (or many) Crossplane Service Brokers, which provide this information back to the Service Catalog. (The Service Catalog may also connect to other kinds of Service Brokers in order to provide more services.)

    The Service Catalog has been deprecated.

  • A Crossplane Service Broker that knows which services it offers and what already instantiated services it’s responsible for. When a user wants to instantiate a certain service (via the Service Catalog), the Crossplane Service Broker creates the respective Crossplane custom resources in the Kubernetes cluster in which it runs.

  • Crossplane will then react on those Crossplane custom resources and from then on manage the lifecycle of the actual service instance, for example Redis.

The Service Catalog and the Crossplane Service Broker don’t necessarily have to run on the same Kubernetes cluster. For example, a Service Catalog can be installed on the Kubernetes cluster of a customer, while the Crossplane Service Broker might be running on a central and dedicated cluster.

Additionally, services managed by Crossplane may be provisioned outside of the cluster on which Crossplane is installed on. For example, Crossplane supports instantiating cloud resources from providers such as Google Cloud, Azure or AWS. Naturally, such resources don’t run on the cluster on which Crossplane is installed.