summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGuangya Liu <gyliu513@gmail.com>2017-02-06 09:55:29 +0800
committerGuangya Liu <gyliu513@gmail.com>2017-02-06 09:55:29 +0800
commit9dcebd3f830195f14f255dcc0b785eb40cb64905 (patch)
treec099c20140cd6bb2f59100f84239ef6bd5aa6709
parentbd16e4964fe9f3d9103049141ab931e18a61ddb8 (diff)
Fixed typo in aggregated-api-servers.md.
-rw-r--r--contributors/design-proposals/aggregated-api-servers.md4
1 files changed, 2 insertions, 2 deletions
diff --git a/contributors/design-proposals/aggregated-api-servers.md b/contributors/design-proposals/aggregated-api-servers.md
index 5b3a10c3..37cda329 100644
--- a/contributors/design-proposals/aggregated-api-servers.md
+++ b/contributors/design-proposals/aggregated-api-servers.md
@@ -80,7 +80,7 @@ There are two configurations in which it makes sense to run `kube-aggregator`.
`api.mycompany.com/v2` from another apiserver while you update clients. But
you can't serve `api.mycompany.com/v1/frobbers` and
`api.mcompany.com/v1/grobinators` from different apiservers. This restriction
- allows us to limit the scope of `kube-aggregator` to a managable level.
+ allows us to limit the scope of `kube-aggregator` to a manageable level.
* 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
@@ -160,7 +160,7 @@ Since the actual server which serves client's request can be opaque to the clien
all API servers need to have homogeneous authentication and authorisation mechanisms.
All API servers will handle authn and authz for their resources themselves.
The current authentication infrastructure allows token authentication delegation to the
-core `kube-apiserver` and trust of an authentication proxy, which can be fullfilled by
+core `kube-apiserver` and trust of an authentication proxy, which can be fulfilled by
`kubernetes-aggregator`.
#### Server Role Bootstrapping