Make docs links be relative so we can version them

examples/mysql-wordpress-pd/README.md

@@ -4,7 +4,7 @@ This example describes how to run a persistent installation of [Wordpress](https
 
 We'll use the [mysql](https://registry.hub.docker.com/_/mysql/) and [wordpress](https://registry.hub.docker.com/_/wordpress/) official [Docker](https://www.docker.com/) images for this installation. (The wordpress image includes an Apache server).
 
-We'll create two Kubernetes [pods](http://docs.k8s.io/pods.md) to run mysql and wordpress, both with associated persistent disks, then set up a Kubernetes [service](http://docs.k8s.io/services.md) to front each pod.
+We'll create two Kubernetes [pods](../../docs/pods.md) to run mysql and wordpress, both with associated persistent disks, then set up a Kubernetes [service](../../docs/services.md) to front each pod.
 
 This example demonstrates several useful things, including: how to set up and use persistent disks with Kubernetes pods; how to define Kubernetes services to leverage docker-links-compatible service environment variables; and use of an external load balancer to expose the wordpress service externally and make it transparent to the user if the wordpress pod moves to a different cluster node.
 
@@ -30,11 +30,11 @@ Next, start up a Kubernetes cluster:
 wget -q -O - https://get.k8s.io | bash
 ```
 
-Please see the [GCE getting started guide](http://docs.k8s.io/getting-started-guides/gce.md) for full details and other options for starting a cluster.
+Please see the [GCE getting started guide](../../docs/getting-started-guides/gce.md) for full details and other options for starting a cluster.
 
 ## Create two persistent disks
 
-For this WordPress installation, we're going to configure our Kubernetes [pods](http://docs.k8s.io/pods.md) to use [persistent disks](https://cloud.google.com/compute/docs/disks). This means that we can preserve installation state across pod shutdown and re-startup.
+For this WordPress installation, we're going to configure our Kubernetes [pods](../../docs/pods.md) to use [persistent disks](https://cloud.google.com/compute/docs/disks). This means that we can preserve installation state across pod shutdown and re-startup.
 
 You will need to create the disks in the same [GCE zone](https://cloud.google.com/compute/docs/zones) as the Kubernetes cluster. The default setup script will create the cluster in the `us-central1-b` zone, as seen in the [config-default.sh](/cluster/gce/config-default.sh) file. Replace `$ZONE` below with the appropriate zone.
 
@@ -123,8 +123,8 @@ If you want to do deeper troubleshooting, e.g. if it seems a container is not st
 
 ### Start the Mysql service
 
-We'll define and start a [service](http://docs.k8s.io/services.md) that lets other pods access the mysql database on a known port and host.
-We will specifically name the service `mysql`.  This will let us leverage the support for [Docker-links-compatible](http://docs.k8s.io/services.md#how-do-they-work) service environment variables when we set up the wordpress pod. The wordpress Docker image expects to be linked to a mysql container named `mysql`, as you can see in the "How to use this image" section on the wordpress docker hub [page](https://registry.hub.docker.com/_/wordpress/).
+We'll define and start a [service](../../docs/services.md) that lets other pods access the mysql database on a known port and host.
+We will specifically name the service `mysql`.  This will let us leverage the support for [Docker-links-compatible](../../docs/services.md#how-do-they-work) service environment variables when we set up the wordpress pod. The wordpress Docker image expects to be linked to a mysql container named `mysql`, as you can see in the "How to use this image" section on the wordpress docker hub [page](https://registry.hub.docker.com/_/wordpress/).
 
 So if we label our Kubernetes mysql service `mysql`, the wordpress pod will be able to use the Docker-links-compatible environment variables, defined by Kubernetes, to connect to the database.
 

examples/phabricator/README.md

@@ -158,7 +158,7 @@ $ kubectl create -f examples/phabricator/authenticator-controller.json
 
 ### Step Four: Turn up the phabricator service
 
-A Kubernetes 'service' is a named load balancer that proxies traffic to one or more containers. The services in a Kubernetes cluster are discoverable inside other containers via *environment variables*. Services find the containers to load balance based on pod labels.  These environment variables are typically referenced in application code, shell scripts, or other places where one node needs to talk to another in a distributed system.  You should catch up on [kubernetes services](http://docs.k8s.io/services.md) before proceeding.
+A Kubernetes 'service' is a named load balancer that proxies traffic to one or more containers. The services in a Kubernetes cluster are discoverable inside other containers via *environment variables*. Services find the containers to load balance based on pod labels.  These environment variables are typically referenced in application code, shell scripts, or other places where one node needs to talk to another in a distributed system.  You should catch up on [kubernetes services](../../docs/services.md) before proceeding.
 
 The pod that you created in Step One has the label `name=phabricator`. The selector field of the service determines which pods will receive the traffic sent to the service. Since we are setting up a service for an external application we also need to request external static IP address (otherwise it will be assigned dynamically):
 

examples/walkthrough/k8s201.md

@@ -12,13 +12,13 @@ Having already learned about Pods and how to create them, you may be struck by a
 kubectl get pods -l name=nginx
 ```
 
-Lists all pods who name label matches 'nginx'.  Labels are discussed in detail [elsewhere](http://docs.k8s.io/labels.md), but they are a core concept for two additional building blocks for Kubernetes, Replication Controllers and Services
+Lists all pods who name label matches 'nginx'.  Labels are discussed in detail [elsewhere](../../docs/labels.md), but they are a core concept for two additional building blocks for Kubernetes, Replication Controllers and Services
 
 ### Replication Controllers
 
 OK, now you have an awesome, multi-container, labelled pod and you want to use it to build an application, you might be tempted to just start building a whole bunch of individual pods, but if you do that, a whole host of operational concerns pop up.  For example: how will you scale the number of pods up or down and how will you ensure that all pods are homogenous?
 
-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.  The design of replication controllers is discussed in detail [elsewhere](http://docs.k8s.io/replication-controller.md).
+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.  The design of replication controllers is discussed in detail [elsewhere](../../docs/replication-controller.md).
 
 An example replication controller that instantiates two pods running nginx looks like:
 ```yaml
@@ -71,7 +71,7 @@ spec:
     name: nginx
 ```
 
-When created, each service is assigned a unique IP address.  This address is tied to the lifespan of the Service, and will not change while the Service is alive.  Pods can be configured to talk to the service, and know that communication to the service will be automatically load-balanced out to some pod that is a member of the set identified by the label selector in the Service.  Services are described in detail [elsewhere](http://docs.k8s.io/services.md).
+When created, each service is assigned a unique IP address.  This address is tied to the lifespan of the Service, and will not change while the Service is alive.  Pods can be configured to talk to the service, and know that communication to the service will be automatically load-balanced out to some pod that is a member of the set identified by the label selector in the Service.  Services are described in detail [elsewhere](../../docs/services.md).
 
 ### Health Checking
 When I write code it never crashes, right?  Sadly the [kubernetes issues list](https://github.com/GoogleCloudPlatform/kubernetes/issues) indicates otherwise...