mirror of https://github.com/crossplane/docs.git
remove outdated reference to service catalog (#373)
This commit is contained in:
parent
3e6aa51602
commit
310b53f197
|
@ -32,7 +32,6 @@ describe each of these scenarios in greater detail.
|
|||
- [Multi-Cluster Multi-Tenancy](#multi-cluster-multi-tenancy)
|
||||
- [Reproducible Platforms with Configuration Packages](#reproducible-platforms-with-configuration-packages)
|
||||
- [Control Plane of Control Planes](#control-plane-of-control-planes)
|
||||
- [Service Provisioning using Open Service Broker API](#service-provisioning-using-open-service-broker-api)
|
||||
|
||||
## Background
|
||||
|
||||
|
@ -301,21 +300,6 @@ This advanced pattern allows for full management of Crossplane clusters using
|
|||
Crossplane itself, and when done properly, is a scalable solution to providing
|
||||
dedicated control planes to many tenants within a single organization.
|
||||
|
||||
### Service Provisioning using Open Service Broker API
|
||||
|
||||
Another way to achieve multi-cluster multi-tenancy is by leveraging the
|
||||
possibilities of the [Open Service Broker API] specification and tie it
|
||||
together with Crossplane.
|
||||
|
||||
A possible architecture could look like this: Crossplane and the
|
||||
[Crossplane Service Broker] are running on the central control plane cluster.
|
||||
The Crossplane objects which represent the service offerings and service plans,
|
||||
the XRDs and Compositions, leverage [provider-helm] to spin up service instances
|
||||
on one or many service clusters. The end-user uses the [Kubernetes Service Catalog]
|
||||
to order services via the Crossplane Service Broker. A demo of this concept can be
|
||||
found under [vshn/application-catalog-demo].
|
||||
|
||||
This way even a tight integration of Crossplane in to [Cloudfoundry] is possible.
|
||||
|
||||
<!-- Named Links -->
|
||||
[managed resources]: {{<ref "../../master/concepts/managed-resources" >}}
|
||||
|
|
Loading…
Reference in New Issue