fix typos

9 files changed, 12 insertions, 12 deletions

diff --git a/contributors/design-proposals/api-machinery/api-chunking.md b/contributors/design-proposals/api-machinery/api-chunking.md
index 0a099fd3..a04c9ba4 100644
--- a/contributors/design-proposals/api-machinery/api-chunking.md
+++ b/contributors/design-proposals/api-machinery/api-chunking.md
@@ -89,7 +89,7 @@ Implementations that cannot offer consistent ranging (returning a set of results
 
 #### etcd3
 
-For etcd3 the continue token would contain a resource version (the snapshot that we are reading that is consistent across the entire LIST) and the start key for the next set of results. Upon receiving a valid continue token the apiserver would instruct etcd3 to retrieve the set of results at a given resource version, beginning at the provided start key, limited by the maximum number of requests provided by the continue token (or optionally, by a different limit specified by the client). If more results remain after reading up to the limit, the  storage should calculate a continue token that would begin at the next possible key, and the continue token set on the returned list.
+For etcd3 the continue token would contain a resource version (the snapshot that we are reading that is consistent across the entire LIST) and the start key for the next set of results. Upon receiving a valid continue token the apiserver would instruct etcd3 to retrieve the set of results at a given resource version, beginning at the provided start key, limited by the maximum number of requests provided by the continue token (or optionally, by a different limit specified by the client). If more results remain after reading up to the limit, the storage should calculate a continue token that would begin at the next possible key, and the continue token set on the returned list.
 
 The storage layer in the apiserver must apply consistency checking to the provided continue token to ensure that malicious users cannot trick the server into serving results outside of its range. The storage layer must perform defensive checking on the provided value, check for path traversal attacks, and have stable versioning for the continue token.
 
diff --git a/contributors/design-proposals/api-machinery/auditing.md b/contributors/design-proposals/api-machinery/auditing.md
index 67f34122..2770f56d 100644
--- a/contributors/design-proposals/api-machinery/auditing.md
+++ b/contributors/design-proposals/api-machinery/auditing.md
@@ -35,7 +35,7 @@ while
 
 ## Constraints and Assumptions
 
-* it is not the goal to implement all output formats one can imagine. The  main goal is to be extensible with a clear golang interface. Implementations of e.g. CADF must be possible, but won't be discussed here.
+* it is not the goal to implement all output formats one can imagine. The main goal is to be extensible with a clear golang interface. Implementations of e.g. CADF must be possible, but won't be discussed here.
 * dynamic loading of backends for new output formats are out of scope.
 
 ## Use Cases
diff --git a/contributors/design-proposals/api-machinery/customresource-conversion-webhook.md b/contributors/design-proposals/api-machinery/customresource-conversion-webhook.md
index dbcf4221..2b4aeb25 100644
--- a/contributors/design-proposals/api-machinery/customresource-conversion-webhook.md
+++ b/contributors/design-proposals/api-machinery/customresource-conversion-webhook.md
@@ -12,7 +12,7 @@ Thanks: @dbsmith, @deads2k, @sttts, @liggit, @enisoc
 
 ### Summary
 
-This document proposes a detailed plan for adding support for version-conversion of  Kubernetes resources defined via Custom Resource Definitions (CRD).  The API Server is extended to call out to a webhook at appropriate parts of the handler stack for CRDs.  
+This document proposes a detailed plan for adding support for version-conversion of Kubernetes resources defined via Custom Resource Definitions (CRD).  The API Server is extended to call out to a webhook at appropriate parts of the handler stack for CRDs.  
 
 No new resources are added; the [CRD resource](https://github.com/kubernetes/kubernetes/blob/34383aa0a49ab916d74ea897cebc79ce0acfc9dd/staging/src/k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/types.go#L187) is extended to include conversion information as well as multiple schema definitions, one for each apiVersion that is to be served.
 
diff --git a/contributors/design-proposals/api-machinery/metadata-policy.md b/contributors/design-proposals/api-machinery/metadata-policy.md
index 9d07186f..b9a78e36 100644
--- a/contributors/design-proposals/api-machinery/metadata-policy.md
+++ b/contributors/design-proposals/api-machinery/metadata-policy.md
@@ -20,7 +20,7 @@ admission controller that uses code, rather than configuration, to map the
 resource requests and limits of a pod to QoS, and attaches the corresponding
 annotation.)
 
-We anticipate a  number of other uses for `MetadataPolicy`, such as defaulting
+We anticipate a number of other uses for `MetadataPolicy`, such as defaulting
 for labels and annotations, prohibiting/requiring particular labels or
 annotations, or choosing a scheduling policy within a scheduler. We do not
 discuss them in this doc.
diff --git a/contributors/design-proposals/apps/controller_history.md b/contributors/design-proposals/apps/controller_history.md
index 6e313ce8..2e1213ad 100644
--- a/contributors/design-proposals/apps/controller_history.md
+++ b/contributors/design-proposals/apps/controller_history.md
@@ -267,7 +267,7 @@ ControllerRevisions, this approach is reasonable.
     - A revision is considered to be live while any generated Object labeled 
      with its `.Name` is live.
     - This method has the benefit of providing visibility, via the label, to 
-    users with respect to the historical  provenance of a generated Object.
+    users with respect to the historical provenance of a generated Object.
     - The primary drawback is the lack of support for using garbage collection 
     to ensure that only non-live version snapshots are collected.
 1. Controllers may also use the `OwnerReferences` field of the 
diff --git a/contributors/design-proposals/apps/selector-generation.md b/contributors/design-proposals/apps/selector-generation.md
index e0b3bf22..2f3a6b49 100644
--- a/contributors/design-proposals/apps/selector-generation.md
+++ b/contributors/design-proposals/apps/selector-generation.md
@@ -61,7 +61,7 @@ think about it.
 about uniqueness, just labeling for user's own reasons.
 - Defaulting logic sets `job.spec.selector` to
 `matchLabels["controller-uid"]="$UIDOFJOB"`
-- Defaulting logic  appends 2 labels to the `.spec.template.metadata.labels`.
+- Defaulting logic appends 2 labels to the `.spec.template.metadata.labels`.
   - The first label is controller-uid=$UIDOFJOB.
   - The second label is "job-name=$NAMEOFJOB".
 
diff --git a/contributors/design-proposals/apps/statefulset-update.md b/contributors/design-proposals/apps/statefulset-update.md
index b4089011..06fd291e 100644
--- a/contributors/design-proposals/apps/statefulset-update.md
+++ b/contributors/design-proposals/apps/statefulset-update.md
@@ -304,7 +304,7 @@ as follows.
     should be consistent with the version indicated by `Status.UpdateRevision`.
     1. If the Pod does not meet either of the prior two conditions, and if 
     ordinal is in the sequence `[0, .Spec.UpdateStrategy.Partition.Ordinal)`, 
-    it should  be consistent with the version indicated by 
+    it should be consistent with the version indicated by 
     `Status.CurrentRevision`.
     1. Otherwise, the Pod should be consistent with the version indicated 
     by `Status.UpdateRevision`.
@@ -446,7 +446,7 @@ object if any of the following conditions are true.
     1. `.Status.UpdateReplicas` is negative or greater than `.Status.Replicas`.
    
 ## Kubectl
-Kubectl will  use the `rollout` command to control and provide the status of 
+Kubectl will use the `rollout` command to control and provide the status of 
 StatefulSet updates.
 
  - `kubectl rollout status statefulset <StatefulSet-Name>`: displays the status 
@@ -648,7 +648,7 @@ spec:
 ### Phased Roll Outs
 Users can create a canary using `kubectl apply`. The only difference between a
  [canary](#canaries) and a phased roll out is that the 
- `.Spec.UpdateStrategy.Partition.Ordinal` is set to  a value less than 
+ `.Spec.UpdateStrategy.Partition.Ordinal` is set to a value less than 
  `.Spec.Replicas-1`.
  
 ```yaml
@@ -810,7 +810,7 @@ intermittent compaction as a form of garbage collection. Applications that use
 log structured merge trees with size tiered compaction (e.g Cassandra) or append 
 only B(+/*) Trees (e.g Couchbase) can temporarily double their storage requirement 
 during compaction. If there is insufficient space for compaction 
-to progress, these applications will either fail or degrade  until 
+to progress, these applications will either fail or degrade until 
 additional capacity is added. While, if the user is using AWS EBS or GCE PD, 
 there are valid manual workarounds to expand the size of a PD, it would be 
 useful to automate the resize via updates to the StatefulSet's 
diff --git a/contributors/design-proposals/auth/no-new-privs.md b/contributors/design-proposals/auth/no-new-privs.md
index b467c35d..5c96c9d1 100644
--- a/contributors/design-proposals/auth/no-new-privs.md
+++ b/contributors/design-proposals/auth/no-new-privs.md
@@ -49,7 +49,7 @@ while creating containers, for example
 `docker run --security-opt=no_new_privs busybox`.
 
 Docker provides via their Go api an object named `ContainerCreateConfig` to
-configure container creation  parameters. In this object, there is a string
+configure container creation parameters. In this object, there is a string
 array `HostConfig.SecurityOpt` to specify the security options. Client can
 utilize this field to specify the arguments for security options while
 creating new containers.
diff --git a/contributors/design-proposals/auth/security_context.md b/contributors/design-proposals/auth/security_context.md
index d7a3e458..360f5046 100644
--- a/contributors/design-proposals/auth/security_context.md
+++ b/contributors/design-proposals/auth/security_context.md
@@ -42,7 +42,7 @@ containers.
 
 In order to support external integration with shared storage, processes running
 in a Kubernetes cluster should be able to be uniquely identified by their Unix
-UID, such that a chain of  ownership can be established. Processes in pods will
+UID, such that a chain of ownership can be established. Processes in pods will
 need to have consistent UID/GID/SELinux category labels in order to access
 shared disks.