Remaining links -> Absolute

2016-02-22 20:44:13 -08:00
parent ebf5d38024
commit 0793b7ecb0
116 changed files with 397 additions and 415 deletions
@@ -75,7 +75,7 @@ This plug-in will observe the incoming request and ensure that it does not viola
 enumerated in the `ResourceQuota` object in a `Namespace`.  If you are using `ResourceQuota`
 objects in your Kubernetes deployment, you MUST use this plug-in to enforce quota constraints.

-See the [resourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/admission_control_resource_quota.md) and the [example of Resource Quota](resourcequota/) for more details.
+See the [resourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_resource_quota.md) and the [example of Resource Quota](/{{page.version}}/docs/admin/resourcequota/) for more details.

 It is strongly encouraged that this plug-in is configured last in the sequence of admission control plug-ins.  This is
 so that quota is not prematurely incremented only for the request to be rejected later in admission control.
@@ -88,7 +88,7 @@ your Kubernetes deployment, you MUST use this plug-in to enforce those constrain
 be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger
 applies a 0.1 CPU requirement to all Pods in the `default` namespace.

-See the [limitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/admission_control_limit_range.md) and the [example of Limit Range](limitrange/) for more details.
+See the [limitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md) and the [example of Limit Range](/{{page.version}}/docs/admin/limitrange/) for more details.

 ### InitialResources (experimental)

@@ -85,7 +85,7 @@ To permit an action Policy with an unset namespace applies regardless of namespa
 3. Kubelet can read and write events: `{"user":"kubelet", "resource": "events"}`
 4. Bob can just read pods in namespace "projectCaribou": `{"user":"bob", "resource": "pods", "readonly": true, "namespace": "projectCaribou"}`

-[Complete file example](http://releases.k8s.io/release-1.1/pkg/auth/authorizer/abac/example_policy_file.jsonl)
+[Complete file example](http://releases.k8s.io/{{page.githubbranch}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)

 ### A quick note on service accounts

@@ -15,7 +15,7 @@ unsatisfied).
 Master components could in theory be run on any node in the cluster. However,
 for simplicity, current set up scripts typically start all master components on
 the same VM, and does not run user containers on this VM. See
-[high-availability.md](high-availability) for an example multi-master-VM setup.
+[high-availability.md](/{{page.version}}/docs/admin/high-availability) for an example multi-master-VM setup.

 Even in the future, when Kubernetes is fully self-hosting, it will probably be
 wise to only allow master components to schedule on a subset of nodes, to limit
@@ -24,19 +24,19 @@ node-compromising security exploit.

 ### kube-apiserver

-[kube-apiserver](kube-apiserver) exposes the Kubernetes API; it is the front-end for the
+[kube-apiserver](/{{page.version}}/docs/admin/kube-apiserver) exposes the Kubernetes API; it is the front-end for the
 Kubernetes control plane. It is designed to scale horizontally (i.e., one scales
-it by running more of them-- [high-availability.md](high-availability)).
+it by running more of them-- [high-availability.md](/{{page.version}}/docs/admin/high-availability)).

 ### etcd

-[etcd](etcd) is used as Kubernetes' backing store. All cluster data is stored here.
+[etcd](/{{page.version}}/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here.
 Proper administration of a Kubernetes cluster includes a backup plan for etcd's
 data.

 ### kube-controller-manager

-[kube-controller-manager](kube-controller-manager) is a binary that runs controllers, which are the
+[kube-controller-manager](/{{page.version}}/docs/admin/kube-controller-manager) is a binary that runs controllers, which are the
 background threads that handle routine tasks in the cluster. Logically, each
 controller is a separate process, but to reduce the number of moving pieces in
 the system, they are all compiled into a single binary and run in a single
@@ -57,7 +57,7 @@ These controllers include:

 ### kube-scheduler

-[kube-scheduler](kube-scheduler) watches newly created pods that have no node assigned, and
+[kube-scheduler](/{{page.version}}/docs/admin/kube-scheduler) watches newly created pods that have no node assigned, and
 selects a node for them to run on.

 ### addons
@@ -65,17 +65,17 @@ selects a node for them to run on.
 Addons are pods and services that implement cluster features. They don't run on
 the master VM, but currently the default setup scripts that make the API calls
 to create these pods and services does run on the master VM. See:
-[kube-master-addons](http://releases.k8s.io/release-1.1/cluster/saltbase/salt/kube-master-addons/kube-master-addons.sh)
+[kube-master-addons](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/kube-master-addons/kube-master-addons.sh)

 Addon objects are created in the "kube-system" namespace.

 Example addons are:
-* [DNS](http://releases.k8s.io/release-1.1/cluster/addons/dns/) provides cluster local DNS.
-* [kube-ui](http://releases.k8s.io/release-1.1/cluster/addons/kube-ui/) provides a graphical UI for the
+* [DNS](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/) provides cluster local DNS.
+* [kube-ui](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/kube-ui/) provides a graphical UI for the
  cluster.
-* [fluentd-elasticsearch](http://releases.k8s.io/release-1.1/cluster/addons/fluentd-elasticsearch/) provides
-  log storage. Also see the [gcp version](http://releases.k8s.io/release-1.1/cluster/addons/fluentd-gcp/).
-* [cluster-monitoring](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/) provides
+* [fluentd-elasticsearch](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/fluentd-elasticsearch/) provides
+  log storage. Also see the [gcp version](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/fluentd-gcp/).
+* [cluster-monitoring](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/) provides
  monitoring for the cluster.

 ## Node components
@@ -85,7 +85,7 @@ the Kubernetes runtime environment.

 ### kubelet

-[kubelet](kubelet) is the primary node agent. It:
+[kubelet](/{{page.version}}/docs/admin/kubelet) is the primary node agent. It:
 * Watches for pods that have been assigned to its node (either by apiserver
  or via local configuration file) and:
 * Mounts the pod's required volumes
@@ -98,7 +98,7 @@ the Kubernetes runtime environment.

 ### kube-proxy

-[kube-proxy](kube-proxy) enables the Kubernetes service abstraction by maintaining
+[kube-proxy](/{{page.version}}/docs/admin/kube-proxy) enables the Kubernetes service abstraction by maintaining
 network rules on the host and performing connection forwarding.

 ### docker
@@ -13,7 +13,7 @@ At v1.0, Kubernetes supports clusters up to 100 nodes with 30 pods per node and

 A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane).

-Normally the number of nodes in a cluster is controlled by the the value `NUM_MINIONS` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/release-1.1/cluster/gce/config-default.sh)).
+Normally the number of nodes in a cluster is controlled by the the value `NUM_MINIONS` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{page.githubbranch}}/cluster/gce/config-default.sh)).

 Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up.

@@ -56,14 +56,14 @@ These limits, however, are based on data collected from addons running on 4-node
 To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:

 - Scale memory and CPU limits for each of the following addons, if used, along with the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster):
-  - Heapster ([GCM/GCL backed](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/google/heapster-controller.yaml), [InfluxDB backed](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/influxdb/heapster-controller.yaml), [InfluxDB/GCL backed](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/googleinfluxdb/heapster-controller-combined.yaml), [standalone](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/standalone/heapster-controller.yaml))
-  * [InfluxDB and Grafana](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
-  * [skydns, kube2sky, and dns etcd](http://releases.k8s.io/release-1.1/cluster/addons/dns/skydns-rc.yaml.in)
-  * [Kibana](http://releases.k8s.io/release-1.1/cluster/addons/fluentd-elasticsearch/kibana-controller.yaml)
+  - Heapster ([GCM/GCL backed](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/google/heapster-controller.yaml), [InfluxDB backed](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/influxdb/heapster-controller.yaml), [InfluxDB/GCL backed](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/googleinfluxdb/heapster-controller-combined.yaml), [standalone](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/standalone/heapster-controller.yaml))
+  * [InfluxDB and Grafana](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+  * [skydns, kube2sky, and dns etcd](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/skydns-rc.yaml.in)
+  * [Kibana](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/fluentd-elasticsearch/kibana-controller.yaml)
 * Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits):
-  * [elasticsearch](http://releases.k8s.io/release-1.1/cluster/addons/fluentd-elasticsearch/es-controller.yaml)
+  * [elasticsearch](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/fluentd-elasticsearch/es-controller.yaml)
 * Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well):
-  * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/release-1.1/cluster/saltbase/salt/fluentd-es/fluentd-es.yaml)
-  * [FluentD with GCP Plugin](http://releases.k8s.io/release-1.1/cluster/saltbase/salt/fluentd-gcp/fluentd-gcp.yaml)
+  * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/fluentd-es/fluentd-es.yaml)
+  * [FluentD with GCP Plugin](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/fluentd-gcp/fluentd-gcp.yaml)

 For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/{{page.version}}/docs/user-guide/compute-resources/#troubleshooting).
@@ -63,7 +63,7 @@ recommend testing the upgrade on an experimental cluster before performing the u

 ## Resizing a cluster

-If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](node/#self-registration-of-nodes).
+If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](/{{page.version}}/docs/admin/node/#self-registration-of-nodes).
 If you're using GCE or GKE it's done by resizing Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:

 ```shell
@@ -145,7 +145,7 @@ kubectl replace nodes $NODENAME --patch='{"apiVersion": "v1", "spec": {"unschedu

 If you deleted the node's VM instance and created a new one, then a new schedulable node resource will
 be created automatically when you create a new VM instance (if you're using a cloud provider that supports
-node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register). See [Node](node) for more details.
+node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register). See [Node](/{{page.version}}/docs/admin/node) for more details.

 ## Advanced Topics

@@ -89,7 +89,7 @@ Mitigations:
 - Action use IaaS providers reliable storage (e.g GCE PD or AWS EBS volume) for VMs with apiserver+etcd
  - Mitigates: Apiserver backing storage lost

- Action: Use (experimental) [high-availability](high-availability) configuration
+- Action: Use (experimental) [high-availability](/{{page.version}}/docs/admin/high-availability) configuration
  - Mitigates: Master VM shutdown or master components (scheduler, API server, controller-managing) crashing
    - Will tolerate one or more simultaneous node or component failures
  - Mitigates: Apiserver backing storage (i.e., etcd's data directory) lost
@@ -108,5 +108,5 @@ Mitigations:
  - Mitigates: Node shutdown
  - Mitigates: Kubelet software fault

- Action: [Multiple independent clusters](multi-cluster) (and avoid making risky changes to all clusters at once)
+- Action: [Multiple independent clusters](/{{page.version}}/docs/admin/multi-cluster) (and avoid making risky changes to all clusters at once)
  - Mitigates: Everything listed above.
@@ -75,7 +75,7 @@ Normally, the machine that a pod runs on is selected by the Kubernetes scheduler
 created by the Daemon controller have the machine already selected (`.spec.nodeName` is specified
 when the pod is created, so it is ignored by the scheduler).  Therefore:

- - the [`unschedulable`](node/#manual-node-administration) field of a node is not respected
+ - the [`unschedulable`](/{{page.version}}/docs/admin/node/#manual-node-administration) field of a node is not respected
   by the daemon set controller.
 - daemon set controller can make pods even when the scheduler has not been started, which can help cluster
   bootstrap.
@@ -140,7 +140,7 @@ use a Daemon Set rather than creating individual pods.
 ### Static Pods

 It is possible to create pods by writing a file to a certain directory watched by Kubelet.  These
-are called [static pods](static-pods).
+are called [static pods](/{{page.version}}/docs/admin/static-pods).
 Unlike DaemonSet, static pods cannot be managed with kubectl
 or other Kubernetes API clients.  Static pods do not depend on the apiserver, making them useful
 in cluster bootstrapping cases.  Also, static pods may be deprecated in the future.
@@ -1,7 +1,7 @@
 ---
 title: "DNS Integration with Kubernetes"
 ---
-As of Kubernetes 0.8, DNS is offered as a [cluster add-on](http://releases.k8s.io/release-1.1/cluster/addons/README.md).
+As of Kubernetes 0.8, DNS is offered as a [cluster add-on](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/README.md).
 If enabled, a DNS Pod and Service will be scheduled on the cluster, and the kubelets will be
 configured to tell individual containers to use the DNS Service's IP to resolve DNS names.

@@ -36,4 +36,4 @@ time.

 ## For more information

-See [the docs for the DNS cluster addon](http://releases.k8s.io/release-1.1/cluster/addons/dns/README.md).
+See [the docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md).
@@ -13,7 +13,7 @@ internet at large), because access to etcd is equivalent to root in your
 cluster.

 Data Reliability: for reasonable safety, either etcd needs to be run as a
-[cluster](high-availability/#clustering-etcd) (multiple machines each running
+[cluster](/{{page.version}}/docs/admin/high-availability/#clustering-etcd) (multiple machines each running
 etcd) or etcd's data directory should be located on durable storage (e.g., GCE's
 persistent disk). In either case, if high availability is required--as it might
 be in a production cluster--the data directory ought to be [backed up
@@ -23,14 +23,14 @@ to reduce downtime in case of corruption.
 ## Default configuration

 The default setup scripts use kubelet's file-based static pods feature to run etcd in a
-[pod](http://releases.k8s.io/release-1.1/cluster/saltbase/salt/etcd/etcd.manifest). This manifest should only
+[pod](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/etcd/etcd.manifest). This manifest should only
 be run on master VMs. The default location that kubelet scans for manifests is
 `/etc/kubernetes/manifests/`.

 ## Kubernetes's usage of etcd

 By default, Kubernetes objects are stored under the `/registry` key in etcd.
-This path can be prefixed by using the [kube-apiserver](kube-apiserver) flag
+This path can be prefixed by using the [kube-apiserver](/{{page.version}}/docs/admin/kube-apiserver) flag
 `--etcd-prefix="/foo"`.

 `etcd` is the only place that Kubernetes keeps state.
@@ -53,11 +53,11 @@ choices. For example, on systemd-based systems (e.g. RHEL, CentOS), you can run
 If you are extending from a standard Kubernetes installation, the `kubelet` binary should already be present on your system.  You can run
 `which kubelet` to determine if the binary is in fact installed.  If it is not installed,
 you should install the [kubelet binary](https://storage.googleapis.com/kubernetes-release/release/v0.19.3/bin/linux/amd64/kubelet), the
-[kubelet init file](http://releases.k8s.io/release-1.1/cluster/saltbase/salt/kubelet/initd) and [high-availability/default-kubelet](high-availability/default-kubelet)
+[kubelet init file](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/kubelet/initd) and [high-availability/default-kubelet](/{{page.version}}/docs/admin/high-availability/default-kubelet)
 scripts.

-If you are using monit, you should also install the monit daemon (`apt-get install monit`) and the [high-availability/monit-kubelet](high-availability/monit-kubelet) and
-[high-availability/monit-docker](high-availability/monit-docker) configs.
+If you are using monit, you should also install the monit daemon (`apt-get install monit`) and the [high-availability/monit-kubelet](/{{page.version}}/docs/admin/high-availability/monit-kubelet) and
+[high-availability/monit-docker](/{{page.version}}/docs/admin/high-availability/monit-docker) configs.

 On systemd systems you `systemctl enable kubelet` and `systemctl enable docker`.

@@ -86,7 +86,7 @@ First, hit the etcd discovery service to create a new token:
 curl https://discovery.etcd.io/new?size=3
 ```

-On each node, copy the [etcd.yaml](high-availability/etcd.yaml) file into `/etc/kubernetes/manifests/etcd.yaml`
+On each node, copy the [etcd.yaml](/{{page.version}}/docs/admin/high-availability/etcd.yaml) file into `/etc/kubernetes/manifests/etcd.yaml`

 The kubelet on each node actively monitors the contents of that directory, and it will create an instance of the `etcd`
 server from the definition of the pod specified in `etcd.yaml`.
@@ -156,7 +156,7 @@ The easiest way to create this directory, may be to copy it from the master node

 ### Starting the API Server

-Once these files exist, copy the [kube-apiserver.yaml](high-availability/kube-apiserver.yaml) into `/etc/kubernetes/manifests/` on each master node.
+Once these files exist, copy the [kube-apiserver.yaml](/{{page.version}}/docs/admin/high-availability/kube-apiserver.yaml) into `/etc/kubernetes/manifests/` on each master node.

 The kubelet monitors this directory, and will automatically create an instance of the `kube-apiserver` container using the pod definition specified
 in the file.
@@ -197,11 +197,11 @@ touch /var/log/kube-controller-manager.log
 ```

 Next, set up the descriptions of the scheduler and controller manager pods on each node.
-by copying [kube-scheduler.yaml](high-availability/kube-scheduler.yaml) and [kube-controller-manager.yaml](high-availability/kube-controller-manager.yaml) into the `/srv/kubernetes/` directory.
+by copying [kube-scheduler.yaml](/{{page.version}}/docs/admin/high-availability/kube-scheduler.yaml) and [kube-controller-manager.yaml](high-availability//{{page.version}}/docs/admin/kube-controller-manager.yaml) into the `/srv/kubernetes/` directory.

 ### Running the podmaster

-Now that the configuration files are in place, copy the [podmaster.yaml](high-availability/podmaster.yaml) config file into `/etc/kubernetes/manifests/`
+Now that the configuration files are in place, copy the [podmaster.yaml](/{{page.version}}/docs/admin/high-availability/podmaster.yaml) config file into `/etc/kubernetes/manifests/`

 As before, the kubelet on the node monitors this directory, and will start an instance of the podmaster using the pod specification provided in `podmaster.yaml`.

@@ -37,7 +37,7 @@ The Namespace provides a unique scope for:

 ## Usage

-Look [here](namespaces/) for an in depth example of namespaces.
+Look [here](/{{page.version}}/docs/admin/namespaces/) for an in depth example of namespaces.

 ### Viewing namespaces

@@ -132,7 +132,7 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te

 ## Namespaces and DNS

-When you create a [Service](/{{page.version}}/docs/user-guide/services), it creates a corresponding [DNS entry](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
@@ -1,7 +1,7 @@
 ---
 title: "Kubernetes Namespaces"
 ---
-Kubernetes _[namespaces](/{{page.version}}/docs/admin/namespaces)_ help different projects, teams, or customers to share a Kubernetes cluster.
+Kubernetes _namespaces_ help different projects, teams, or customers to share a Kubernetes cluster.

 It does this by providing the following:

@@ -49,7 +49,7 @@ One pattern this organization could follow is to partition the Kubernetes cluste

 Let's create two new namespaces to hold our work.

-Use the file [`namespace-dev.json`](namespace-dev.json) which describes a development namespace:
+Use the file [`namespace-dev.json`](/{{page.version}}/docs/admin/namespacesnamespace-dev.json) which describes a development namespace:

 <!-- BEGIN MUNGE: EXAMPLE namespace-dev.json -->

@@ -66,7 +66,7 @@ Use the file [`namespace-dev.json`](namespace-dev.json) which describes a develo
 }
 ```

-[Download example](namespace-dev.json)
+[Download example](/{{page.version}}/docs/admin/namespacesnamespace-dev.json)
 <!-- END MUNGE: EXAMPLE namespace-dev.json -->

 Create the development namespace using kubectl.
@@ -163,7 +163,7 @@ people have reported success with Flannel and Kubernetes.

 ### OpenVSwitch

-[OpenVSwitch](ovs-networking) is a somewhat more mature but also
+[OpenVSwitch](/{{page.version}}/docs/admin/ovs-networking) is a somewhat more mature but also
 complicated way to build an overlay network.  This is endorsed by several of the
 "Big Shops" for networking.

@@ -147,7 +147,7 @@ restrictions around nodes: pods from several namespaces may run on the same node

 ## Example

-See a [detailed example for how to use resource quota](resourcequota/).
+See a [detailed example for how to use resource quota](/{{page.version}}/docs/admin/resourcequota/).

 ## Read More

@@ -99,4 +99,4 @@ We should define a grains.conf key that captures more specifically what network

 ## Further reading

-The [cluster/saltbase](http://releases.k8s.io/release-1.1/cluster/saltbase/) tree has more details on the current SaltStack configuration.
+The [cluster/saltbase](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/) tree has more details on the current SaltStack configuration.
@@ -494,7 +494,7 @@ doing!

 ## Write end-to-end tests

-Check out the [E2E docs](e2e-tests) for detailed information about how to write end-to-end
+Check out the [E2E docs](/{{page.version}}/docs/devel/e2e-tests) for detailed information about how to write end-to-end
 tests for your feature.

 ## Examples and docs
@@ -22,7 +22,7 @@ particular, they may be self-merged by the release branch owner without fanfare,
 in the case the release branch owner knows the cherry pick was already
 requested - this should not be the norm, but it may happen.

-[Contributor License Agreements](http://releases.k8s.io/release-1.1/CONTRIBUTING.md) is considered implicit
+[Contributor License Agreements](http://releases.k8s.io/{{page.githubbranch}}/CONTRIBUTING.md) is considered implicit
 for all code within cherry-pick pull requests, ***unless there is a large
 conflict***.

@@ -3,7 +3,7 @@ title: "Kubernetes API client libraries"
 ---
 ### Supported

-   * [Go](http://releases.k8s.io/release-1.1/pkg/client/)
+   * [Go](http://releases.k8s.io/{{page.githubbranch}}/pkg/client/)

 ### User Contributed

@@ -2,13 +2,11 @@
 title: "devel/coding-conventions"
 ---

-Code conventions
-
  - Bash
    - https://google-styleguide.googlecode.com/svn/trunk/shell.xml
    - Ensure that build, release, test, and cluster-management scripts run on OS X
  - Go
-    - Ensure your code passes the [presubmit checks](development/#hooks)
+    - Ensure your code passes the [presubmit checks](/{{page.version}}/docs/devel/development/#hooks)
    - [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments)
    - [Effective Go](https://golang.org/doc/effective_go)
    - Comment your code.
@@ -27,8 +25,8 @@ Code conventions
    - API conventions
      - [API changes](/{{page.version}}/docs/devel/api_changes)
      - [API conventions](/{{page.version}}/docs/devel/api-conventions)
-    - [Kubectl conventions](kubectl-conventions)
-    - [Logging conventions](logging)
+    - [Kubectl conventions](/{{page.version}}/docs/devel/kubectl-conventions)
+    - [Logging conventions](/{{page.version}}/docs/devel/logging)

 Testing conventions

@@ -58,6 +56,3 @@ Coding advice

  - Go
    - [Go landmines](https://gist.github.com/lavalamp/4bd23295a9f32706a48f)
-
-
-
@@ -39,6 +39,3 @@ PRs that are incorrectly judged to be merge-able, may be reverted and subject to
 ## Holds

 Any maintainer or core contributor who wants to review a PR but does not have time immediately may put a hold on a PR simply by saying so on the PR discussion and offering an ETA measured in single-digit days at most.  Any PR that has a hold shall not be merged until the person who requested the hold acks the review, withdraws their hold, or is overruled by a preponderance of maintainers.
-
-
-
@@ -3,7 +3,7 @@ title: "Development Guide"
 ---
 # Releases and Official Builds

-Official releases are built in Docker containers.  Details are [here](http://releases.k8s.io/release-1.1/build/README.md).  You can do simple builds and development with just a local Docker installation.  If want to build go locally outside of docker, please continue below.
+Official releases are built in Docker containers.  Details are [here](http://releases.k8s.io/{{page.githubbranch}}/build/README.md).  You can do simple builds and development with just a local Docker installation.  If want to build go locally outside of docker, please continue below.

 ## Go development environment

@@ -66,7 +66,7 @@ git push -f origin myfeature

 1. Visit https://github.com/$YOUR_GITHUB_USERNAME/kubernetes
 2. Click the "Compare and pull request" button next to your "myfeature" branch.
-3. Check out the pull request [process](pull-requests) for more details
+3. Check out the pull request [process](/{{page.version}}/docs/devel/pull-requests) for more details

 ### When to retain commits and when to squash

@@ -80,7 +80,7 @@ fixups (e.g. automated doc formatting), use one or more commits for the
 changes to tooling and a final commit to apply the fixup en masse.  This makes
 reviews much easier.

-See [Faster Reviews](faster_reviews) for more details.
+See [Faster Reviews](/{{page.version}}/docs/devel/faster_reviews) for more details.

 ## godep and dependency management

@@ -297,18 +297,18 @@ go run hack/e2e.go -v -ctl='delete pod foobar'
 ## Conformance testing

 End-to-end testing, as described above, is for [development
-distributions](writing-a-getting-started-guide).  A conformance test is used on
-a [versioned distro](writing-a-getting-started-guide).
+distributions](/{{page.version}}/docs/devel/writing-a-getting-started-guide).  A conformance test is used on
+a [versioned distro](/{{page.version}}/docs/devel/writing-a-getting-started-guide).

 The conformance test runs a subset of the e2e-tests against a manually-created cluster.  It does not
 require support for up/push/down and other operations.  To run a conformance test, you need to know the
 IP of the master for your cluster and the authorization arguments to use.  The conformance test is
 intended to run against a cluster at a specific binary release of Kubernetes.
-See [conformance-test.sh](http://releases.k8s.io/release-1.1/hack/conformance-test.sh).
+See [conformance-test.sh](http://releases.k8s.io/{{page.githubbranch}}/hack/conformance-test.sh).

 ## Testing out flaky tests

-[Instructions here](flaky-tests)
+[Instructions here](/{{page.version}}/docs/devel/flaky-tests)

 ## Regenerating the CLI documentation

@@ -1,7 +1,7 @@
 ---
 title: "Getting Kubernetes Builds"
 ---
-You can use [hack/get-build.sh](http://releases.k8s.io/release-1.1/hack/get-build.sh) to or use as a reference on how to get the most recent builds with curl. With `get-build.sh` you can grab the most recent stable build, the most recent release candidate, or the most recent build to pass our ci and gce e2e tests (essentially a nightly build).
+You can use [hack/get-build.sh](http://releases.k8s.io/{{page.githubbranch}}/hack/get-build.sh) to or use as a reference on how to get the most recent builds with curl. With `get-build.sh` you can grab the most recent stable build, the most recent release candidate, or the most recent build to pass our ci and gce e2e tests (essentially a nightly build).

 Run `./hack/get-build.sh -h` for its usage.

@@ -21,30 +21,30 @@ divided by the node's capacity).
 Finally, the node with the highest priority is chosen
 (or, if there are multiple such nodes, then one of them is chosen at random). The code
 for this main scheduling loop is in the function `Schedule()` in
-[plugin/pkg/scheduler/generic_scheduler.go](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/generic_scheduler.go)
+[plugin/pkg/scheduler/generic_scheduler.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/generic_scheduler.go)

 ## Scheduler extensibility

 The scheduler is extensible: the cluster administrator can choose which of the pre-defined
 scheduling policies to apply, and can add new ones. The built-in predicates and priorities are
-defined in [plugin/pkg/scheduler/algorithm/predicates/predicates.go](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/algorithm/predicates/predicates.go) and
-[plugin/pkg/scheduler/algorithm/priorities/priorities.go](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/algorithm/priorities/priorities.go), respectively.
+defined in [plugin/pkg/scheduler/algorithm/predicates/predicates.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithm/predicates/predicates.go) and
+[plugin/pkg/scheduler/algorithm/priorities/priorities.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithm/priorities/priorities.go), respectively.
 The policies that are applied when scheduling can be chosen in one of two ways. Normally,
 the policies used are selected by the functions `defaultPredicates()` and `defaultPriorities()` in
-[plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go).
+[plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go).
 However, the choice of policies
 can be overridden by passing the command-line flag `--policy-config-file` to the scheduler, pointing to a JSON
 file specifying which scheduling policies to use. See
 [examples/scheduler-policy-config.json](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/scheduler-policy-config.json) for an example
 config file. (Note that the config file format is versioned; the API is defined in
-[plugin/pkg/scheduler/api](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/api/)).
+[plugin/pkg/scheduler/api](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/api/)).
 Thus to add a new scheduling policy, you should modify predicates.go or priorities.go,
 and either register the policy in `defaultPredicates()` or `defaultPriorities()`, or use a policy config file.

 ## Exploring the code

 If you want to get a global picture of how the scheduler works, you can start in
-[plugin/cmd/kube-scheduler/app/server.go](http://releases.k8s.io/release-1.1/plugin/cmd/kube-scheduler/app/server.go)
+[plugin/cmd/kube-scheduler/app/server.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/cmd/kube-scheduler/app/server.go)



@@ -1,7 +1,7 @@
 ---
 title: "Scheduler Algorithm in Kubernetes"
 ---
-For each unscheduled Pod, the Kubernetes scheduler tries to find a node across the cluster according to a set of rules. A general introduction to the Kubernetes scheduler can be found at [scheduler.md](scheduler). In this document, the algorithm of how to select a node for the Pod is explained. There are two steps before a destination node of a Pod is chosen. The first step is filtering all the nodes and the second is ranking the remaining nodes to find a best fit for the Pod.
+For each unscheduled Pod, the Kubernetes scheduler tries to find a node across the cluster according to a set of rules. A general introduction to the Kubernetes scheduler can be found at [scheduler.md](/{{page.version}}/docs/devel/scheduler). In this document, the algorithm of how to select a node for the Pod is explained. There are two steps before a destination node of a Pod is chosen. The first step is filtering all the nodes and the second is ranking the remaining nodes to find a best fit for the Pod.

 ## Filtering the nodes

@@ -14,7 +14,7 @@ The purpose of filtering the nodes is to filter out the nodes that do not meet c
 - `PodSelectorMatches`: Check if the labels of the node match the labels specified in the Pod's `nodeSelector` field ([Here](/{{page.version}}/docs/user-guide/node-selection/) is an example of how to use `nodeSelector` field).
 - `CheckNodeLabelPresence`: Check if all the specified labels exist on a node or not, regardless of the value.

-The details of the above predicates can be found in [plugin/pkg/scheduler/algorithm/predicates/predicates.go](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/algorithm/predicates/predicates.go). All predicates mentioned above can be used in combination to perform a sophisticated filtering policy. Kubernetes uses some, but not all, of these predicates by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go).
+The details of the above predicates can be found in [plugin/pkg/scheduler/algorithm/predicates/predicates.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithm/predicates/predicates.go). All predicates mentioned above can be used in combination to perform a sophisticated filtering policy. Kubernetes uses some, but not all, of these predicates by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go).

 ## Ranking the nodes

@@ -32,7 +32,7 @@ Currently, Kubernetes scheduler provides some practical priority functions, incl
 - `CalculateSpreadPriority`: Spread Pods by minimizing the number of Pods belonging to the same service on the same node.
 - `CalculateAntiAffinityPriority`: Spread Pods by minimizing the number of Pods belonging to the same service on nodes with the same value for a particular label.

-The details of the above priority functions can be found in [plugin/pkg/scheduler/algorithm/priorities](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/algorithm/priorities/). Kubernetes uses some, but not all, of these priority functions by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/release-1.1/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go). Similar as predicates, you can combine the above priority functions and assign weight factors (positive number) to them as you want (check [scheduler.md](scheduler) for how to customize).
+The details of the above priority functions can be found in [plugin/pkg/scheduler/algorithm/priorities](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithm/priorities/). Kubernetes uses some, but not all, of these priority functions by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/{{page.githubbranch}}/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go). Similar as predicates, you can combine the above priority functions and assign weight factors (positive number) to them as you want (check [scheduler.md](/{{page.version}}/docs/devel/scheduler) for how to customize).



@@ -37,7 +37,7 @@ These guidelines say *what* to do.  See the Rationale section for *why*.
   own repo.
 - Add or update a row in [The Matrix](/{{page.version}}/docs/getting-started-guides/).
 - State the binary version of Kubernetes that you tested clearly in your Guide doc.
- - Setup a cluster and run the [conformance test](development/#conformance-testing) against it, and report the
+ - Setup a cluster and run the [conformance test](/{{page.version}}/docs/devel/development/#conformance-testing) against it, and report the
   results in your PR.
 - Versioned distros should typically not modify or add code in `cluster/`.  That is just scripts for developer
   distros.
@@ -28,16 +28,16 @@ export KUBERNETES_PROVIDER=aws; wget -q -O - https://get.k8s.io | bash
 export KUBERNETES_PROVIDER=aws; curl -sS https://get.k8s.io | bash
 ```

-NOTE: This script calls [cluster/kube-up.sh](http://releases.k8s.io/release-1.1/cluster/kube-up.sh)
-which in turn calls [cluster/aws/util.sh](http://releases.k8s.io/release-1.1/cluster/aws/util.sh)
-using [cluster/aws/config-default.sh](http://releases.k8s.io/release-1.1/cluster/aws/config-default.sh).
+NOTE: This script calls [cluster/kube-up.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/kube-up.sh)
+which in turn calls [cluster/aws/util.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/aws/util.sh)
+using [cluster/aws/config-default.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/aws/config-default.sh).

 This process takes about 5 to 10 minutes. Once the cluster is up, the IP addresses of your master and node(s) will be printed,
 as well as information about the default services running in the cluster (monitoring, logging, dns). User credentials and security
 tokens are written in `~/.kube/config`, they will be necessary to use the CLI or the HTTP Basic Auth.

 By default, the script will provision a new VPC and a 4 node k8s cluster in us-west-2a (Oregon) with `t2.micro` instances running on Ubuntu.
-You can override the variables defined in [config-default.sh](http://releases.k8s.io/release-1.1/cluster/aws/config-default.sh) to change this behavior as follows:
+You can override the variables defined in [config-default.sh](http://releases.k8s.io/{{page.githubbranch}}/cluster/aws/config-default.sh) to change this behavior as follows:

 ```shell
 export KUBE_AWS_ZONE=eu-west-1c
@@ -21,7 +21,7 @@ cd kubernetes
 make release
 ```

-For more details on the release process see the [`build/` directory](http://releases.k8s.io/release-1.1/build/)
+For more details on the release process see the [`build/` directory](http://releases.k8s.io/{{page.githubbranch}}/build/)



@@ -1,9 +1,6 @@
 ---
 title: "Getting Started on CoreOS"
 ---
-
-
-
 * TOC
 {:toc}

@@ -10,7 +10,7 @@ Here's a diagram of what the final result will look like:
 ![Kubernetes Single Node on Docker](/images/docs/k8s-docker.png)

 _Note_:
-These instructions are somewhat significantly more advanced than the [single node](docker) instructions.  If you are
+These instructions are somewhat significantly more advanced than the [single node](/{{page.version}}/docs/getting-started-guides/docker) instructions.  If you are
 interested in just starting to explore Kubernetes, we recommend that you start there.

 _Note_:
@@ -5,9 +5,9 @@ title: "Deploy DNS"

 First of all, download the template dns rc and svc file from

-[skydns-rc template](skydns-rc.yaml.in)
+[skydns-rc template](/{{page.version}}/docs/getting-started-guides/docker-multinode/skydns-rc.yaml.in)

-[skydns-svc template](skydns-svc.yaml.in)
+[skydns-svc template](/{{page.version}}/docs/getting-started-guides/docker-multinode/skydns-svc.yaml.in)

 ### Set env

@@ -176,4 +176,4 @@ If all else fails, ask questions on [Slack](/{{page.version}}/docs/troubleshooti

 ### Next steps

-Move on to [adding one or more workers](worker) or [deploy a dns](deployDNS)
+Move on to [adding one or more workers](/{{page.version}}/docs/getting-started-guides/docker-multinode/worker) or [deploy a dns](/{{page.version}}/docs/getting-started-guides/docker-multinode/deployDNS)
@@ -3,7 +3,7 @@ title: "Adding a Kubernetes worker node via Docker."
 ---
 These instructions are very similar to the master set-up above, but they are duplicated for clarity.
 You need to repeat these instructions for each node you want to join the cluster.
-We will assume that the IP address of this node is `${NODE_IP}` and you have the IP address of the master in `${MASTER_IP}` that you created in the [master instructions](master).
+We will assume that the IP address of this node is `${NODE_IP}` and you have the IP address of the master in `${MASTER_IP}` that you created in the [master instructions](/{{page.version}}/docs/getting-started-guides/docker-multinode/master).

 For each worker node, there are three steps:

@@ -136,4 +136,4 @@ sudo docker run -d --net=host --privileged gcr.io/google_containers/hyperkube:v1

 ### Next steps

-Move on to [testing your cluster](testing) or add another node](#).
+Move on to [testing your cluster](/{{page.version}}/docs/getting-started-guides/docker-multinode/testing) or add another node](#).
@@ -1,7 +1,7 @@
 ---
 title: "Kubernetes multiple nodes cluster with flannel on Fedora"
 ---
-This document describes how to deploy Kubernetes on multiple hosts to set up a multi-node cluster and networking with flannel. Follow fedora [getting started guide](fedora_manual_config) to setup 1 master (fed-master) and 2 or more nodes. Make sure that all nodes have different names (fed-node1, fed-node2 and so on) and labels (fed-node1-label, fed-node2-label, and so on) to avoid any conflict. Also make sure that the Kubernetes master host is running etcd, kube-controller-manager, kube-scheduler, and kube-apiserver services, and the nodes are running docker, kube-proxy and kubelet services. Now install flannel on Kubernetes nodes. flannel on each node configures an overlay network that docker uses. flannel runs on each node to setup a unique class-C container network.
+This document describes how to deploy Kubernetes on multiple hosts to set up a multi-node cluster and networking with flannel. Follow fedora [getting started guide](/{{page.version}}/docs/getting-started-guides/fedora/fedora_manual_config) to setup 1 master (fed-master) and 2 or more nodes. Make sure that all nodes have different names (fed-node1, fed-node2 and so on) and labels (fed-node1-label, fed-node2-label, and so on) to avoid any conflict. Also make sure that the Kubernetes master host is running etcd, kube-controller-manager, kube-scheduler, and kube-apiserver services, and the nodes are running docker, kube-proxy and kubelet services. Now install flannel on Kubernetes nodes. flannel on each node configures an overlay network that docker uses. flannel runs on each node to setup a unique class-C container network.

 * TOC
 {:toc}
@@ -40,7 +40,7 @@ wget -q -O - https://get.k8s.io | bash

 Once this command completes, you will have a master VM and four worker VMs, running as a Kubernetes cluster.

-By default, some containers will already be running on your cluster. Containers like `kibana` and `elasticsearch` provide [logging](logging), while `heapster` provides [monitoring](http://releases.k8s.io/release-1.1/cluster/addons/cluster-monitoring/README.md) services.
+By default, some containers will already be running on your cluster. Containers like `kibana` and `elasticsearch` provide [logging](/{{page.version}}/docs/getting-started-guides/logging), while `heapster` provides [monitoring](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/README.md) services.

 The script run by the commands above creates a cluster with the name/prefix "kubernetes". It defines one specific cluster config, so you can't run it more than once.

@@ -53,7 +53,7 @@ cluster/kube-up.sh

 If you want more than one cluster running in your project, want to use a different name, or want a different number of worker nodes, see the `<kubernetes>/cluster/gce/config-default.sh` file for more fine-grained configuration before you start up your cluster.

-If you run into trouble, please see the section on [troubleshooting](gce/#troubleshooting), post to the
+If you run into trouble, please see the section on [troubleshooting](/{{page.version}}/docs/getting-started-guides/gce/#troubleshooting), post to the
 [google-containers group](https://groups.google.com/forum/#!forum/google-containers), or come ask questions on [Slack](/{{page.version}}/docs/troubleshooting/#slack).

 The next few steps will show you:
@@ -5,7 +5,7 @@ Kubernetes can run on a range of platforms, from your laptop, to VMs on a cloud
 bare metal servers.  The effort required to set up a cluster varies from running a single command to
 crafting your own customized cluster.  We'll guide you in picking a solution that fits for your needs.

-If you just want to "kick the tires" on Kubernetes, we recommend the [local Docker-based](docker) solution.
+If you just want to "kick the tires" on Kubernetes, we recommend the [local Docker-based](/{{page.version}}/docs/getting-started-guides/docker) solution.

 The local Docker-based solution is one of several [Local cluster](#local-machine-solutions) solutions
 that are quick to set up, but are limited to running on one machine.
@@ -31,9 +31,9 @@ But their size and availability is limited to that of a single machine.

 The local-machine solutions are:

- [Local Docker-based](docker) (recommended starting point)
- [Vagrant](vagrant) (works on any platform with Vagrant: Linux, MacOS, or Windows.)
- [No-VM local cluster](locally) (Linux only)
+- [Local Docker-based](/{{page.version}}/docs/getting-started-guides/docker) (recommended starting point)
+- [Vagrant](/{{page.version}}/docs/getting-started-guides/vagrant) (works on any platform with Vagrant: Linux, MacOS, or Windows.)
+- [No-VM local cluster](/{{page.version}}/docs/getting-started-guides/locally) (Linux only)


 ### Hosted Solutions
@@ -58,7 +58,7 @@ base operating systems.
 If you can find a guide below that matches your needs, use it.  It may be a little out of date, but
 it will be easier than starting from scratch.  If you do want to start from scratch because you
 have special requirements or just because you want to understand what is underneath a Kubernetes
-cluster, try the [Getting Started from Scratch](scratch) guide.
+cluster, try the [Getting Started from Scratch](/{{page.version}}/docs/getting-started-guides/scratch) guide.

 If you are interested in supporting Kubernetes on a new platform, check out our [advice for
 writing a new solution](/{{page.version}}/docs/devel/writing-a-getting-started-guide).
@@ -221,7 +221,7 @@ juju destroy-environment --force `juju env`
 The Kubernetes charms and bundles can be found in the `kubernetes` project on
 github.com:

- - [Bundle Repository](http://releases.k8s.io/release-1.1/cluster/juju/bundles)
+ - [Bundle Repository](http://releases.k8s.io/{{page.githubbranch}}/cluster/juju/bundles)
   * [Kubernetes master charm](https://releases.k8s.io/release-1.1/cluster/juju/charms/trusty/kubernetes-master)
   * [Kubernetes node charm](https://releases.k8s.io/release-1.1/cluster/juju/charms/trusty/kubernetes)
 - [More about Juju](https://jujucharms.com)
@@ -8,7 +8,7 @@ title: "Getting started locally"

 #### Linux

-Not running Linux? Consider running Linux in a local virtual machine with [Vagrant](vagrant), or on a cloud provider like [Google Compute Engine](gce)
+Not running Linux? Consider running Linux in a local virtual machine with [Vagrant](/{{page.version}}/docs/getting-started-guides/vagrant), or on a cloud provider like [Google Compute Engine](/{{page.version}}/docs/getting-started-guides/gce)

 #### Docker

@@ -2,7 +2,7 @@
 title: "Cluster Level Logging with Elasticsearch and Kibana"
 ---
 On the Google Compute Engine (GCE) platform the default cluster level logging support targets
-[Google Cloud Logging](https://cloud.google.com/logging/docs/) as described at the [Logging](logging) getting
+[Google Cloud Logging](https://cloud.google.com/logging/docs/) as described at the [Logging](/{{page.version}}/docs/getting-started-guides/logging) getting
 started page. Here we describe how to set up a cluster to ingest logs into Elasticsearch and view them using Kibana as an
 alternative to Google Cloud Logging.

@@ -213,6 +213,6 @@ $ cat 21\:00\:00_21\:59\:59_S0.json | jq '.structPayload.log'
 ...
 ```

-This page has touched briefly on the underlying mechanisms that support gathering cluster level logs on a Kubernetes deployment. The approach here only works for gathering the standard output and standard error output of the processes running in the pod's containers. To gather other logs that are stored in files one can use a sidecar container to gather the required files as described at the page [Collecting log files within containers with Fluentd](http://releases.k8s.io/release-1.1/contrib/logging/fluentd-sidecar-gcp/README.md) and sending them to the Google Cloud Logging service.
+This page has touched briefly on the underlying mechanisms that support gathering cluster level logs on a Kubernetes deployment. The approach here only works for gathering the standard output and standard error output of the processes running in the pod's containers. To gather other logs that are stored in files one can use a sidecar container to gather the required files as described at the page [Collecting log files within containers with Fluentd](http://releases.k8s.io/{{page.githubbranch}}/contrib/logging/fluentd-sidecar-gcp/README.md) and sending them to the Google Cloud Logging service.

 Some of the material in this section also appears in the blog article [Cluster Level Logging with Kubernetes](http://blog.kubernetes.io/2015/06/cluster-level-logging-with-kubernetes)
@@ -63,7 +63,7 @@ accomplished in two ways:

 - Configure network to route Pod IPs
  - Harder to setup from scratch.
-  - Google Compute Engine ([GCE](gce)) and [AWS](/{{page.version}}/docs/getting-started-guides/aws) guides use this approach.
+  - Google Compute Engine ([GCE](/{{page.version}}/docs/getting-started-guides/gce)) and [AWS](/{{page.version}}/docs/getting-started-guides/aws) guides use this approach.
  - Need to make the Pod IPs routable by programming routers, switches, etc.
  - Can be configured external to Kubernetes, or can implement in the "Routes" interface of a Cloud Provider module.
  - Generally highest performance.
@@ -815,7 +815,7 @@ At this point you should be able to run through one of the basic examples, such

 ### Running the Conformance Test

-You may want to try to run the [Conformance test](http://releases.k8s.io/release-1.1/hack/conformance-test.sh).  Any failures may give a hint as to areas that need more attention.
+You may want to try to run the [Conformance test](http://releases.k8s.io/{{page.githubbranch}}/hack/conformance-test.sh).  Any failures may give a hint as to areas that need more attention.

 ### Networking

@@ -258,4 +258,4 @@ Some examples are as follows:

 The script will not delete any resources of your cluster, it just replaces the binaries.
 You can use `kubectl` command to check if the newly upgraded k8s is working correctly.
-For example, use `$ kubectl get nodes` to see if all of your nodes are ready.Or refer to [test-it-out](ubuntu/#test-it-out)
+For example, use `$ kubectl get nodes` to see if all of your nodes are ready.Or refer to [test-it-out](/{{page.version}}/docs/getting-started-guides/ubuntu/#test-it-out)
@@ -22,10 +22,10 @@ title: "Kubernetes Documentation: releases.k8s.io/release-1.1"
 * There are example files and walkthroughs in the [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples)
  folder.

-* If something went wrong, see the [troubleshooting](troubleshooting) document for how to debug.
+* If something went wrong, see the [troubleshooting](/{{page.version}}/docs/troubleshooting) document for how to debug.
 You should also check the [known issues](/{{page.version}}/docs/user-guide/known-issues) for the release you're using.

-* To report a security issue, see [Reporting a Security Issue](reporting-security-issues).
+* To report a security issue, see [Reporting a Security Issue](/{{page.version}}/docs/reporting-security-issues).



@@ -23,7 +23,7 @@ $ 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).
+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`.
@@ -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,7 +4,7 @@ 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
@@ -16,8 +16,8 @@ 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,7 +234,7 @@ 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
@@ -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.


@@ -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,7 +196,7 @@ 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:

@@ -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

@@ -20,9 +20,9 @@ Docker images have metadata associated with them that is used to store informati
 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
+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:
@@ -91,6 +91,3 @@ The relationship between Docker's capabilities and [Linux capabilities](http://m
 | SETFCAP |  CAP_SETFCAP |
 | WAKE_ALARM |  CAP_WAKE_ALARM |
 | 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
@@ -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,

@@ -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
@@ -74,10 +74,5 @@ 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/).
-
-
-
-
-
+* 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
@@ -103,7 +103,7 @@ 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:
+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,7 +3,7 @@ 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

@@ -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
@@ -11,7 +11,7 @@ Kubernetes components, such as kubelet and apiserver, use the [glog](https://god

 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/).)
+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 -->

@@ -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}
@@ -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:

@@ -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
@@ -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
@@ -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,7 +8,7 @@ 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:

@@ -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
@@ -236,11 +236,11 @@ spec:

 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

@@ -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
@@ -56,7 +56,7 @@ 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
@@ -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.
@@ -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.
@@ -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}
@@ -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

@@ -48,7 +48,7 @@ See the [design document](https://github.com/kubernetes/kubernetes/blob/{{ page.

 #### 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
+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).