Footer links -> absolute, catching https links to github

2016-02-22 20:53:29 -08:00
parent 0793b7ecb0
commit d44b497a35
17 changed files with 30 additions and 30 deletions
@@ -19,7 +19,7 @@ heapster monitoring will be turned-on by default).
 ## Step One: Run & expose php-apache server

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

 First, we will start a replication controller running the image and expose it as an external service:
@@ -43,7 +43,7 @@ Before you start using the Ingress resource, there are a few things you should u

 * The Ingress resource is not available in any Kubernetes release prior to 1.1
 * You need an Ingress controller to satisfy an Ingress. Simply creating the resource will have no effect.
-* On GCE/GKE there should be a [L7 cluster addon](https://releases.k8s.io/release-1.1/cluster/addons/cluster-loadbalancing/glbc/README.md#prerequisites), on other platforms you either need to write your own or [deploy an existing controller](https://github.com/kubernetes/contrib/tree/master/Ingress) as a pod.
+* On GCE/GKE there should be a [L7 cluster addon](https://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-loadbalancing/glbc/README.md#prerequisites), on other platforms you either need to write your own or [deploy an existing controller](https://github.com/kubernetes/contrib/tree/master/Ingress) as a pod.
 * The resource currently does not support HTTPS, but will do so before it leaves beta.

 ## The Ingress Resource
@@ -75,7 +75,7 @@ __Lines 8-9__: Each http rule contains the following information: A host (eg: fo

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

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

 ## Ingress controllers

@@ -5,7 +5,7 @@ Understanding how an application behaves when deployed is crucial to scaling the

 ### Overview

-Heapster is a cluster-wide aggregator of monitoring and event data. It currently supports Kubernetes natively and works on all Kubernetes setups. Heapster runs as a pod in the cluster, similar to how any Kubernetes application would run. The Heapster pod discovers all nodes in the cluster and queries usage information from the nodes' [Kubelet](https://releases.k8s.io/release-1.1/DESIGN.md#kubelet)s, the on-machine Kubernetes agent. The Kubelet itself fetches the data from [cAdvisor](https://github.com/google/cadvisor). Heapster groups the information by pod along with the relevant labels. This data is then pushed to a configurable backend for storage and visualization. Currently supported backends include [InfluxDB](http://influxdb.com/) (with [Grafana](http://grafana.org/) for visualization) and [Google Cloud Monitoring](https://cloud.google.com/monitoring/). The overall architecture of the service can be seen below:
+Heapster is a cluster-wide aggregator of monitoring and event data. It currently supports Kubernetes natively and works on all Kubernetes setups. Heapster runs as a pod in the cluster, similar to how any Kubernetes application would run. The Heapster pod discovers all nodes in the cluster and queries usage information from the nodes' [Kubelet](https://releases.k8s.io/{{page.githubbranch}}/DESIGN.md#kubelet)s, the on-machine Kubernetes agent. The Kubelet itself fetches the data from [cAdvisor](https://github.com/google/cadvisor). Heapster groups the information by pod along with the relevant labels. This data is then pushed to a configurable backend for storage and visualization. Currently supported backends include [InfluxDB](http://influxdb.com/) (with [Grafana](http://grafana.org/) for visualization) and [Google Cloud Monitoring](https://cloud.google.com/monitoring/). The overall architecture of the service can be seen below:

 ![overall monitoring architecture](/images/docs/monitoring-architecture.png)

@@ -51,4 +51,4 @@ The API will generally not modify fields that you have set; it just sets ones wh

 ## <a name="finding_schema_docs"></a>Finding Documentation on Resource Fields

-You can browse auto-generated API documentation at the [project website](/{{page.version}}/docs/api/) or on [github](https://releases.k8s.io/release-1.1/docs/api-reference).
+You can browse auto-generated API documentation at the [project website](/{{page.version}}/docs/api/) or on [github](https://releases.k8s.io/{{page.githubbranch}}/docs/api-reference).