diff --git a/docs/concepts/cluster-administration/manage-deployment.md b/docs/concepts/cluster-administration/manage-deployment.md
index 90fd1ea559..c6cc97048d 100644
--- a/docs/concepts/cluster-administration/manage-deployment.md
+++ b/docs/concepts/cluster-administration/manage-deployment.md
@@ -301,7 +301,7 @@ deployment "my-nginx" autoscaled
 
 Now your nginx replicas will be scaled up and down as needed, automatically.
 
-For more information, please see [kubectl scale](/docs/user-guide/kubectl/{{page.version}}/#scale), [kubectl autoscale](/docs/user-guide/kubectl/v1.6/#autoscale) and [horizontal pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) document.
+For more information, please see [kubectl scale](/docs/user-guide/kubectl/{{page.version}}/#scale), [kubectl autoscale](/docs/user-guide/kubectl/{{page.version}}/#autoscale) and [horizontal pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) document.
 
 
 ## In-place updates of resources
diff --git a/docs/concepts/cluster-administration/sysctl-cluster.md b/docs/concepts/cluster-administration/sysctl-cluster.md
index 3079345d9b..1376b2522c 100644
--- a/docs/concepts/cluster-administration/sysctl-cluster.md
+++ b/docs/concepts/cluster-administration/sysctl-cluster.md
@@ -118,5 +118,5 @@ spec:
 **Note**: a pod with the _unsafe_ sysctls specified above will fail to launch on
 any node which has not enabled those two _unsafe_ sysctls explicitly. As with
 _node-level_ sysctls it is recommended to use [_taints and toleration_
-feature](/docs/user-guide/kubectl/v1.6/#taint) or [taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
+feature](/docs/user-guide/kubectl/{{page.version}}/#taint) or [taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
 to schedule those pods onto the right nodes.
diff --git a/docs/tasks/access-application-cluster/access-cluster.md b/docs/tasks/access-application-cluster/access-cluster.md
index 297ff597d7..ad23eea693 100644
--- a/docs/tasks/access-application-cluster/access-cluster.md
+++ b/docs/tasks/access-application-cluster/access-cluster.md
@@ -53,7 +53,7 @@ Run it like this:
 $ kubectl proxy --port=8080 &
 ```
 
-See [kubectl proxy](/docs/user-guide/kubectl/v1.6/#proxy) for more details.
+See [kubectl proxy](/docs/user-guide/kubectl/{{page.version}}/#proxy) for more details.
 
 Then you can explore the API with curl, wget, or a browser, like so:
 
@@ -195,7 +195,7 @@ You have several options for connecting to nodes, pods and services from outside
   - Access services through public IPs.
     - Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
       the cluster.  See the [services](/docs/user-guide/services) and
-      [kubectl expose](/docs/user-guide/kubectl/v1.6/#expose) documentation.
+      [kubectl expose](/docs/user-guide/kubectl/{{page.version}}/#expose) documentation.
     - Depending on your cluster environment, this may just expose the service to your corporate network,
       or it may expose it to the internet.  Think about whether the service being exposed is secure.
       Does it do its own authentication?
@@ -211,7 +211,7 @@ You have several options for connecting to nodes, pods and services from outside
     - Only works for HTTP/HTTPS.
     - Described [here](#manually-constructing-apiserver-proxy-urls).
   - Access from a node or pod in the cluster.
-    - Run a pod, and then connect to a shell in it using [kubectl exec](/docs/user-guide/kubectl/v1.6/#exec).
+    - Run a pod, and then connect to a shell in it using [kubectl exec](/docs/user-guide/kubectl/{{page.version}}/#exec).
       Connect to other nodes, pods, and services from that shell.
     - Some clusters may allow you to ssh to a node in the cluster.  From there you may be able to
       access cluster services.  This is a non-standard method, and will work on some clusters but
diff --git a/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
index 672495468a..8fe3d9cf0b 100644
--- a/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+++ b/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
@@ -87,7 +87,7 @@ local workstation to debug the database that is running in the pod.
 
 
 {% capture whatsnext %}
-Learn more about [kubectl port-forward](/docs/user-guide/kubectl/v1.6/#port-forward).
+Learn more about [kubectl port-forward](/docs/user-guide/kubectl/{{page.version}}/#port-forward).
 {% endcapture %}
 
 
diff --git a/docs/tasks/configure-pod-container/configmap.md b/docs/tasks/configure-pod-container/configmap.md
index 71e1c39f49..e77248b191 100644
--- a/docs/tasks/configure-pod-container/configmap.md
+++ b/docs/tasks/configure-pod-container/configmap.md
@@ -36,7 +36,7 @@ The data source corresponds to a key-value pair in the ConfigMap, where
 * key = the file name or the key you provided on the command line, and
 * value = the file contents or the literal value you provided on the command line.
 
-You can use [`kubectl describe`](/docs/user-guide/kubectl/{{page.version}}/#describe) or [`kubectl get`](/docs/user-guide/kubectl/v1.6/#get) to retrieve information about a ConfigMap. The former shows a summary of the ConfigMap, while the latter returns the full contents of the ConfigMap.
+You can use [`kubectl describe`](/docs/user-guide/kubectl/{{page.version}}/#describe) or [`kubectl get`](/docs/user-guide/kubectl/{{page.version}}/#get) to retrieve information about a ConfigMap. The former shows a summary of the ConfigMap, while the latter returns the full contents of the ConfigMap.
 
 ### Create ConfigMaps from directories
 
diff --git a/docs/tasks/debug-application-cluster/get-shell-running-container.md b/docs/tasks/debug-application-cluster/get-shell-running-container.md
index a9c6bb14bc..30ace321b8 100644
--- a/docs/tasks/debug-application-cluster/get-shell-running-container.md
+++ b/docs/tasks/debug-application-cluster/get-shell-running-container.md
@@ -140,7 +140,7 @@ kubectl exec -it my-pod --container main-app -- /bin/bash
 
 {% capture whatsnext %}
 
-* [kubectl exec](/docs/user-guide/kubectl/v1.6/#exec)
+* [kubectl exec](/docs/user-guide/kubectl/{{page.version}}/#exec)
 
 {% endcapture %}
 
diff --git a/docs/tasks/run-application/horizontal-pod-autoscale.md b/docs/tasks/run-application/horizontal-pod-autoscale.md
index 57e2217cd7..d9844a3e30 100644
--- a/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -91,7 +91,7 @@ In addition, there is a special `kubectl autoscale` command for easy creation of
 For instance, executing `kubectl autoscale rc foo --min=2 --max=5 --cpu-percent=80`
 will create an autoscaler for replication controller *foo*, with target CPU utilization set to `80%`
 and the number of replicas between 2 and 5.
-The detailed documentation of `kubectl autoscale` can be found [here](/docs/user-guide/kubectl/v1.6/#autoscale).
+The detailed documentation of `kubectl autoscale` can be found [here](/docs/user-guide/kubectl/{{page.version}}/#autoscale).
 
 
 ## Autoscaling during rolling update
@@ -150,5 +150,5 @@ custom metrics API with the API aggregation layer. Both of these API servers mus
 ## Further reading
 
 * Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
-* kubectl autoscale command: [kubectl autoscale](/docs/user-guide/kubectl/v1.6/#autoscale).
+* kubectl autoscale command: [kubectl autoscale](/docs/user-guide/kubectl/{{page.version}}/#autoscale).
 * Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
diff --git a/docs/tasks/run-application/rolling-update-replication-controller.md b/docs/tasks/run-application/rolling-update-replication-controller.md
index 5f1829a31c..bacf7344ae 100644
--- a/docs/tasks/run-application/rolling-update-replication-controller.md
+++ b/docs/tasks/run-application/rolling-update-replication-controller.md
@@ -16,7 +16,7 @@ which in turn uses a
 For more information, see
 [Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
 
-To update a service without an outage, `kubectl` supports what is called ['rolling update'](/docs/user-guide/kubectl/v1.6/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) and the [example of rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) for more information.
+To update a service without an outage, `kubectl` supports what is called ['rolling update'](/docs/user-guide/kubectl/{{page.version}}/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) and the [example of rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) for more information.
 
 Note that `kubectl rolling-update` only supports Replication Controllers. However, if you deploy applications with Replication Controllers,
 consider switching them to [Deployments](/docs/concepts/workloads/controllers/deployment/). A Deployment is a higher-level controller that automates rolling updates
diff --git a/docs/tasks/run-application/run-replicated-stateful-application.md b/docs/tasks/run-application/run-replicated-stateful-application.md
index 73e6c1ce9f..a36a9cac06 100644
--- a/docs/tasks/run-application/run-replicated-stateful-application.md
+++ b/docs/tasks/run-application/run-replicated-stateful-application.md
@@ -349,7 +349,7 @@ and then return on its own.
 
 If your Kubernetes cluster has multiple Nodes, you can simulate Node downtime
 (such as when Nodes are upgraded) by issuing a
-[drain](/docs/user-guide/kubectl/v1.6/#drain).
+[drain](/docs/user-guide/kubectl/{{page.version}}/#drain).
 
 First determine which Node one of the MySQL Pods is on:
 
diff --git a/docs/tasks/run-application/run-single-instance-stateful-application.md b/docs/tasks/run-application/run-single-instance-stateful-application.md
index 3880efb568..7cff263353 100644
--- a/docs/tasks/run-application/run-single-instance-stateful-application.md
+++ b/docs/tasks/run-application/run-single-instance-stateful-application.md
@@ -181,7 +181,7 @@ underlying resource upon deleting the PersistentVolume.
 
 * Learn more about [Deploying applications](/docs/user-guide/deploying-applications/)
 
-* [kubectl run documentation](/docs/user-guide/kubectl/v1.6/#run)
+* [kubectl run documentation](/docs/user-guide/kubectl/{{page.version}}/#run)
 
 * [Volumes](/docs/concepts/storage/volumes/) and [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)