deepsan
84c2324c2b
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.
41 lines
2.5 KiB
Markdown
41 lines
2.5 KiB
Markdown
---
|
|
title: Kubernetes API Aggregation Layer
|
|
reviewers:
|
|
- lavalamp
|
|
- cheftako
|
|
- chenopis
|
|
content_type: concept
|
|
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 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.
|
|
|
|
<!-- body -->
|
|
|
|
## Aggregation layer
|
|
|
|
The aggregation layer runs in-process with the kube-apiserver. Until an extension resource is registered, the aggregation layer will do nothing. To register an API, you add an _APIService_ object, which "claims" the URL path in the Kubernetes API. At that point, the aggregation layer will proxy anything sent to that API path (e.g. `/apis/myextension.mycompany.io/v1/…`) to the registered APIService.
|
|
|
|
The most common way to implement the APIService is to run an *extension API server* in Pod(s) that run in your cluster. If you're using the extension API server to manage resources in your cluster, the extension API server (also written as "extension-apiserver") is typically paired with one or more {{< glossary_tooltip text="controllers" term_id="controller" >}}. The apiserver-builder library provides a skeleton for both extension API servers and the associated controller(s).
|
|
|
|
### Response latency
|
|
|
|
Extension API servers should have low latency networking to and from the kube-apiserver.
|
|
Discovery requests are required to round-trip from the kube-apiserver in five seconds or less.
|
|
|
|
If your extension API server cannot achieve that latency requirement, consider making changes that let you meet it.
|
|
|
|
## {{% heading "whatsnext" %}}
|
|
|
|
* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/).
|
|
* Then, [setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer.
|
|
* Read about [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/) in the API reference
|
|
|
|
Alternatively: learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
|
|