diff --git a/docs/getting-started-guides/clc.md b/docs/getting-started-guides/clc.md
index 121b6c1030..bd0804eb9b 100644
--- a/docs/getting-started-guides/clc.md
+++ b/docs/getting-started-guides/clc.md
@@ -218,7 +218,7 @@ We configure the Kubernetes cluster with the following features:
 We use the following to create the kubernetes cluster:
 
 * Kubernetes 1.1.7
-* Unbuntu 14.04
+* Ubuntu 14.04
 * Flannel 0.5.4
 * Docker 1.9.1-0~trusty
 * Etcd 2.2.2
diff --git a/docs/getting-started-guides/kops.md b/docs/getting-started-guides/kops.md
index 90ea6546a2..0b2381dd18 100644
--- a/docs/getting-started-guides/kops.md
+++ b/docs/getting-started-guides/kops.md
@@ -57,7 +57,7 @@ kops uses DNS for discovery, both inside the cluster and so that you can reach t
 from clients.
 
 kops has a strong opinion on the cluster name: it should be a valid DNS name.  By doing so you will
-no longer get your clusters confused, you can share clusters with your colleagues unambigiously,
+no longer get your clusters confused, you can share clusters with your colleagues unambiguously,
 and you can reach them without relying on remembering an IP address. 
 
 You can, and probably should, use subdomains to divide your clusters.  As our example we will use
diff --git a/docs/getting-started-guides/photon-controller.md b/docs/getting-started-guides/photon-controller.md
index ec9d9511fa..df9d14326a 100644
--- a/docs/getting-started-guides/photon-controller.md
+++ b/docs/getting-started-guides/photon-controller.md
@@ -163,7 +163,7 @@ balancer. Specifically:
 Configure your service with the NodePort option. For example, this
 service uses the NodePort option. All Kubernetes nodes will listen on
 a port and forward network traffic to any pods in the service. In this
-case, Kubernets will choose a random port, but it will be the same
+case, Kubernetes will choose a random port, but it will be the same
 port on all nodes.
 
 ```yaml
diff --git a/docs/getting-started-guides/scratch.md b/docs/getting-started-guides/scratch.md
index dd554c5715..2ef0f75dc3 100644
--- a/docs/getting-started-guides/scratch.md
+++ b/docs/getting-started-guides/scratch.md
@@ -69,7 +69,7 @@ accomplished in two ways:
 
 - **Using an overlay network**
   - An overlay network obscures the underlying network architecture from the 
-    pod network through traffic encapsulation (e.g vxlan).
+    pod network through traffic encapsulation (e.g. vxlan).
   - Encapsulation reduces performance, though exactly how much depends on your solution.
 - **Without an overlay network**
   - Configure the underlying network fabric (switches, routers, etc.) to be aware of pod IP addresses.
@@ -180,7 +180,7 @@ we recommend that you run these as containers, so you need an image to be built.
 You have several choices for Kubernetes images:
 
 - Use images hosted on Google Container Registry (GCR):
-  - e.g `gcr.io/google_containers/hyperkube:$TAG`, where `TAG` is the latest
+  - e.g. `gcr.io/google_containers/hyperkube:$TAG`, where `TAG` is the latest
     release tag, which can be found on the [latest releases page](https://github.com/kubernetes/kubernetes/releases/latest).
   - Ensure $TAG is the same tag as the release tag you are using for kubelet and kube-proxy.
   - The [hyperkube](https://releases.k8s.io/{{page.githubbranch}}/cmd/hyperkube) binary is an all in one binary
diff --git a/docs/tutorials/stateful-application/basic-stateful-set.md b/docs/tutorials/stateful-application/basic-stateful-set.md
index 07e41cd56d..0edf9f9d38 100644
--- a/docs/tutorials/stateful-application/basic-stateful-set.md
+++ b/docs/tutorials/stateful-application/basic-stateful-set.md
@@ -122,7 +122,7 @@ launching `web-1`. In fact, `web-1` is not launched until `web-0` is
 [Running and Ready](/docs/user-guide/pod-states). 
 
 ### Pods in a StatefulSet
-Unlike Pods in other controllers, the Pods in a StatefulSet have a unqiue 
+Unlike Pods in other controllers, the Pods in a StatefulSet have a unique 
 ordinal index and a stable network identity.
 
 #### Examining the Pod's Ordinal Index
@@ -177,7 +177,7 @@ Name:      web-1.nginx
 Address 1: 10.244.2.6
 ```
 
-The CNAME of the headless serivce points to SRV records (one for each Pod that 
+The CNAME of the headless service points to SRV records (one for each Pod that 
 is Running and Ready). The SRV records point to A record entries that 
 contain the Pods' IP addresses.