diff --git a/docs/concepts/cluster-administration/access-cluster.md b/docs/concepts/cluster-administration/access-cluster.md
index d61e04fa56..27942f2175 100644
--- a/docs/concepts/cluster-administration/access-cluster.md
+++ b/docs/concepts/cluster-administration/access-cluster.md
@@ -14,7 +14,7 @@ Kubernetes CLI, `kubectl`.
 
 To access a cluster, you need to know the location of the cluster and have credentials
 to access it.  Typically, this is automatically set-up when you work through
-though a [Getting started guide](/docs/getting-started-guides/),
+a [Getting started guide](/docs/getting-started-guides/),
 or someone else setup the cluster and provided you with credentials and a location.
 
 Check the location and credentials that kubectl knows about with this command:
diff --git a/docs/tasks/debug-application-cluster/logging-stackdriver.md b/docs/tasks/debug-application-cluster/logging-stackdriver.md
index b382d0faf7..b2946616a4 100644
--- a/docs/tasks/debug-application-cluster/logging-stackdriver.md
+++ b/docs/tasks/debug-application-cluster/logging-stackdriver.md
@@ -5,7 +5,7 @@ assignees:
 title: Logging Using Stackdriver
 ---
 
-Before reading this page, it's highly recommended to familiasrize yourself with the [overview of logging in Kubernetes](/docs/user-guide/logging/overview).
+Before reading this page, it's highly recommended to familiarize yourself with the [overview of logging in Kubernetes](/docs/user-guide/logging/overview).
 
 This article assumes that you have created a Kubernetes cluster with cluster-level logging support for sending logs to Stackdriver Logging. You can do this either by selecting the  **Enable Stackdriver Logging** checkbox in the create cluster dialogue in [GKE](https://cloud.google.com/container-engine/), or by setting the `KUBE_LOGGING_DESTINATION` flag to `gcp` when manually starting a cluster using `kube-up.sh`.
 
diff --git a/docs/user-guide/accessing-the-cluster.md b/docs/user-guide/accessing-the-cluster.md
index 10440383c9..53bcd7b926 100644
--- a/docs/user-guide/accessing-the-cluster.md
+++ b/docs/user-guide/accessing-the-cluster.md
@@ -1,10 +1,10 @@
----
-assignees:
-- lavalamp
-- mikedanese
-title: Accessing Clusters
----
-
-{% include user-guide-content-moved.md %}
-
+---
+assignees:
+- lavalamp
+- mikedanese
+title: Accessing Clusters
+---
+
+{% include user-guide-content-moved.md %}
+
 [Accessing Clusters](/docs/concepts/cluster-administration/access-cluster/)
\ No newline at end of file
diff --git a/docs/user-guide/introspection-and-debugging.md b/docs/user-guide/introspection-and-debugging.md
index 47d1293900..ff0bb99539 100644
--- a/docs/user-guide/introspection-and-debugging.md
+++ b/docs/user-guide/introspection-and-debugging.md
@@ -120,7 +120,6 @@ A common scenario that you can detect using events is when you've created a Pod
 
 ```shell
 $ kubectl get pods
-NAME             READY     REASON    RESTARTS   AGE
 NAME                                READY     STATUS    RESTARTS   AGE
 nginx-deployment-1006230814-6winp   1/1       Running   0          7m
 nginx-deployment-1006230814-fmgu3   1/1       Running   0          7m
@@ -264,11 +263,11 @@ Sometimes when debugging it can be useful to look at the status of a node -- for
 
 ```shell
 $ kubectl get nodes
-NAME                     LABELS                                          STATUS
-kubernetes-node-861h     kubernetes.io/hostname=kubernetes-node-861h     NotReady
-kubernetes-node-bols     kubernetes.io/hostname=kubernetes-node-bols     Ready
-kubernetes-node-st6x     kubernetes.io/hostname=kubernetes-node-st6x     Ready
-kubernetes-node-unaj     kubernetes.io/hostname=kubernetes-node-unaj     Ready
+NAME                     STATUS        AGE
+kubernetes-node-861h     NotReady      1h
+kubernetes-node-bols     Ready         1h
+kubernetes-node-st6x     Ready         1h
+kubernetes-node-unaj     Ready         1h
 
 $ kubectl describe node kubernetes-node-861h
 Name:			kubernetes-node-861h