From ef39f0c054f32b775aa9adb78db76520add79c6d Mon Sep 17 00:00:00 2001 From: Zhang Xingcai Date: Fri, 13 Oct 2017 23:02:42 +0800 Subject: [PATCH] Update aggregated-api-servers.md --- .../design-proposals/api-machinery/aggregated-api-servers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributors/design-proposals/api-machinery/aggregated-api-servers.md b/contributors/design-proposals/api-machinery/aggregated-api-servers.md index ae3f59e01..94bc9a429 100644 --- a/contributors/design-proposals/api-machinery/aggregated-api-servers.md +++ b/contributors/design-proposals/api-machinery/aggregated-api-servers.md @@ -82,7 +82,7 @@ There are two configurations in which it makes sense to run `kube-aggregator`. * Follow API conventions: APIs exposed by every API server should adhere to [kubernetes API conventions](../devel/api-conventions.md). * Support discovery API: Each API server should support the kubernetes discovery API - (list the suported groupVersions at `/apis` and list the supported resources + (list the supported groupVersions at `/apis` and list the supported resources at `/apis//`) * No bootstrap problem: The core kubernetes apiserver must not depend on any other aggregated server to come up. Non-core apiservers may use other non-core