Fixed some typo in community documents.

contributors/design-proposals/all-in-one-volume.md

@@ -12,7 +12,7 @@ is no way to achieve this in Kubernetes without scripting inside of a container.
 
 ## Constraints and Assumptions
 
-1.  The volume types must remain unchanged for backward compatability
+1.  The volume types must remain unchanged for backward compatibility
 2.  There will be a new volume type for this proposed functionality, but no
     other API changes
 3.  The new volume type should support atomic updates in the event of an input

contributors/design-proposals/core-metrics-pipeline.md

@@ -50,12 +50,12 @@ The [Monitoring Architecture](https://github.com/kubernetes/kubernetes/blob/mast
 By publishing core metrics, the kubelet is relieved of its responsibility to provide metrics for monitoring.
 The third party monitoring pipeline also is relieved of any responsibility to provide these metrics to system components.
 
-cAdvisor is structured to collect metrics on an interval, which is appropriate for a stand-alone metrics collector.  However, many functions in the kubelet are latency-sensitive (eviction, for example), and would benifit from a more "On-Demand" metrics collection design.
+cAdvisor is structured to collect metrics on an interval, which is appropriate for a stand-alone metrics collector.  However, many functions in the kubelet are latency-sensitive (eviction, for example), and would benefit from a more "On-Demand" metrics collection design.
 
 ### Proposal
 This proposal is to use this set of core metrics, collected by the kubelet, and used solely by kubernetes system components to support "First-Class Resource Isolation and Utilization Features".  This proposal is not designed to be an API published by the kubelet, but rather a set of metrics collected by the kubelet that will be transformed, and published in the future.
 
-The target "Users" of this set of metrics are kubernetes components (though not neccessarily directly).  This set of metrics itself is not designed to be user-facing, but is designed to be general enough to support user-facing components.
+The target "Users" of this set of metrics are kubernetes components (though not necessarily directly).  This set of metrics itself is not designed to be user-facing, but is designed to be general enough to support user-facing components.
 
 ### Non Goals
 Everything covered in the [Monitoring Architecture](https://github.com/kubernetes/kubernetes/blob/master/docs/design/monitoring_architecture.md) design doc will not be covered in this proposal.  This includes the third party metrics pipeline, and the methods by which the metrics found in this proposal are provided to other kubernetes components.
@@ -104,7 +104,7 @@ Metrics requirements for "First Class Resource Isolation and Utilization Feature
 
 ### Proposed Core Metrics:
 This section defines "usage metrics" for filesystems, CPU, and Memory.  
-As stated in Non-Goals, this proposal does not attempt to define the specific format by which these are exposed.  For convenience, it may be neccessary to include static information such as start time, node capacities for CPU, Memory, or filesystems, and more.
+As stated in Non-Goals, this proposal does not attempt to define the specific format by which these are exposed.  For convenience, it may be necessary to include static information such as start time, node capacities for CPU, Memory, or filesystems, and more.
 
 ```go
 // CpuUsage holds statistics about the amount of cpu time consumed  

contributors/design-proposals/daemonset-update.md

@@ -101,7 +101,7 @@ type RollingUpdateDaemonSet struct {
 
 // DaemonSetSpec is the specification of a daemon set.
 type DaemonSetSpec struct {
-	// Note: Existing fields, including Selector and Template are ommitted in
+	// Note: Existing fields, including Selector and Template are omitted in
 	// this proposal.  
 
 	// Update strategy to replace existing DaemonSet pods with new pods.
@@ -124,7 +124,7 @@ const (
 // DaemonSetStatus represents the current status of a daemon set.
 type DaemonSetStatus struct {
 	// Note: Existing fields, including CurrentNumberScheduled, NumberMissscheduled,
-	// DesiredNumberScheduled, NumberReady, and ObservedGeneration are ommitted in
+	// DesiredNumberScheduled, NumberReady, and ObservedGeneration are omitted in
 	// this proposal.
 
 	// UpdatedNumberScheduled is the total number of nodes that are running updated

contributors/design-proposals/federated-replicasets.md

@@ -391,7 +391,7 @@ Include federated replica set name in the cluster name hash so that we get
 slightly different ordering for different RS. So that not all RS of size 1
 end up on the same cluster.
 
-3. Assign minimum prefered number of replicas to each of the clusters, if
+3. Assign minimum preferred number of replicas to each of the clusters, if
 there is enough replicas and capacity.
 
 4. If rebalance = false, assign the previously present replicas to the clusters,

contributors/design-proposals/hpa-v2.md

@@ -1,4 +1,4 @@
-Horizontal Pod Autoscaler with Arbitary Metrics
+Horizontal Pod Autoscaler with Arbitrary Metrics
 ===============================================
 
 The current Horizontal Pod Autoscaler object only has support for CPU as

contributors/design-proposals/kubelet-rootfs-distribution.md

@@ -139,7 +139,7 @@ Similarly, for the mount utilities, the [Flex Volume v2](https://github.com/kube
 
 **Downsides**:
 
-This requires waiting on other features which might take a signficant time to land. It also could end up not fully fixing the problem (e.g. pushing down port-forwarding to the runtime doesn't ensure the runtime doesn't rely on host utilities).
+This requires waiting on other features which might take a significant time to land. It also could end up not fully fixing the problem (e.g. pushing down port-forwarding to the runtime doesn't ensure the runtime doesn't rely on host utilities).
 
 The Flex Volume feature is several releases out from fully replacing the current volumes as well.
 

contributors/design-proposals/multi-platform.md

@@ -131,7 +131,7 @@ TL;DR;
 
 ### Components should expose their platform
 
-It should be possible to run clusters with mixed platforms smoothly. After all, bringing heterogenous machines together to a single unit (a cluster) is one of Kubernetes' greatest strengths. And since the Kubernetes' components communicate over HTTP, two binaries of different architectures may talk to each other normally.
+It should be possible to run clusters with mixed platforms smoothly. After all, bringing heterogeneous machines together to a single unit (a cluster) is one of Kubernetes' greatest strengths. And since the Kubernetes' components communicate over HTTP, two binaries of different architectures may talk to each other normally.
 
 The crucial thing here is that the components that handle platform-specific tasks (e.g. kubelet) should expose their platform. In the kubelet case, we've initially solved it by exposing the labels `beta.kubernetes.io/{os,arch}` on every node. This way an user may run binaries for different platforms on a multi-platform cluster, but still it requires manual work to apply the label to every manifest.
 
@@ -206,7 +206,7 @@ However, before temporarily [deactivating builds](https://github.com/kubernetes/
 Go 1.5 introduced many changes. To name a few that are relevant to Kubernetes:
  - C was eliminated from the tree (it was earlier used for the bootstrap runtime).
  - All processors are used by default, which means we should be able to remove [lines like this one](https://github.com/kubernetes/kubernetes/blob/v1.2.0/cmd/kubelet/kubelet.go#L37)
- - The garbage collector became more efficent (but also [confused our latency test](https://github.com/golang/go/issues/14396)).
+ - The garbage collector became more efficient (but also [confused our latency test](https://github.com/golang/go/issues/14396)).
  - `linux/arm64` and `linux/ppc64le` were added as new ports.
  - The `GO15VENDOREXPERIMENT` was started. We switched from `Godeps/_workspace` to the native `vendor/` in [this PR](https://github.com/kubernetes/kubernetes/pull/24242).
  - It's not required to pre-build the whole standard library `std` when cross-compliling. [Details](#prebuilding-the-standard-library-std)
@@ -448,7 +448,7 @@ ARMv6       | arm    | 6     | -           | 32-bit
 ARMv7       | arm    | 7     | armhf       | 32-bit
 ARMv8       | arm64  | -     | aarch64     | 64-bit
 
-The compability between the versions is pretty straightforward, ARMv5 binaries may run on ARMv7 hosts, but not vice versa.
+The compatibility between the versions is pretty straightforward, ARMv5 binaries may run on ARMv7 hosts, but not vice versa.
 
 ## Cross-building docker images for linux
 

contributors/design-proposals/propagation.md

@@ -140,7 +140,7 @@ runtime support matrix and when that will be addressed.
 distros.
 
 1. (From @euank) Changing those mountflags may make docker even less stable,
-this may lock up kernel accidently or potentially leak mounts.
+this may lock up kernel accidentally or potentially leak mounts.
 
 
 ## Decision

contributors/devel/adding-an-APIGroup.md

@@ -45,7 +45,7 @@ cmd/libs/go2idl/ tool.
 
 Each type should be an exported struct (have a capitalized name). The struct
 should have the `TypeMeta` and `ObjectMeta` embeds. There should be a `Spec` and
-a `Status` field. If the object is soley a data storage object, and will not be
+a `Status` field. If the object is solely a data storage object, and will not be
 modified by a controller, the status field can be left off and the fields inside
 the `Spec` can be inlined directly into the struct.
 

contributors/devel/automation.md

@@ -104,7 +104,7 @@ kindness...)
 PRs should only need to be manually re-tested if you believe there was a flake
 during the original test. All flakes should be filed as an
 [issue](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Fflake).
-Once you find or file a flake a contributer (this may be you!) should request
+Once you find or file a flake a contributor (this may be you!) should request
 a retest with "@k8s-bot test this issue: #NNNNN", where NNNNN is replaced with
 the issue number you found or filed.
 

contributors/devel/gubernator.md

@@ -19,7 +19,7 @@
 [Gubernator](https://k8s-gubernator.appspot.com/) is a webpage for viewing and filtering Kubernetes
 test results.
 
-Gubernator simplifies the debugging proccess and makes it easier to track down failures by automating many
+Gubernator simplifies the debugging process and makes it easier to track down failures by automating many
 steps commonly taken in searching through logs, and by offering tools to filter through logs to find relevant lines.
 Gubernator automates the steps of finding the failed tests, displaying relevant logs, and determining the
 failed pods and the corresponing pod UID, namespace, and container ID.
@@ -83,7 +83,7 @@ included, the "Weave by timestamp" option can weave the selected logs together b
 
 *Currently Gubernator can only be used with remote node e2e tests.*
 
-**NOTE: Using Gubernator with local tests will publically upload your test logs to Google Cloud Storage**
+**NOTE: Using Gubernator with local tests will publicly upload your test logs to Google Cloud Storage**
 
 To use Gubernator to view logs from local test runs, set the GUBERNATOR tag to true.
 A URL link to view the test results will be printed to the console.