Fix service-catalog usage of apiserver aggregation

The Service Catalog architecture changed from using api aggregation to CRDs, but the docs still refer to the older architecture using api aggregation.

Couple of changes here:
1. Change the sentence on how Service Catalog is implemented
2. Replace the example for usage of api aggregation from service-catalog to metrics-server. There are multiple implementations that can be linked to(keda, prometheus, datadog,...), but keeping the documentation neutral by pointing to kubernetes-sigs/metrics-server

References:
- Service Catalog [v0.3.0 release notes](https://github.com/kubernetes-sigs/service-catalog/releases/tag/v0.3.0):

> In release 0.3.0, we've focused on replacing the Aggregated API Server with the CustomResourceDefinitions (CRDs) and the Admission Webhook solution.

- Project [README](https://github.com/kubernetes-sigs/service-catalog/pull/2691/files)
> Service Catalog recently switched to a new CRDs-based architecture. The old API Server-based implementation is available on the v0.2 branch. We support this implementation by providing bug fixes until July 2020.
pull/29635/head
deepsan 2021-09-07 14:34:49 -07:00
parent cf9753423a
commit 84c2324c2b
2 changed files with 2 additions and 2 deletions

View File

@ -11,7 +11,7 @@ weight: 20
<!-- overview -->
The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs.
The additional APIs can either be ready-made solutions such as [service-catalog](/docs/concepts/extend-kubernetes/service-catalog/), or APIs that you develop yourself.
The additional APIs can either be ready-made solutions such as a [metrics server](https://github.com/kubernetes-sigs/metrics-server), or APIs that you develop yourself.
The aggregation layer is different from [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} recognise new kinds of object.

View File

@ -32,7 +32,7 @@ The application can access the message queue as a service.
Service Catalog uses the [Open service broker API](https://github.com/openservicebrokerapi/servicebroker) to communicate with service brokers, acting as an intermediary for the Kubernetes API Server to negotiate the initial provisioning and retrieve the credentials necessary for the application to use a managed service.
It is implemented as an extension API server and a controller, using etcd for storage. It also uses the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) available in Kubernetes 1.7+ to present its API.
It is implemented using a [CRDs-based](/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) architecture.
<br>