Repository files navigation

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

This chart bootstraps aNetdata deployment on aKubernetescluster using theHelm package manager.

By default, the chart installs:

• A Netdata child pod on each node of a cluster, using aDaemonset
• A Netdata k8s state monitoring pod on one node, using aDeployment. This virtual node is callednetdata-k8s-state.
• A Netdata parent pod on one node, using aDeployment. This virtual node is callednetdata-parent.

Disabled by default:

• A Netdata restarterCronJob. Its main purpose is to automatically update Netdata when using nightly releases.

The child pods and the state pod function as headless collectors that collect and forwardall the metrics to the parent pod. The parent pod uses persistent volumes to store metrics and alarms, handle alarmnotifications, and provide the Netdata UI to view metrics using an ingress controller.

Please validate that the settings are suitable for your cluster before using them in production.

• A working cluster running Kubernetes v1.9 or newer.
• Thekubectl command line tool,withinone minor version difference ofyour cluster, on an administrative system.
• TheHelm package manager v3.8.0 or newer on the same administrative system.

Netdata is a comprehensive monitoring solution that requires specific access to host resources to function effectively. By design, monitoring solutions like Netdata need visibility into various system components to collect metrics and provide insights. The following mounts, privileges, and capabilities are essential for Netdata's operation, and applying restrictive security profiles or limiting these accesses may significantly impact functionality or render the monitoring solution ineffective.

You can install the Helm chart via our Helm repository, or by cloning this repository.

To use Netdata's Helm repository, run the following commands:

helm repo add netdata https://netdata.github.io/helmchart/helm install netdata netdata/netdata

See ourinstall Netdata on Kubernetesdocumentation for detailed installation and configuration instructions. The remainder of this document assumes youinstalled the Helm chart by cloning this repository, and thus uses slightly differenthelm install/helm upgradecommands.

Clone the repository locally.

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

To install the chart with the release namenetdata:

helm install netdata ./netdata-helmchart/charts/netdata

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

Tip: List all releases usinghelm list.

To uninstall/delete themy-release deployment:

 helm delete netdata

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.slack.webhook_url=MySlackAPIURL \    --set notifications.slack.recipient="@MyUser MyChannel"

Another example, to set a different ingress controller.

By defaultkubernetes.io/ingress.class set to usenginx as an ingress controller, but you can setTraefik as youringress controller by settingingress.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 canbe 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 theDO_NOT_TRACKenvironment variable to non-zero or non-empty value inparent.env /child.env configuration (e.g.,:DO_NOT_TRACK: 1)or uncomment the line invalues.yml.

To deploy additional netdata user configuration files, you will need to add similar entries to eithertheparent.configs or thechild.configs arrays. Regardless of whether you add config files that reside directlyunder/etc/netdata or in a subdirectory such as/etc/netdata/go.d, you can use the already provided configurationsas reference. For reference, theparent.configs the array includes anexample alarm that would get triggered if thepython.dexample module was enabled. Whenever you pass the sensitive data to your configuration like the databasecredential, you can take an option to put it into the Kubernetes Secret by specifyingstoredType: secret in theselected configuration. By default, all the configurations will be placed in the Kubernetes configmap.

Note that in this chart's default configuration, the parent performs the health checks and triggers alarms but collects little data. As a result, the only other configuration files that might make sense to add to the parent arethe 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 theyaml file. Note that the first line undervar: |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

There are two different persistent volumes onparent node by design (not counting any Configmap/Secret mounts). Bothcan be used, but they don't have to be. Keep in mind that whenever persistent volumes forparent are not used, all thedata for specific PV is lost in case of pod removal.

1. database (/var/cache/netdata) - all metrics data is stored here. Performance of this volume affects query timings.
2. alarms (/var/lib/netdata) - alarm log, if not persistent pod recreation will result in parent appearing as a newnode innetdata.cloud (due to./registry/ and./cloud.d/ being removed).

In case ofchild instance it is a bit simpler. By default, hostPath:/var/lib/netdata-k8s-child is mounted on childin:/var/lib/netdata. You can disable it, but this option is pretty much required in a real life scenario, as withoutit each pod deletion will result in a new replication node for a parent.

Netdata'sservice discovery, which is installed as part of theHelm chart installation, finds what services are running on a cluster's pods, converts that into configuration files,and exports them, so they can be monitored.

Service discovery currently supports the following applications via their associated collector:

• ActiveMQ
• Apache
• Bind
• CockroachDB
• Consul
• CoreDNS
• Elasticsearch
• Fluentd
• FreeRADIUS
• HDFS
• Lighttpd
• Logstash
• MySQL
• NGINX
• OpenVPN
• PHP-FPM
• RabbitMQ
• Tengine
• Unbound
• VerneMQ
• ZooKeeper

Service discovery supports Prometheus endpoints viathePrometheus collector.

Annotations on pods allow a fine control of the scraping process:

• prometheus.io/scrape: The default configuration will scrape all pods and, if set to false, this annotation excludesthe pod from the scraping process.
• prometheus.io/path: If the metrics path is not/metrics, define it with this annotation.
• prometheus.io/port: Scrape the pod on the indicated port instead of the pod’s declared ports.

If your cluster runs services on non-default ports or uses non-default names, you may need to configure servicediscovery to start collecting metrics from your services. You have to editthedefault ConfigMap that is shipped with theHelmchart and deploy that to your cluster.

First, copynetdata-helmchart/sdconfig/child.yml to a new location outside thenetdata-helmchart directory. Thedestination can be anywhere you like, but the following examples assume it resides next to thenetdata-helmchartdirectory.

cp netdata-helmchart/sdconfig/child.yml.

Edit the newchild.yml file according to your needs. SeetheHelm chart configuration and the file itself for details. Youcan then runhelm install/helm upgrade with the--set-file argument to use your configuredchild.yml file instead of thedefault, changing the path if you copied it elsewhere.

helm install --set-file sd.child.configmap.from.value=./child.yml netdata ./netdata-helmchart/charts/netdatahelm upgrade --set-file sd.child.configmap.from.value=./child.yml netdata ./netdata-helmchart/charts/netdata

Now that you pushed an edited ConfigMap to your cluster, service discovery should find and set up metrics collectionfrom your non-default service.

Occasionally, you will want to addspecificlabelsandannotations to the parent and/orchild pods. You might want to do this to tell other applications on the cluster how to treat your pods, or simply tocategorize applications on your cluster. You can label and annotate the parent and child pods by using thepodLabelsandpodAnnotations dictionaries under theparent andchild objects, respectively.

For example, suppose you're installing Netdata on all your database nodes, and you'd like the child pods to be labeledwithworkload: database so that you're able to recognize this.

At the same time, say you've configuredchaoskube to killall pods annotated withchaoskube.io/enabled: true, and you'd like chaoskube to be enabled for the parent pod but notthe childs.

You would do this by installing as:

$helm install \  --set child.podLabels.workload=database \  --set 'child.podAnnotations.chaoskube\.io/enabled=false' \  --set 'parent.podAnnotations.chaoskube\.io/enabled=true' \  netdata ./netdata-helmchart/charts/netdata

If you want to contribute, we’re humbled!

• Take a look at ourContributing Guidelines.
• This repository is under theNetdata Code Of Conduct.
• Chat about your contribution and let us help you inourforum!