From 0f73f145fa168634a6c55862bfe2320e14389e55 Mon Sep 17 00:00:00 2001 From: Anthony Date: Mon, 14 Aug 2017 16:27:14 +0800 Subject: [PATCH] Update apiserver-aggregation.md modify "their API" to "an API" --- docs/concepts/api-extension/apiserver-aggregation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/api-extension/apiserver-aggregation.md b/docs/concepts/api-extension/apiserver-aggregation.md index 74f4ee8b27..b246da369b 100644 --- a/docs/concepts/api-extension/apiserver-aggregation.md +++ b/docs/concepts/api-extension/apiserver-aggregation.md @@ -18,7 +18,7 @@ The aggregation layer allows Kubernetes to be extended with additional APIs, bey The aggregation layer enables installing additional Kubernetes-style APIs in your cluster. These can either be pre-built, existing 3rd party solutions, such as [service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md), or user-created APIs like [apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md), which can get you started. -In 1.7 the aggregation layer runs in-process with the kube-apiserver. Until an extension resource is registered, the aggregation layer will do nothing. To register their API, users must 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. +In 1.7 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, users must 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. Ordinarily, the APIService will be implemented by an *extension-apiserver* in a pod running in the cluster. This extension-apiserver will normally need to be paired with one or more controllers if active management of the added resources is needed. As a result, the apiserver-builder will actually provide a skeleton for both. As another example, when the service-catalog is installed, it provides both the extension-apiserver and controller for the services it provides.