Remaining links -> Absolute

2016-02-22 20:44:13 -08:00
parent ebf5d38024
commit 0793b7ecb0
116 changed files with 397 additions and 415 deletions
@@ -22,8 +22,8 @@ Check the location and credentials that kubectl knows about with this command:
 $ kubectl config view
 ```

-Many of the [examples](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/) provide an introduction to using
-kubectl and complete documentation is found in the [kubectl manual](kubectl/kubectl).
+Many of the [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/) provide an introduction to using
+kubectl and complete documentation is found in the [kubectl manual](/{{page.version}}/docs/user-guide/kubectl/kubectl).

 ### Directly accessing the REST API

@@ -52,7 +52,7 @@ Run it like this:
 $ kubectl proxy --port=8080 &
 ```

-See [kubectl proxy](kubectl/kubectl_proxy) for more details.
+See [kubectl proxy](/{{page.version}}/docs/user-guide/kubectl/kubectl_proxy) for more details.

 Then you can explore the API with curl, wget, or a browser, like so:

@@ -98,8 +98,8 @@ with future high-availability support.

 There are [client libraries](/{{page.version}}/docs/devel/client-libraries) for accessing the API
 from several languages.  The Kubernetes project-supported
-[Go](http://releases.k8s.io/release-1.1/pkg/client/)
-client library can use the same [kubeconfig file](kubeconfig-file)
+[Go](http://releases.k8s.io/{{page.githubbranch}}/pkg/client/)
+client library can use the same [kubeconfig file](/{{page.version}}/docs/user-guide/kubeconfig-file)
 as the kubectl CLI does to locate and authenticate to the apiserver.

 See documentation for other libraries for how they authenticate.
@@ -114,7 +114,7 @@ the `kubernetes` DNS name, which resolves to a Service IP which in turn
 will be routed to an apiserver.

 The recommended way to authenticate to the apiserver is with a
-[service account](service-accounts) credential.  By kube-system, a pod
+[service account](/{{page.version}}/docs/user-guide/service-accounts) credential.  By kube-system, a pod
 is associated with a service account, and a credential (token) for that
 service account is placed into the filesystem tree of each container in that pod,
 at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
@@ -125,7 +125,7 @@ From within a pod the recommended ways to connect to API are:
    process within a container.  This proxies the
    Kubernetes API to the localhost interface of the pod, so that other processes
    in any container of the pod can access it.  See this [example of using kubectl proxy
-    in a pod](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/kubectl-container/).
+    in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/).
  - use the Go client library, and create a client using the `client.NewInCluster()` factory.
    This handles locating and authenticating to the apiserver.

@@ -136,7 +136,7 @@ In each case, the credentials of the pod are used to communicate securely with t

 The previous section was about connecting the Kubernetes API server.  This section is about
 connecting to other services running on Kubernetes cluster.  In Kubernetes, the
-[nodes](/{{page.version}}/docs/admin/node), [pods](pods) and [services](services) all have
+[nodes](/{{page.version}}/docs/admin/node), [pods](/{{page.version}}/docs/user-guide/pods) and [services](/{{page.version}}/docs/user-guide/services) all have
 their own IPs.  In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
 routable, so they will not be reachable from a machine outside the cluster,
 such as your desktop machine.
@@ -147,8 +147,8 @@ 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](services) and
-      [kubectl expose](kubectl/kubectl_expose) documentation.
+      the cluster.  See the [services](/{{page.version}}/docs/user-guide/services) and
+      [kubectl expose](/{{page.version}}/docs/user-guide/kubectl/kubectl_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?
@@ -164,7 +164,7 @@ You have several options for connecting to nodes, pods and services from outside
    - Only works for HTTP/HTTPS.
    - Described [here](#discovering-builtin-services).
  - Access from a node or pod in the cluster.
-    - Run a pod, and then connect to a shell in it using [kubectl exec](kubectl/kubectl_exec).
+    - Run a pod, and then connect to a shell in it using [kubectl exec](/{{page.version}}/docs/user-guide/kubectl/kubectl_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
@@ -251,7 +251,7 @@ There are several different proxies you may encounter when using Kubernetes:
    - proxy to target may use HTTP or HTTPS as chosen by proxy using available information
    - can be used to reach a Node, Pod, or Service
    - does load balancing when used to reach a Service
-  1. The [kube proxy](services/#ips-and-vips):
+  1. The [kube proxy](/{{page.version}}/docs/user-guide/services/#ips-and-vips):
    - runs on each node
    - proxies UDP and TCP
    - does not understand HTTP
@@ -1,7 +1,7 @@
 ---
 title: "Annotations"
 ---
-We have [labels](labels) for identifying metadata.
+We have [labels](/{{page.version}}/docs/user-guide/labels) for identifying metadata.

 It is also useful to be able to attach arbitrary non-identifying metadata, for retrieval by API clients such as tools, libraries, etc. This information may be large, may be structured or unstructured, may include characters not permitted by labels, etc. Such information would not be used for object selection and therefore doesn't belong in labels.

@@ -186,6 +186,6 @@ check:

 #### More information

-If none of the above solves your problem, follow the instructions in [Debugging Service document](debugging-services) to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving.
+If none of the above solves your problem, follow the instructions in [Debugging Service document](/{{page.version}}/docs/user-guide/debugging-services) to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving.

 You may also visit [troubleshooting document](/{{page.version}}/docs/troubleshooting/) for more information.
@@ -4,20 +4,20 @@ title: "Compute Resources"
 * TOC
 {:toc}

-When specifying a [pod](pods), you can optionally specify how much CPU and memory (RAM) each
+When specifying a [pod](/{{page.version}}/docs/user-guide/pods), you can optionally specify how much CPU and memory (RAM) each
 container needs.  When containers have their resource requests specified, the scheduler is
 able to make better decisions about which nodes to place pods on; and when containers have their
 limits specified, contention for resources on a node can be handled in a specified manner. For
 more details about the difference between requests and limits, please refer to
-[Resource QoS](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/proposals/resource-qos.md).
+[Resource QoS](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/resource-qos.md).

 *CPU* and *memory* are each a *resource type*.  A resource type has a base unit.  CPU is specified
 in units of cores.  Memory is specified in units of bytes.

 CPU and RAM are collectively referred to as *compute resources*, or just *resources*.  Compute
 resources are measureable quantities which can be requested, allocated, and consumed.  They are
-distinct from [API resources](working-with-resources).  API resources, such as pods and
-[services](services) are objects that can be written to and retrieved from the Kubernetes API
+distinct from [API resources](/{{page.version}}/docs/user-guide/working-with-resources).  API resources, such as pods and
+[services](/{{page.version}}/docs/user-guide/services) are objects that can be written to and retrieved from the Kubernetes API
 server.

 ## Resource Requests and Limits of Pod and Container
@@ -111,7 +111,7 @@ To determine if a container cannot be scheduled or is being killed due to resour

 The resource usage of a pod is reported as part of the Pod status.

-If [optional monitoring](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/README.md) is configured for your cluster,
+If [optional monitoring](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/README.md) is configured for your cluster,
 then pod resource usage can be retrieved from the monitoring system.

 ## Troubleshooting
@@ -234,11 +234,11 @@ We can see that this container was terminated because `reason:OOM Killed`, where

 The current system only allows resource quantities to be specified on a container.
 It is planned to improve accounting for resources which are shared by all containers in a pod,
-such as [EmptyDir volumes](volumes/#emptydir).
+such as [EmptyDir volumes](/{{page.version}}/docs/user-guide/volumes/#emptydir).

 The current system only supports container requests and limits for CPU and Memory.
 It is planned to add new resource types, including a node disk space
-resource, and a framework for adding custom [resource types](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/resources.md#resource-types).
+resource, and a framework for adding custom [resource types](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/resources.md#resource-types).

 Kubernetes supports overcommitment of resources by supporting multiple levels of [Quality of Service](http://issue.k8s.io/168).

@@ -9,16 +9,16 @@ This document is meant to highlight and consolidate in one place configuration b
 1. Group related objects together in a single file. This is often better than separate files.
 1. Use `kubectl create -f <directory>` where possible. This looks for config objects in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes them to create.
 1. Create a service before corresponding replication controllers so that the scheduler can spread the pods comprising the service. You can also create the replication controller without specifying replicas, create the service, then scale up the replication controller, which may work better in an example using progressive disclosure and may have benefits in real scenarios also, such as ensuring one replica works before creating lots of them)
-1. Don't use `hostPort` unless absolutely necessary (e.g., for a node daemon) as it will prevent certain scheduling configurations due to port conflicts. Use the apiserver proxying or port forwarding for debug/admin access, or a service for external service access. If you need to expose a pod's port on the host machine, consider using a [NodePort](services/#type--loadbalancer) service before resorting to `hostPort`. If you only need access to the port for debugging purposes, you can also use the [kubectl proxy and apiserver proxy](/{{page.version}}/docs/user-guide/connecting-to-applications-proxy) or [kubectl port-forward](/{{page.version}}/docs/user-guide/connecting-to-applications-port-forward).
+1. Don't use `hostPort` unless absolutely necessary (e.g., for a node daemon) as it will prevent certain scheduling configurations due to port conflicts. Use the apiserver proxying or port forwarding for debug/admin access, or a service for external service access. If you need to expose a pod's port on the host machine, consider using a [NodePort](/{{page.version}}/docs/user-guide/services/#type--loadbalancer) service before resorting to `hostPort`. If you only need access to the port for debugging purposes, you can also use the [kubectl proxy and apiserver proxy](/{{page.version}}/docs/user-guide/connecting-to-applications-proxy) or [kubectl port-forward](/{{page.version}}/docs/user-guide/connecting-to-applications-port-forward).
 1. Don't use `hostNetwork` for the same reasons as `hostPort`.
 1. Don't specify default values unnecessarily, to simplify and minimize configs. For example, omit the selector and labels in ReplicationController if you want them to be the same as the labels in its podTemplate, since those fields are populated from the podTemplate labels by default.
 1. Instead of attaching one label to a set of pods to represent a service (e.g., `service: myservice`) and another to represent the replication controller managing the pods (e.g., `controller: mycontroller`), attach labels that identify semantic attributes of your application or deployment and select the appropriate subsets in your service and replication controller, such as `{ app: myapp, tier: frontend, deployment: v3 }`. A service can be made to span multiple deployments, such as across rolling updates, by simply omitting release-specific labels from its selector, rather than updating a service's selector to match the replication controller's selector fully.
-1. Use kubectl bulk operations (via files and/or labels) for get and delete. See [label selectors](labels/#label-selectors) and [using labels effectively](managing-deployments/#using-labels-effectively).
-1. Use kubectl run and expose to quickly create and expose single container replication controllers. See the [quick start guide](quick-start) for an example.
-1. Use headless services for easy service discovery when you don't need kube-proxy load balancing. See [headless services](services/#headless-services).
+1. Use kubectl bulk operations (via files and/or labels) for get and delete. See [label selectors](/{{page.version}}/docs/user-guide/labels/#label-selectors) and [using labels effectively](/{{page.version}}/docs/user-guide/managing-deployments/#using-labels-effectively).
+1. Use kubectl run and expose to quickly create and expose single container replication controllers. See the [quick start guide](/{{page.version}}/docs/user-guide/quick-start) for an example.
+1. Use headless services for easy service discovery when you don't need kube-proxy load balancing. See [headless services](/{{page.version}}/docs/user-guide/services/#headless-services).
 1. Use kubectl delete rather than stop. Delete has a superset of the functionality of stop and stop is deprecated.
 1. If there is a viable alternative to naked pods (i.e. pods not bound to a controller), go with the alternative. Controllers are almost always preferable to creating pods (except for some `restartPolicy: Never` scenarios). A minimal Job is coming. See [#1624](http://issue.k8s.io/1624). Naked pods will not be rescheduled in the event of node failure.
-1. Put a version number or hash as a suffix to the name and in a label on a replication controller to facilitate rolling update, as we do for [--image](kubectl/kubectl_rolling-update). This is necessary because rolling-update actually creates a new controller as opposed to modifying the existing controller. This does not play well with version agnostic controller names.
+1. Put a version number or hash as a suffix to the name and in a label on a replication controller to facilitate rolling update, as we do for [--image](/{{page.version}}/docs/user-guide/kubectl/kubectl_rolling-update). This is necessary because rolling-update actually creates a new controller as opposed to modifying the existing controller. This does not play well with version agnostic controller names.
 1. Put an object description in an annotation to allow better introspection.


@@ -89,7 +89,7 @@ spec:  # specification of the pod's contents
    args: ["/bin/echo \"${MESSAGE}\""]
 ```

-However, a shell isn't necessary just to expand environment variables. Kubernetes will do it for you if you use [`$(ENVVAR)` syntax](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/expansion):
+However, a shell isn't necessary just to expand environment variables. Kubernetes will do it for you if you use [`$(ENVVAR)` syntax](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/expansion):

 ```yaml
 command: ["/bin/echo"]
@@ -113,11 +113,11 @@ NAME         ENDPOINTS
 nginxsvc     10.245.0.14:80,10.245.0.15:80
 ```

-You should now be able to curl the nginx Service on `10.0.116.146:80` from any node in your cluster. Note that the Service IP is completely virtual, it never hits the wire, if you're curious about how this works you can read more about the [service proxy](services/#virtual-ips-and-service-proxies).
+You should now be able to curl the nginx Service on `10.0.116.146:80` from any node in your cluster. Note that the Service IP is completely virtual, it never hits the wire, if you're curious about how this works you can read more about the [service proxy](/{{page.version}}/docs/user-guide/services/#virtual-ips-and-service-proxies).

 ## Accessing the Service

-Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS. The former works out of the box while the latter requires the [kube-dns cluster addon](http://releases.k8s.io/release-1.1/cluster/addons/dns/README.md).
+Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS. The former works out of the box while the latter requires the [kube-dns cluster addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md).

 ### Environment Variables

@@ -155,7 +155,7 @@ NAME       CLUSTER_IP      EXTERNAL_IP   PORT(S)         SELECTOR           AGE
 kube-dns   10.179.240.10   <none>        53/UDP,53/TCP   k8s-app=kube-dns   8d
 ```

-If it isn't running, you can [enable it](http://releases.k8s.io/release-1.1/cluster/addons/dns/README.md#how-do-i-configure-it). The rest of this section will assume you have a Service with a long lived IP (nginxsvc), and a dns server that has assigned a name to that IP (the kube-dns cluster addon), so you can talk to the Service from any pod in your cluster using standard methods (e.g. gethostbyname). Let's create another pod to test this:
+If it isn't running, you can [enable it](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md#how-do-i-configure-it). The rest of this section will assume you have a Service with a long lived IP (nginxsvc), and a dns server that has assigned a name to that IP (the kube-dns cluster addon), so you can talk to the Service from any pod in your cluster using standard methods (e.g. gethostbyname). Let's create another pod to test this:

 ```yaml
 $ cat curlpod.yaml
@@ -196,9 +196,9 @@ Till now we have only accessed the nginx server from within the cluster. Before

 * Self signed certificates for https (unless you already have an identity certificate)
 * An nginx server configured to use the certificates
-* A [secret](secrets) that makes the certificates accessible to pods
+* A [secret](/{{page.version}}/docs/user-guide/secrets) that makes the certificates accessible to pods

-You can acquire all these from the [nginx https example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/https-nginx/), in short:
+You can acquire all these from the [nginx https example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/https-nginx/), in short:

 ```shell
 $ make keys secret KEY=/tmp/nginx.key CERT=/tmp/nginx.crt SECRET=/tmp/secret.json
@@ -262,7 +262,7 @@ spec:
 Noteworthy points about the nginx-app manifest:

 - It contains both rc and service specification in the same file
- The [nginx server](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/https-nginx/default.conf) serves http traffic on port 80 and https traffic on 443, and nginx Service exposes both ports.
+- The [nginx server](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/https-nginx/default.conf) serves http traffic on port 80 and https traffic on 443, and nginx Service exposes both ports.
 - Each container has access to the keys through a volume mounted at /etc/nginx/ssl. This is setup *before* the nginx server is started.

 ```shell
@@ -383,4 +383,4 @@ cluster/private cloud network.

 ## What's next?

-[Learn about more Kubernetes features that will help you run containers reliably in production.](production-pods)
+[Learn about more Kubernetes features that will help you run containers reliably in production.](/{{page.version}}/docs/user-guide/production-pods)
@@ -1,7 +1,7 @@
 ---
 title: "Connecting to applications: kubectl port-forward"
 ---
-kubectl port-forward forwards connections to a local port to a port on a pod. Its man page is available [here](kubectl/kubectl_port-forward). Compared to [kubectl proxy](/{{page.version}}/docs/user-guide/accessing-the-cluster/#using-kubectl-proxy), `kubectl port-forward` is more generic as it can forward TCP traffic while `kubectl proxy` can only forward HTTP traffic. This guide demonstrates how to use `kubectl port-forward` to connect to a Redis database, which may be useful for database debugging.
+kubectl port-forward forwards connections to a local port to a port on a pod. Its man page is available [here](/{{page.version}}/docs/user-guide/kubectl/kubectl_port-forward). Compared to [kubectl proxy](/{{page.version}}/docs/user-guide/accessing-the-cluster/#using-kubectl-proxy), `kubectl port-forward` is more generic as it can forward TCP traffic while `kubectl proxy` can only forward HTTP traffic. This guide demonstrates how to use `kubectl port-forward` to connect to a Redis database, which may be useful for database debugging.

 ## Creating a Redis master

@@ -1,7 +1,7 @@
 ---
 title: "Connecting to applications: kubectl proxy and apiserver proxy"
 ---
-You have seen the [basics](/{{page.version}}/docs/user-guide/accessing-the-cluster) about `kubectl proxy` and `apiserver proxy`. This guide shows how to use them together to access a service([kube-ui](ui)) running on the Kubernetes cluster from your workstation.
+You have seen the [basics](/{{page.version}}/docs/user-guide/accessing-the-cluster) about `kubectl proxy` and `apiserver proxy`. This guide shows how to use them together to access a service([kube-ui](/{{page.version}}/docs/user-guide/ui)) running on the Kubernetes cluster from your workstation.


 ## Getting the apiserver proxy URL of kube-ui
@@ -13,7 +13,7 @@ $ kubectl cluster-info | grep "KubeUI"
 KubeUI is running at https://173.255.119.104/api/v1/proxy/namespaces/kube-system/services/kube-ui
 ```

-if this command does not find the URL, try the steps [here](ui/#accessing-the-ui).
+if this command does not find the URL, try the steps [here](/{{page.version}}/docs/user-guide/ui/#accessing-the-ui).


 ## Connecting to the kube-ui service from your local workstation
@@ -6,7 +6,7 @@ This document describes the environment for Kubelet managed containers on a Kube
 This cluster information makes it possible to build applications that are *cluster aware*.
 Additionally, the Kubernetes container environment defines a series of hooks that are surfaced to optional hook handlers defined as part of individual containers.  Container hooks are somewhat analogous to operating system signals in a traditional process model.   However these hooks are designed to make it easier to build reliable, scalable cloud applications in the Kubernetes cluster.  Containers that participate in this cluster lifecycle become *cluster native*.

-Another important part of the container environment is the file system that is available to the container.  In Kubernetes, the filesystem is a combination of an [image](images) and one or more [volumes](volumes).
+Another important part of the container environment is the file system that is available to the container.  In Kubernetes, the filesystem is a combination of an [image](/{{page.version}}/docs/user-guide/images) and one or more [volumes](/{{page.version}}/docs/user-guide/volumes).

 The following sections describe both the cluster information provided to containers, as well as the hooks and life-cycle that allows containers to interact with the management system.

@@ -21,7 +21,7 @@ There are two types of information that are available within the container envir

 Currently, the Pod name for the pod in which the container is running is set as the hostname of the container, and is accessible through all calls to access the hostname within the container (e.g. the hostname command, or the [gethostname][1] function call in libc), but this is planned to change in the future and should not be used.

-The Pod name and namespace are also available as environment variables via the [downward API](downward-api).  Additionally, user-defined environment variables from the pod definition, are also available to the container, as are any environment variables specified statically in the Docker image.
+The Pod name and namespace are also available as environment variables via the [downward API](/{{page.version}}/docs/user-guide/downward-api).  Additionally, user-defined environment variables from the pod definition, are also available to the container, as are any environment variables specified statically in the Docker image.

 In the future, we anticipate expanding this information with richer information about the container.  Examples include available memory, number of restarts, and in general any state that you could get from the call to GET /pods on the API server.

@@ -36,7 +36,7 @@ FOO_SERVICE_HOST=<the host the service is running on>
 FOO_SERVICE_PORT=<the port the service is running on>
 ```

-Services have dedicated IP address, and are also surfaced to the container via DNS (If [DNS addon](http://releases.k8s.io/release-1.1/cluster/addons/dns/) is enabled).  Of course DNS is still not an enumerable protocol, so we will continue to provide environment variables so that containers can do discovery.
+Services have dedicated IP address, and are also surfaced to the container via DNS (If [DNS addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/) is enabled).  Of course DNS is still not an enumerable protocol, so we will continue to provide environment variables so that containers can do discovery.

 ## Container Hooks

@@ -52,7 +52,7 @@ This hook is sent immediately after a container is created.  It notifies the co

 *PreStop*

-This hook is called immediately before a container is terminated. No parameters are passed to the handler. This event handler is blocking, and must complete before the call to delete the container is sent to the Docker daemon.  The SIGTERM notification sent by Docker is also still sent. A more complete description of termination behavior can be found in [Termination of Pods](pods/#termination-of-pods).
+This hook is called immediately before a container is terminated. No parameters are passed to the handler. This event handler is blocking, and must complete before the call to delete the container is sent to the Docker daemon.  The SIGTERM notification sent by Docker is also still sent. A more complete description of termination behavior can be found in [Termination of Pods](/{{page.version}}/docs/user-guide/pods/#termination-of-pods).

 ### Hook Handler Execution

@@ -18,11 +18,11 @@ we can use:

 Docker images have metadata associated with them that is used to store information about the image.
 The image author may use this to define defaults for the command and arguments to run a container
-when the user does not supply values.  Docker calls the fields for commands and arguments
-`Entrypoint` and `Cmd` respectively.  The full details for this feature are too complicated to
-describe here, mostly due to the fact that the docker API allows users to specify both of these
+when the user does not supply values. Docker calls the fields for commands and arguments
+`Entrypoint` and `Cmd` respectively. The full details for this feature are too complicated to
+describe here, mostly due to the fact that the Docker API allows users to specify both of these
 fields as either a string array or a string and there are subtle differences in how those cases are
-handled.  We encourage the curious to check out [docker's documentation]() for this feature.
+handled.  We encourage the curious to check out Docker's documentation for this feature.

 Kubernetes allows you to override both the image's default command (docker `Entrypoint`) and args
 (docker `Cmd`) with the `Command` and `Args` fields of `Container`.  The rules are:
@@ -90,7 +90,4 @@ The relationship between Docker's capabilities and [Linux capabilities](http://m
 | LEASE |  CAP_LEASE |
 | SETFCAP |  CAP_SETFCAP |
 | WAKE_ALARM |  CAP_WAKE_ALARM |
-| BLOCK_SUSPEND |  CAP_BLOCK_SUSPEND |
-
-
-
+| BLOCK_SUSPEND |  CAP_BLOCK_SUSPEND |
@@ -1,18 +1,18 @@
 ---
 title: "Kubernetes User Guide: Managing Applications: Deploying continuously running applications"
 ---
-You previously read about how to quickly deploy a simple replicated application using [`kubectl run`](quick-start) and how to configure and launch single-run containers using pods ([Configuring containers](/{{page.version}}/docs/user-guide/configuring-containers)). Here you'll use the configuration-based approach to deploy a continuously running, replicated application.
+You previously read about how to quickly deploy a simple replicated application using [`kubectl run`](/{{page.version}}/docs/user-guide/quick-start) and how to configure and launch single-run containers using pods ([Configuring containers](/{{page.version}}/docs/user-guide/configuring-containers)). Here you'll use the configuration-based approach to deploy a continuously running, replicated application.

 * TOC
 {:toc}

 ## Launching a set of replicas using a configuration file

-Kubernetes creates and manages sets of replicated containers (actually, replicated [Pods](pods)) using [*Replication Controllers*](replication-controller).
+Kubernetes creates and manages sets of replicated containers (actually, replicated [Pods](/{{page.version}}/docs/user-guide/pods)) using [*Replication Controllers*](/{{page.version}}/docs/user-guide/replication-controller).

 A replication controller simply ensures that a specified number of pod "replicas" are running at any one time. If there are too many, it will kill some. If there are too few, it will start more. It's analogous to Google Compute Engine's [Instance Group Manager](https://cloud.google.com/compute/docs/instance-groups/manager/) or AWS's [Auto-scaling Group](http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AutoScalingGroup) (with no scaling policies).

-The replication controller created to run nginx by `kubectl run` in the [Quick start](quick-start) could be specified using YAML as follows:
+The replication controller created to run nginx by `kubectl run` in the [Quick start](/{{page.version}}/docs/user-guide/quick-start) could be specified using YAML as follows:

 ```yaml
 apiVersion: v1
@@ -70,7 +70,7 @@ my-nginx-buaiq   1/1       Running   0          51s

 ## Deleting replication controllers

-When you want to kill your application, delete your replication controller, as in the [Quick start](quick-start):
+When you want to kill your application, delete your replication controller, as in the [Quick start](/{{page.version}}/docs/user-guide/quick-start):

 ```shell
 $ kubectl delete rc my-nginx
@@ -83,7 +83,7 @@ If you try to delete the pods before deleting the replication controller, it wil

 ## Labels

-Kubernetes uses user-defined key-value attributes called [*labels*](labels) to categorize and identify sets of resources, such as pods and replication controllers. The example above specified a single label in the pod template, with key `app` and value `nginx`. All pods created carry that label, which can be viewed using `-L`:
+Kubernetes uses user-defined key-value attributes called [*labels*](/{{page.version}}/docs/user-guide/labels) to categorize and identify sets of resources, such as pods and replication controllers. The example above specified a single label in the pod template, with key `app` and value `nginx`. All pods created carry that label, which can be viewed using `-L`:

 ```shell
 $ kubectl get pods -L app
@@ -100,7 +100,7 @@ CONTROLLER   CONTAINER(S)   IMAGE(S)   SELECTOR    REPLICAS   APP
 my-nginx     nginx          nginx      app=nginx   2          nginx
 ```

-More importantly, the pod template's labels are used to create a [`selector`](labels/#label-selectors) that will match pods carrying those labels. You can see this field by requesting it using the [Go template output format of `kubectl get`](kubectl/kubectl_get):
+More importantly, the pod template's labels are used to create a [`selector`](/{{page.version}}/docs/user-guide/labels/#label-selectors) that will match pods carrying those labels. You can see this field by requesting it using the [Go template output format of `kubectl get`](/{{page.version}}/docs/user-guide/kubectl/kubectl_get):

 ```shell
 $ kubectl get rc my-nginx -o template --template="{{.spec.selector}}"
@@ -57,7 +57,7 @@ spec:
        - containerPort: 80
 ```

-[Download example](nginx-deployment.yaml)
+[Download example](/{{page.version}}/docs/user-guide/nginx-deployment.yaml)
 <!-- END MUNGE: EXAMPLE nginx-deployment.yaml -->

 Run the example by downloading the example file and then running this command:
@@ -135,7 +135,7 @@ spec:
        - containerPort: 80
 ```

-[Download example](new-nginx-deployment.yaml)
+[Download example](/{{page.version}}/docs/user-guide/new-nginx-deployment.yaml)
 <!-- END MUNGE: EXAMPLE new-nginx-deployment.yaml -->


@@ -250,7 +250,7 @@ before changing course.

 As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and
 `metadata` fields.  For general information about working with config files,
-see [here](deploying-applications), [here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](working-with-resources).
+see [here](/{{page.version}}/docs/user-guide/deploying-applications), [here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](/{{page.version}}/docs/user-guide/working-with-resources).

 A Deployment also needs a [`.spec` section](/{{page.version}}/docs/devel/api-conventions/#spec-and-status).

@@ -258,8 +258,8 @@ A Deployment also needs a [`.spec` section](/{{page.version}}/docs/devel/api-con

 The `.spec.template` is the only required field of the `.spec`.

-The `.spec.template` is a [pod template](replication-controller/#pod-template).  It has exactly
-the same schema as a [pod](pods), except it is nested and does not have an
+The `.spec.template` is a [pod template](/{{page.version}}/docs/user-guide/replication-controller/#pod-template).  It has exactly
+the same schema as a [pod](/{{page.version}}/docs/user-guide/pods), except it is nested and does not have an
 `apiVersion` or `kind`.

 ### Replicas
@@ -347,5 +347,5 @@ Note: This is not implemented yet.

 ### kubectl rolling update

-[Kubectl rolling update](kubectl/kubectl_rolling-update) also updates pods and replication controllers in a similar fashion.
+[Kubectl rolling update](/{{page.version}}/docs/user-guide/kubectl/kubectl_rolling-update) also updates pods and replication controllers in a similar fashion.
 But deployments is declarative and is server side.
@@ -8,7 +8,7 @@ In this doc, we introduce the Kubernetes command line for interacting with the a

 #### docker run

-How do I run an nginx container and expose it to the world? Checkout [kubectl run](kubectl/kubectl_run).
+How do I run an nginx container and expose it to the world? Checkout [kubectl run](/{{page.version}}/docs/user-guide/kubectl/kubectl_run).

 With docker:

@@ -30,7 +30,7 @@ replicationcontroller "nginx-app" created
 $ kubectl expose rc nginx-app --port=80 --name=nginx-http
 ```

-With kubectl, we create a [replication controller](replication-controller) which will make sure that N pods are running nginx (where N is the number of replicas stated in the spec, which defaults to 1). We also create a [service](services) with a selector that matches the replication controller's selector. See the [Quick start](quick-start) for more information.
+With kubectl, we create a [replication controller](/{{page.version}}/docs/user-guide/replication-controller) which will make sure that N pods are running nginx (where N is the number of replicas stated in the spec, which defaults to 1). We also create a [service](/{{page.version}}/docs/user-guide/services) with a selector that matches the replication controller's selector. See the [Quick start](/{{page.version}}/docs/user-guide/quick-start) for more information.

 By default images are run in the background, similar to `docker run -d ...`, if you want to run things in the foreground, use:

@@ -45,7 +45,7 @@ To destroy the replication controller (and it's pods)  you need to run `kubectl

 #### docker ps

-How do I list what is currently running? Checkout [kubectl get](kubectl/kubectl_get).
+How do I list what is currently running? Checkout [kubectl get](/{{page.version}}/docs/user-guide/kubectl/kubectl_get).

 With docker:

@@ -65,7 +65,7 @@ nginx-app-5jyvm   1/1       Running   0          1h

 #### docker attach

-How do I attach to a process that is already running in a container?  Checkout [kubectl attach](kubectl/kubectl_attach)
+How do I attach to a process that is already running in a container?  Checkout [kubectl attach](/{{page.version}}/docs/user-guide/kubectl/kubectl_attach)

 With docker:

@@ -89,7 +89,7 @@ $ kubectl attach -it nginx-app-5jyvm

 #### docker exec

-How do I execute a command in a container? Checkout [kubectl exec](kubectl/kubectl_exec).
+How do I execute a command in a container? Checkout [kubectl exec](/{{page.version}}/docs/user-guide/kubectl/kubectl_exec).

 With docker:

@@ -128,11 +128,11 @@ $ kubectl exec -ti nginx-app-5jyvm -- /bin/sh
 # exit
 ```

-For more information see [Getting into containers](getting-into-containers).
+For more information see [Getting into containers](/{{page.version}}/docs/user-guide/getting-into-containers).

 #### docker logs

-How do I follow stdout/stderr of a running process? Checkout [kubectl logs](kubectl/kubectl_logs).
+How do I follow stdout/stderr of a running process? Checkout [kubectl logs](/{{page.version}}/docs/user-guide/kubectl/kubectl_logs).


 With docker:
@@ -159,11 +159,11 @@ $ kubectl logs --previous nginx-app-zibvs
 10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
 ```

-See [Logging](logging) for more information.
+See [Logging](/{{page.version}}/docs/user-guide/logging) for more information.

 #### docker stop and docker rm

-How do I stop and delete a running process? Checkout [kubectl delete](kubectl/kubectl_delete).
+How do I stop and delete a running process? Checkout [kubectl delete](/{{page.version}}/docs/user-guide/kubectl/kubectl_delete).

 With docker

@@ -197,11 +197,11 @@ Notice that we don't delete the pod directly. With kubectl we want to delete the

 #### docker login

-There is no direct analog of `docker login` in kubectl. If you are interested in using Kubernetes with a private registry, see [Using a Private Registry](images/#using-a-private-registry).
+There is no direct analog of `docker login` in kubectl. If you are interested in using Kubernetes with a private registry, see [Using a Private Registry](/{{page.version}}/docs/user-guide/images/#using-a-private-registry).

 #### docker version

-How do I get the version of my client and server? Checkout [kubectl version](kubectl/kubectl_version).
+How do I get the version of my client and server? Checkout [kubectl version](/{{page.version}}/docs/user-guide/kubectl/kubectl_version).

 With docker:

@@ -229,7 +229,7 @@ Server Version: version.Info{Major:"0", Minor:"21+", GitVersion:"v0.21.1-411-g32

 #### docker info

-How do I get miscellaneous info about my environment and configuration? Checkout [kubectl cluster-info](kubectl/kubectl_cluster-info).
+How do I get miscellaneous info about my environment and configuration? Checkout [kubectl cluster-info](/{{page.version}}/docs/user-guide/kubectl/kubectl_cluster-info).

 With docker:

@@ -76,7 +76,7 @@ spec:
  restartPolicy: Never
 ```

-[Download example](downward-api/dapi-pod.yaml)
+[Download example](/{{page.version}}/docs/user-guide/downward-api/dapi-pod.yaml)
 <!-- END MUNGE: EXAMPLE downward-api/dapi-pod.yaml -->


@@ -86,7 +86,7 @@ Using a similar syntax it's possible to expose pod information to containers usi
 Downward API are dumped to a mounted volume. This is achieved using a `downwardAPI`
 volume type and the different items represent the files to be created. `fieldPath` references the field to be exposed.

-Downward API volume permits to store more complex data like [`metadata.labels`](labels) and [`metadata.annotations`](/{{page.version}}/docs/user-guide/annotations). Currently key/value pair set fields are saved using `key="value"` format:
+Downward API volume permits to store more complex data like [`metadata.labels`](/{{page.version}}/docs/user-guide/labels) and [`metadata.annotations`](/{{page.version}}/docs/user-guide/annotations). Currently key/value pair set fields are saved using `key="value"` format:

 ```conf
 key1="value1"
@@ -145,10 +145,10 @@ spec:
              fieldPath: metadata.annotations
 ```

-[Download example](downward-api/volume/dapi-volume.yaml)
+[Download example](/{{page.version}}/docs/user-guide/downward-api/volume/dapi-volume.yaml)
 <!-- END MUNGE: EXAMPLE downward-api/volume/dapi-volume.yaml -->

 Some more thorough examples:

-   * [environment variables](environment-guide/)
-   * [downward API](downward-api/)
+   * [environment variables](/{{page.version}}/docs/user-guide/environment-guide/)
+   * [downward API](/{{page.version}}/docs/user-guide/downward-api/)
@@ -15,7 +15,7 @@ started](/{{page.version}}/docs/getting-started-guides/) for installation instru
 Containers consume the downward API using environment variables.  The downward API allows
 containers to be injected with the name and namespace of the pod the container is in.

-Use the [`examples/downward-api/dapi-pod.yaml`](dapi-pod.yaml) file to create a Pod with a container that consumes the
+Use the [`dapi-pod.yaml`](/{{page.version}}/docs/user-guide/downward-api/dapi-pod.yaml) file to create a Pod with a container that consumes the
 downward API.

 ```shell
@@ -69,7 +69,7 @@ Backend Namespace: default
 ```

 First the frontend pod's information is printed. The pod name and
-[namespace](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/namespaces.md) are retrieved from the
+[namespace](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md) are retrieved from the
 [Downward API](/{{page.version}}/docs/user-guide/downward-api). Next, `USER_VAR` is the name of
 an environment variable set in the [pod
 definition](/{{page.version}}/docs/user-guide/environment-guide/show-rc.yaml). Then, the dynamic Kubernetes environment
@@ -5,7 +5,7 @@ Developers can use `kubectl exec` to run commands in a container. This guide dem

 ## Using kubectl exec to check the environment variables of a container

-Kubernetes exposes [services](services/#environment-variables) through environment variables. It is convenient to check these environment variables using `kubectl exec`.
+Kubernetes exposes [services](/{{page.version}}/docs/user-guide/services/#environment-variables) through environment variables. It is convenient to check these environment variables using `kubectl exec`.

 We first create a pod and a service,

@@ -28,21 +28,21 @@ Then, it compares the arithmetic mean of the pods' CPU utilization with the targ
 CPU utilization is the recent CPU usage of a pod divided by the sum of CPU requested by the pod's containers.
 Please note that if some of the pod's containers do not have CPU request set,
 CPU utilization for the pod will not be defined and the autoscaler will not take any action.
-Further details of the autoscaling algorithm are given [here](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm).
+Further details of the autoscaling algorithm are given [here](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm).

 Autoscaler uses heapster to collect CPU utilization.
 Therefore, it is required to deploy heapster monitoring in your cluster for autoscaling to work.

 Autoscaler accesses corresponding replication controller or deployment by scale sub-resource.
 Scale is an interface which allows to dynamically set the number of replicas and to learn the current state of them.
-More details on scale sub-resource can be found [here](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/horizontal-pod-autoscaler.md#scale-subresource).
+More details on scale sub-resource can be found [here](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/horizontal-pod-autoscaler.md#scale-subresource).


 ## API Object

 Horizontal pod autoscaler is a top-level resource in the Kubernetes REST API (currently in [beta](/{{page.version}}/docs/api/)#api-versioning)).
 More details about the API object can be found at
-[HorizontalPodAutoscaler Object](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
+[HorizontalPodAutoscaler Object](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).

 ## Support for horizontal pod autoscaler in kubectl

@@ -55,7 +55,7 @@ In addition, there is a special `kubectl autoscale` command that allows for easy
 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](kubectl/kubectl_autoscale).
+The detailed documentation of `kubectl autoscale` can be found [here](/{{page.version}}/docs/user-guide/kubectl/kubectl_autoscale).


 ## Autoscaling during rolling update
@@ -73,11 +73,6 @@ the horizontal pod autoscaler will not be bound to the new replication controlle

 ## Further reading

-* Design documentation: [Horizontal Pod Autoscaling](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/horizontal-pod-autoscaler.md).
-* Manual of autoscale command in kubectl: [kubectl autoscale](kubectl/kubectl_autoscale).
-* Usage example of [Horizontal Pod Autoscaler](horizontal-pod-autoscaling/).
-
-
-
-
-
+* Design documentation: [Horizontal Pod Autoscaling](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/horizontal-pod-autoscaler.md).
+* Manual of autoscale command in kubectl: [kubectl autoscale](/{{page.version}}/docs/user-guide/kubectl/kubectl_autoscale).
+* Usage example of [Horizontal Pod Autoscaler](/{{page.version}}/docs/user-guide/horizontal-pod-autoscaling/).
@@ -20,7 +20,7 @@ heapster monitoring will be turned-on by default).

 To demonstrate horizontal pod autoscaler we will use a custom docker image based on php-apache server.
 The image can be found [here](https://releases.k8s.io/release-1.1/docs/user-guide/horizontal-pod-autoscaling/image).
-It defines [index.php](image/index.php) page which performs some CPU intensive computations.
+It defines [index.php](/{{page.version}}/docs/user-guide/horizontal-pod-autoscaling/image/index.php) page which performs some CPU intensive computations.

 First, we will start a replication controller running the image and expose it as an external service:

@@ -69,7 +69,7 @@ OK!
 ## Step Two: Create horizontal pod autoscaler

 Now that the server is running, we will create a horizontal pod autoscaler for it.
-To create it, we will use the [hpa-php-apache.yaml](hpa-php-apache.yaml) file, which looks like this:
+To create it, we will use the [hpa-php-apache.yaml](/{{page.version}}/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml) file, which looks like this:

 ```yaml
 apiVersion: extensions/v1beta1
@@ -93,7 +93,7 @@ controlled by the php-apache replication controller we created in the first step
 Roughly speaking, the horizontal autoscaler will increase and decrease the number of replicas
 (via the replication controller) so as to maintain an average CPU utilization across all Pods of 50%
 (since each pod requests 200 milli-cores by [kubectl run](#kubectl-run), this means average CPU utilization of 100 milli-cores).
-See [here](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.
+See [here](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.

 We will create the autoscaler by executing the following command:

@@ -102,8 +102,8 @@ $ kubectl create -f docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.ya
 horizontalpodautoscaler "php-apache" created
 ```

-Alternatively, we can create the autoscaler using [kubectl autoscale](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/user-guide/kubectl/kubectl_autoscale.md).
-The following command will create the equivalent autoscaler as defined in the [hpa-php-apache.yaml](hpa-php-apache.yaml) file:
+Alternatively, we can create the autoscaler using [kubectl autoscale](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/user-guide/kubectl/kubectl_autoscale.md).
+The following command will create the equivalent autoscaler as defined in the [hpa-php-apache.yaml](/{{page.version}}/docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml) file:

 ```shell
 $ kubectl autoscale rc php-apache --cpu-percent=50 --min=1 --max=10
@@ -3,11 +3,11 @@ title: "Identifiers"
 ---
 All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID.

-For non-unique user-provided attributes, Kubernetes provides [labels](labels) and [annotations](/{{page.version}}/docs/user-guide/annotations).
+For non-unique user-provided attributes, Kubernetes provides [labels](/{{page.version}}/docs/user-guide/labels) and [annotations](/{{page.version}}/docs/user-guide/annotations).

 ## Names

-Names are generally client-provided.  Only one object of a given kind can have a given name at a time (i.e., they are spatially unique).  But if you delete an object, you can make a new object with the same name.  Names are the used to refer to an object in a resource URL, such as `/api/v1/pods/some-name`.   By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, `-`, and `.`, but certain resources have more specific restrictions.  See the [identifiers design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/identifiers.md) for the precise syntax rules for names.
+Names are generally client-provided.  Only one object of a given kind can have a given name at a time (i.e., they are spatially unique).  But if you delete an object, you can make a new object with the same name.  Names are the used to refer to an object in a resource URL, such as `/api/v1/pods/some-name`.   By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, `-`, and `.`, but certain resources have more specific restrictions.  See the [identifiers design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/identifiers.md) for the precise syntax rules for names.

 ## UIDs

@@ -146,7 +146,7 @@ where node creation is automated.
 Kubernetes supports specifying registry keys on a pod.

 First, create a `.dockercfg`, such as running `docker login <registry.domain>`.
-Then put the resulting `.dockercfg` file into a [secret resource](secrets).  For example:
+Then put the resulting `.dockercfg` file into a [secret resource](/{{page.version}}/docs/user-guide/secrets).  For example:

 ```shell
 $ docker login
@@ -201,7 +201,7 @@ spec:

 This needs to be done for each pod that is using a private registry.
 However, setting of this field can be automated by setting the imagePullSecrets
-in a [serviceAccount](service-accounts) resource.
+in a [serviceAccount](/{{page.version}}/docs/user-guide/service-accounts) resource.

 Currently, all pods will potentially have read access to any images which were
 pulled using imagePullSecrets.  That is, imagePullSecrets does *NOT* protect your
@@ -67,13 +67,13 @@ rules:

 *POSTing this to the API server will have no effect if you have not configured an [Ingress controller](#ingress-controllers).*

-__Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.  For general information about working with config files, see [here](simple-yaml), [here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](working-with-resources).
+__Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.  For general information about working with config files, see [here](/{{page.version}}/docs/user-guide/simple-yaml), [here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](/{{page.version}}/docs/user-guide/working-with-resources).

 __Lines 5-7__: Ingress [spec](/{{page.version}}/docs/devel/api-conventions/#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.

 __Lines 8-9__: Each http rule contains the following information: A host (eg: foo.bar.com, defaults to * in this example), a list of paths (eg: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend.

-__Lines 10-12__: A backend is a service:port combination as described in the [services doc](services). Ingress traffic is typically sent directly to the endpoints matching a backend.
+__Lines 10-12__: A backend is a service:port combination as described in the [services doc](/{{page.version}}/docs/user-guide/services). Ingress traffic is typically sent directly to the endpoints matching a backend.

 __Global Parameters__: For the sake of simplicity the example Ingress has no global parameters, see the [api-reference](https://releases.k8s.io/release-1.1/pkg/apis/extensions/v1beta1/types.go) for a full definition of the resource. One can specify a global default backend in the absence of which requests that don't match a path in the spec are sent to the default backend of the Ingress controller. Though the Ingress resource doesn't support HTTPS yet, security configs would also be global.

@@ -100,7 +100,7 @@ spec:
    servicePort: 80
 ```

-[Download example](ingress.yaml)
+[Download example](/{{page.version}}/docs/user-guide/ingress.yaml)
 <!-- END MUNGE: EXAMPLE ingress.yaml -->

 If you create it using `kubectl -f` you should see:
@@ -308,9 +308,9 @@ status:

 Learn about additional debugging tools, including:

-* [Logging](logging)
-* [Monitoring](monitoring)
-* [Getting into containers via `exec`](getting-into-containers)
+* [Logging](/{{page.version}}/docs/user-guide/logging)
+* [Monitoring](/{{page.version}}/docs/user-guide/monitoring)
+* [Getting into containers via `exec`](/{{page.version}}/docs/user-guide/getting-into-containers)
 * [Connecting to containers via proxies](/{{page.version}}/docs/user-guide/connecting-to-applications-proxy)
 * [Connecting to containers via port forwarding](/{{page.version}}/docs/user-guide/connecting-to-applications-port-forward)

@@ -42,7 +42,7 @@ spec:
      restartPolicy: Never
 ```

-[Download example](job.yaml)
+[Download example](/{{page.version}}/docs/user-guide/job.yaml)
 <!-- END MUNGE: EXAMPLE job.yaml -->

 Run the example job by downloading the example file and then running this command:
@@ -93,7 +93,7 @@ $ kubectl logs pi-aiw0a
 ## Writing a Job Spec

 As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields.  For
-general information about working with config files, see [here](simple-yaml),
+general information about working with config files, see [here](/{{page.version}}/docs/user-guide/simple-yaml),
 [here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](working-with-resources).

 A Job also needs a [`.spec` section](/{{page.version}}/docs/devel/api-conventions/#spec-and-status).
@@ -102,14 +102,14 @@ A Job also needs a [`.spec` section](/{{page.version}}/docs/devel/api-convention

 The `.spec.template` is the only required field of the `.spec`.

-The `.spec.template` is a [pod template](replication-controller/#pod-template).  It has exactly
-the same schema as a [pod](pods), except it is nested and does not have an `apiVersion` or
+The `.spec.template` is a [pod template](/{{page.version}}/docs/user-guide/replication-controller/#pod-template).  It has exactly
+the same schema as a [pod](/{{page.version}}/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or
 `kind`.

 In addition to required fields for a Pod, a pod template in a job must specify appropriate
 lables (see [pod selector](#pod-selector) and an appropriate restart policy.

-Only a [`RestartPolicy`](pod-states) equal to `Never` or `OnFailure` are allowed.
+Only a [`RestartPolicy`](/{{page.version}}/docs/user-guide/pod-states) equal to `Never` or `OnFailure` are allowed.

 ### Pod Selector

@@ -117,7 +117,7 @@ The `.spec.selector` field is a label query over a set of pods.

 The `spec.selector` is an object consisting of two fields:

-* `matchLabels` - works the same as the `.spec.selector` of a [ReplicationController](replication-controller)
+* `matchLabels` - works the same as the `.spec.selector` of a [ReplicationController](/{{page.version}}/docs/user-guide/replication-controller)
 * `matchExpressions` - allows to build more sophisticated selectors by specyfing key,
  list of values and an operator that relates the key and values.

@@ -161,7 +161,7 @@ a non-zero exit code, or the Container was killed for exceeding a memory limit,
 happens, and the `.spec.template.containers[].restartPolicy = "OnFailure"`, then the Pod stays
 on the node, but the Container is re-run.  Therefore, your program needs to handle the the case when it is
 restarted locally, or else specify `.spec.template.containers[].restartPolicy = "Never"`.
-See [pods-states](pod-states) for more information on `restartPolicy`.
+See [pods-states](/{{page.version}}/docs/user-guide/pod-states) for more information on `restartPolicy`.

 An entire Pod can also fail, for a number of reasons, such as when the pod is kicked off the node
 (node is upgraded, rebooted, delelted, etc.), or if a container of the Pod fails and the
@@ -188,11 +188,11 @@ requires only a single pod.

 ### Replication Controller

-Jobs are complementary to [Replication Controllers](replication-controller).
+Jobs are complementary to [Replication Controllers](/{{page.version}}/docs/user-guide/replication-controller).
 A Replication Controller manages pods which are not expected to terminate (e.g. web servers), and a Job
 manages pods that are expected to terminate (e.g. batch jobs).

-As discussed in [life of a pod](pod-states), `Job` is *only* appropriate for pods with
+As discussed in [life of a pod](/{{page.version}}/docs/user-guide/pod-states), `Job` is *only* appropriate for pods with
 `RestartPolicy` equal to `OnFailure` or `Never`.  (Note: If `RestartPolicy` is not set, the default
 value is `Always`.)

@@ -122,7 +122,7 @@ The rules for loading and merging the kubeconfig files are straightforward, but
 ## Manipulation of kubeconfig via `kubectl config <subcommand>`

 In order to more easily manipulate kubeconfig files, there are a series of subcommands to `kubectl config` to help.
-See [kubectl/kubectl_config.md](kubectl/kubectl_config) for help.
+See [kubectl/kubectl_config.md](/{{page.version}}/docs/user-guide/kubectl/kubectl_config) for help.

 ### Example

@@ -1,7 +1,7 @@
 ---
 title: "kubectl overview"
 ---
-Use this overview of the `kubectl` command line interface to help you start running commands against Kubernetes clusters. This overview quickly covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](kubectl/kubectl) reference documentation.
+Use this overview of the `kubectl` command line interface to help you start running commands against Kubernetes clusters. This overview quickly covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/{{page.version}}/docs/user-guide/kubectl/kubectl) reference documentation.

 TODO: Auto-generate this file to ensure it's always in sync with any `kubectl` changes, see [#14177](http://pr.k8s.io/14177).

@@ -74,7 +74,7 @@ Operation       | Syntax	|       Description
 `stop`		| `kubectl stop` | Deprecated: Instead, see `kubectl delete`.
 `version`		| `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server.

-Remember: For more about command operations, see the [kubectl](kubectl/kubectl) reference documentation.
+Remember: For more about command operations, see the [kubectl](/{{page.version}}/docs/user-guide/kubectl/kubectl) reference documentation.

 ## Resource types

@@ -101,7 +101,7 @@ Resource type	| Abbreviated alias

 ## Output options

-Use the following sections for information about how you can format or sort the output of certain commands. For details about which commands support the various output options, see the [kubectl](kubectl/kubectl) reference documentation.
+Use the following sections for information about how you can format or sort the output of certain commands. For details about which commands support the various output options, see the [kubectl](/{{page.version}}/docs/user-guide/kubectl/kubectl) reference documentation.

 ### Formatting output

@@ -120,8 +120,8 @@ Output format | Description
 `-o=custom-columns=<spec>` | Print a table using a comma separated list of [custom columns](#custom-columns).
 `-o=custom-columns-file=<filename>` | Print a table using the [custom columns](#custom-columns) template in the `<filename>` file.
 `-o=json`     | Output a JSON formatted API object.
-`-o=jsonpath=<template>` | Print the fields defined in a [jsonpath](jsonpath) expression.
-`-o=jsonpath-file=<filename>` | Print the fields defined by the [jsonpath](jsonpath) expression in the `<filename>` file.
+`-o=jsonpath=<template>` | Print the fields defined in a [jsonpath](/{{page.version}}/docs/user-guide/jsonpath) expression.
+`-o=jsonpath-file=<filename>` | Print the fields defined by the [jsonpath](/{{page.version}}/docs/user-guide/jsonpath) expression in the `<filename>` file.
 `-o=name`     | Print only the resource name and nothing else.
 `-o=wide`     | Output in the plain-text format with any additional information. For pods, the node name is included.
 `-o=yaml`     | Output a YAML formatted API object.
@@ -132,7 +132,7 @@ In this example, the following command outputs the details for a single pod as a

 `$ kubectl get pod web-pod-13je7 -o=yaml`

-Remember: See the [kubectl](kubectl/kubectl) reference documentation for details about which output format is supported by each command.
+Remember: See the [kubectl](/{{page.version}}/docs/user-guide/kubectl/kubectl) reference documentation for details about which output format is supported by each command.

 #### Custom columns

@@ -167,7 +167,7 @@ submit-queue   610995

 ### Sorting list objects

-To output objects to a sorted list in your terminal window, you can add the `--sort-by` flag to a supported `kubectl` command. Sort your objects by specifying any numeric or string field with the `--sort-by` flag. To specify a field, use a [jsonpath](jsonpath) expression.
+To output objects to a sorted list in your terminal window, you can add the `--sort-by` flag to a supported `kubectl` command. Sort your objects by specifying any numeric or string field with the `--sort-by` flag. To specify a field, use a [jsonpath](/{{page.version}}/docs/user-guide/jsonpath) expression.

 #### Syntax

@@ -267,4 +267,4 @@ $ kubectl logs -f <pod-name>

 ## Next steps

-Start using the [kubectl](kubectl/kubectl) commands.
+Start using the [kubectl](/{{page.version}}/docs/user-guide/kubectl/kubectl) commands.
@@ -43,7 +43,7 @@ Valid label values must be 63 characters or less and must be empty or begin and

 ## Label selectors

-Unlike [names and UIDs](identifiers), labels do not provide uniqueness. In general, we expect many objects to carry the same label(s).
+Unlike [names and UIDs](/{{page.version}}/docs/user-guide/identifiers), labels do not provide uniqueness. In general, we expect many objects to carry the same label(s).

 Via a _label selector_, the client/user can identify a set of objects. The label selector is the core grouping primitive in Kubernetes.

@@ -125,7 +125,7 @@ $ kubectl get pods -l 'environment,environment notin (frontend)'

 ### Set references in API objects

-Some Kubernetes objects, such as [`service`s](services) and [`replicationcontroller`s](replication-controller), also use label selectors to specify sets of other resources, such as [pods](pods).
+Some Kubernetes objects, such as [`service`s](/{{page.version}}/docs/user-guide/services) and [`replicationcontroller`s](/{{page.version}}/docs/user-guide/replication-controller), also use label selectors to specify sets of other resources, such as [pods](/{{page.version}}/docs/user-guide/pods).

 #### Service and ReplicationController

@@ -149,7 +149,7 @@ this selector (respectively in `json` or `yaml` format) is equivalent to `compon

 #### Job and other new resources

-Newer resources, such as [job](jobs), support _set-based_ requirements as well.
+Newer resources, such as [job](/{{page.version}}/docs/user-guide/jobs), support _set-based_ requirements as well.

 ```yaml
 selector:
@@ -3,7 +3,7 @@ title: "Overview"
 ---
 This example shows two types of pod [health checks](/{{page.version}}/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks): HTTP checks and container execution checks.

-The [exec-liveness.yaml](exec-liveness.yaml) demonstrates the container execution check.
+The [exec-liveness.yaml](/{{page.version}}/docs/user-guide/liveness/exec-liveness.yaml) demonstrates the container execution check.

 ```yaml
 livenessProbe:
@@ -26,7 +26,7 @@ echo ok > /tmp/health; sleep 10; rm -rf /tmp/health; sleep 600
 so when Kubelet executes the health check 15 seconds (defined by initialDelaySeconds) after the container started, the check would fail.


-The [http-liveness.yaml](http-liveness.yaml) demonstrates the HTTP check.
+The [http-liveness.yaml](/{{page.version}}/docs/user-guide/liveness/http-liveness.yaml) demonstrates the HTTP check.

 ```yaml
 livenessProbe:
@@ -2,9 +2,9 @@
 title: "Elasticsearch/Kibana Logging Demonstration"
 ---
 This directory contains two [pod](/{{page.version}}/docs/user-guide/pods) specifications which can be used as synthetic
-logging sources. The pod specification in [synthetic_0_25lps.yaml](synthetic_0_25lps.yaml)
+logging sources. The pod specification in [synthetic_0_25lps.yaml](/{{page.version}}/docs/user-guide/logging-demo/synthetic_0_25lps.yaml)
 describes a pod that just emits a log message once every 4 seconds. The pod specification in
-[synthetic_10lps.yaml](synthetic_10lps.yaml)
+[synthetic_10lps.yaml](/{{page.version}}/docs/user-guide/logging-demo/synthetic_10lps.yaml)
 describes a pod that just emits 10 log lines per second.

 See [logging document](/{{page.version}}/docs/user-guide/logging/) for more details about logging. To observe the ingested log lines when using Google Cloud Logging please see the getting
@@ -10,8 +10,8 @@ Kubernetes components, such as kubelet and apiserver, use the [glog](https://god
 ## Examining the logs of running containers

 The logs of a running container may be fetched using the command `kubectl logs`. For example, given
-this pod specification [counter-pod.yaml](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/blog-logging/counter-pod.yaml), which has a container which writes out some text to standard
-output every second. (You can find different pod specifications [here](logging-demo/).)
+this pod specification [counter-pod.yaml](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/blog-logging/counter-pod.yaml), which has a container which writes out some text to standard
+output every second. (You can find different pod specifications [here](/{{page.version}}/docs/user-guide/logging-demo/).)

 <!-- BEGIN MUNGE: EXAMPLE ../../examples/blog-logging/counter-pod.yaml -->

@@ -28,7 +28,7 @@ spec:
           'for ((i = 0; ; i++)); do echo "$i: $(date)"; sleep 1; done']
 ```

-[Download example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/blog-logging/counter-pod.yaml)
+[Download example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/blog-logging/counter-pod.yaml)
 <!-- END MUNGE: EXAMPLE ../../examples/blog-logging/counter-pod.yaml -->

 we can run the pod:
@@ -86,7 +86,7 @@ describes how to ingest cluster level logs into Elasticsearch and view them usin
 ## Ingesting Application Log Files

 Cluster level logging only collects the standard output and standard error output of the applications
-running in containers. The guide [Collecting log files within containers with Fluentd](http://releases.k8s.io/release-1.1/contrib/logging/fluentd-sidecar-gcp/README.md) explains how the log files of applications can also be ingested into Google Cloud logging.
+running in containers. The guide [Collecting log files within containers with Fluentd](http://releases.k8s.io/{{page.githubbranch}}/contrib/logging/fluentd-sidecar-gcp/README.md) explains how the log files of applications can also be ingested into Google Cloud logging.

 ## Known issues

@@ -1,7 +1,7 @@
 ---
 title: "Kubernetes User Guide: Managing Applications: Managing deployments"
 ---
-You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features we'll discuss in more depth are [configuration files](/{{page.version}}/docs/user-guide/configuring-containers/#configuration-in-kubernetes) and [labels](deploying-applications/#labels).
+You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features we'll discuss in more depth are [configuration files](/{{page.version}}/docs/user-guide/configuring-containers/#configuration-in-kubernetes) and [labels](/{{page.version}}/docs/user-guide/deploying-applications/#labels).

 * TOC
 {:toc}
@@ -113,7 +113,7 @@ my-nginx-svc   app=nginx   app=nginx   10.0.152.174   80/TCP

 The examples we've used so far apply at most a single label to any resource. There are many scenarios where multiple labels should be used to distinguish sets from one another.

-For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels:
+For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels:

 ```yaml
 labels:
@@ -233,7 +233,7 @@ my-nginx-o0ef1   1/1       Running   0          1h

 At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios.

-To update a service without an outage, `kubectl` supports what is called ['rolling update'?](kubectl/kubectl_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://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/simple-rolling-update.md) and the [example of rolling update](update-demo/) for more information.
+To update a service without an outage, `kubectl` supports what is called ['rolling update'?](/{{page.version}}/docs/user-guide/kubectl/kubectl_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://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/simple-rolling-update.md) and the [example of rolling update](/{{page.version}}/docs/user-guide/update-demo/) for more information.

 Let's say you were running version 1.7.9 of nginx:

@@ -256,7 +256,7 @@ spec:
        - containerPort: 80
 ```

-To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/simple-rolling-update.md):
+To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/simple-rolling-update.md):

 ```shell
 $ kubectl rolling-update my-nginx --image=nginx:1.9.1
@@ -361,7 +361,7 @@ Update succeeded. Deleting my-nginx
 my-nginx-v4
 ```

-You can also run the [update demo](update-demo/) to see a visual representation of the rolling update process.
+You can also run the [update demo](/{{page.version}}/docs/user-guide/update-demo/) to see a visual representation of the rolling update process.

 ## In-place updates of resources

@@ -405,5 +405,5 @@ replicationcontrollers/my-nginx-v4

 ## What's next?

- [Learn about how to use `kubectl` for application introspection and debugging.](introspection-and-debugging)
+- [Learn about how to use `kubectl` for application introspection and debugging.](/{{page.version}}/docs/user-guide/introspection-and-debugging)
 - [Tips and tricks when working with config](/{{page.version}}/docs/user-guide/config-best-practices
@@ -1,7 +1,7 @@
 ---
 title: "Resource Usage Monitoring in Kubernetes"
 ---
-Understanding how an application behaves when deployed is crucial to scaling the application and providing a reliable service. In a Kubernetes cluster, application performance can be examined at many different levels: containers, [pods](pods), [services](services), and whole clusters. As part of Kubernetes we want to provide users with detailed resource usage information about their running applications at all these levels. This will give users deep insights into how their applications are performing and where possible application bottlenecks may be found. In comes [Heapster](https://github.com/GoogleCloudPlatform/heapster), a project meant to provide a base monitoring platform on Kubernetes.
+Understanding how an application behaves when deployed is crucial to scaling the application and providing a reliable service. In a Kubernetes cluster, application performance can be examined at many different levels: containers, [pods](/{{page.version}}/docs/user-guide/pods), [services](/{{page.version}}/docs/user-guide/services), and whole clusters. As part of Kubernetes we want to provide users with detailed resource usage information about their running applications at all these levels. This will give users deep insights into how their applications are performing and where possible application bottlenecks may be found. In comes [Heapster](https://github.com/GoogleCloudPlatform/heapster), a project meant to provide a base monitoring platform on Kubernetes.

 ### Overview

@@ -19,7 +19,7 @@ In future versions of Kubernetes, objects in the same namespace will have the sa
 access control policies by default.

 It is not necessary to use multiple namespaces just to separate slightly different
-resources, such as different versions of the same software: use [labels](labels) to distinguish
+resources, such as different versions of the same software: use [labels](/{{page.version}}/docs/user-guide/labels) to distinguish
 resources within the same namespace.

 ## Working with Namespaces
@@ -73,7 +73,7 @@ $ kubectl config set-context $(CONTEXT) --namespace=<insert-namespace-name-here>

 ## Namespaces and DNS

-When you create a [Service](services), it creates a corresponding [DNS entry](/{{page.version}}/docs/admin/dns).
+When you create a [Service](/{{page.version}}/docs/user-guide/services), it creates a corresponding [DNS entry](/{{page.version}}/docs/admin/dns).
 This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means
 that if a container just uses `<service-name>` it will resolve to the service which
 is local to a namespace.  This is useful for using the same configuration across
@@ -15,7 +15,7 @@ Then, to add a label to the node you've chosen, run `kubectl label nodes <node-n

 If this fails with an "invalid command" error, you're likely using an older version of kubectl that doesn't have the `label` command. In that case, see the [previous version](https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) of this guide for instructions on how to manually set labels on a node.

-Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/identifiers.md)), meaning that they are not allowed to contain any upper-case letters.
+Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/identifiers.md)), meaning that they are not allowed to contain any upper-case letters.

 You can verify that it worked by re-running `kubectl get nodes` and checking that the node now has a label.

@@ -9,17 +9,17 @@ Kubernetes supports [Docker](http://www.docker.io) and [Rocket](https://coreos.c

 While Kubernetes currently focuses on continuously-running stateless (e.g. web server or in-memory object cache) and "cloud native" stateful applications (e.g. NoSQL datastores), in the near future it will support all the other workload types commonly found in production cluster environments, such as batch, stream processing, and traditional databases.

-In Kubernetes, all containers run inside [pods](pods). A pod can host a single container, or multiple cooperating containers; in the latter case, the containers in the pod are guaranteed to be co-located on the same machine and can share resources. A pod can also contain zero or more [volumes](volumes), which are directories that are private to a container or shared across containers in a pod. For each pod the user creates, the system finds a machine that is healthy and that has sufficient available capacity, and starts up the corresponding container(s) there. If a container fails it can be automatically restarted by Kubernetes' node agent, called the Kubelet. But if the pod or its machine fails, it is not automatically moved or restarted unless the user also defines a [replication controller](replication-controller), which we discuss next.
+In Kubernetes, all containers run inside [pods](/{{page.version}}/docs/user-guide/pods). A pod can host a single container, or multiple cooperating containers; in the latter case, the containers in the pod are guaranteed to be co-located on the same machine and can share resources. A pod can also contain zero or more [volumes](/{{page.version}}/docs/user-guide/volumes), which are directories that are private to a container or shared across containers in a pod. For each pod the user creates, the system finds a machine that is healthy and that has sufficient available capacity, and starts up the corresponding container(s) there. If a container fails it can be automatically restarted by Kubernetes' node agent, called the Kubelet. But if the pod or its machine fails, it is not automatically moved or restarted unless the user also defines a [replication controller](/{{page.version}}/docs/user-guide/replication-controller), which we discuss next.

-Users can create and manage pods themselves, but Kubernetes drastically simplifies system management by allowing users to delegate two common pod-related activities: deploying multiple pod replicas based on the same pod configuration, and creating replacement pods when a pod or its machine fails. The Kubernetes API object that manages these behaviors is called a [replication controller](replication-controller). It defines a pod in terms of a template, that the system then instantiates as some number of pods (specified by the user). The replicated set of pods might constitute an entire application, a micro-service, or one layer in a multi-tier application. Once the pods are created, the system continually monitors their health and that of the machines they are running on; if a pod fails due to a software problem or machine failure, the replication controller automatically creates a new pod on a healthy machine, to maintain the set of pods at the desired replication level. Multiple pods from the same or different applications can share the same machine. Note that a replication controller is needed even in the case of a single non-replicated pod if the user wants it to be re-created when it or its machine fails.
+Users can create and manage pods themselves, but Kubernetes drastically simplifies system management by allowing users to delegate two common pod-related activities: deploying multiple pod replicas based on the same pod configuration, and creating replacement pods when a pod or its machine fails. The Kubernetes API object that manages these behaviors is called a [replication controller](/{{page.version}}/docs/user-guide/replication-controller). It defines a pod in terms of a template, that the system then instantiates as some number of pods (specified by the user). The replicated set of pods might constitute an entire application, a micro-service, or one layer in a multi-tier application. Once the pods are created, the system continually monitors their health and that of the machines they are running on; if a pod fails due to a software problem or machine failure, the replication controller automatically creates a new pod on a healthy machine, to maintain the set of pods at the desired replication level. Multiple pods from the same or different applications can share the same machine. Note that a replication controller is needed even in the case of a single non-replicated pod if the user wants it to be re-created when it or its machine fails.

-Frequently it is useful to refer to a set of pods, for example to limit the set of pods on which a mutating operation should be performed, or that should be queried for status. As a general mechanism, users can attach to most Kubernetes API objects arbitrary key-value pairs called [labels](labels), and then use a set of label selectors (key-value queries over labels) to constrain the target of API operations. Each resource also has a map of string keys and values that can be used by external tooling to store and retrieve arbitrary metadata about this object, called [annotations](/{{page.version}}/docs/user-guide/annotations).
+Frequently it is useful to refer to a set of pods, for example to limit the set of pods on which a mutating operation should be performed, or that should be queried for status. As a general mechanism, users can attach to most Kubernetes API objects arbitrary key-value pairs called [labels](/{{page.version}}/docs/user-guide/labels), and then use a set of label selectors (key-value queries over labels) to constrain the target of API operations. Each resource also has a map of string keys and values that can be used by external tooling to store and retrieve arbitrary metadata about this object, called [annotations](/{{page.version}}/docs/user-guide/annotations).

 Kubernetes supports a unique [networking model](/{{page.version}}/docs/admin/networking). Kubernetes encourages a flat address space and does not dynamically allocate ports, instead allowing users to select whichever ports are convenient for them. To achieve this, it allocates an IP address for each pod.

-Modern Internet applications are commonly built by layering micro-services, for example a set of web front-ends talking to a distributed in-memory key-value store talking to a replicated storage service. To facilitate this architecture, Kubernetes offers the [service](services) abstraction, which provides a stable IP address and [DNS name](/{{page.version}}/docs/admin/dns) that corresponds to a dynamic set of pods such as the set of pods constituting a micro-service. The set is defined using a label selector and thus can refer to any set of pods. When a container running in a Kubernetes pod connects to this address, the connection is forwarded by a local agent (called the kube proxy) running on the source machine, to one of the corresponding back-end containers. The exact back-end is chosen using a round-robin policy to balance load. The kube proxy takes care of tracking the dynamic set of back-ends as pods are replaced by new pods on new hosts, so that the service IP address (and DNS name) never changes.
+Modern Internet applications are commonly built by layering micro-services, for example a set of web front-ends talking to a distributed in-memory key-value store talking to a replicated storage service. To facilitate this architecture, Kubernetes offers the [service](/{{page.version}}/docs/user-guide/services) abstraction, which provides a stable IP address and [DNS name](/{{page.version}}/docs/admin/dns) that corresponds to a dynamic set of pods such as the set of pods constituting a micro-service. The set is defined using a label selector and thus can refer to any set of pods. When a container running in a Kubernetes pod connects to this address, the connection is forwarded by a local agent (called the kube proxy) running on the source machine, to one of the corresponding back-end containers. The exact back-end is chosen using a round-robin policy to balance load. The kube proxy takes care of tracking the dynamic set of back-ends as pods are replaced by new pods on new hosts, so that the service IP address (and DNS name) never changes.

-Every resource in Kubernetes, such as a pod, is identified by a URI and has a UID. Important components of the URI are the kind of object (e.g. pod), the object's name, and the object's [namespace](namespaces). For a certain object kind, every name is unique within its namespace. In contexts where an object name is provided without a namespace, it is assumed to be in the default namespace. UID is unique across time and space.
+Every resource in Kubernetes, such as a pod, is identified by a URI and has a UID. Important components of the URI are the kind of object (e.g. pod), the object's name, and the object's [namespace](/{{page.version}}/docs/user-guide/namespaces). For a certain object kind, every name is unique within its namespace. In contexts where an object name is provided without a namespace, it is assumed to be in the default namespace. UID is unique across time and space.



@@ -1,7 +1,7 @@
 ---
 title: "Persistent Volumes and Claims"
 ---
-This document describes the current state of `PersistentVolumes` in Kubernetes.  Familiarity with [volumes](volumes) is suggested.
+This document describes the current state of `PersistentVolumes` in Kubernetes.  Familiarity with [volumes](/{{page.version}}/docs/user-guide/volumes) is suggested.

 * TOC
 {:toc}
@@ -14,7 +14,7 @@ A `PersistentVolume` (PV) is a piece of networked storage in the cluster that ha

 A `PersistentVolumeClaim` (PVC) is a request for storage by a user.  It is similar to a pod.  Pods consume node resources and PVCs consume PV resources.  Pods can request specific levels of resources (CPU and Memory).  Claims can request specific size and access modes (e.g, can be mounted once read/write or many times read-only).

-Please see the [detailed walkthrough with working examples](persistent-volumes/).
+Please see the [detailed walkthrough with working examples](/{{page.version}}/docs/user-guide/persistent-volumes/).


 ## Lifecycle of a volume and claim
@@ -80,7 +80,7 @@ apiVersion: v1

 ### Capacity

-Generally, a PV will have a specific storage capacity.  This is set using the PV's `capacity` attribute.  See the Kubernetes [Resource Model](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/resources.md) to understand the units expected by `capacity`.
+Generally, a PV will have a specific storage capacity.  This is set using the PV's `capacity` attribute.  See the Kubernetes [Resource Model](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/resources.md) to understand the units expected by `capacity`.

 Currently, storage size is the only resource that can be set or requested.  Future attributes may include IOPS, throughput, etc.

@@ -146,7 +146,7 @@ Claims use the same conventions as volumes when requesting storage with specific

 ### Resources

-Claims, like pods, can request specific quantities of a resource.  In this case, the request is for storage.  The same [resource model](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/resources.md) applies to both volumes and claims.
+Claims, like pods, can request specific quantities of a resource.  In this case, the request is for storage.  The same [resource model](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/resources.md) applies to both volumes and claims.

 ## Claims As Volumes

@@ -6,7 +6,7 @@ nginx serving content from your persistent volume.

 This guide assumes knowledge of Kubernetes fundamentals and that you have a cluster up and running.

-See [Persistent Storage design document](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/persistent-storage.md) for more information.
+See [Persistent Storage design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/persistent-storage.md) for more information.

 ## Provisioning

@@ -46,12 +46,13 @@ More detailed information about the current (and previous) container statuses ca

 ## RestartPolicy

-The possible values for RestartPolicy are `Always`, `OnFailure`, or `Never`. If RestartPolicy is not set, the default value is `Always`. RestartPolicy applies to all containers in the pod. RestartPolicy only refers to restarts of the containers by the Kubelet on the same node. Failed containers that are restarted by Kubelet, are restarted with an exponential back-off delay, the delay is in multiples of sync-frequency 0, 1x, 2x, 4x, 8x ... capped at 5 minutes and is reset after 10 minutes of successful execution. As discussed in the [pods document](pods/#durability-of-pods-or-lack-thereof), once bound to a node, a pod will never be rebound to another node. This means that some kind of controller is necessary in order for a pod to survive node failure, even if just a single pod at a time is desired.
+The possible values for RestartPolicy are `Always`, `OnFailure`, or `Never`. If RestartPolicy is not set, the default value is `Always`. RestartPolicy applies to all containers in the pod. RestartPolicy only refers to restarts of the containers by the Kubelet on the same node. Failed containers that are restarted by Kubelet, are restarted with an exponential back-off delay, the delay is in multiples of sync-frequency 0, 1x, 2x, 4x, 8x ... capped at 5 minutes and is reset after 10 minutes of successful execution. As discussed in the [pods document](/{{page.version}}/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), once bound to a node, a pod will never be rebound to another node. This means that some kind of controller is necessary in order for a pod to survive node failure, even if just a single pod at a time is desired.

 Three types of controllers are currently available:

- Use a [`Job`](jobs) for pods which are expected to terminate (e.g. batch computations).
- Use a [`ReplicationController`](replication-controller) for pods which are not expected to
+- Use a [`Job`](/{{page.version}}/docs/user-guide/jobs) for pods which are expected to terminate (e.g. batch computations).
+- Use a [`ReplicationController`](/{{page.version}}/docs/user-guide/replication-controller) for pods which are not expected to
+
  terminate, and where (e.g. web servers).
 - Use a [`DaemonSet`](/{{page.version}}/docs/admin/daemons): Use for pods which need to run 1 per machine because they provide a
  machine-specific system service.
@@ -19,9 +19,9 @@ The context of the pod can be defined as the conjunction of several Linux namesp

 Applications within a pod also have access to shared volumes, which are defined at the pod level and made available in each application's filesystem. Additionally, a pod may define top-level cgroup isolations which form an outer bound to any individual isolation applied to constituent applications.

-In terms of [Docker](https://www.docker.com/) constructs, a pod consists of a colocated group of Docker containers with shared [volumes](volumes). PID namespace sharing is not yet implemented with Docker.
+In terms of [Docker](https://www.docker.com/) constructs, a pod consists of a colocated group of Docker containers with shared [volumes](/{{page.version}}/docs/user-guide/volumes). PID namespace sharing is not yet implemented with Docker.

-Like individual application containers, pods are considered to be relatively ephemeral rather than durable entities. As discussed in [life of a pod](pod-states), pods are scheduled to nodes and remain there until termination (according to restart policy) or deletion. When a node dies, the pods scheduled to that node are deleted. Specific pods are never rescheduled to new nodes; instead, they must be replaced (see [replication controller](replication-controller) for more details). (In the future, a higher-level API may support pod migration.)
+Like individual application containers, pods are considered to be relatively ephemeral rather than durable entities. As discussed in [life of a pod](/{{page.version}}/docs/user-guide/pod-states), pods are scheduled to nodes and remain there until termination (according to restart policy) or deletion. When a node dies, the pods scheduled to that node are deleted. Specific pods are never rescheduled to new nodes; instead, they must be replaced (see [/{{page.version}}/docs/user-guide/replication controller](/{{page.version}}/docs/user-guide/replication-controller) for more details). (In the future, a higher-level API may support pod migration.)

 ## Motivation for pods

@@ -68,7 +68,7 @@ That approach would provide co-location, but would not provide most of the benef

 Pods aren't intended to be treated as durable [pets](https://blog.engineyard.com/2014/pets-vs-cattle). They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance.

-In general, users shouldn't need to create pods directly. They should almost always use controllers (e.g., [replication controller](replication-controller)), even for singletons.  Controllers provide self-healing with a cluster scope, as well as replication and rollout management.
+In general, users shouldn't need to create pods directly. They should almost always use controllers (e.g., [replication controller](/{{page.version}}/docs/user-guide/replication-controller)), even for singletons.  Controllers provide self-healing with a cluster scope, as well as replication and rollout management.

 The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api), [Aurora](http://aurora.apache.org/documentation/latest/configuration-reference/#job-schema), and [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).

@@ -1,7 +1,7 @@
 ---
 title: "Kubernetes User Guide: Managing Applications: Prerequisites"
 ---
-To deploy and manage applications on Kubernetes, you'll use the Kubernetes command-line tool, [kubectl](kubectl/kubectl). It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps.
+To deploy and manage applications on Kubernetes, you'll use the Kubernetes command-line tool, [kubectl](/{{page.version}}/docs/user-guide/kubectl/kubectl). It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps.

 ## Installing kubectl

@@ -38,7 +38,7 @@ export PATH=<path/to/kubernetes-directory>/platforms/linux/amd64:$PATH

 ## Configuring kubectl

-In order for kubectl to find and access the Kubernetes cluster, it needs a [kubeconfig file](kubeconfig-file), which is created automatically when creating a cluster using kube-up.sh (see the [getting started guides](/{{page.version}}/docs/getting-started-guides/) for more about creating clusters). If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](sharing-clusters).
+In order for kubectl to find and access the Kubernetes cluster, it needs a [kubeconfig file](/{{page.version}}/docs/user-guide/kubeconfig-file), which is created automatically when creating a cluster using kube-up.sh (see the [getting started guides](/{{page.version}}/docs/getting-started-guides/) for more about creating clusters). If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/{{page.version}}/docs/user-guide/sharing-clusters).
 By default, kubectl configuration lives at `~/.kube/config`.

 #### Making sure you're ready
@@ -53,4 +53,4 @@ If you see a url response, you are ready to go.

 ## What's next?

-[Learn how to launch and expose your application.](quick-start)
+[Learn how to launch and expose your application.](/{{page.version}}/docs/user-guide/quick-start)
@@ -8,9 +8,9 @@ You've seen [how to configure and deploy pods and containers](/{{page.version}}/

 ## Persistent storage

-The container file system only lives as long as the container does, so when a container crashes and restarts, changes to the filesystem will be lost and the container will restart from a clean slate. To access more-persistent storage, outside the container file system, you need a [*volume*](volumes). This is especially important to stateful applications, such as key-value stores and databases.
+The container file system only lives as long as the container does, so when a container crashes and restarts, changes to the filesystem will be lost and the container will restart from a clean slate. To access more-persistent storage, outside the container file system, you need a [*volume*](/{{page.version}}/docs/user-guide/volumes). This is especially important to stateful applications, such as key-value stores and databases.

-For example, [Redis](http://redis.io/) is a key-value cache and store, which we use in the [guestbook](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/) and other examples. We can add a volume to it to store persistent data as follows:
+For example, [Redis](http://redis.io/) is a key-value cache and store, which we use in the [guestbook](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/) and other examples. We can add a volume to it to store persistent data as follows:

 ```yaml
 apiVersion: v1
@@ -39,15 +39,15 @@ spec:
          name: data   # must match the name of the volume, above
 ```

-`emptyDir` volumes live for the lifespan of the [pod](pods), which is longer than the lifespan of any one container, so if the container fails and is restarted, our storage will live on.
+`emptyDir` volumes live for the lifespan of the [pod](/{{page.version}}/docs/user-guide/pods), which is longer than the lifespan of any one container, so if the container fails and is restarted, our storage will live on.

-In addition to the local disk storage provided by `emptyDir`, Kubernetes supports many different network-attached storage solutions, including PD on GCE and EBS on EC2, which are preferred for critical data, and will handle details such as mounting and unmounting the devices on the nodes. See [the volumes doc](volumes) for more details.
+In addition to the local disk storage provided by `emptyDir`, Kubernetes supports many different network-attached storage solutions, including PD on GCE and EBS on EC2, which are preferred for critical data, and will handle details such as mounting and unmounting the devices on the nodes. See [the volumes doc](/{{page.version}}/docs/user-guide/volumes) for more details.

 ## Distributing credentials

 Many applications need credentials, such as passwords, OAuth tokens, and TLS keys, to authenticate with other applications, databases, and services. Storing these credentials in container images or environment variables is less than ideal, since the credentials can then be copied by anyone with access to the image, pod/container specification, host file system, or host Docker daemon.

-Kubernetes provides a mechanism, called [*secrets*](secrets), that facilitates delivery of sensitive credentials to applications. A `Secret` is a simple resource containing a map of data. For instance, a simple secret with a username and password might look as follows:
+Kubernetes provides a mechanism, called [*secrets*](/{{page.version}}/docs/user-guide/secrets), that facilitates delivery of sensitive credentials to applications. A `Secret` is a simple resource containing a map of data. For instance, a simple secret with a username and password might look as follows:

 ```yaml
 apiVersion: v1
@@ -104,14 +104,14 @@ spec:
          name: supersecret
 ```

-For more details, see the [secrets document](secrets), [example](secrets/) and [design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/secrets.md).
+For more details, see the [secrets document](/{{page.version}}/docs/user-guide/secrets), [example](/{{page.version}}/docs/user-guide/secrets/) and [design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/secrets.md).

 ## Authenticating with a private image registry

-Secrets can also be used to pass [image registry credentials](images/#using-a-private-registry).
+Secrets can also be used to pass [image registry credentials](/{{page.version}}/docs/user-guide/images/#using-a-private-registry).

 First, create a `.dockercfg` file, such as running `docker login <registry.domain>`.
-Then put the resulting `.dockercfg` file into a [secret resource](secrets).  For example:
+Then put the resulting `.dockercfg` file into a [secret resource](/{{page.version}}/docs/user-guide/secrets).  For example:

 ```shell
 $ docker login
@@ -159,9 +159,9 @@ spec:

 ## Helper containers

-[Pods](pods) support running multiple containers co-located together. They can be used to host vertically integrated application stacks, but their primary motivation is to support auxiliary helper programs that assist the primary application. Typical examples are data pullers, data pushers, and proxies.
+[Pods](/{{page.version}}/docs/user-guide/pods) support running multiple containers co-located together. They can be used to host vertically integrated application stacks, but their primary motivation is to support auxiliary helper programs that assist the primary application. Typical examples are data pullers, data pushers, and proxies.

-Such containers typically need to communicate with one another, often through the file system. This can be achieved by mounting the same volume into both containers. An example of this pattern would be a web server with a [program that polls a git repository](http://releases.k8s.io/release-1.1/contrib/git-sync/) for new updates:
+Such containers typically need to communicate with one another, often through the file system. This can be achieved by mounting the same volume into both containers. An example of this pattern would be a web server with a [program that polls a git repository](http://releases.k8s.io/{{page.githubbranch}}/contrib/git-sync/) for new updates:

 ```yaml
 apiVersion: v1
@@ -202,7 +202,7 @@ More examples can be found in our [blog article](http://blog.kubernetes.io/2015/

 Kubernetes's scheduler will place applications only where they have adequate CPU and memory, but it can only do so if it knows how much [resources they require](/{{page.version}}/docs/user-guide/compute-resources). The consequence of specifying too little CPU is that the containers could be starved of CPU if too many other containers were scheduled onto the same node. Similarly, containers could die unpredictably due to running out of memory if no memory were requested, which can be especially likely for large-memory applications.

-If no resource requirements are specified, a nominal amount of resources is assumed. (This default is applied via a [LimitRange](/{{page.version}}/docs/admin/limitrange/) for the default [Namespace](namespaces). It can be viewed with `kubectl describe limitrange limits`.) You may explicitly specify the amount of resources required as follows:
+If no resource requirements are specified, a nominal amount of resources is assumed. (This default is applied via a [LimitRange](/{{page.version}}/docs/admin/limitrange/) for the default [Namespace](/{{page.version}}/docs/user-guide/namespaces). It can be viewed with `kubectl describe limitrange limits`.) You may explicitly specify the amount of resources required as follows:

 ```yaml
 apiVersion: v1
@@ -234,13 +234,13 @@ spec:
            memory: 64Mi
 ```

-The container will die due to OOM (out of memory) if it exceeds its specified limit, so specifying a value a little higher than expected generally improves reliability. By specifying request, pod is guaranteed to be able to use that much of resource when needed. See [Resource QoS](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/proposals/resource-qos.md) for the difference between resource limits and requests.
+The container will die due to OOM (out of memory) if it exceeds its specified limit, so specifying a value a little higher than expected generally improves reliability. By specifying request, pod is guaranteed to be able to use that much of resource when needed. See [Resource QoS](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/resource-qos.md) for the difference between resource limits and requests.

-If you're not sure how much resources to request, you can first launch the application without specifying resources, and use [resource usage monitoring](monitoring) to determine appropriate values.
+If you're not sure how much resources to request, you can first launch the application without specifying resources, and use [resource usage monitoring](/{{page.version}}/docs/user-guide/monitoring) to determine appropriate values.

 ## Liveness and readiness probes (aka health checks)

-Many applications running for long periods of time eventually transition to broken states, and cannot recover except by restarting them. Kubernetes provides [*liveness probes*](pod-states/#container-probes) to detect and remedy such situations.
+Many applications running for long periods of time eventually transition to broken states, and cannot recover except by restarting them. Kubernetes provides [*liveness probes*](/{{page.version}}/docs/user-guide/pod-states/#container-probes) to detect and remedy such situations.

 A common way to probe an application is using HTTP, which can be specified as follows:

@@ -272,7 +272,7 @@ spec:

 Other times, applications are only temporarily unable to serve, and will recover on their own. Typically in such cases you'd prefer not to kill the application, but don't want to send it requests, either, since the application won't respond correctly or at all. A common such scenario is loading large data or configuration files during application startup. Kubernetes provides *readiness probes* to detect and mitigate such situations. Readiness probes are configured similarly to liveness probes, just using the `readinessProbe` field. A pod with containers reporting that they are not ready will not receive traffic through Kubernetes [services](/{{page.version}}/docs/user-guide/connecting-applications).

-For more details (e.g., how to specify command-based probes), see the [example in the walkthrough](walkthrough/k8s201/#health-checking), the [standalone example](liveness/), and the [documentation](pod-states/#container-probes).
+For more details (e.g., how to specify command-based probes), see the [example in the walkthrough](/{{page.version}}/docs/user-guide/walkthrough/k8s201/#health-checking), the [standalone example](/{{page.version}}/docs/user-guide/liveness/), and the [documentation](/{{page.version}}/docs/user-guide/pod-states/#container-probes).

 ## Lifecycle hooks and termination notice

@@ -309,7 +309,7 @@ spec:

 ## Termination message

-In order to achieve a reasonably high level of availability, especially for actively developed applications, it's important to debug failures quickly. Kubernetes can speed debugging by surfacing causes of fatal errors in a way that can be display using [`kubectl`](kubectl/kubectl) or the [UI](ui), in addition to general [log collection](logging). It is possible to specify a `terminationMessagePath` where a container will write its 'death rattle'?, such as assertion failure messages, stack traces, exceptions, and so on. The default path is `/dev/termination-log`.
+In order to achieve a reasonably high level of availability, especially for actively developed applications, it's important to debug failures quickly. Kubernetes can speed debugging by surfacing causes of fatal errors in a way that can be display using [`kubectl`](/{{page.version}}/docs/user-guide/kubectl/kubectl) or the [UI](/{{page.version}}/docs/user-guide/ui), in addition to general [log collection](/{{page.version}}/docs/user-guide/logging). It is possible to specify a `terminationMessagePath` where a container will write its 'death rattle'?, such as assertion failure messages, stack traces, exceptions, and so on. The default path is `/dev/termination-log`.

 Here is a toy example:

@@ -340,4 +340,4 @@ $ kubectl get pods/pod-w-message -o go-template="{{range .status.containerStatus
 ```
 ## What's next?

-[Learn more about managing deployments.](managing-deployments)
+[Learn more about managing deployments.](/{{page.version}}/docs/user-guide/managing-deployments)
@@ -1,7 +1,7 @@
 ---
 title: "Kubernetes User Guide: Managing Applications: Quick start"
 ---
-This guide will help you get oriented to Kubernetes and running your first containers on the cluster. If you are already familiar with the docker-cli, you can also checkout the docker-cli to kubectl migration guide [here](docker-cli-to-kubectl).
+This guide will help you get oriented to Kubernetes and running your first containers on the cluster. If you are already familiar with the docker-cli, you can also checkout the docker-cli to kubectl migration guide [here](/{{page.version}}/docs/user-guide/docker-cli-to-kubectl).

 * TOC
 {:toc}
@@ -10,7 +10,7 @@ This guide will help you get oriented to Kubernetes and running your first conta

 Once your application is packaged into a container and pushed to an image registry, you're ready to deploy it to Kubernetes.

-For example, [nginx](http://wiki.nginx.org/Main) is a popular HTTP server, with a [pre-built container on Docker hub](https://registry.hub.docker.com/_/nginx/). The [`kubectl run`](kubectl/kubectl_run) command below will create two nginx replicas, listening on port 80.
+For example, [nginx](http://wiki.nginx.org/Main) is a popular HTTP server, with a [pre-built container on Docker hub](https://registry.hub.docker.com/_/nginx/). The [`kubectl run`](/{{page.version}}/docs/user-guide/kubectl/kubectl_run) command below will create two nginx replicas, listening on port 80.

 ```shell
 $ kubectl run my-nginx --image=nginx --replicas=2 --port=80
@@ -48,7 +48,7 @@ my-nginx     10.179.240.1     25.1.2.3          80/TCP                 run=nginx

 You may need to wait for a minute or two for the external ip address to be provisioned.

-In order to access your nginx landing page, you also have to make sure that traffic from external IPs is allowed. Do this by opening a [firewall to allow traffic on port 80](services-firewalls).
+In order to access your nginx landing page, you also have to make sure that traffic from external IPs is allowed. Do this by opening a [firewall to allow traffic on port 80](/{{page.version}}/docs/user-guide/services-firewalls).

 ## Killing the application

@@ -8,7 +8,7 @@ title: "Replication Controller"

 A _replication controller_ ensures that a specified number of pod "replicas" are running at any one time.  If there are too many, it will kill some.  If there are too few, it will start more. Unlike in the case where a user directly created pods, a replication controller replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a replication controller even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node.  A replication controller delegates local container restarts to some agent on the node (e.g., Kubelet or Docker).

-As discussed in [life of a pod](pod-states), `ReplicationController` is *only* appropriate for pods with `RestartPolicy = Always`. (Note: If `RestartPolicy` is not set, the default value is `Always`.)  `ReplicationController` should refuse to instantiate any pod that has a different restart policy. As discussed in [issue #503](http://issue.k8s.io/503#issuecomment-50169443), we expect other types of controllers to be added to Kubernetes to handle other types of workloads, such as build/test and batch workloads, in the future.
+As discussed in [life of a pod](/{{page.version}}/docs/user-guide/pod-states), `ReplicationController` is *only* appropriate for pods with `RestartPolicy = Always`. (Note: If `RestartPolicy` is not set, the default value is `Always`.)  `ReplicationController` should refuse to instantiate any pod that has a different restart policy. As discussed in [issue #503](http://issue.k8s.io/503#issuecomment-50169443), we expect other types of controllers to be added to Kubernetes to handle other types of workloads, such as build/test and batch workloads, in the future.

 A replication controller will never terminate on its own, but it isn't expected to be as long-lived as services. Services may be composed of pods controlled by multiple replication controllers, and it is expected that many replication controllers may be created and destroyed over the lifetime of a service (for instance, to perform an update of pods that run the service). Both services themselves and their clients should remain oblivious to the replication controllers that maintain the pods of the services.

@@ -24,7 +24,7 @@ Pods created by a replication controller are intended to be fungible and semanti

 ### Labels

-The population of pods that a replication controller is monitoring is defined with a [label selector](labels/#label-selectors), which creates a loosely coupled relationship between the controller and the pods controlled, in contrast to pods, which are more tightly coupled to their definition. We deliberately chose not to represent the set of pods controlled using a fixed-length array of pod specifications, because our experience is that approach increases complexity of management operations, for both clients and the system.
+The population of pods that a replication controller is monitoring is defined with a [label selector](/{{page.version}}/docs/user-guide/labels/#label-selectors), which creates a loosely coupled relationship between the controller and the pods controlled, in contrast to pods, which are more tightly coupled to their definition. We deliberately chose not to represent the set of pods controlled using a fixed-length array of pod specifications, because our experience is that approach increases complexity of management operations, for both clients and the system.

 The replication controller should verify that the pods created from the specified template have labels that match its label selector. Though it isn't verified yet, you should also ensure that only one replication controller controls any given pod, by ensuring that the label selectors of replication controllers do not target overlapping sets. If you do end up with multiple controllers that have overlapping selectors, you will have to manage the deletion yourself with --cascade=false until there are no controllers with an overlapping superset of selectors.

@@ -32,7 +32,7 @@ Note that replication controllers may themselves have labels and would generally

 Pods may be removed from a replication controller's target set by changing their labels. This technique may be used to remove pods from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (assuming that the number of replicas is not also changed).

-Similarly, deleting a replication controller using the API does not affect the pods it created. Its `replicas` field must first be set to `0` in order to delete the pods controlled. (Note that the client tool, `kubectl`, provides a single operation, [delete](kubectl/kubectl_delete) to delete both the replication controller and the pods it controls. If you want to leave the pods running when deleting a replication controller, specify `--cascade=false`. However, there is no such operation in the API at the moment)
+Similarly, deleting a replication controller using the API does not affect the pods it created. Its `replicas` field must first be set to `0` in order to delete the pods controlled. (Note that the client tool, `kubectl`, provides a single operation, [delete](/{{page.version}}/docs/user-guide/kubectl/kubectl_delete) to delete both the replication controller and the pods it controls. If you want to leave the pods running when deleting a replication controller, specify `--cascade=false`. However, there is no such operation in the API at the moment)

 ## Responsibilities of the replication controller

@@ -63,7 +63,7 @@ Ideally, the rolling update controller would take application readiness into acc
 The two replication controllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates.

 Rolling update is implemented in the client tool
-[kubectl](kubectl/kubectl_rolling-update)
+[kubectl](/{{page.version}}/docs/user-guide/kubectl/kubectl_rolling-update)

 ### Multiple release tracks

@@ -4,7 +4,7 @@ title: "Secrets"
 Objects of type `secret` are intended to hold sensitive information, such as
 passwords, OAuth tokens, and ssh keys.  Putting this information in a `secret`
 is safer and more flexible than putting it verbatim in a `pod` definition or in
-a docker image. See [Secrets design document](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/secrets.md) for more information.
+a docker image. See [Secrets design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/secrets.md) for more information.

 * TOC
 {:toc}
@@ -19,7 +19,7 @@ more control over how it is used, and reduces the risk of accidental exposure.
 Users can create secrets, and the system also creates some secrets.

 To use a secret, a pod needs to reference the secret.
-A secret can be used with a pod in two ways: either as files in a [volume](volumes) mounted on one or more of
+A secret can be used with a pod in two ways: either as files in a [volume](/{{page.version}}/docs/user-guide/volumes) mounted on one or more of
 its containers, or used by kubelet when pulling images for the pod.

 ### Service Accounts Automatically Create and Attach Secrets with API Credentials
@@ -32,7 +32,7 @@ The automatic creation and use of API credentials can be disabled or overridden
 if desired.  However, if all you need to do is securely access the apiserver,
 this is the recommended workflow.

-See the [Service Account](service-accounts) documentation for more
+See the [Service Account](/{{page.version}}/docs/user-guide/service-accounts) documentation for more
 information on how Service Accounts work.

 ### Creating a Secret Manually
@@ -51,12 +51,12 @@ data:
 ```

 The data field is a map.  Its keys must match
-[`DNS_SUBDOMAIN`](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/identifiers.md), except that leading dots are also
+[`DNS_SUBDOMAIN`](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/identifiers.md), except that leading dots are also
 allowed.  The values are arbitrary data, encoded using base64. The values of
 username and password in the example above, before base64 encoding,
 are `value-1` and `value-2`, respectively, with carriage return and newline characters at the end.

-Create the secret using [`kubectl create`](kubectl/kubectl_create).
+Create the secret using [`kubectl create`](/{{page.version}}/docs/user-guide/kubectl/kubectl_create).

 Once the secret is created, you can need to modify your pod to specify
 that it should use the secret.
@@ -101,11 +101,11 @@ own `volumeMounts` block, but only one `spec.volumes` is needed per secret.
 You can package many files into one secret, or use many secrets,
 whichever is convenient.

-See another example of creating a secret and a pod that consumes that secret in a volume [here](secrets/).
+See another example of creating a secret and a pod that consumes that secret in a volume [here](/{{page.version}}/docs/user-guide/secrets/).

 ### Manually specifying an imagePullSecret

-Use of imagePullSecrets is described in the [images documentation](images/#specifying-imagepullsecrets-on-a-pod)
+Use of imagePullSecrets is described in the [images documentation](/{{page.version}}/docs/user-guide/images/#specifying-imagepullsecrets-on-a-pod)

 ### Arranging for imagePullSecrets to be Automatically Attached

@@ -113,7 +113,7 @@ You can manually create an imagePullSecret, and reference it from
 a serviceAccount.  Any pods created with that serviceAccount
 or that default to use that serviceAccount, will get have the imagePullSecret of the
 field set to that of the service account.
-See [here](service-accounts/#adding-imagepullsecrets-to-a-service-account)
+See [here](/{{page.version}}/docs/user-guide/service-accounts/#adding-imagepullsecrets-to-a-service-account)
 for a detailed explanation of that process.


@@ -187,7 +187,7 @@ change, even if the secret resource is modified.  To change the secret used,
 the original pod must be deleted, and a new pod (perhaps with an identical
 `PodSpec`) must be created.  Therefore, updating a secret follows the same
 workflow as deploying a new container image.  The `kubectl rolling-update`
-command can be used ([man page](kubectl/kubectl_rolling-update)).
+command can be used ([man page](/{{page.version}}/docs/user-guide/kubectl/kubectl_rolling-update)).

 The [`resourceVersion`](/{{page.version}}/docs/devel/api-conventions/#concurrency-control-and-consistency)
 of the secret is not specified when it is referenced.
@@ -1,7 +1,7 @@
 ---
 title: "Secrets example"
 ---
-Following this example, you will create a [secret](/{{page.version}}/docs/user-guide/secrets/) and a [pod](/{{page.version}}/docs/user-guide/pods/) that consumes that secret in a [volume](/{{page.version}}/docs/user-guide/volumes/). See [Secrets design document](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/secrets.md) for more information.
+Following this example, you will create a secret and a [pod](/{{page.version}}/docs/user-guide/pods/) that consumes that secret in a [volume](/{{page.version}}/docs/user-guide/volumes/). See [Secrets design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/secrets.md) for more information.

 ## Step Zero: Prerequisites

@@ -13,7 +13,7 @@ started](/{{page.version}}/docs/getting-started-guides/) for installation instru

 A secret contains a set of named byte arrays.

-Use the [`examples/secrets/secret.yaml`](secret.yaml) file to create a secret:
+Use the [`examples/secrets/secret.yaml`](/{{page.version}}/docs/user-guide/secrets/secret.yaml) file to create a secret:

 ```shell
 $ kubectl create -f docs/user-guide/secrets/secret.yaml
@@ -44,7 +44,7 @@ data-2: 11 bytes
 Pods consume secrets in volumes.  Now that you have created a secret, you can create a pod that
 consumes it.

-Use the [`examples/secrets/secret-pod.yaml`](secret-pod.yaml) file to create a Pod that consumes the secret.
+Use the [`examples/secrets/secret-pod.yaml`](/{{page.version}}/docs/user-guide/secrets/secret-pod.yaml) file to create a Pod that consumes the secret.

 ```shell
 $ kubectl create -f docs/user-guide/secrets/secret-pod.yaml
@@ -1,4 +1,4 @@
 ---
 title: "Security Contexts"
 ---
-A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. See [security context design](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/security_context.md) for more details.
+A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. See [security context design](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/security_context.md) for more details.
@@ -130,7 +130,7 @@ token:

 ## Adding ImagePullSecrets to a service account

-First, create an imagePullSecret, as described [here](images/#specifying-imagepullsecrets-on-a-pod)
+First, create an imagePullSecret, as described [here](/{{page.version}}/docs/user-guide/images/#specifying-imagepullsecrets-on-a-pod)
 Next, verify it has been created.  For example:

 ```shell
@@ -1,10 +1,10 @@
 ---
 title: "Services in Kubernetes"
 ---
-Kubernetes [`Pods`](pods) are mortal. They are born and they die, and they
-are not resurrected.  [`ReplicationControllers`](replication-controller) in
+Kubernetes [`Pods`](/{{page.version}}/docs/user-guide/pods) are mortal. They are born and they die, and they
+are not resurrected.  [`ReplicationControllers`](/{{page.version}}/docs/user-guide/replication-controller) in
 particular create and destroy `Pods` dynamically (e.g. when scaling up or down
-or when doing [rolling updates](kubectl/kubectl_rolling-update)).  While each `Pod` gets its own IP address, even
+or when doing [rolling updates](/{{page.version}}/docs/user-guide/kubectl/kubectl_rolling-update)).  While each `Pod` gets its own IP address, even
 those IP addresses cannot be relied upon to be stable over time. This leads to
 a problem: if some set of `Pods` (let's call them backends) provides
 functionality to other `Pods` (let's call them frontends) inside the Kubernetes
@@ -16,7 +16,7 @@ Enter `Services`.
 A Kubernetes `Service` is an abstraction which defines a logical set of `Pods`
 and a policy by which to access them - sometimes called a micro-service.  The
 set of `Pods` targeted by a `Service` is (usually) determined by a [`Label
-Selector`](labels/#label-selectors) (see below for why you might want a
+Selector`](/{{page.version}}/docs/user-guide/labels/#label-selectors) (see below for why you might want a
 `Service` without a selector).

 As an example, consider an image-processing backend which is running with 3
@@ -89,7 +89,7 @@ abstract other kinds of backends.  For example:
  * You want to have an external database cluster in production, but in test
    you use your own databases.
  * You want to point your service to a service in another
-    [`Namespace`](namespaces) or on another cluster.
+    [`Namespace`](/{{page.version}}/docs/user-guide/namespaces) or on another cluster.
  * You are migrating your workload to Kubernetes and some of your backends run
    outside of Kubernetes.

@@ -240,7 +240,7 @@ variables and DNS.
 When a `Pod` is run on a `Node`, the kubelet adds a set of environment variables
 for each active `Service`.  It supports both [Docker links
 compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see
-[makeLinkVariables](http://releases.k8s.io/release-1.1/pkg/kubelet/envvars/envvars.go#L49))
+[makeLinkVariables](http://releases.k8s.io/{{page.githubbranch}}/pkg/kubelet/envvars/envvars.go#L49))
 and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables,
 where the Service name is upper-cased and dashes are converted to underscores.

@@ -265,7 +265,7 @@ variables will not be populated.  DNS does not have this restriction.
 ### DNS

 An optional (though strongly recommended) [cluster
-add-on](http://releases.k8s.io/release-1.1/cluster/addons/README.md) is a DNS server.  The
+add-on](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/README.md) is a DNS server.  The
 DNS server watches the Kubernetes API for new `Services` and creates a set of
 DNS records for each.  If DNS has been enabled throughout the cluster then all
 `Pods` should be able to do name resolution of `Services` automatically.
@@ -528,4 +528,4 @@ of which `Pods` they are actually accessing.

 Service is a top-level resource in the kubernetes REST API. More details about the
 API object can be found at: [Service API
-object](/{{ page.version }}/docs/api-reference/v1/definitions/#_v1_service).
+object](/{{page.version}}/docs/api-reference/v1/definitions/#_v1_service).
@@ -2,7 +2,7 @@
 title: "Sharing Cluster Access"
 ---
 Client access to a running Kubernetes cluster can be shared by copying
-the `kubectl` client config bundle ([kubeconfig](kubeconfig-file)).
+the `kubectl` client config bundle ([kubeconfig](/{{page.version}}/docs/user-guide/kubeconfig-file)).
 This config bundle lives in `$HOME/.kube/config`, and is generated
 by `cluster/kube-up.sh`. Sample steps for sharing `kubeconfig` below.

@@ -89,7 +89,7 @@ $ export KUBECONFIG=/path/to/standalone/.kube/config
 kube master at cluster turnup. They can be found on the master under
 `/srv/kubernetes`. Bearer token/basic auth are also generated on the kube master.

-For more details on `kubeconfig` see [kubeconfig-file.md](kubeconfig-file),
+For more details on `kubeconfig` see [kubeconfig-file.md](/{{page.version}}/docs/user-guide/kubeconfig-file),
 and/or run `kubectl config -h`.

 ## Merging `kubeconfig` Example
@@ -116,4 +116,4 @@ $ scp host2:/path/to/home2/.kube/config /path/to/other/.kube/config
 $ export $KUBECONFIG=/path/to/other/.kube/config
 ```

-Detailed examples and explanation of `kubeconfig` loading/merging rules can be found in [kubeconfig-file](kubeconfig-file).
+Detailed examples and explanation of `kubeconfig` loading/merging rules can be found in [kubeconfig-file](/{{page.version}}/docs/user-guide/kubeconfig-file).
@@ -9,7 +9,7 @@ to Kubernetes and running your first containers on the cluster.

 From this point onwards, it is assumed that `kubectl` is on your path from one of the getting started guides.

-The [`kubectl run`](kubectl/kubectl_run) line below will create two [nginx](https://registry.hub.docker.com/_/nginx/) [pods](pods) listening on port 80. It will also create a [replication controller](replication-controller) named `my-nginx` to ensure that there are always two pods running.
+The [`kubectl run`](/{{page.version}}/docs/user-guide/kubectl/kubectl_run) line below will create two [nginx](https://registry.hub.docker.com/_/nginx/) [pods](/{{page.version}}/docs/user-guide/pods) listening on port 80. It will also create a [replication controller](/{{page.version}}/docs/user-guide/replication-controller) named `my-nginx` to ensure that there are always two pods running.

 ```shell
 kubectl run my-nginx --image=nginx --replicas=2 --port=80
@@ -35,7 +35,7 @@ kubectl stop rc my-nginx

 ### Exposing your pods to the internet.

-On some platforms (for example Google Compute Engine) the kubectl command can integrate with your cloud provider to add a [public IP address](services/#external-services) for the pods,
+On some platforms (for example Google Compute Engine) the kubectl command can integrate with your cloud provider to add a [public IP address](/{{page.version}}/docs/user-guide/services/#external-services) for the pods,
 to do this run:

 ```shell
@@ -52,5 +52,5 @@ In order to access your nginx landing page, you also have to make sure that traf

 ### Next: Configuration files

-Most people will eventually want to use declarative configuration files for creating/modifying their applications.  A [simplified introduction](simple-yaml)
+Most people will eventually want to use declarative configuration files for creating/modifying their applications.  A [simplified introduction](/{{page.version}}/docs/user-guide/simple-yaml)
 is given in a different document.
@@ -1,7 +1,7 @@
 ---
 title: "Getting started with config files."
 ---
-In addition to the imperative style commands described [elsewhere](simple-nginx), Kubernetes
+In addition to the imperative style commands described [elsewhere](/{{page.version}}/docs/user-guide/simple-nginx), Kubernetes
 supports declarative YAML or JSON configuration files.  Often times config files are preferable
 to imperative commands, since they can be checked into version control and changes to the files
 can be code reviewed, producing a more robust, reliable and archival system.
@@ -32,7 +32,7 @@ spec:
    - containerPort: 80
 ```

-[Download example](pod.yaml)
+[Download example](/{{page.version}}/docs/user-guide/pod.yaml)
 <!-- END MUNGE: EXAMPLE pod.yaml -->

 You can see your cluster's pods:
@@ -49,7 +49,7 @@ $ kubectl delete pods nginx

 ### Running a replicated set of containers from a configuration file

-To run replicated containers, you need a [Replication Controller](replication-controller).
+To run replicated containers, you need a [Replication Controller](/{{page.version}}/docs/user-guide/replication-controller).
 A replication controller is responsible for ensuring that a specific number of pods exist in the
 cluster.

@@ -84,7 +84,7 @@ spec:
        - containerPort: 80
 ```

-[Download example](replication.yaml)
+[Download example](/{{page.version}}/docs/user-guide/replication.yaml)
 <!-- END MUNGE: EXAMPLE replication.yaml -->

 To delete the replication controller (and the pods it created):
@@ -14,7 +14,7 @@ kubectl create -f cluster/addons/kube-ui/kube-ui-rc.yaml --namespace=kube-system
 kubectl create -f cluster/addons/kube-ui/kube-ui-svc.yaml --namespace=kube-system
 ```

-Normally, this should be taken care of automatically by the [`kube-addons.sh`](http://releases.k8s.io/release-1.1/cluster/saltbase/salt/kube-addons/kube-addons.sh) script that runs on the master.
+Normally, this should be taken care of automatically by the [`kube-addons.sh`](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/kube-addons/kube-addons.sh) script that runs on the master.

 ## Using the UI

@@ -56,4 +56,4 @@ Other views (Pods, Nodes, Replication Controllers, Services, and Events) simply

 ## More Information

-For more information, see the [Kubernetes UI development document](http://releases.k8s.io/release-1.1/www/README.md) in the www directory.
+For more information, see the [Kubernetes UI development document](http://releases.k8s.io/{{page.githubbranch}}/www/README.md) in the www directory.
@@ -19,7 +19,7 @@ limitations under the License.

 -->

-This example demonstrates the usage of Kubernetes to perform a [rolling update](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/user-guide/kubectl/kubectl_rolling-update.md) on a running group of [pods](/{{page.version}}/docs/user-guide/pods). See [here](/{{page.version}}/docs/user-guide/managing-deployments/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/simple-rolling-update.md) for more information.
+This example demonstrates the usage of Kubernetes to perform a [rolling update](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/user-guide/kubectl/kubectl_rolling-update.md) on a running group of [pods](/{{page.version}}/docs/user-guide/pods). See [here](/{{page.version}}/docs/user-guide/managing-deployments/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/simple-rolling-update.md) for more information.

 ### Step Zero: Prerequisites

@@ -8,7 +8,7 @@ container starts with a clean slate.  Second, when running containers together
 in a `Pod` it is often necessary to share files between those containers.  The
 Kubernetes `Volume` abstraction solves both of these problems.

-Familiarity with [pods](pods) is suggested.
+Familiarity with [pods](/{{page.version}}/docs/user-guide/pods) is suggested.

 * TOC
 {:toc}
@@ -235,7 +235,7 @@ writers simultaneously.
 __Important: You must have your own NFS server running with the share exported
 before you can use it__

-See the [NFS example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/nfs/) for more details.
+See the [NFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/nfs/) for more details.

 ### iscsi

@@ -254,7 +254,7 @@ and then serve it in parallel from as many pods as you need.  Unfortunately,
 iSCSI volumes can only be mounted by a single consumer in read-write mode - no
 simultaneous readers allowed.

-See the [iSCSI example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/iscsi/) for more details.
+See the [iSCSI example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/iscsi/) for more details.

 ### flocker

@@ -269,7 +269,7 @@ can be "handed off" between pods as required.

 __Important: You must have your own Flocker installation running before you can use it__

-See the [Flocker example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/flocker/) for more details.
+See the [Flocker example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/flocker/) for more details.

 ### glusterfs

@@ -284,7 +284,7 @@ simultaneously.
 __Important: You must have your own GlusterFS installation running before you
 can use it__

-See the [GlusterFS example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/glusterfs/) for more details.
+See the [GlusterFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/glusterfs/) for more details.

 ### rbd

@@ -304,7 +304,7 @@ and then serve it in parallel from as many pods as you need.  Unfortunately,
 RBD volumes can only be mounted by a single consumer in read-write mode - no
 simultaneous writers allowed.

-See the [RBD example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/rbd/) for more details.
+See the [RBD example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/rbd/) for more details.

 ### gitRepo

@@ -345,16 +345,16 @@ non-volatile storage.
 __Important: You must create a secret in the Kubernetes API before you can use
 it__

-Secrets are described in more detail [here](secrets).
+Secrets are described in more detail [here](/{{page.version}}/docs/user-guide/secrets).

 ### persistentVolumeClaim

 A `persistentVolumeClaim` volume is used to mount a
-[PersistentVolume](persistent-volumes) into a pod.  PersistentVolumes are a
+[PersistentVolume](/{{page.version}}/docs/user-guide/persistent-volumes) into a pod.  PersistentVolumes are a
 way for users to "claim" durable storage (such as a GCE PersistentDisk or an
 iSCSI volume) without knowing the details of the particular cloud environment.

-See the [PersistentVolumes example](persistent-volumes/) for more
+See the [PersistentVolumes example](/{{page.version}}/docs/user-guide/persistent-volumes/) for more
 details.

 ### downwardAPI
@@ -362,7 +362,7 @@ details.
 A `downwardAPI` volume is used to make downward API data available to applications.
 It mounts a directory and writes the requested data in plain text files.

-See the [`downwardAPI` volume example](downward-api/volume/)  for more details.
+See the [`downwardAPI` volume example](/{{page.version}}/docs/user-guide/downward-api/volume/)  for more details.

 ## Resources

@@ -43,12 +43,12 @@ spec:

 A pod definition is a declaration of a _desired state_.  Desired state is a very important concept in the Kubernetes model.  Many things present a desired state to the system, and it is Kubernetes' responsibility to make sure that the current state matches the desired state.  For example, when you create a Pod, you declare that you want the containers in it to be running.  If the containers happen to not be running (e.g. program failure, ...), Kubernetes will continue to (re-)create them for you in order to drive them to the desired state. This process continues until the Pod is deleted.

-See the [design document](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/README.md) for more details.
+See the [design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/README.md) for more details.


 #### Pod Management

-Create a pod containing an nginx server ([pod-nginx.yaml](pod-nginx.yaml)):
+Create a pod containing an nginx server ([pod-nginx.yaml](/{{page.version}}/docs/user-guide/walkthrough/pod-nginx.yaml)):

 ```shell
 $ kubectl create -f docs/user-guide/walkthrough/pod-nginx.yaml
@@ -100,7 +100,7 @@ volumeMounts:
      mountPath: /data/redis
 ```

-Example Redis pod definition with a persistent storage volume ([pod-redis.yaml](pod-redis.yaml)):
+Example Redis pod definition with a persistent storage volume ([pod-redis.yaml](/{{page.version}}/docs/user-guide/walkthrough/pod-redis.yaml)):

 <!-- BEGIN MUNGE: EXAMPLE pod-redis.yaml -->

@@ -121,7 +121,7 @@ spec:
    emptyDir: {}
 ```

-[Download example](pod-redis.yaml)
+[Download example](/{{page.version}}/docs/user-guide/walkthrough/pod-redis.yaml)
 <!-- END MUNGE: EXAMPLE pod-redis.yaml -->

 Notes:
@@ -178,5 +178,5 @@ Finally, we have also introduced an environment variable to the `git-monitor` co

 ## What's Next?

-Continue on to [Kubernetes 201](k8s201) or
-for a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/)
+Continue on to [Kubernetes 201](/{{page.version}}/docs/user-guide/walkthrough/k8s201) or
+for a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/)
@@ -2,7 +2,7 @@
 title: "Kubernetes 201 - Labels, Replication Controllers, Services and Health Checking"
 ---

-If you went through [Kubernetes 101](README), you learned about kubectl, pods, volumes, and multiple containers.
+If you went through [Kubernetes 101](/{{page.version}}/docs/user-guide/walkthrough/), you learned about kubectl, pods, volumes, and multiple containers.
 For Kubernetes 201, we will pick up where 101 left off and cover some slightly more advanced topics in Kubernetes, related to application productionization, deployment and
 scaling.

@@ -22,7 +22,7 @@ labels:
    app: nginx
 ```

-For example, here is the nginx pod definition with labels ([pod-nginx-with-label.yaml](pod-nginx-with-label.yaml)):
+For example, here is the nginx pod definition with labels ([pod-nginx-with-label.yaml](/{{page.version}}/docs/user-guide/walkthrough/pod-nginx-with-label.yaml)):

 <!-- BEGIN MUNGE: EXAMPLE pod-nginx-with-label.yaml -->

@@ -41,10 +41,10 @@ spec:
    - containerPort: 80
 ```

-[Download example](pod-nginx-with-label.yaml)
+[Download example](/{{page.version}}/docs/user-guide/walkthrough/pod-nginx-with-label.yaml)
 <!-- END MUNGE: EXAMPLE pod-nginx-with-label.yaml -->

-Create the labeled pod ([pod-nginx-with-label.yaml](pod-nginx-with-label.yaml)):
+Create the labeled pod ([pod-nginx-with-label.yaml](/{{page.version}}/docs/user-guide/walkthrough/pod-nginx-with-label.yaml)):

 ```shell
 $ kubectl create -f docs/user-guide/walkthrough/pod-nginx-with-label.yaml
@@ -66,7 +66,7 @@ OK, now you know how to make awesome, multi-container, labeled pods and you want

 Replication controllers are the objects to answer these questions.  A replication controller combines a template for pod creation (a "cookie-cutter" if you will) and a number of desired replicas, into a single Kubernetes object.  The replication controller also contains a label selector that identifies the set of objects managed by the replication controller.  The replication controller constantly measures the size of this set relative to the desired size, and takes action by creating or deleting pods.

-For example, here is a replication controller that instantiates two nginx pods ([replication-controller.yaml](replication-controller.yaml)):
+For example, here is a replication controller that instantiates two nginx pods ([replication-controller.yaml](/{{page.version}}/docs/user-guide/walkthrough/replication-controller.yaml)):

 <!-- BEGIN MUNGE: EXAMPLE replication-controller.yaml -->

@@ -97,12 +97,12 @@ spec:
        - containerPort: 80
 ```

-[Download example](replication-controller.yaml)
+[Download example](/{{page.version}}/docs/user-guide/walkthrough/replication-controller.yaml)
 <!-- END MUNGE: EXAMPLE replication-controller.yaml -->

 #### Replication Controller Management

-Create an nginx replication controller ([replication-controller.yaml](replication-controller.yaml)):
+Create an nginx replication controller ([replication-controller.yaml](/{{page.version}}/docs/user-guide/walkthrough/replication-controller.yaml)):

 ```shell
 $ kubectl create -f docs/user-guide/walkthrough/replication-controller.yaml
@@ -127,7 +127,7 @@ For more information, see [Replication Controllers](/{{page.version}}/docs/user-

 Once you have a replicated set of pods, you need an abstraction that enables connectivity between the layers of your application.  For example, if you have a replication controller managing your backend jobs, you don't want to have to reconfigure your front-ends whenever you re-scale your backends.  Likewise, if the pods in your backends are scheduled (or rescheduled) onto different machines, you can't be required to re-configure your front-ends.  In Kubernetes, the service abstraction achieves these goals.  A service provides a way to refer to a set of pods (selected by labels) with a single static IP address. It may also provide load balancing, if supported by the provider.

-For example, here is a service that balances across the pods created in the previous nginx replication controller example ([service.yaml](service.yaml)):
+For example, here is a service that balances across the pods created in the previous nginx replication controller example ([service.yaml](/{{page.version}}/docs/user-guide/walkthrough/service.yaml)):

 <!-- BEGIN MUNGE: EXAMPLE service.yaml -->

@@ -150,12 +150,12 @@ spec:
    app: nginx
 ```

-[Download example](service.yaml)
+[Download example](/{{page.version}}/docs/user-guide/walkthrough/service.yaml)
 <!-- END MUNGE: EXAMPLE service.yaml -->

 #### Service Management

-Create an nginx service ([service.yaml](service.yaml)):
+Create an nginx service ([service.yaml](/{{page.version}}/docs/user-guide/walkthrough/service.yaml)):

 ```shell
 $ kubectl create -f docs/user-guide/walkthrough/service.yaml
@@ -239,7 +239,7 @@ In all cases, if the Kubelet discovers a failure the container is restarted.

 The container health checks are configured in the `livenessProbe` section of your container config. There you can also specify an `initialDelaySeconds` that is a grace period from when the container is started to when health checks are performed, to enable your container to perform any necessary initialization.

-Here is an example config for a pod with an HTTP health check ([pod-with-http-healthcheck.yaml](pod-with-http-healthcheck.yaml)):
+Here is an example config for a pod with an HTTP health check ([pod-with-http-healthcheck.yaml](/{{page.version}}/docs/user-guide/walkthrough/pod-with-http-healthcheck.yaml)):

 <!-- BEGIN MUNGE: EXAMPLE pod-with-http-healthcheck.yaml -->

@@ -266,7 +266,7 @@ spec:
    - containerPort: 80
 ```

-[Download example](pod-with-http-healthcheck.yaml)
+[Download example](/{{page.version}}/docs/user-guide/walkthrough/pod-with-http-healthcheck.yaml)
 <!-- END MUNGE: EXAMPLE pod-with-http-healthcheck.yaml -->

 For more information about health checking, see [Container Probes](/{{page.version}}/docs/user-guide/pod-states/#container-probes).
@@ -274,4 +274,4 @@ For more information about health checking, see [Container Probes](/{{page.versi

 ## What's Next?

-For a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{ page.githubbranch }}/examples/guestbook/).
+For a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/).