Fixes broken links

2017-05-02 18:12:48 -03:00
parent 4150fc8d7c
commit d2de692a32
11 changed files with 13 additions and 13 deletions
@@ -201,4 +201,4 @@ You can use `kubectl convert` command to convert config files between different
 kubectl convert -f pod.yaml --output-version v1
 ```

-For more options, please refer to the usage of [kubectl convert](/docs/user-guide/kubectl/kubectl_convert/) command.
+For more options, please refer to the usage of [kubectl convert](/docs/user-guide/kubectl/v1.6/#convert) command.
@@ -304,7 +304,7 @@ deployment "my-nginx" autoscaled

 Now your nginx replicas will be scaled up and down as needed, automatically.

-For more information, please see [kubectl scale](/docs/user-guide/kubectl/v1.6/#scale), [kubectl autoscale](/docs/user-guide/kubectl/v1.6/#autoscale) and [horizontal pod autoscaler](/docs/user-guide/horizontal-pod-autoscaler/) document.
+For more information, please see [kubectl scale](/docs/user-guide/kubectl/v1.6/#scale), [kubectl autoscale](/docs/user-guide/kubectl/v1.6/#autoscale) and [horizontal pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) document.


 ## In-place updates of resources
@@ -49,7 +49,7 @@ associated with each signal.
 The value for `memory.available` is derived from the cgroupfs instead of tools
 like `free -m`.  This is important because `free -m` does not work in a
 container, and if users use the [node
-allocatable](/docs/admin/node-allocatable.md) feature, out of resource decisions
+allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions
 are made local to the end user pod part of the cgroup hierarchy as well as the
 root node.  This
 [script](/docs/concepts/cluster-administration/out-of-resource/memory-available.sh)
@@ -11,7 +11,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/{{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), [Google Cloud Monitoring](https://cloud.google.com/monitoring/) and many others described in more details [here](https://github.com/kubernetes/heapster/blob/master/docs/sink-configuration.md). 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](/docs/admin/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), [Google Cloud Monitoring](https://cloud.google.com/monitoring/) and many others described in more details [here](https://github.com/kubernetes/heapster/blob/master/docs/sink-configuration.md). The overall architecture of the service can be seen below:

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