No design/ docs, no linking to README files

2016-02-17 19:25:29 -08:00
parent f249edaed0
commit 88c758d834
108 changed files with 315 additions and 324 deletions
@@ -4,13 +4,13 @@ title: "Kubernetes User Guide: Managing Applications"
 * TOC
 {:toc}

-The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster.  Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/{{page.version}}/docs/admin/README). The [Developer Guide](/{{page.version}}/docs/devel/README) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project.
+The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster.  Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/{{page.version}}/docs/admin/). The [Developer Guide](/{{page.version}}/docs/devel/) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project.

 Please ensure you have completed the [prerequisites for running examples from the user guide](prereqs).

 ## Quick walkthrough

-1. [Kubernetes 101](walkthrough/README)
+1. [Kubernetes 101](walkthrough/)
 1. [Kubernetes 201](walkthrough/k8s201)

 ## Thorough walkthrough
@@ -36,10 +36,10 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo
 [**Overview**](overview)
 : A brief overview of Kubernetes concepts.

-[**Cluster**](../admin/README)
+[**Cluster**](/{{page.version}}/docs/admin/)
 : A cluster is a set of physical or virtual machines and other infrastructure resources used by Kubernetes to run your applications.

-[**Node**](../admin/node)
+[**Node**](/{{page.version}}/docs/admin/node)
 : A node is a physical or virtual machine running Kubernetes, onto which pods can be scheduled.

 [**Pod**](pods)
@@ -48,7 +48,7 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo
 [**Label**](labels)
 : A label is a key/value pair that is attached to a resource, such as a pod, to convey a user-defined identifying attribute. Labels can be used to organize and to select subsets of resources.

-[**Selector**](labels.html#label-selectors)
+[**Selector**](labels/#label-selectors)
 : A selector is an expression that matches labels in order to identify related resources, such as which pods are targeted by a load-balanced service.

 [**Replication Controller**](replication-controller)
@@ -87,7 +87,4 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo
  * [Migrating from docker-cli to kubectl](docker-cli-to-kubectl)
  * [Tips and tricks when working with config](config-best-practices)
  * [Assign pods to selected nodes](node-selection/)
-  * [Perform a rolling update on a running group of pods](update-demo/)
-
-
-
+  * [Perform a rolling update on a running group of pods](update-demo/)
@@ -13,7 +13,7 @@ Kubernetes CLI, `kubectl`.

 To access a cluster, you need to know the location of the cluster and have credentials
 to access it.  Typically, this is automatically set-up when you work through
-though a [Getting started guide](../getting-started-guides/README),
+though a [Getting started guide](/{{page.version}}/docs/getting-started-guides/),
 or someone else setup the cluster and provided you with credentials and a location.

 Check the location and credentials that kubectl knows about with this command:
@@ -90,13 +90,13 @@ certificate.

 On some clusters, the apiserver does not require authentication; it may serve
 on localhost, or be protected by a firewall.  There is not a standard
-for this.  [Configuring Access to the API](../admin/accessing-the-api)
+for this.  [Configuring Access to the API](/{{page.version}}/docs/admin/accessing-the-api)
 describes how a cluster admin can configure this.  Such approaches may conflict
 with future high-availability support.

 ### Programmatic access to the API

-There are [client libraries](../devel/client-libraries) for accessing the API
+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)
@@ -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](../admin/node), [pods](pods) and [services](services) all have
+[nodes](/{{page.version}}/docs/admin/node), [pods](pods) and [services](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.
@@ -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.html#ips-and-vips):
+  1. The [kube proxy](services/#ips-and-vips):
    - runs on each node
    - proxies UDP and TCP
    - does not understand HTTP
@@ -3,7 +3,7 @@ title: "Application Troubleshooting"
 ---
 This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly.
 This is *not* a guide for people who want to debug their cluster.  For that you should check out
-[this guide](../admin/cluster-troubleshooting)
+[this guide](/{{page.version}}/docs/admin/cluster-troubleshooting)

 * TOC
 {:toc}
@@ -41,7 +41,7 @@ there are insufficient resources of one type or another that prevent scheduling.
 your pod.  Reasons include:

 * **You don't have enough resources**:  You may have exhausted the supply of CPU or Memory in your cluster, in this case
-you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See [Compute Resources document](compute-resources.html#my-pods-are-pending-with-event-message-failedscheduling) for more information.
+you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See [Compute Resources document](compute-resources/#my-pods-are-pending-with-event-message-failedscheduling) for more information.

 * **You are using `hostPort`**:  When you bind a Pod to a `hostPort` there are a limited number of places that pod can be
 scheduled.  In most cases, `hostPort` is unnecessary, try using a Service object to expose your Pod.  If you do require
@@ -171,7 +171,7 @@ Here you can see from the `Allocated resources` section that that a pod which as

 Looking at the `Pods` section, you can see which pods are taking up space on the node.

-The [resource quota](../admin/resource-quota) feature can be configured
+The [resource quota](/{{page.version}}/docs/admin/resource-quota) feature can be configured
 to limit the total amount of resources that can be consumed.  If used in conjunction
 with namespaces, it can prevent one team from hogging all the resources.

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

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

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

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

@@ -9,13 +9,13 @@ 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.html#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](connecting-to-applications-proxy) or [kubectl port-forward](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](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](connecting-to-applications-proxy) or [kubectl port-forward](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.html#label-selectors) and [using labels effectively](managing-deployments.html#using-labels-effectively).
+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.html#headless-services).
+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 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.
@@ -31,7 +31,7 @@ The value of `metadata.name`, `hello-world`, will be the name of the pod resourc

 `restartPolicy: Never` indicates that we just want to run the container once and then terminate the pod.

-The [`command`](containers.html#containers-and-commands) overrides the Docker container's `Entrypoint`. Command arguments (corresponding to Docker's `Cmd`) may be specified using `args`, as follows:
+The [`command`](containers/#containers-and-commands) overrides the Docker container's `Entrypoint`. Command arguments (corresponding to Docker's `Cmd`) may be specified using `args`, as follows:

 ```yaml
 command: ["/bin/echo"]
@@ -65,7 +65,7 @@ pods/hello-world

 `kubectl create --validate` currently warns about problems it detects, but creates the resource anyway, unless a required field is absent or a field value is invalid. Unknown API fields are ignored, so be careful. This pod was created, but with no `command`, which is an optional field, since the image may specify an `Entrypoint`.
 View the [Pod API
-object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html#_v1_pod)
+object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_pod)
 to see the list of valid fields.

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

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

 ```yaml
 command: ["/bin/echo"]
@@ -57,7 +57,7 @@ $ kubectl get pods -l app=nginx -o json | grep podIP

 You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Like Docker, ports can still be published to the host node's interface(s), but the need for this is radically diminished because of the networking model.

-You can read more about [how we achieve this](../admin/networking.html#how-to-achieve-this) if you're curious.
+You can read more about [how we achieve this](/{{page.version}}/docs/admin/networking/#how-to-achieve-this) if you're curious.

 ## Creating a Service

@@ -83,7 +83,7 @@ spec:
    app: nginx
 ```

-This specification will create a Service which targets TCP port 80 on any Pod with the `app=nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html#_v1_service) to see the list of supported fields in service definition.
+This specification will create a Service which targets TCP port 80 on any Pod with the `app=nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_service) to see the list of supported fields in service definition.
 Check your Service:

 ```shell
@@ -113,7 +113,7 @@ 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.html#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](services/#virtual-ips-and-service-proxies).

 ## Accessing the Service

@@ -198,7 +198,7 @@ Till now we have only accessed the nginx server from within the cluster. Before
 * An nginx server configured to use the certificates
 * A [secret](secrets) that makes the certificates accessible to pods

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

 ```shell
 $ make keys secret KEY=/tmp/nginx.key CERT=/tmp/nginx.crt SECRET=/tmp/secret.json
@@ -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](accessing-the-cluster.html#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](kubectl/kubectl_port-forward). Compared to [kubectl proxy](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

@@ -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.html#accessing-the-ui).
+if this command does not find the URL, try the steps [here](ui/#accessing-the-ui).


 ## Connecting to the kube-ui service from your local workstation
@@ -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.html#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](pods/#termination-of-pods).

 ### Hook Handler Execution

@@ -494,7 +494,7 @@ misbehaving.  And yet your `Service` is not working.  You should probably let
 us know, so we can help investigate!

 Contact us on
-[Slack](../troubleshooting.html#slack) or
+[Slack](../troubleshooting/#slack) or
 [email](https://groups.google.com/forum/#!forum/google-containers) or
 [GitHub](https://github.com/kubernetes/kubernetes).

@@ -35,7 +35,7 @@ spec:

 Some differences compared to specifying just a pod are that the `kind` is `ReplicationController`, the number of `replicas` desired is specified, and the pod specification is under the `template` field. The names of the pods don't need to be specified explicitly because they are generated from the name of the replication controller.
 View the [replication controller API
-object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html#_v1_replicationcontroller)
+object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_replicationcontroller)
 to view the list of supported fields.

 This replication controller can be created using `create`, just as with pods:
@@ -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.html#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`](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):

 ```shell
 $ kubectl get rc my-nginx -o template --template="{{.spec.selector}}"
@@ -19,14 +19,14 @@ A typical use case is:

 ## Enabling Deployments on kubernetes cluster

-Deployments is part of the [`extensions` API Group](../api.html#api-groups) and is not enabled by default.
+Deployments is part of the [`extensions` API Group](../api/#api-groups) and is not enabled by default.
 Set `--runtime-config=extensions/v1beta1/deployments=true` on API server to
 enable it.
 This can be achieved by exporting `ENABLE_DEPLOYMENTS=true` before running
 `kube-up.sh` script on GCE.

 Note that Deployment objects effectively have [API version
-`v1alpha1`](../api.html#api-versioning).
+`v1alpha1`](../api/#api-versioning).
 Alpha objects may change or even be discontinued in future software releases.
 However, due to to a known issue, they will appear as API version `v1beta1` if
 enabled.
@@ -252,13 +252,13 @@ As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, a
 `metadata` fields.  For general information about working with config files,
 see [here](deploying-applications), [here](configuring-containers), and [here](working-with-resources).

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

 ### Pod Template

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

-The `.spec.template` is a [pod template](replication-controller.html#pod-template).  It has exactly
+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 `kind`.

@@ -197,7 +197,7 @@ 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.html#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](images/#using-a-private-registry).

 #### docker version

@@ -2,7 +2,7 @@
 title: "Downward API volume plugin"
 ---
 Following this example, you will create a pod with a downward API volume.
-A downward API volume is a k8s volume plugin with the ability to save some pod information in a plain text file. The pod information can be  for example some [metadata](..//{{page.version}}/docs/devel/api-conventions.html#metadata).
+A downward API volume is a k8s volume plugin with the ability to save some pod information in a plain text file. The pod information can be  for example some [metadata](..//{{page.version}}/docs/devel/api-conventions/#metadata).

 Supported metadata fields:

@@ -64,10 +64,10 @@ Response from backend
 Backend Container
 Backend Pod Name: backend-rc-6qiya
 Backend Namespace: default
-
 ```
+
 First the frontend pod's information is printed. The pod name and
-[namespace](/{{page.version}}/docs/design/namespaces) are retrieved from the
+[namespace](https://github.com/kubernetes/kubernetes/blob/master/docs/design/namespaces) are retrieved from the
 [Downward API](/{{page.version}}/docs/user-guide/downward-api). Next, `USER_VAR` is the name of
 an environment variable set in the [pod
 definition](show-rc.yaml). Then, the dynamic Kubernetes environment
@@ -69,7 +69,7 @@ Backend Namespace: default
 ```

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

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

-Kubernetes exposes [services](services.html#environment-variables) through environment variables. It is convenient to check these environment variables using `kubectl exec`.
+Kubernetes exposes [services](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,

@@ -7,7 +7,7 @@ This document describes the current state of Horizontal Pod Autoscaler in Kubern

 Horizontal pod autoscaling allows the number of pods in a replication controller or deployment
 to scale automatically based on observed CPU utilization.
-It is a [beta](../api.html#api-versioning) feature in Kubernetes 1.1.
+It is a [beta](../api/#api-versioning) feature in Kubernetes 1.1.

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

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

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


 ## API Object

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

 ## Support for horizontal pod autoscaler in kubectl

@@ -73,9 +73,9 @@ the horizontal pod autoscaler will not be bound to the new replication controlle

 ## Further reading

-* Design documentation: [Horizontal Pod Autoscaling](../design/horizontal-pod-autoscaler).
+* Design documentation: [Horizontal Pod Autoscaling](https://github.com/kubernetes/kubernetes/tree/master/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/README).
+* Usage example of [Horizontal Pod Autoscaler](horizontal-pod-autoscaling/).



@@ -1,7 +1,7 @@
 ---
 title: "Horizontal Pod Autoscaler"
 ---
-Horizontal pod autoscaling is a [beta](/{{page.version}}/docs/api.html#api-versioning) feature in Kubernetes 1.1.
+Horizontal pod autoscaling is a [beta](/{{page.version}}/docs/api/#api-versioning) feature in Kubernetes 1.1.
 It allows the number of pods in a replication controller or deployment to scale automatically based on observed CPU usage.
 In the future also other metrics will be supported.

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

 We will create the autoscaler by executing the following command:

@@ -1,7 +1,7 @@
 ---
 title: "Horizontal Pod Autoscaler"
 ---
-Horizontal pod autoscaling is a [beta](/{{page.version}}/docs/api.html#api-versioning) feature in Kubernetes 1.1.
+Horizontal pod autoscaling is a [beta](/{{page.version}}/docs/api/#api-versioning) feature in Kubernetes 1.1.
 It allows the number of pods in a replication controller or deployment to scale automatically based on observed CPU usage.
 In the future also other metrics will be supported.

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

 We will create the autoscaler by executing the following command:

@@ -7,11 +7,8 @@ For non-unique user-provided attributes, Kubernetes provides [labels](labels) an

 ## Names

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

 ## UIDs

-UID are generated by Kubernetes.  Every object created over the whole lifetime of a Kubernetes cluster has a distinct UID (i.e., they are spatially and temporally unique).
-
-
-
+UID are generated by Kubernetes.  Every object created over the whole lifetime of a Kubernetes cluster has a distinct UID (i.e., they are spatially and temporally unique).
@@ -4,13 +4,13 @@ title: "Kubernetes User Guide: Managing Applications"
 * TOC
 {:toc}

-The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster.  Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/{{page.version}}/docs/admin/README). The [Developer Guide](/{{page.version}}/docs/devel/README) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project.
+The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster.  Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/{{page.version}}/docs/admin/). The [Developer Guide](/{{page.version}}/docs/devel/) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project.

 Please ensure you have completed the [prerequisites for running examples from the user guide](prereqs).

 ## Quick walkthrough

-1. [Kubernetes 101](walkthrough/README)
+1. [Kubernetes 101](walkthrough/)
 1. [Kubernetes 201](walkthrough/k8s201)

 ## Thorough walkthrough
@@ -36,10 +36,10 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo
 [**Overview**](overview)
 : A brief overview of Kubernetes concepts.

-[**Cluster**](../admin/README)
+[**Cluster**](/{{page.version}}/docs/admin/)
 : A cluster is a set of physical or virtual machines and other infrastructure resources used by Kubernetes to run your applications.

-[**Node**](../admin/node)
+[**Node**](/{{page.version}}/docs/admin/node)
 : A node is a physical or virtual machine running Kubernetes, onto which pods can be scheduled.

 [**Pod**](pods)
@@ -48,7 +48,7 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo
 [**Label**](labels)
 : A label is a key/value pair that is attached to a resource, such as a pod, to convey a user-defined identifying attribute. Labels can be used to organize and to select subsets of resources.

-[**Selector**](labels.html#label-selectors)
+[**Selector**](labels/#label-selectors)
 : A selector is an expression that matches labels in order to identify related resources, such as which pods are targeted by a load-balanced service.

 [**Replication Controller**](replication-controller)
@@ -69,7 +69,7 @@ rules:

 __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](configuring-containers), and [here](working-with-resources).

-__Lines 5-7__: Ingress [spec](../devel/api-conventions.html#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 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.

@@ -96,13 +96,13 @@ As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `meta
 general information about working with config files, see [here](simple-yaml),
 [here](configuring-containers), and [here](working-with-resources).

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

 ### Pod Template

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

-The `.spec.template` is a [pod template](replication-controller.html#pod-template).  It has exactly
+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
 `kind`.

@@ -135,7 +135,7 @@ think that those pods were created by it.  Kubernetes will not stop you from doi
 By default, a Job is complete when one Pod runs to successful completion.  You can also specify that
 this needs to happen multiple times by specifying `.spec.completions` with a value greater than 1.
 When multiple completions are requested, each Pod created by the Job controller has an identical
-[`spec`](../devel/api-conventions.html#spec-and-status).  In particular, all pods will have
+[`spec`](/{{page.version}}/docs/devel/api-conventions/#spec-and-status).  In particular, all pods will have
 the same command line and the same image, the same volumes, and mostly the same environment
 variables.  It is up to the user to arrange for the pods to do work on different things.  For
 example, the pods might all access a shared work queue service to acquire work units.
@@ -198,9 +198,9 @@ value is `Always`.)

 ## Caveats

-Job objects are in the [`extensions` API Group](../api.html#api-groups).
+Job objects are in the [`extensions` API Group](../api/#api-groups).

-Job objects have [API version `v1beta1`](../api.html#api-versioning).  Beta objects may
+Job objects have [API version `v1beta1`](../api/#api-versioning).  Beta objects may
 undergo changes to their schema and/or semantics in future software releases, but
 similar functionality will be supported.

@@ -2,7 +2,7 @@
 title: "Checking Pod Health"
 ---

-This example shows two types of pod [health checks](../production-pods.html#liveness-and-readiness-probes-aka-health-checks): HTTP checks and container execution checks.
+This example shows two types of pod [health checks](../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.

@@ -37,7 +37,7 @@ livenessProbe:
 ```
 The Kubelet sends an HTTP request to the specified path and port to perform the health check. If you take a look at image/server.go, you will see the server starts to respond with an error code 500 after 10 seconds, so the check fails. The Kubelet sends the probe to the container's ip address by default which could be specified with `host` as part of httpGet probe. If the container listens on `127.0.0.1`, `host` should be specified as `127.0.0.1`. In general, if the container listens on its ip address or on all interfaces (0.0.0.0), there is no need to specify the `host` as part of the httpGet probe.

-This [guide](../walkthrough/k8s201.html#health-checking) has more information on health checks.
+This [guide](../walkthrough/k8s201/#health-checking) has more information on health checks.

 ## Get your hands dirty

@@ -1,7 +1,7 @@
 ---
 title: "Overview"
 ---
-This example shows two types of pod [health checks](../production-pods.html#liveness-and-readiness-probes-aka-health-checks): HTTP checks and container execution checks.
+This example shows two types of pod [health checks](../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.

@@ -39,7 +39,7 @@ livenessProbe:

 The Kubelet sends an HTTP request to the specified path and port to perform the health check. If you take a look at image/server.go, you will see the server starts to respond with an error code 500 after 10 seconds, so the check fails. The Kubelet sends the probe to the container's ip address by default which could be specified with `host` as part of httpGet probe. If the container listens on `127.0.0.1`, `host` should be specified as `127.0.0.1`. In general, if the container listens on its ip address or on all interfaces (0.0.0.0), there is no need to specify the `host` as part of the httpGet probe.

-This [guide](../walkthrough/k8s201.html#health-checking) has more information on health checks.
+This [guide](../walkthrough/k8s201/#health-checking) has more information on health checks.

 ## Get your hands dirty

@@ -5,7 +5,7 @@ This page is designed to help you use logs to troubleshoot issues with your Kube

 ## Logging by Kubernetes Components

-Kubernetes components, such as kubelet and apiserver, use the [glog](https://godoc.org/github.com/golang/glog) logging library.  Developer conventions for logging severity are described in [docs/devel/logging.md](../devel/logging).
+Kubernetes components, such as kubelet and apiserver, use the [glog](https://godoc.org/github.com/golang/glog) logging library.  Developer conventions for logging severity are described in [docs/devel/logging.md](/{{page.version}}/docs/devel/logging).

 ## Examining the logs of running containers

@@ -74,13 +74,13 @@ $ kubectl logs kube-dns-v3-7r1l9 etcd

 ## Cluster level logging to Google Cloud Logging

-The getting started guide [Cluster Level Logging to Google Cloud Logging](../getting-started-guides/logging)
+The getting started guide [Cluster Level Logging to Google Cloud Logging](/{{page.version}}/docs/getting-started-guides/logging)
 explains how container logs are ingested into [Google Cloud Logging](https://cloud.google.com/logging/docs/)
 and shows how to query the ingested logs.

 ## Cluster level logging with Elasticsearch and Kibana

-The getting started guide [Cluster Level Logging with Elasticsearch and Kibana](../getting-started-guides/logging-elasticsearch)
+The getting started guide [Cluster Level Logging with Elasticsearch and Kibana](/{{page.version}}/docs/getting-started-guides/logging-elasticsearch)
 describes how to ingest cluster level logs into Elasticsearch and view them using Kibana.

 ## Ingesting Application Log Files
@@ -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](configuring-containers.html#configuration-in-kubernetes) and [labels](deploying-applications.html#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](configuring-containers/#configuration-in-kubernetes) and [labels](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](../design/simple-rolling-update) 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'?](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/tree/master/docs/design/simple-rolling-update.md) and the [example of rolling update](update-demo/) for more information.

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

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

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

 ```shell
 $ kubectl rolling-update my-nginx --image=nginx:1.9.1
@@ -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](../admin/dns).
+When you create a [Service](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: "Node selection example"
 ---
-This example shows how to assign a [pod](../pods) to a specific [node](../../admin/node) or to one of a set of nodes using node labels and the nodeSelector field in a pod specification. Generally this is unnecessary, as the scheduler will take care of things for you, but you may want to do so in certain circumstances like to ensure that your pod ends up on a machine with an SSD attached to it.
+This example shows how to assign a [pod](../pods) to a specific [node](/{{page.version}}/docs/admin/node) or to one of a set of nodes using node labels and the nodeSelector field in a pod specification. Generally this is unnecessary, as the scheduler will take care of things for you, but you may want to do so in certain circumstances like to ensure that your pod ends up on a machine with an SSD attached to it.

 ### Step Zero: Prerequisites

@@ -15,7 +15,7 @@ Then, to add a label to the node you've chosen, run `kubectl label nodes <node-n

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

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

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

@@ -1,7 +1,7 @@
 ---
 title: "Node selection example"
 ---
-This example shows how to assign a [pod](../pods) to a specific [node](../../admin/node) or to one of a set of nodes using node labels and the nodeSelector field in a pod specification. Generally this is unnecessary, as the scheduler will take care of things for you, but you may want to do so in certain circumstances like to ensure that your pod ends up on a machine with an SSD attached to it.
+This example shows how to assign a [pod](../pods) to a specific [node](/{{page.version}}/docs/admin/node) or to one of a set of nodes using node labels and the nodeSelector field in a pod specification. Generally this is unnecessary, as the scheduler will take care of things for you, but you may want to do so in certain circumstances like to ensure that your pod ends up on a machine with an SSD attached to it.

 ### Step Zero: Prerequisites

@@ -15,7 +15,7 @@ Then, to add a label to the node you've chosen, run `kubectl label nodes <node-n

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

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

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

@@ -15,9 +15,9 @@ Users can create and manage pods themselves, but Kubernetes drastically simplifi

 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](annotations).

-Kubernetes supports a unique [networking model](../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.
+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](../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](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.

@@ -80,7 +80,7 @@ apiVersion: v1

 ### Capacity

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

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

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

 ### Resources

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

 ## Claims As Volumes

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

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

-See [Persistent Storage design document](../../design/persistent-storage) for more information.
+See [Persistent Storage design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/persistent-storage) for more information.

 ## Provisioning

@@ -90,7 +90,7 @@ $ curl 10.0.0.241:3000
 I love Kubernetes storage!

 ```
-Hopefully this simple guide is enough to get you started with PersistentVolumes.  If you have any questions, join the team on [Slack](../../troubleshooting.html#slack) and ask!
+Hopefully this simple guide is enough to get you started with PersistentVolumes.  If you have any questions, join the team on [Slack](../../troubleshooting/#slack) and ask!

 Enjoy!

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

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

-See [Persistent Storage design document](../../design/persistent-storage) for more information.
+See [Persistent Storage design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/persistent-storage.md) for more information.

 ## Provisioning

@@ -88,6 +88,6 @@ $ curl 10.0.0.241:3000
 I love Kubernetes storage!
 ```

-Hopefully this simple guide is enough to get you started with PersistentVolumes.  If you have any questions, join the team on [Slack](../../troubleshooting.html#slack) and ask!
+Hopefully this simple guide is enough to get you started with PersistentVolumes.  If you have any questions, join the team on [Slack](../../troubleshooting/#slack) and ask!

 Enjoy!
@@ -7,7 +7,7 @@ This document covers the lifecycle of a pod.  It is not an exhaustive document,

 ## Pod Phase

-As consistent with the overall [API convention](../devel/api-conventions.html#typical-status-properties), phase is a simple, high-level summary of the phase of the lifecycle of a pod. It is not intended to be a comprehensive rollup of observations of container-level or even pod-level conditions or other state, nor is it intended to be a comprehensive state machine.
+As consistent with the overall [API convention](/{{page.version}}/docs/devel/api-conventions/#typical-status-properties), phase is a simple, high-level summary of the phase of the lifecycle of a pod. It is not intended to be a comprehensive rollup of observations of container-level or even pod-level conditions or other state, nor is it intended to be a comprehensive state machine.

 The number and meanings of `PodPhase` values are tightly guarded.  Other than what is documented here, nothing should be assumed about pods with a given `PodPhase`.

@@ -46,17 +46,17 @@ 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.html#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](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
  terminate, and where (e.g. web servers).
- Use a [`DaemonSet`](../admin/daemons): Use for pods which need to run 1 per machine because they provide a
+- 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.
 If you are unsure whether to use ReplicationController or Daemon, then see [Daemon Set versus
-Replication Controller](../admin/daemons.html#daemon-set-versus-replication-controller).
+Replication Controller](/{{page.version}}/docs/admin/daemons/#daemon-set-versus-replication-controller).

 `ReplicationController` is *only* appropriate for pods with `RestartPolicy = Always`.
 `Job` is *only* appropriate for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
@@ -29,7 +29,7 @@ Like individual application containers, pods are considered to be relatively eph

 Pods facilitate data sharing and communication among their constituents.

-The applications in the pod all use the same network namespace/IP and port space, and can find and communicate with each other using localhost. Each pod has an IP address in a flat shared networking namespace that has full communication with other physical computers and containers across the network. The hostname is set to the pod's Name for the application containers within the pod. [More details on networking](../admin/networking).
+The applications in the pod all use the same network namespace/IP and port space, and can find and communicate with each other using localhost. Each pod has an IP address in a flat shared networking namespace that has full communication with other physical computers and containers across the network. The hostname is set to the pod's Name for the application containers within the pod. [More details on networking](/{{page.version}}/docs/admin/networking).

 In addition to defining the application containers that run in the pod, the pod specifies a set of shared storage volumes. Volumes enable data to survive container restarts and to be shared among the applications within the pod.

@@ -93,7 +93,7 @@ An example flow:
 2. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period.
 3. Pod shows up as "Terminating" when listed in client commands
 4. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the pod shutdown process.
-  1. If the pod has defined a [preStop hook](container-environment.html#hook-details), it is invoked inside of the pod. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.
+  1. If the pod has defined a [preStop hook](container-environment/#hook-details), it is invoked inside of the pod. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.
  2. The processes in the Pod are sent the TERM signal.
 5. (simultaneous with 3), Pod is removed from endpoints list for service, and are no longer considered part of the set of running pods for replication controllers. Pods that shutdown slowly can continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
 6. When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
@@ -118,7 +118,7 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'

 Pod is a top-level resource in the kubernetes REST API. More details about the
 API object can be found at: [Pod API
-object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html#_v1_pod).
+object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_pod).



@@ -104,11 +104,11 @@ spec:
          name: supersecret
 ```

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

 ## Authenticating with a private image registry

-Secrets can also be used to pass [image registry credentials](images.html#using-a-private-registry).
+Secrets can also be used to pass [image registry credentials](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:
@@ -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](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](../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](namespaces). It can be viewed with `kubectl describe limitrange limits`.) You may explicitly specify the amount of resources required as follows:

 ```yaml
 apiVersion: v1
@@ -240,7 +240,7 @@ If you're not sure how much resources to request, you can first launch the appli

 ## 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.html#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*](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,14 +272,14 @@ 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](connecting-applications).

-For more details (e.g., how to specify command-based probes), see the [example in the walkthrough](walkthrough/k8s201.html#health-checking), the [standalone example](liveness/), and the [documentation](pod-states.html#container-probes).
+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).

 ## Lifecycle hooks and termination notice

 Of course, nodes and applications may fail at any time, but many applications benefit from clean shutdown, such as to complete in-flight requests, when the termination of the application is deliberate. To support such cases, Kubernetes supports two kinds of notifications:

 * Kubernetes will send SIGTERM to applications, which can be handled in order to effect graceful termination. SIGKILL is sent a configurable number of seconds later if the application does not terminate sooner (defaults to 30 seconds, controlled by `spec.terminationGracePeriodSeconds`).
-* Kubernetes supports the (optional) specification of a [*pre-stop lifecycle hook*](container-environment.html#container-hooks), which will execute prior to sending SIGTERM.
+* Kubernetes supports the (optional) specification of a [*pre-stop lifecycle hook*](container-environment/#container-hooks), which will execute prior to sending SIGTERM.

 The specification of a pre-stop hook is similar to that of probes, but without the timing-related parameters. For example:

@@ -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.html#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](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.

@@ -75,4 +75,4 @@ For instance, a service might target all pods with `tier in (frontend), environm

 Replication controller is a top-level resource in the kubernetes REST API. More details about the
 API object can be found at: [ReplicationController API
-object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions.html#_v1_replicationcontroller).
+object](http://kubernetes.io/v1.1/docs/api-reference/v1/definitions/#_v1_replicationcontroller).
@@ -1,6 +1,6 @@
 ---
 title: "Resource Quota"
 ---
-This page has been moved to [here](../../admin/resourcequota/README)
+This page has been moved to [here](/{{page.version}}/docs/admin/resourcequota/)


@@ -1,6 +1,6 @@
 ---
 title: "Resource Quota"
 ---
-This page has been moved to [here](../../admin/resourcequota/README)
+This page has been moved to [here](/{{page.version}}/docs/admin/resourcequota/)


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

 * TOC
 {:toc}
@@ -51,7 +51,7 @@ data:
 ```

 The data field is a map.  Its keys must match
-[`DNS_SUBDOMAIN`](../design/identifiers), except that leading dots are also
+[`DNS_SUBDOMAIN`](https://github.com/kubernetes/kubernetes/tree/master/docs/design/identifiers.md), except that leading dots are also
 allowed.  The values are arbitrary data, encoded using base64. The values of
 username and password in the example above, before base64 encoding,
 are `value-1` and `value-2`, respectively, with carriage return and newline characters at the end.
@@ -105,7 +105,7 @@ See another example of creating a secret and a pod that consumes that secret in

 ### Manually specifying an imagePullSecret

-Use of imagePullSecrets is described in the [images documentation](images.html#specifying-imagepullsecrets-on-a-pod)
+Use of imagePullSecrets is described in the [images documentation](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.html#adding-imagepullsecrets-to-a-service-account)
+See [here](service-accounts/#adding-imagepullsecrets-to-a-service-account)
 for a detailed explanation of that process.


@@ -189,7 +189,7 @@ the original pod must be deleted, and a new pod (perhaps with an identical
 workflow as deploying a new container image.  The `kubectl rolling-update`
 command can be used ([man page](kubectl/kubectl_rolling-update)).

-The [`resourceVersion`](../devel/api-conventions.html#concurrency-control-and-consistency)
+The [`resourceVersion`](/{{page.version}}/docs/devel/api-conventions/#concurrency-control-and-consistency)
 of the secret is not specified when it is referenced.
 Therefore, if a secret is updated at about the same time as pods are starting,
 then it is not defined which version of the secret will be used for the pod. It
@@ -1,7 +1,7 @@
 ---
 title: "Secrets example"
 ---
-Following this example, you will create a [secret](../secrets) and a [pod](../pods) that consumes that secret in a [volume](../volumes). See [Secrets design document](../../design/secrets) for more information.
+Following this example, you will create a [secret](../secrets) and a [pod](../pods) that consumes that secret in a [volume](../volumes). See [Secrets design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/secrets) for more information.

 ## Step Zero: Prerequisites

@@ -1,7 +1,7 @@
 ---
 title: "Secrets example"
 ---
-Following this example, you will create a [secret](../secrets) and a [pod](../pods) that consumes that secret in a [volume](../volumes). See [Secrets design document](../../design/secrets) for more information.
+Following this example, you will create a [secret](../secrets) and a [pod](../pods) that consumes that secret in a [volume](../volumes). See [Secrets design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/secrets.md) for more information.

 ## Step Zero: Prerequisites

@@ -1,4 +1,4 @@
 ---
 title: "Security Contexts"
 ---
-A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. See [security context design](../design/security_context) for more details.
+A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. See [security context design](https://github.com/kubernetes/kubernetes/tree/master/docs/design/security_context.md) for more details.
@@ -4,7 +4,7 @@ title: "Service Accounts"
 A service account provides an identity for processes that run in a Pod.

 *This is a user introduction to Service Accounts.  See also the
-[Cluster Admin Guide to Service Accounts](../admin/service-accounts-admin).*
+[Cluster Admin Guide to Service Accounts](/{{page.version}}/docs/admin/service-accounts-admin).*

 *Note: This document describes how service accounts behave in a cluster set up
 as recommended by the Kubernetes project.  Your cluster administrator may have
@@ -24,10 +24,10 @@ When you create a pod, you do not need to specify a service account.  It is
 automatically assigned the `default` service account of the same namespace.  If
 you get the raw json or yaml for a pod you have created (e.g. `kubectl get
 pods/podname -o yaml`), you can see the `spec.serviceAccount` field has been
-[automatically set](working-with-resources.html#resources-are-automatically-modified).
+[automatically set](working-with-resources/#resources-are-automatically-modified).

 You can access the API using a proxy or with a client library, as described in
-[Accessing the Cluster](accessing-the-cluster.html#accessing-the-api-from-a-pod).
+[Accessing the Cluster](accessing-the-cluster/#accessing-the-api-from-a-pod).

 ## Using Multiple Service Accounts.

@@ -130,7 +130,7 @@ token:

 ## Adding ImagePullSecrets to a service account

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

 ```shell
@@ -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.html#label-selectors) (see below for why you might want a
+Selector`](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
@@ -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.html#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](services/#external-services) for the pods,
 to do this run:

 ```shell
@@ -21,7 +21,7 @@ limitations under the License.

 # Rolling update example

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

 ### Step Zero: Prerequisites

@@ -21,7 +21,7 @@ limitations under the License.

 # Rolling update example

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

 ### Step Zero: Prerequisites

@@ -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/README)  for more details.
+See the [`downwardAPI` volume example](downward-api/volume/)  for more details.

 ## Resources

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

-See the [design document](../../design/README) for more details.
+See the [design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/) for more details.


 #### Pod Management
@@ -171,4 +171,4 @@ Finally, we have also introduced an environment variable to the `git-monitor` co
 ## What's Next?

 Continue on to [Kubernetes 201](k8s201) or
-for a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/README)
+for a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/)
@@ -43,7 +43,7 @@ spec:

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

-See the [design document](../../design/README) for more details.
+See the [design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/README.md) for more details.


 #### Pod Management
@@ -269,7 +269,7 @@ spec:
 [Download example](pod-with-http-healthcheck.yaml)
 <!-- END MUNGE: EXAMPLE pod-with-http-healthcheck.yaml -->

-For more information about health checking, see [Container Probes](../pod-states.html#container-probes).
+For more information about health checking, see [Container Probes](../pod-states/#container-probes).


 ## What's Next?
@@ -5,7 +5,7 @@ title: "Working with Resources"
 and who want to learn more about using kubectl to manage resources such
 as pods and services.  Users who want to access the REST API directly,
 and developers who want to extend the Kubernetes API should
-refer to the [api conventions](../devel/api-conventions) and
+refer to the [api conventions](/{{page.version}}/docs/devel/api-conventions) and
 the [api document](../api).*

 ## Resources are Automatically Modified
@@ -41,9 +41,9 @@ If you `diff -u /tmp/original.yaml /tmp/current.yaml`, you can see the fields ad
 The system adds fields in several ways:

  - Some fields are added synchronously with creation of the resource and some are set asynchronously.
-    - For example: `metadata.uid` is set synchronously.  (Read more about [metadata](../devel/api-conventions.html#metadata)).
-    - For example, `status.hostIP` is set only after the pod has been scheduled.  This often happens fast, but you may notice pods which do not have this set yet.  This is called Late Initialization.  (Read mode about [status](../devel/api-conventions.html#spec-and-status) and [late initialization](../devel/api-conventions.html#late-initialization) ).
-  - Some fields are set to default values.  Some defaults vary by cluster and some are fixed for the API at a certain version.  (Read more about [defaulting](../devel/api-conventions.html#defaulting)).
+    - For example: `metadata.uid` is set synchronously.  (Read more about [metadata](/{{page.version}}/docs/devel/api-conventions/#metadata)).
+    - For example, `status.hostIP` is set only after the pod has been scheduled.  This often happens fast, but you may notice pods which do not have this set yet.  This is called Late Initialization.  (Read mode about [status](/{{page.version}}/docs/devel/api-conventions/#spec-and-status) and [late initialization](/{{page.version}}/docs/devel/api-conventions/#late-initialization) ).
+  - Some fields are set to default values.  Some defaults vary by cluster and some are fixed for the API at a certain version.  (Read more about [defaulting](/{{page.version}}/docs/devel/api-conventions/#defaulting)).
    - For example, `spec.containers[0].imagePullPolicy` always defaults to `IfNotPresent` in api v1.
    - For example, `spec.containers[0].resources.limits.cpu` may be defaulted to  `100m` on some clusters, to some other value on others, and not defaulted at all on others.