correct some words

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

correct again

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

contributors/design-proposals/container-runtime-interface-v1.md

@@ -225,7 +225,7 @@ applicable to its platform, and should return an error otherwise.
 ### Keep it minimal
 
 The proposed interface is experimental, i.e., it will go through (many) changes
-until it stabilizes. The principle is to to keep the interface minimal and
+until it stabilizes. The principle is to keep the interface minimal and
 extend it later if needed. This includes a several features that are still in
 discussion and may be achieved alternatively:
 

contributors/design-proposals/control-plane-resilience.md

@@ -10,9 +10,9 @@
 
 Some amount of confusion exists around how we currently, and in future
 want to ensure resilience of the Kubernetes (and by implication
-Kubernetes Cluster Federation) control plane.  This document is an attempt to capture that
+Kubernetes Cluster Federation) control plane. This document is an attempt to capture that
 definitively. It covers areas including self-healing, high
-availability, bootstrapping and recovery.  Most of the information in
+availability, bootstrapping and recovery. Most of the information in
 this document already exists in the form of github comments,
 PR's/proposals, scattered documents, and corridor conversations, so
 document is primarily a consolidation and clarification of existing
@@ -23,7 +23,7 @@ ideas.
 * **Self-healing:** automatically restarting or replacing failed
   processes and machines without human intervention
 * **High availability:** continuing to be available and work correctly
-  even if some components are down or uncontactable.  This typically
+  even if some components are down or uncontactable. This typically
   involves multiple replicas of critical services, and a reliable way
   to find available replicas. Note that it's possible (but not
   desirable) to have high

contributors/design-proposals/deploy.md

@@ -121,7 +121,7 @@ See issue [#17164](https://github.com/kubernetes/kubernetes/issues/17164).
 We store previous deployment version information in annotations `rollout.kubectl.kubernetes.io/change-source` and `rollout.kubectl.kubernetes.io/version` of replication controllers of the deployment, to support rolling back changes as well as for the users to view previous changes with `kubectl rollout history`.
 - `rollout.kubectl.kubernetes.io/change-source`, which is optional, records the kubectl command of the last mutation made to this rollout. Users may use `--record` in `kubectl` to record current command in this annotation.
 - `rollout.kubectl.kubernetes.io/version` records a version number to distinguish the change sequence of a deployment's
-replication controllers. A deployment obtains the largest version number from its replication controllers and increments the number by 1 upon update or creation of the deployment, and update the version annotation of its new replication controller.
+replication controllers. A deployment obtains the largest version number from its replication controllers and increments the number by 1 upon update or creation of the deployment, and updates the version annotation of its new replication controller.
 
 When the users perform a rollback, i.e. `kubectl rollout undo`, the deployment first looks at its existing replication controllers, regardless of their number of replicas. Then it finds the one with annotation `rollout.kubectl.kubernetes.io/version` that either contains the specified rollback version number or contains the second largest version number among all the replication controllers (current new replication controller should obtain the largest version number) if the user didn't specify any version number (the user wants to rollback to the last change). Lastly, it
 starts scaling up that replication controller it's rolling back to, and scaling down the current ones, and then update the version counter and the rollout annotations accordingly.