Spelling fixes inspired by github.com/client9/misspell

docs/design/clustering/dynamic.seqdiag

@@ -15,7 +15,7 @@ seqdiag {
 
   user ->> kubelet [label="start\n- bootstrap-cluster-uri"];
   kubelet => bootstrap [label="get-master", return="returns\n- master-location\n- master-ca"];
-  kubelet ->> master [label="signCert\n- unsigned-kubelet-cert", return="retuns\n- kubelet-cert"];
+  kubelet ->> master [label="signCert\n- unsigned-kubelet-cert", return="returns\n- kubelet-cert"];
   user => master [label="getSignRequests"];
   user => master [label="approveSignRequests"];
   kubelet <<-- master [label="returns\n- kubelet-cert"];

docs/design/enhance-pluggable-policy.md

@@ -54,7 +54,7 @@ An API request has the following attributes that can be considered for authoriza
   - resourceVersion - the API version of the resource being accessed
   - resource - which resource is being accessed
     - applies only to the API endpoints, such as
-        `/api/v1beta1/pods`.  For miscelaneous endpoints, like `/version`, the kind is the empty string.
+        `/api/v1beta1/pods`.  For miscellaneous endpoints, like `/version`, the kind is the empty string.
   - resourceName - the name of the resource during a get, update, or delete action.
   - subresource - which subresource is being accessed
 

docs/design/indexed-job.md

@@ -33,18 +33,18 @@ Documentation for other releases can be found at
 ## Summary
 
 This design extends kubernetes with user-friendly support for
-running embarassingly parallel jobs.
+running embarrassingly parallel jobs.
 
 Here, *parallel* means on multiple nodes, which means multiple pods.
-By *embarassingly parallel*,  it is meant that the pods
+By *embarrassingly parallel*,  it is meant that the pods
 have no dependencies between each other.  In particular, neither
 ordering between pods nor gang scheduling are supported.
 
-Users already have two other options for running embarassingly parallel
+Users already have two other options for running embarrassingly parallel
 Jobs (described in the next section), but both have ease-of-use issues.
 
 Therefore, this document proposes extending the Job resource type to support
-a third way to run embarassingly parallel programs, with a focus on
+a third way to run embarrassingly parallel programs, with a focus on
 ease of use.
 
 This new style of Job is called an *indexed job*, because each Pod of the Job
@@ -53,7 +53,7 @@ is specialized to work on a particular *index* from a fixed length array of work
 ## Background
 
 The Kubernetes [Job](../../docs/user-guide/jobs.md) already supports
-the embarassingly parallel use case through *workqueue jobs*.
+the embarrassingly parallel use case through *workqueue jobs*.
 While [workqueue jobs](../../docs/user-guide/jobs.md#job-patterns)
  are very flexible, they can be difficult to use.
 They: (1) typically require running a message queue
@@ -242,7 +242,7 @@ In the above example:
 - `--restart=OnFailure` implies creating a job instead of replicationController.
 - Each pods command line is `/usr/local/bin/process_file $F`.
 - `--per-completion-env=` implies the jobs `.spec.completions` is set to the length of the argument array (3 in the example).
-- `--per-completion-env=F=<values>` causes env var with `F` to be available in the enviroment when the command line is evaluated.
+- `--per-completion-env=F=<values>` causes env var with `F` to be available in the environment when the command line is evaluated.
 
 How exactly this happens is discussed later in the doc: this is a sketch of the user experience.
 
@@ -269,7 +269,7 @@ Another case we do not try to handle is where the input file does not exist yet
 
 #### Multiple parameters
 
-The user may also have multiple paramters, like in [work list 2](#work-list-2).
+The user may also have multiple parameters, like in [work list 2](#work-list-2).
 One way is to just list all the command lines already expanded, one per line, in a file, like this:
 
 ```
@@ -491,7 +491,7 @@ The index-only approach:
 - requires that the user keep the *per completion parameters* in a separate storage, such as a configData or networked storage.
 - makes no changes to the JobSpec.
 - Drawback: while in separate storage, they could be mutatated, which would have unexpected effects
-- Drawback: Logic for using index to lookup paramters needs to be in the Pod.
+- Drawback: Logic for using index to lookup parameters needs to be in the Pod.
 - Drawback: CLIs and UIs are limited to using the "index" as the identity of a pod
   from a job.  They cannot easily say, for example `repeated failures on the pod processing banana.txt`.
 

docs/design/taint-toleration-dedicated.md

@@ -51,7 +51,7 @@ on a node but do not prevent it, taints that prevent a pod from starting on Kube
 if the pod's `NodeName` was written directly (i.e. pod did not go through the scheduler),
 and taints that evict already-running pods.
 [This comment](https://github.com/kubernetes/kubernetes/issues/3885#issuecomment-146002375)
-has more background on these diffrent scenarios. We will focus on the first
+has more background on these different scenarios. We will focus on the first
 kind of taint in this doc, since it is the kind required for the "dedicated nodes" use case.
 
 Implementing dedicated nodes using taints and tolerations is straightforward: in essence, a node that
@@ -264,7 +264,7 @@ their taint. Thus we need to ensure that a new node does not become "Ready" unti
 configured with its taints. One way to do this is to have an admission controller that adds the taint whenever
 a Node object is created.
 
-A quota policy may want to treat nodes diffrently based on what taints, if any,
+A quota policy may want to treat nodes differently based on what taints, if any,
 they have. For example, if a particular namespace is only allowed to access dedicated nodes,
 then it may be convenient to give the namespace unlimited quota. (To use finite quota,
 you'd have to size the namespace's quota to the sum of the sizes of the machines in the