Based on the work of varyumin (https://github.com/varyumin/netdata)

This Helm chart is in Beta. Please validate that the settings are suitable for your cluster, before using them in production

This chart bootstraps a netdata deployment on a Kubernetes cluster using the Helm package manager.

The chart installs a netdata slave pod on each node of a cluster, using a Daemonset if not disabled, and a netdata master pod on one node, using a Statefulset. The slaves function as headless collectors that simply collect and forward all the metrics to the master netdata. The master uses persistent volumes to store metrics and alarms, handles alarm notifications and provides the netdata UI to view the metrics, using an ingress controller.

• Kubernetes 1.9+

Clone the repository locally

$ git clone https://github.com/netdata/helmchart.git netdata

To install the chart with the release name my-release:

$ helm install --name my-release ./netdata

The command deploys nginx-ingress on the Kubernetes cluster in the default configuration. The configuration section lists the parameters that can be configured during installation.

Tip: List all releases using helm list

To uninstall/delete the my-release deployment:

$ helm delete my-release --purge

The command removes all the Kubernetes components associated with the chart and deletes the release.

The following table lists the configurable parameters of the netdata chart and their default values.

Example to set the parameters from the command line:

$ helm install ./netdata --name my-release \
    --set notifications.slackurl=MySlackAPIURL \
    --set notifications.slackrecipiet="@MyUser MyChannel"

Another example, to set a different ingress controller.

By default kubernetes.io/ingress.class set to use nginx as an ingress controller but you can set Traefik as your ingress controller by setting ingress.annotations.

$ helm install ./netdata --name my-release \
    --set ingress.annotations=kubernetes.io/ingress.class: traefik

Alternatively to passing each variable in the command line, a YAML file that specifies the values for the parameters can be provided while installing the chart. For example,

$ helm install ./netdata --name my-release -f values.yaml

Tip: You can use the default values.yaml

Note:: To opt out of anonymous statistics, set the DO_NOT_TRACK environment variable to non-zero or non-empty value in master.env / slave.env configuration (e.g: DO_NOT_TRACK: 1) or uncomment the line in values.yml.

To deploy additional netdata user configuration files, you will need to add similar entries to either the master.configs or the slave. configs arrays. Regardless of whether you add config files that reside directly under /etc/netdata or in a subdirectory such as /etc/netdata/go.d, you can use the already provided configurations as reference. For reference, the master.configs the array includes an example alarm that would get triggered if the python.d example module was enabled.

Note that with the default configuration of this chart, the master does the health checks and triggers alarms, but does not collect much data. As a result, the only other configuration files that might make sense to add to the master are the alarm and alarm template definitions, under /etc/netdata/health.d.

Tip: Do pay attention to the indentation of the config file contents, as it matters for the parsing of the yaml file. Note that the first line under var: | must be indented with two more spaces relative to the preceding line:

  data: |-
    config line 1 #Need those two spaces
        config line 2 #No problem indenting more here

Occasionally, you will want to add specific labels and annotations to the master and/or slave pods. You might want to do this to tell other applications on the cluster how to treat your pods, or simply to categorize applications on your cluster. You can label and annotate the master and slave pods by using the podLabels and podAnnotations dictionaries under the master and slave objects, respectively.

For example, suppose you're installing netdata on all your database nodes, and you'd like the slave pods to be labeled with workload: database so that you're able to recognize this. At the same time, say you've configured chaoskube to kill all pods annotated with chaoskube.io/enabled: true, and you'd like chaoskube to be enabled for the master pod but not the slaves. You would do this by installing as:

$ helm install ./netdata --name my-release \
    --set slave.podLabels.workload=database \
    --set 'slave.podAnnotations.chaoskube\.io/enabled=false' \
    --set 'master.podAnnotations.chaoskube\.io/enabled=true'