All Projects → netdata → Helmchart

netdata / Helmchart

Licence: gpl-3.0
Helm chart for kubernetes deployments

Labels

Projects that are alternatives of or similar to Helmchart

Mustache
A simple Mustache parser/evaluator for Swift
Stars: ✭ 20 (-80.77%)
Mutual labels:  mustache
Choerodon Front
Choerodon Front is a total front-end of Choerodon that combines Choerodon IAM and Choerodon DevOps.
Stars: ✭ 62 (-40.38%)
Mutual labels:  mustache
Helm Charts
Helm Charts for Jaeger backend
Stars: ✭ 94 (-9.62%)
Mutual labels:  mustache
Helm Charts
Prometheus community Helm charts
Stars: ✭ 962 (+825%)
Mutual labels:  mustache
Connect Api Specification
This repository contains the OpenAPI specification as well as templates for generating SDKs for Square's APIs
Stars: ✭ 56 (-46.15%)
Mutual labels:  mustache
Helm Charts
Helm Charts ⛵ @ Delivery Hero ⭐
Stars: ✭ 75 (-27.88%)
Mutual labels:  mustache
Harbor Helm
The helm chart to deploy Harbor
Stars: ✭ 647 (+522.12%)
Mutual labels:  mustache
Scriban
A fast, powerful, safe and lightweight scripting language and engine for .NET
Stars: ✭ 1,360 (+1207.69%)
Mutual labels:  mustache
Mustache
Mustache templating language in Go
Stars: ✭ 57 (-45.19%)
Mutual labels:  mustache
Helm Charts
Kubernetes Helm Charts for the Center for Open Science
Stars: ✭ 88 (-15.38%)
Mutual labels:  mustache
K8s Minecraft
Running a Minecraft server in Kubernetes
Stars: ✭ 37 (-64.42%)
Mutual labels:  mustache
Charts
Community managed Helm charts for running Falco with Kubernetes
Stars: ✭ 55 (-47.12%)
Mutual labels:  mustache
Template Mustache
Drawing Mustaches on Perl, for fun and profit
Stars: ✭ 82 (-21.15%)
Mutual labels:  mustache
Pomerium Helm
Official helm charts for Pomerium.
Stars: ✭ 32 (-69.23%)
Mutual labels:  mustache
Helm Charts
Contains Helm charts for Kubernetes related open source tools
Stars: ✭ 95 (-8.65%)
Mutual labels:  mustache
Handlebars.net
A real .NET Handlebars engine
Stars: ✭ 723 (+595.19%)
Mutual labels:  mustache
Mustache4dart
mustache implementation for Dart
Stars: ✭ 71 (-31.73%)
Mutual labels:  mustache
Project Init
Project templates in rust
Stars: ✭ 104 (+0%)
Mutual labels:  mustache
Api2html
Using the data from your API, generate the HTML on the fly! Server-side rendering of the mustache templates
Stars: ✭ 97 (-6.73%)
Mutual labels:  mustache
Otomi Core
Otomi Container Platform, a suite of integrated best of breed open source tools combined with automation & self service, all wrapped together and made available as an enterprise ready and single deployable solution
Stars: ✭ 84 (-19.23%)
Mutual labels:  mustache

Netdata Helm chart for Kubernetes deployments

Artifact HUB Version: 3.6.3 AppVersion: v1.29.3

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

Introduction

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

The chart installs a Netdata child pod on each node of a cluster, using a Daemonset if not disabled, and a Netdata parent pod on one node, using a Deployment. The child pods function as headless collectors that collect and forward all the metrics to the parent pod. The parent pod uses persistent volumes to store metrics and alarms, handle alarm notifications, 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.

Prerequisites

Installing the Helm chart

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

Installing via our Helm repository (recommended)

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 our install Netdata on Kubernetes documentation for detailed installation and configuration instructions. The remainder of this document assumes you installed the Helm chart by cloning this repository, and thus uses slightly different helm install/helm upgrade commands.

Install by cloning the repository

Clone the repository locally.

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

To install the chart with the release name netdata:

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

The command deploys 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.

Once the Netdata deployment is up and running, read our guide, Monitor a Kubernetes (k8s) cluster with Netdata, for a breakdown of all the collectors, metrics, and charts available for health monitoring and performance troubleshooting.

Uninstalling the Chart

To uninstall/delete the my-release deployment:

 helm delete netdata

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

Configuration

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

Parameter Description Default
replicaCount Number of replicas for the parent netdata Deployment 1
image.repository Container image repo netdata/netdata
image.tag Container image tag Latest stable netdata release (e.g. v1.29.3)
image.pullPolicy Container image pull policy Always
service.type Parent service type ClusterIP
service.port Parent service port 19999
service.loadBalancerIP Static LoadBalancer IP, only to be used with service type=LoadBalancer ""
service.loadBalancerSourceRanges List of allowed IPs for LoadBalancer []
service.externalTrafficPolicy Denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints Cluster
service.healthCheckNodePort Specifies the health check node port Allocated a port from your cluster's NodePort range
service.clusterIP Specific cluster IP when service type is cluster IP. Use None for headless service Allocated an IP from your cluster's service IP range
service.annotations Additional annotations to add to the service {}
ingress.enabled Create Ingress to access the netdata web UI true
ingress.annotations Associate annotations to the Ingress kubernetes.io/ingress.class: nginx and kubernetes.io/tls-acme: "true"
ingress.path URL path for the ingress /
ingress.hosts URL hostnames for the ingress (they need to resolve to the external IP of the ingress controller) netdata.k8s.local
rbac.create if true, create & use RBAC resources true
rbac.pspEnabled Specifies whether a PodSecurityPolicy should be created. true
serviceAccount.create if true, create a service account true
serviceAccount.name The name of the service account to use. If not set and create is true, a name is generated using the fullname template. netdata
clusterrole.name Name of the cluster role linked with the service account netdata
APIKEY The key shared between the parent and the child netdata for streaming 11111111-2222-3333-4444-555555555555
parent.port Parent's listen port 19999
parent.resources Resources for the parent deployment {}
parent.livenessProbe.failureThreshold When a liveness probe fails, Kubernetes will try failureThreshold times before giving up. Giving up the liveness probe means restarting the container 3
parent.livenessProbe.periodSeconds How often (in seconds) to perform the liveness probe 30
parent.livenessProbe.successThreshold Minimum consecutive successes for the liveness probe to be considered successful after having failed 1
parent.livenessProbe.timeoutSeconds Number of seconds after which the liveness probe times out 1
parent.readinessProbe.failureThreshold When a readiness probe fails, Kubernetes will try failureThreshold times before giving up. Giving up the readiness probe means marking the Pod Unready 3
parent.readinessProbe.periodSeconds How often (in seconds) to perform the readiness probe 30
parent.readinessProbe.successThreshold Minimum consecutive successes for the readiness probe to be considered successful after having failed 1
parent.readinessProbe.timeoutSeconds Number of seconds after which the readiness probe times out 1
parent.terminationGracePeriodSeconds Duration in seconds the pod needs to terminate gracefully 300
parent.nodeSelector Node selector for the parent deployment {}
parent.tolerations Tolerations settings for the parent deployment []
parent.affinity Affinity settings for the parent deployment {}
parent.priorityClassName Pod priority class name for the parent deployment ""
parent.database.persistence Whether the parent should use a persistent volume for the DB true
parent.database.storageclass The storage class for the persistent volume claim of the parent's database store, mounted to /var/cache/netdata the default storage class
parent.database.volumesize The storage space for the PVC of the parent database 2Gi
parent.alarms.persistence Whether the parent should use a persistent volume for the alarms log true
parent.alarms.storageclass The storage class for the persistent volume claim of the parent's alarm log, mounted to /var/lib/netdata the default storage class
parent.alarms.volumesize The storage space for the PVC of the parent alarm log 100Mi
parent.env Set environment parameters for the parent deployment {}
parent.podLabels Additional labels to add to the parent pods {}
parent.podAnnotations Additional annotations to add to the parent pods {}
parent.configs Manage custom parent's configs See Configuration files.
parent.claiming.enabled Enable parent claiming for netdata cloud false
parent.claiming.token Claim token ""
parent.claiming.room Comma separated list of claim rooms IDs ""
child.enabled Install child daemonset to gather data from nodes true
child.port Children's listen port service.port (Same as parent's listen port)
child.updateStrategy An update strategy to replace existing DaemonSet pods with new pods {}
child.resources Resources for the child daemonsets {}
child.livenessProbe.failureThreshold When a liveness probe fails, Kubernetes will try failureThreshold times before giving up. Giving up the liveness probe means restarting the container 3
child.livenessProbe.periodSeconds How often (in seconds) to perform the liveness probe 30
child.livenessProbe.successThreshold Minimum consecutive successes for the liveness probe to be considered successful after having failed 1
child.livenessProbe.timeoutSeconds Number of seconds after which the liveness probe times out 1
child.readinessProbe.failureThreshold When a readiness probe fails, Kubernetes will try failureThreshold times before giving up. Giving up the readiness probe means marking the Pod Unready 3
child.readinessProbe.periodSeconds How often (in seconds) to perform the readiness probe 30
child.readinessProbe.successThreshold Minimum consecutive successes for the readiness probe to be considered successful after having failed 1
child.readinessProbe.timeoutSeconds Number of seconds after which the readiness probe times out 1
child.terminationGracePeriodSeconds Duration in seconds the pod needs to terminate gracefully 30
child.nodeSelector Node selector for the child daemonsets {}
child.tolerations Tolerations settings for the child daemonsets - operator: Exists with effect: NoSchedule
child.affinity Affinity settings for the child daemonsets {}
child.priorityClassName Pod priority class name for the child daemonsets ""
child.env Set environment parameters for the child daemonset {}
child.podLabels Additional labels to add to the child pods {}
child.podAnnotations Additional annotations to add to the child pods {}
child.podAnnotationAppArmor.enabled Whether or not to include the AppArmor security annotation true
child.persistence.hostPath Host node directory for storing child instance data /var/lib/netdata-k8s-child
child.persistence.enabled Whether or not to persist /var/lib/netdata in the child.persistence.hostPath. true
child.configs Manage custom child's configs See Configuration files.
child.claiming.enabled Enable child claiming for netdata cloud false
child.claiming.token Claim token ""
child.claiming.room Comma separated list of claim rooms IDs ""
notifications.slackurl URL for slack notifications ""
notifications.slackrecipient Slack recipient list ""
sysctlImage.enabled Enable an init container to modify Kernel settings false
sysctlImage.command sysctlImage command to execute []
sysctlImage.repository sysctlImage Init container name alpine
sysctlImage.tag sysctlImage Init container tag latest
sysctlImage.pullPolicy sysctlImage Init container pull policy Always
sysctlImage.resources sysctlImage Init container CPU/Memory resource requests/limits {}
wgetImage.repository wgetImage Init container name netdata/wget
wgetImage.tag wgetImage Init container tag latest
wgetImage.pullPolicy wgetImage Init container pull policy Always
sd.image.repository Service-discovery image repo netdata/agent-sd
sd.image.tag Service-discovery image tag Latest stable release (e.g. v0.1.0)
sd.image.pullPolicy Service-discovery image pull policy Always
sd.child.enabled Add service-discovery sidecar container to the netdata child pod definition true
sd.child.resources Child service-discovery container CPU/Memory resource requests/limits {}
sd.child.configmap.name Child service-discovery ConfigMap name netdata-child-sd-config-map
sd.child.configmap.key Child service-discovery ConfigMap key config.yml
sd.child.configmap.from.file File to use for child service-discovery configuration generation sdconfig/sd-child.yml
sd.child.configmap.from.value Value to use for child service-discovery configuration generation {}

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 parent.env / child.env configuration (e.g: DO_NOT_TRACK: 1) or uncomment the line in values.yml.

Configuration files

Parameter Description Default
parent.configs.netdata Contents of the parent's netdata.conf memory mode = save
parent.configs.stream Contents of the parent's stream.conf Store child data, accept all connections, and issue alarms for child data.
parent.configs.health Contents of health_alarm_notify.conf Email disabled, a sample of the required settings for Slack notifications
parent.configs.exporting Contents of exporting.conf Disabled
child.configs.netdata Contents of the child's netdata.conf No persistent storage, no alarms, no UI
child.configs.stream Contents of the child's stream.conf Send metrics to the parent at netdata:{{ service.port }}
child.configs.exporting Contents of the child's exporting.conf Disabled
child.configs.kubelet Contents of the child's go.d/k8s_kubelet.conf that drives the kubelet collector Update metrics every sec, do not retry to detect the endpoint, look for the kubelet metrics at http://127.0.0.1:10255/metrics
child.configs.kubeproxy Contents of the child's go.d/k8s_kubeproxy.conf that drives the kubeproxy collector Update metrics every sec, do not retry to detect the endpoint, look for the coredns metrics at http://127.0.0.1:10249/metrics

To deploy additional netdata user configuration files, you will need to add similar entries to either the parent.configs or the child. 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 parent.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 parent 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 parent 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

Service discovery and supported services

Netdata's service discovery, which is installed as part of the Helm 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.

Applications

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

Prometheus endpoints

Service discovery supports Prometheus endpoints via the Prometheus 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 excludes the 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.

Configure service discovery

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

First, copy netdata-helmchart/sdconfig/child.yml to a new location outside the netdata-helmchart directory. The destination can be anywhere you like, but the following examples assume it resides next to the netdata-helmchart directory.

cp netdata-helmchart/sdconfig/child.yml .

Edit the new child.yml file according to your needs. See the Helm chart configuration and the file itself for details. You can then run helm install/helm upgrade with the --set-file argument to use your configured child.yml file instead of the default, changing the path if you copied it elsewhere.

helm install --set-file sd.child.configmap.from.value=./child.yml netdata ./netdata-helmchart/charts/netdata
helm 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 collection from your non-default service.

Custom pod labels and annotations

Occasionally, you will want to add specific labels and annotations to the parent and/or child 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 parent and child pods by using the podLabels and podAnnotations dictionaries under the parent and child objects, respectively.

For example, suppose you're installing Netdata on all your database nodes, and you'd like the child 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 parent pod but not the 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
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].