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).

Tell us about a new Kubernetes application


Never miss a thing! Sign up for our newsletter to stay updated.


Discover and learn about everything Kubernetes