Merge pull request #1588 from zhxcai/typos

Fix some typos

6 files changed, 7 insertions, 7 deletions

diff --git a/contributors/design-proposals/storage/grow-volume-size.md b/contributors/design-proposals/storage/grow-volume-size.md
index 4ef2ab2c..e43680bd 100644
--- a/contributors/design-proposals/storage/grow-volume-size.md
+++ b/contributors/design-proposals/storage/grow-volume-size.md
@@ -78,7 +78,7 @@ new controller will be:
   for same volume then resize request will be pending and retried once previous resize request has completed.
 * Controller resize in effect will be level based rather than edge based. If there are more than one pending resize request for same PVC then
   new resize requests for same PVC will replace older pending request.
-* Resize will be performed via volume plugin interface, executed inside a goroutine spawned by `operation_exectutor`.
+* Resize will be performed via volume plugin interface, executed inside a goroutine spawned by `operation_executor`.
 * A new plugin interface called `volume.Expander` will be added to volume plugin interface. The `Expander` interface
   will also define if volume requires a file system resize:
 
diff --git a/contributors/design-proposals/storage/local-storage-overview.md b/contributors/design-proposals/storage/local-storage-overview.md
index de1298a0..708f6600 100644
--- a/contributors/design-proposals/storage/local-storage-overview.md
+++ b/contributors/design-proposals/storage/local-storage-overview.md
@@ -213,7 +213,7 @@ The term `Partitions` are used here to describe the main use cases for local sto
     apiVersion: storage.k8s.io/v1
     metadata:
       name: local-fast
-    toplogyKey: kubernetes.io/hostname
+    topologyKey: kubernetes.io/hostname
     ```
     ```yaml
     kind: PersistentVolume
@@ -388,7 +388,7 @@ The term `Partitions` are used here to describe the main use cases for local sto
        - name: myEphemeralPersistentVolume
          mountPath: /mnt/tmpdata
      volumes:
-     - name: myEphemeralPeristentVolume
+     - name: myEphemeralPersistentVolume
        inline:
          spec:
            accessModes: [ "ReadWriteOnce" ]
diff --git a/contributors/design-proposals/storage/local-storage-pv.md b/contributors/design-proposals/storage/local-storage-pv.md
index d397c681..524c0444 100644
--- a/contributors/design-proposals/storage/local-storage-pv.md
+++ b/contributors/design-proposals/storage/local-storage-pv.md
@@ -506,7 +506,7 @@ The boostrapper requires the following permissions:
 * Create ClusterRoleBindings
 * Create DaemonSet
 
-Since the boostrapper generates the DaemonSet spec, the ConfigMap can be simplifed to just specify the
+Since the boostrapper generates the DaemonSet spec, the ConfigMap can be simplified to just specify the
 host directories:
 
 ```
diff --git a/contributors/design-proposals/storage/mount-options.md b/contributors/design-proposals/storage/mount-options.md
index 099e8602..f0ab51b1 100644
--- a/contributors/design-proposals/storage/mount-options.md
+++ b/contributors/design-proposals/storage/mount-options.md
@@ -9,7 +9,7 @@ such as  - `nfs`, `glusterfs` or `aws-ebs` etc.
 
 We currently support network filesystems: NFS, Glusterfs, Ceph FS, SMB (Azure file), Quobytes, and local filesystems such as ext[3|4] and XFS.
 
-Mount time options that are operationally important and have no security implications should be suppported. Examples are NFS's TCP mode, versions, lock mode, caching mode; Glusterfs's caching mode; SMB's version, locking, id mapping; and more.
+Mount time options that are operationally important and have no security implications should be supported. Examples are NFS's TCP mode, versions, lock mode, caching mode; Glusterfs's caching mode; SMB's version, locking, id mapping; and more.
 
 ## Design
 
diff --git a/contributors/design-proposals/storage/pod-safety.md b/contributors/design-proposals/storage/pod-safety.md
index cca09292..3976e47b 100644
--- a/contributors/design-proposals/storage/pod-safety.md
+++ b/contributors/design-proposals/storage/pod-safety.md
@@ -1,4 +1,4 @@
-# Pod Safety, Consistency Guarantees, and Storage Implicitions
+# Pod Safety, Consistency Guarantees, and Storage Implications
 
 @smarterclayton @bprashanth
 
diff --git a/contributors/design-proposals/testing/flakiness-sla.md b/contributors/design-proposals/testing/flakiness-sla.md
index b76be2f0..efed5e96 100644
--- a/contributors/design-proposals/testing/flakiness-sla.md
+++ b/contributors/design-proposals/testing/flakiness-sla.md
@@ -6,12 +6,12 @@ Agreement) for flakiness in our tests, as well as actions that we will
 take when we are out of SLA.
 
 ## Definition of "We"
+
 Throughout the document the term _we_ is used. This is intended to refer
 to the Kubernetes project as a whole, and any governance structures the
 project puts in place. It is not intended to refer to any specific group
 of individuals.
 
-
 ## Definition of a "Flake"
 
 We'll start by the definition of a _flake_. _Flakiness_ is defined for a