Heapster with supplementary information

README.md

@@ -35,7 +35,7 @@ the raw metrics.
 - [Metrics Documentation](#metrics-documentation)
 - [Kube-state-metrics self metrics](#kube-state-metrics-self-metrics)
 - [Resource recommendation](#resource-recommendation)
-- [kube-state-metrics vs. Heapster](#kube-state-metrics-vs-heapster)
+- [kube-state-metrics vs. Heapster(metrics-server)](#kube-state-metrics-vs-heapster)
 - [Setup](#setup)
   - [Building the Docker container](#building-the-docker-container)
 - [Usage](#usage)
@@ -134,32 +134,32 @@ These numbers are based on [scalability tests](https://github.com/kubernetes/kub
 
 Note that if CPU limits are set too low, kube-state-metrics' internal queues will not be able to be worked off quickly enough, resulting in increased memory consumption as the queue length grows. If you experience problems resulting from high memory allocation, try increasing the CPU limits.
 
-### kube-state-metrics vs. Heapster
+### kube-state-metrics vs. Heapster(metrics-server)
 
-[Heapster](https://github.com/kubernetes/heapster) is a project which fetches
+Heapster([metrics-server](https://github.com/kubernetes-incubator/metrics-server)) is a project which fetches
 metrics (such as CPU and memory utilization) from the Kubernetes API server and
 nodes and sends them to various time-series backends such as InfluxDB or Google
 Cloud Monitoring. Its most important function right now is implementing certain
 metric APIs that Kubernetes components like the horizontal pod auto-scaler
 query to make decisions.
 
-While Heapster's focus is on forwarding metrics already generated by
+While Heapster([metrics-server](https://github.com/kubernetes-incubator/metrics-server))'s focus is on forwarding metrics already generated by
 Kubernetes, kube-state-metrics is focused on generating completely new metrics
 from Kubernetes' object state (e.g. metrics based on deployments, replica sets,
-etc.). The reason not to extend Heapster with kube-state-metrics' abilities is
-because the concerns are fundamentally different: Heapster only needs to fetch,
+etc.). The reason not to extend Heapster([metrics-server](https://github.com/kubernetes-incubator/metrics-server)) with kube-state-metrics' abilities is
+because the concerns are fundamentally different: Heapster([metrics-server](https://github.com/kubernetes-incubator/metrics-server)) only needs to fetch,
 format and forward metrics that already exist, in particular from Kubernetes
 components, and write them into sinks, which are the actual monitoring
 systems. kube-state-metrics, in contrast, holds an entire snapshot of
 Kubernetes state in memory and continuously generates new metrics based off of
 it but has no responsibility for exporting its metrics anywhere.
 
 In other words, kube-state-metrics itself is designed to be another source for
-Heapster (although this is not currently the case).
+Heapster([metrics-server](https://github.com/kubernetes-incubator/metrics-server)) (although this is not currently the case).
 
-Additionally, some monitoring systems such as Prometheus do not use Heapster
+Additionally, some monitoring systems such as Prometheus do not use Heapster([metrics-server](https://github.com/kubernetes-incubator/metrics-server))
 for metric collection at all and instead implement their own, but
-[Prometheus can scrape metrics from heapster itself to alert on Heapster's health](https://github.com/kubernetes/heapster/blob/master/docs/debugging.md#debuging).
+[Prometheus can scrape metrics from heapster itself to alert on Heapster(metrics-server)'s health](https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/).
 Having kube-state-metrics as a separate project enables access to these metrics
 from those monitoring systems.