Heapster collected resource measurements from Kubernetes workloads and machines and exposed them to other components. It served older monitoring and autoscaling setups that needed a common view of CPU, memory and related cluster activity. The project is retired, but its former consumers may still explain why it remains in an inherited cluster. Replacing it means separating the need for immediate resource metrics from the need to store and query longer monitoring history.
Current guidance
Heapster is explicitly retired. Its old chart should not be used as the starting point for a new monitoring system.
Upstream separates the migration by task: Metrics Server supplies basic CPU/memory resource metrics for autoscaling, while a monitoring pipeline such as Prometheus addresses historical observation and querying. Metrics Server is not a full replacement for stored monitoring data.
Identify which Heapster consumers remain, replace each function deliberately and verify HPA behavior as well as dashboards. Remove the old component only after dependent services have migrated.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
Heapster enables Container Cluster Monitoring and Performance Analysis. It collects and interprets various signals like compute resource usage, lifecycle events, etc, and exports cluster metrics via REST endpoints. The Chart can also enable eventer, which can send the kubernetes event logs to a remote location.
Heapster Metric Model
The Heapster Model is a structured representation of metrics for Kubernetes clusters, which is exposed through a set of REST API endpoints. It allows the extraction of up to 15 minutes of historical data for any Container, Pod, Node or Namespace in the cluster, as well as the cluster itself (depending on the metric).
Deprecated Heapster Model API
The model API does not conform to the standards of a Kubernetes API. It cannot be easily aggregated, does not have autogenerated serialization and clients for its types, and does has a number of corner cases in its design that cause it to fail to display metrics in certain case.
Within Kubernetes, its use been replaced by the resource metrics API and custom metrics API, found in the k8s.io/metrics repository. New applications that need metrics are encouraged to use these APIs instead.
Running Heapster on Kubernetes
Heapster can run on a Kubernetes cluster using a number of backends. Some common choices:
- InfluxDB
- Stackdriver Monitoring and Logging for Google Cloud Platform
- Other backends
Running Heapster on OpenShift
Using Heapster to monitor an OpenShift cluster requires some additional changes to the Kubernetes instructions to allow communication between the Heapster instance and OpenShift’s secured endpoints.
Heapster supports pluggable storage backends
Sink Owners:
Each sink in Heapster needs to have at least one “owner”. The owner will be responsible for doing code reviews of pull requests regarding their sink, and will be a point of contact for issues relating to their sink.
Owners will not be responsible for actually triaging issues and pull requests, but once assigned, they will be responsible for responding to the issues.
PRs affecting a particular sink generally need to be approved by the sink owner. Similarly, PRs affecting a particular sink that have LGTM from the sink owner will be considered ok-to-merge by the Heapster maintainers (i.e. sink owners will not have official merge permissions, but the maintainer’s role in this case is just to perform the actual merge).
Sources & further reading
Spotted something that needs another look?
Help improve this page →