Merge pull request #1335 from zhxcai/typo

Automatic merge from submit-queue.

fix some misspelled words

3 files changed, 4 insertions, 4 deletions

diff --git a/contributors/design-proposals/instrumentation/core-metrics-pipeline.md b/contributors/design-proposals/instrumentation/core-metrics-pipeline.md
index 0849aae4..7fc346da 100644
--- a/contributors/design-proposals/instrumentation/core-metrics-pipeline.md
+++ b/contributors/design-proposals/instrumentation/core-metrics-pipeline.md
@@ -32,7 +32,7 @@ This document proposes a design for the set of metrics included in an eventual C
 ["cAdvisor":](https://github.com/google/cadvisor) An open source container monitoring solution which only monitors containers, and has no concept of kubernetes constructs like pods or volumes.  
 ["Summary API":](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/stats/v1alpha1/types.go) A kubelet API which currently exposes node metrics for use by both system components and monitoring systems.  
 ["CRI":](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md) The Container Runtime Interface designed to provide an abstraction over runtimes (docker, rkt, etc).  
-"Core Metrics": A set of metrics described in the [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md) whose purpose is to provide metrics for first-class resource isolation and untilization features, including [resource feasibility checking](https://github.com/eBay/Kubernetes/blob/master/docs/design/resources.md#the-resource-model) and node resource management.
+"Core Metrics": A set of metrics described in the [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md) whose purpose is to provide metrics for first-class resource isolation and utilization features, including [resource feasibility checking](https://github.com/eBay/Kubernetes/blob/master/docs/design/resources.md#the-resource-model) and node resource management.
 "Resource": A consumable element of a node (e.g. memory, disk space, CPU time, etc).  
 "First-class Resource": A resource critical for scheduling, whose requests and limits can be (or soon will be) set via the Pod/Container Spec.  
 "Metric": A measure of consumption of a Resource.  
diff --git a/contributors/design-proposals/instrumentation/custom-metrics-api.md b/contributors/design-proposals/instrumentation/custom-metrics-api.md
index a730d4d4..bc0cc67f 100644
--- a/contributors/design-proposals/instrumentation/custom-metrics-api.md
+++ b/contributors/design-proposals/instrumentation/custom-metrics-api.md
@@ -307,7 +307,7 @@ repository will most likely also house other metrics-related APIs for
 Kubernetes (e.g. historical metrics API definitions, the resource metrics
 API definitions, etc).
 
-Note that there will not be a canonical implemenation of the custom
+Note that there will not be a canonical implementation of the custom
 metrics API under Kubernetes, just the types and clients.  Implementations
 will be left up to the monitoring pipelines.
 
diff --git a/contributors/design-proposals/storage/raw-block-pv.md b/contributors/design-proposals/storage/raw-block-pv.md
index d4132c78..6ac48d1e 100644
--- a/contributors/design-proposals/storage/raw-block-pv.md
+++ b/contributors/design-proposals/storage/raw-block-pv.md
@@ -539,12 +539,12 @@ It is important the values that are passed to the container runtimes are valid a
 
 The accessModes would be passed as part of the options array and would need validate against the specific runtime engine. 
 Since rkt doesn't use the CRI, the config values would need to be passed in the legacy method.
-Note: the container runtime doesn't require a privileged pod to enable the device as RWX (RMW), but still requires privileges to mount as is consistent with the filesystem implemenatation today.
+Note: the container runtime doesn't require a privileged pod to enable the device as RWX (RMW), but still requires privileges to mount as is consistent with the filesystem implementation today.
 
 The runtime option would be placed in the DeviceInfo as such:
 devices = append(devices, kubecontainer.DeviceInfo{PathOnHost: path, PathInContainer: path, Permissions: "XXX"}) 
 
-The implemenation plan would be to rename the current makeDevices to makeGPUDevices and create a separate function to add the raw block devices to the option array to be passed to the container runtime. This would iterate on the paths passed in for the pod/container.
+The implementation plan would be to rename the current makeDevices to makeGPUDevices and create a separate function to add the raw block devices to the option array to be passed to the container runtime. This would iterate on the paths passed in for the pod/container.
 
 Since the future of this in Kubernetes for GPUs and other plug-able devices is migrating to a device plugin architecture, there are 
 still differentiating components of storage that are enough to not to enforce alignment to their convention. Two factors when