correct some words

Signed-off-by: liwenqi <vikilwq@zju.edu.cn>

correct again

Signed-off-by: liwenqi <vikilwq@zju.edu.cn>

5 files changed, 8 insertions, 8 deletions

diff --git a/contributors/design-proposals/admission_control_limit_range.md b/contributors/design-proposals/admission_control_limit_range.md
index 06cce2cb..4821dfce 100644
--- a/contributors/design-proposals/admission_control_limit_range.md
+++ b/contributors/design-proposals/admission_control_limit_range.md
@@ -154,9 +154,9 @@ Per container, the following must hold true:
 
 Supported Defaults:
 
-1. Default - if the named resource has no enumerated value, the Limit is equal
+1. Default - if the named resource has no enumerated values, the Limit is equal
 to the Default
-2. DefaultRequest - if the named resource has no enumerated value, the Request
+2. DefaultRequest - if the named resource has no enumerated values, the Request
 is equal to the DefaultRequest
 
 **Type: Pod**
diff --git a/contributors/design-proposals/api-group.md b/contributors/design-proposals/api-group.md
index 435994fe..586cc7d6 100644
--- a/contributors/design-proposals/api-group.md
+++ b/contributors/design-proposals/api-group.md
@@ -49,7 +49,7 @@
 
     * for OpenShift v1 API, because it's currently registered at /oapi/v1, to be backward compatible, OpenShift may set prefix="oapi", group="".
 
-    * for other new third-party API, they should also use the prefix="apis" and choose the group and version. This can be done through the thirdparty API plugin mechanism in [13000](http://pr.k8s.io/13000).
+    * for other new third-party API, they should also use the prefix="apis" and choose the group and version. This can be done through the third-party API plugin mechanism in [13000](http://pr.k8s.io/13000).
 
 2. supporting API discovery:
 
diff --git a/contributors/design-proposals/apiserver-watch.md b/contributors/design-proposals/apiserver-watch.md
index 572074aa..2fc8900a 100644
--- a/contributors/design-proposals/apiserver-watch.md
+++ b/contributors/design-proposals/apiserver-watch.md
@@ -63,7 +63,7 @@ The rest of this section describes the concrete steps that need to be done
 to implement the proposal.
 
 1. Since we want the watch in apiserver to be optional for different resource
-types, this needs to be self-contained and hidden behind a well defined API.
+types, this needs to be self-contained and hidden behind a well-defined API.
 This should be a layer very close to etcd - in particular all registries:
 "pkg/registry/generic/registry" should be built on top of it.
 We will solve it by turning tools.EtcdHelper by extracting its interface
diff --git a/contributors/design-proposals/client-package-structure.md b/contributors/design-proposals/client-package-structure.md
index 2d30021d..9cbd6aa8 100644
--- a/contributors/design-proposals/client-package-structure.md
+++ b/contributors/design-proposals/client-package-structure.md
@@ -151,7 +151,7 @@ Where:
    resource.
 
 The types returned/consumed by such functions will be e.g. api/v1, NOT the
-current version inspecific types. The current internal-versioned client is
+current version in specific types. The current internal-versioned client is
 inconvenient for users, as it does not protect them from having to recompile
 their code with every minor update. (We may continue to generate an
 internal-versioned client for our own use for a while, but even for our own
@@ -235,7 +235,7 @@ We do this to:
   against their cluster, but we need to make guarantees that the clients we
   shipped with v1.X.0 will work with v1.X+1.0, and vice versa. That's not
   practical unless we "bless" a particular version of each API group and ship an
-  official client set with earch release. (If the server supports 15 groups with
+  official client set with each release. (If the server supports 15 groups with
   2 versions each, that's 2^15 different possible client sets. We don't want to
   test all of them.)
 
diff --git a/contributors/design-proposals/cluster-deployment.md b/contributors/design-proposals/cluster-deployment.md
index c6466f89..e9ca8d54 100644
--- a/contributors/design-proposals/cluster-deployment.md
+++ b/contributors/design-proposals/cluster-deployment.md
@@ -74,7 +74,7 @@ TODO: Enumerate certificates which have to be generated.
 **v1.2 simplifications**:
 
 1. kubelet-runner.sh - we will provide a custom docker image to run kubelet; it will contain
-kubelet binary and will run it using ```nsenter``` to workaround problem with mount propagation
+kubelet binary and will run it using ```nsenter``` to workaround problems with mount propagation
 1. kubelet config file - we will read kubelet configuration file from disk instead of apiserver; it will
 be generated locally and copied to all nodes.
 
@@ -125,7 +125,7 @@ network solutions.
 
 1. flannel daemon will run as a standalone binary (not in docker container)
 2. flannel server will assign CIDRs to nodes outside of kubernetes; this will require restarting kubelet
-after reconfiguring network bridge on local machine; this will also require running master nad node differently
+after reconfiguring network bridge on local machine; this will also require running master and node differently
 (```--configure-cbr0=false``` on node and ```--allocate-node-cidrs=false``` on master), which breaks encapsulation
 between nodes