Fix some typos

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:
 

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" ]

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:
 
 ```

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
 

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
 

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