Abstract
Installs the web dashboarding system Grafana
Grafana Helm Chart#
Get Repo Info#
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
Installing the Chart#
To install the chart with the release name my-release
:
helm install my-release grafana/grafana
Uninstalling the Chart#
To uninstall/delete the my-release deployment:
helm delete my-release
Note
The command removes all the Kubernetes components associated with the chart and deletes the release.
Upgrading an existing Release to a new major version#
A major chart version change (like v1.2.3 -> v2.0.0) indicates that there is an incompatible breaking change needing manual actions.
To 4.0.0 (And 3.12.1)#
This version requires Helm >= 2.12.0.
To 5.0.0#
You have to add –force to your helm upgrade command as the labels of the chart have changed.
To 6.0.0#
This version requires Helm >= 3.1.0.
To 7.0.0#
For consistency with other Helm charts, the global.image.registry
parameter was renamed to global.imageRegistry
. If you were not
previously setting global.image.registry
, no action is required on
upgrade. If you were previously setting global.image.registry
, you
will need to instead set global.imageRegistry
.
Configuration#
Parameter |
Description |
Default |
---|---|---|
|
Number of nodes |
|
|
Pod disruption minimum available |
|
|
Pod disruption maximum unavailable |
|
|
Pod disruption apiVersion |
|
|
Deployment strategy |
|
|
Liveness Probe settings |
|
|
Readiness Probe settings |
|
|
Deployment securityContext |
|
|
Name of Priority Class to assign pods |
|
|
Image registry |
|
|
Image repository |
|
|
Overrides the Grafana image tag whose default is the chart appVersion ( |
`` |
|
Image sha (optional) |
`` |
|
Image pull policy |
|
|
Image pull secrets (can be templated) |
|
|
Enable grafana service |
|
|
Kubernetes service IP families |
|
|
Kubernetes service IP family policy |
|
|
Kubernetes service type |
|
|
Kubernetes port where service is exposed |
|
|
Name of the port on the service |
|
|
Adds the appProtocol field to the service |
`` |
|
Internal service is port |
|
|
Kubernetes service nodePort |
|
|
Service annotations (can be templated) |
|
|
Custom labels |
|
|
internal cluster service IP |
|
|
IP address to assign to load balancer (if supported) |
|
|
list of IP CIDRs allowed access to lb (if supported) |
|
|
service external IP addresses |
|
|
change the default externalTrafficPolicy |
|
|
Create a headless service |
|
|
Additional service ports for sidecar containers |
|
|
adds rules to the pod’s /etc/hosts |
|
|
Enables Ingress |
|
|
Ingress annotations (values are templated) |
|
|
Custom labels |
|
|
Ingress accepted path |
|
|
Ingress type of path |
|
|
Ingress accepted hostnames |
|
|
Ingress extra paths to prepend to every host configuration. Useful when configuring custom actions with AWS ALB Ingress Controller. Requires |
|
|
Ingress TLS configuration |
|
|
Ingress Class Name. MAY be required for Kubernetes versions >= 1.18 |
|
|
CPU/Memory resource requests/limits |
|
|
Node labels for pod assignment |
|
|
Toleration labels for pod assignment |
|
|
Affinity settings for pod assignment |
|
|
Init containers to add to the grafana pod |
|
|
Sidecar containers to add to the grafana pod |
|
|
Volumes that can be mounted in sidecar containers |
|
|
Custom labels for all manifests |
|
|
Name of the k8s scheduler (other than default) |
|
|
Use persistent volume to store data |
|
|
Type of persistence ( |
|
|
Size of persistent volume claim |
|
|
Use an existing PVC to persist data (can be templated) |
|
|
Type of persistent volume claim |
|
|
Persistence access modes |
|
|
PersistentVolumeClaim annotations |
|
|
PersistentVolumeClaim finalizers |
|
|
Extra labels to apply to a PVC. |
|
|
Mount a sub dir of the persistent volume (can be templated) |
|
|
If persistence is not enabled, whether to mount the local storage in-memory to improve performance |
|
|
SizeLimit for the in-memory local storage |
|
|
Hide NOTES warning, useful when persisting to a database |
|
|
If false, don’t reset data ownership at startup |
true |
|
init-chown-data container image registry |
|
|
init-chown-data container image repository |
|
|
init-chown-data container image tag |
|
|
init-chown-data container image sha (optional) |
|
|
init-chown-data container image pull policy |
|
|
init-chown-data pod resource requests & limits |
|
|
Alternate scheduler name |
|
|
Extra environment variables passed to pods |
|
|
Environment variables from alternate sources.[1] |
|
|
Name of a Kubernetes secret[2] |
|
|
List of Kubernetes secrets[2] |
|
|
List of Kubernetes ConfigMaps[2] |
|
|
Sensible environment variables passed to pods and stored as secret.[3] |
|
|
Inject Kubernetes services as environment variables. |
|
|
Additional grafana server secret mounts |
|
|
Additional grafana server volume mounts |
|
|
Additional Grafana server volumes |
|
|
Mounted the service account token on the grafana pod. Mandatory, if sidecars are enabled |
|
|
Enable creating the grafana configmap |
|
|
Additional grafana server configMap volume mounts (values are templated) |
|
|
Additional grafana server emptyDir volume mounts |
|
|
Plugins to be loaded along with Grafana |
|
|
Configure grafana datasources (passed through tpl) |
|
|
Configure grafana alerting (passed through tpl) |
|
|
Configure grafana notifiers |
|
|
Configure grafana dashboard providers |
|
|
Dashboards to import |
|
|
ConfigMaps reference that contains dashboards |
|
|
Grafana’s primary configuration |
|
|
Global image pull registry for all images. |
|
|
Global image pull secrets[4] |
|
|
Enable LDAP authentication |
|
|
The name of an existing secret containing the |
|
|
Grafana’s LDAP configuration |
|
|
Deployment annotations |
|
|
Deployment labels |
|
|
Pod annotations |
|
|
Pod labels |
|
|
Name of the grafana port on the pod |
|
|
Lifecycle hooks for podStart and preStop Example |
|
|
Sidecar image registry |
|
|
Sidecar image repository |
|
|
Sidecar image tag |
|
|
Sidecar image sha (optional) |
|
|
Sidecar image pull policy |
|
|
Sidecar resources |
|
|
Sidecar securityContext |
|
|
Sets the kiwigrid/k8s-sidecar UNIQUE_FILENAMES environment variable.[5] |
|
|
Enables the cluster wide search for alerts and adds/updates/deletes them in grafana |
|
|
Label that config maps with alerts should have to be added |
|
|
Label value that config maps with alerts should have to be added |
|
|
Namespaces list.[6] |
|
|
Method to use to detect ConfigMap changes.[7] |
|
|
Should the sidecar looks into secrets, configmaps or both. |
|
|
Full url of datasource configuration reload API endpoint, to invoke after a config-map change0 |
|
|
Enabling this omits defining the REQ_URL and REQ_METHOD environment variables |
|
|
Set to true to deploy the alerts sidecar as an initContainer.[8] |
|
|
Additional alerts sidecar volume mounts. |
|
|
Enables the cluster wide search for dashboards and adds/updates/deletes them in grafana |
|
|
Enables creation of sidecar provider |
|
|
Unique name of the grafana provider |
|
|
Id of the organisation, to which the dashboards should be added |
|
|
Logical folder in which grafana groups dashboards |
|
|
Allows you to specify the static UID for the logical folder above |
|
|
Activate to avoid the deletion of imported dashboards |
|
|
Allow updating provisioned dashboards from the UI |
|
|
Provider type |
|
|
Allow Grafana to replicate dashboard structure from filesystem. |
|
|
Method to use to detect ConfigMap changes.[7] |
|
|
Set to true to skip tls verification for kube api calls |
|
|
Label that config maps with dashboards should have to be added |
|
|
Label value that config maps with dashboards should have to be added |
|
|
Folder in the pod that should hold the collected dashboards[9] |
|
|
The annotation the sidecar will look for in configmaps |
|
|
The default folder name[9] |
|
|
Namespaces list.[6] |
|
|
Absolute path to shell script to execute after a configmap got reloaded. |
|
|
Full url of dashboards configuration reload API endpoint, to invoke after a config-map change |
|
|
Enabling this omits defining REQ_USERNAME, REQ_PASSWORD, REQ_URL and REQ_METHOD |
|
|
Should the sidecar looks into secrets, configmaps or both. |
|
|
Additional dashboard sidecar volume mounts. |
|
|
Enables the cluster wide search for datasources and adds/updates/deletes them in grafana |
|
|
Label that config maps with datasources should have to be added |
|
|
Label value that config maps with datasources should have to be added |
|
|
Namespaces list.[6] |
|
|
Method to use to detect ConfigMap changes.[7] |
|
|
Should the sidecar looks into secrets, configmaps or both. |
|
|
Full url of datasource configuration reload API endpoint, to invoke after a config-map change |
|
|
Enabling this omits defining the REQ_URL and REQ_METHOD environment variables |
|
|
Set to true to deploy the datasource sidecar[8] |
|
|
Enables the cluster wide search for notifiers and adds/updates/deletes them in grafana |
|
|
Label that config maps with notifiers should have to be added |
|
|
Label value that config maps with notifiers should have to be added |
|
|
Namespaces list.[6] |
|
|
Method to use to detect ConfigMap changes.[7] |
|
|
Should the sidecar looks into secrets, configmaps or both. |
|
|
Full url of notifier configuration reload API endpoint, to invoke after a config-map change |
|
|
Enabling this omits defining the REQ_URL and REQ_METHOD environment variables |
|
|
Set to true to deploy the notifier sidecar as an initContainer[8] |
|
|
The name of an existing secret containing the SMTP credentials. |
|
|
The key in the existing SMTP secret containing the username. |
|
|
The key in the existing SMTP secret containing the password. |
|
|
The name of an existing secret containing the admin credentials (can be templated). |
|
|
The key in the existing admin secret containing the username. |
|
|
The key in the existing admin secret containing the password. |
|
|
Automount the service account token |
|
|
ServiceAccount annotations |
|
|
Create service account |
|
|
ServiceAccount labels |
|
|
Service account name to use[10] |
`` |
|
Service account name to use for test[10] |
|
|
Create and use RBAC resources |
|
|
Creates Role and Rolebinding instead of the default ClusterRole and ClusterRoleBindings |
|
|
Set to a rolename to use existing role[11] |
|
|
Create PodSecurityPolicy (with |
|
|
Enforce AppArmor in created PodSecurityPolicy (requires |
|
|
Additional rules to add to the Role |
[] |
|
Additional rules to add to the ClusterRole |
[] |
|
Define command to be executed by grafana container at startup |
|
|
Define additional args if command is used |
|
|
Whether to create test-related resources |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Environment variables to be passed to the |
|
|
Name of a Kubernetes secret[2] |
|
|
Resources of |
|
|
Curl docker image registry |
|
|
Curl docker image repository |
|
|
Curl docker image tag |
|
|
Curl docker image sha (optional) |
|
|
Curl docker image pull policy |
|
|
Override the deployment namespace |
|
|
Use servicemonitor from prometheus operator |
|
|
Namespace this servicemonitor is installed in |
`` |
|
How frequently Prometheus should scrape |
|
|
Path to scrape |
|
|
Scheme to use for metrics scraping |
|
|
TLS configuration block for the endpoint |
|
|
Labels for the servicemonitor passed to Prometheus Operator |
|
|
Timeout after which the scrape is ended |
|
|
RelabelConfigs to apply to samples before scraping. |
|
|
MetricRelabelConfigs to apply to samples before ingestion. |
|
|
Number of old ReplicaSets to retain |
|
|
Enable the image-renderer deployment & service |
|
|
image-renderer Image registry |
|
|
image-renderer Image repository |
|
|
image-renderer Image tag |
|
|
image-renderer Image sha (optional) |
|
|
image-renderer ImagePullPolicy |
|
|
extra env-vars for image-renderer |
|
|
Environment variables for image-renderer from alternate sources.[1] |
|
|
Additional image-renderer configMap volume mounts (values are templated) |
|
|
Additional image-renderer secret volume mounts |
|
|
Additional image-renderer volume mounts |
|
|
Additional image-renderer volumes |
|
|
image-renderer deployment serviceAccountName |
|
|
image-renderer deployment securityContext |
|
|
image-renderer image-renderer pod annotation |
|
|
image-renderer deployment Host Aliases |
|
|
image-renderer deployment priority class |
|
|
Enable the image-renderer service |
|
|
image-renderer service port name |
|
|
image-renderer port used by deployment |
|
|
image-renderer service port used by service |
|
|
Adds the appProtocol field to the service |
`` |
|
Grafana sub path to use for image renderer callback url |
|
|
Remote image renderer url |
|
|
Callback url for the Grafana image renderer |
|
|
name of the image-renderer port on the pod |
|
|
number of image-renderer replica sets to keep |
|
|
Enable a NetworkPolicy to limit ingress |
|
|
Enable a NetworkPolicy to limit outbound traffic to only the created grafana pods |
|
|
Set resource limits for image-renderer pods |
|
|
Node labels for pod assignment |
|
|
Toleration labels for pod assignment |
|
|
Affinity settings for pod assignment |
|
|
Enable creation of NetworkPolicy resources. |
|
|
Don’t require client label for connections |
|
|
A Kubernetes LabelSelector[12] |
|
|
Enable the creation of an ingress network policy |
|
|
Enable the creation of an egress network policy |
|
|
An array of ports to allow for the egress |
|
|
Enable backward compatibility of kubernetes[13] |
|
Example ingress with path#
With grafana 6.3 and above
grafana.ini:
server:
domain: monitoring.example.com
root_url: "%(protocol)s://%(domain)s/grafana"
serve_from_sub_path: true
ingress:
enabled: true
hosts:
- "monitoring.example.com"
path: "/grafana"
Example of extraVolumeMounts and extraVolumes#
Configure additional volumes with extraVolumes
and volume mounts with extraVolumeMounts
.
Example for extraVolumeMounts
and corresponding extraVolumes
:
extraVolumeMounts:
- name: plugins
mountPath: /var/lib/grafana/plugins
subPath: configs/grafana/plugins
readOnly: false
- name: dashboards
mountPath: /var/lib/grafana/dashboards
hostPath: /usr/shared/grafana/dashboards
readOnly: false
extraVolumes:
- name: plugins
existingClaim: existing-grafana-claim
- name: dashboards
hostPath: /usr/shared/grafana/dashboards
Volumes default to emptyDir
. Set to persistentVolumeClaim
,
hostPath
, csi
, or configMap
for other types. For a
persistentVolumeClaim
, specify an existing claim name with
existingClaim
.
Import dashboards#
There are a few methods to import dashboards to Grafana. Below are some examples and explanations as to how to use each method:
dashboards:
default:
some-dashboard:
json:
{
"annotations":
...
# Complete json file here
...
"title": "Some Dashboard",
"uid": "abcd1234",
"version": 1
}
custom-dashboard:
# This is a path to a file inside the dashboards directory inside
# the chart directory
file: dashboards/custom-dashboard.json
prometheus-stats:
# Ref: https://grafana.com/dashboards/2
gnetId: 2
revision: 2
datasource: Prometheus
loki-dashboard-quick-search:
gnetId: 12019
revision: 2
datasource:
- name: DS_PROMETHEUS
value: Prometheus
- name: DS_LOKI
value: Loki
local-dashboard:
url: https://raw.githubusercontent.com/user/repository/master/dashboards/dashboard.json
BASE64 dashboards#
Dashboards could be stored on a server that does not return JSON directly and instead of it returns a Base64 encoded file (e.g. Gerrit) A new parameter has been added to the url use case so if you specify a b64content value equals to true after the url entry a Base64 decoding is applied before save the file to disk. If this entry is not set or is equals to false not decoding is applied to the file before saving it to disk.
Gerrit use case#
Gerrit API for download files has the following schema: https://yourgerritserver/a/{project-name}/branches/{branch-id}/files/{file-id}/content where {project-name} and {file-id} usually has ‘/’ in their values and so they MUST be replaced by %2F so if project-name is user/repo, branch-id is master and file-id is equals to dir1/dir2/dashboard the url value is https://yourgerritserver/a/user%2Frepo/branches/master/files/dir1%2Fdir2%2Fdashboard/content
Sidecar for dashboards#
If the parameter sidecar.dashboards.enabled
is set, a sidecar container is deployed in the grafana
pod. This container watches all configmaps (or secrets) in the cluster and filters out the ones with
a label as defined in sidecar.dashboards.label
. The files defined in those configmaps are written
to a folder and accessed by grafana. Changes to the configmaps are monitored and the imported
dashboards are deleted/updated.
A recommendation is to use one configmap per dashboard, as a reduction of multiple dashboards inside one configmap is currently not properly mirrored in grafana.
Example dashboard config:
apiVersion: v1
kind: ConfigMap
metadata:
name: sample-grafana-dashboard
labels:
grafana_dashboard: "1"
data:
k8s-dashboard.json: |-
[...]
Sidecar for datasources#
If the parameter sidecar.datasources.enabled
is set, an init container is deployed in the grafana
pod. This container lists all secrets (or configmaps, though not recommended) in the cluster and
filters out the ones with a label as defined in sidecar.datasources.label
. The files defined in
those secrets are written to a folder and accessed by grafana on startup. Using these yaml files,
the data sources in grafana can be imported.
Should you aim for reloading datasources in Grafana each time the config is
changed, set sidecar.datasources.skipReload: false
and adjust
sidecar.datasources.reloadURL
to
http://<svc-name>.<namespace>.svc.cluster.local/api/admin/provisioning/datasources/reload
.
Secrets are recommended over configmaps for this usecase because datasources usually contain private data like usernames and passwords. Secrets are the more appropriate cluster resource to manage those.
Example values to add a postgres datasource as a kubernetes secret:
apiVersion: v1
kind: Secret
metadata:
name: grafana-datasources
labels:
grafana_datasource: 'true' # default value for: sidecar.datasources.label
stringData:
pg-db.yaml: |-
apiVersion: 1
datasources:
- name: My pg db datasource
type: postgres
url: my-postgresql-db:5432
user: db-readonly-user
secureJsonData:
password: 'SUperSEcretPa$$word'
jsonData:
database: my_dataset
sslmode: 'disable' # disable/require/verify-ca/verify-full
maxOpenConns: 0 # Grafana v5.4+
maxIdleConns: 2 # Grafana v5.4+
connMaxLifetime: 14400 # Grafana v5.4+
postgresVersion: 1000 # 903=9.3, 904=9.4, 905=9.5, 906=9.6, 1000=10
timescaledb: false
# <bool> allow users to edit datasources from the UI.
editable: false
Example values to add a datasource adapted from Grafana:
datasources:
datasources.yaml:
apiVersion: 1
datasources:
# <string, required> name of the datasource. Required
- name: Graphite
# <string, required> datasource type. Required
type: graphite
# <string, required> access mode. proxy or direct (Server or Browser in the UI). Required
access: proxy
# <int> org id. will default to orgId 1 if not specified
orgId: 1
# <string> url
url: http://localhost:8080
# <string> database password, if used
password:
# <string> database user, if used
user:
# <string> database name, if used
database:
# <bool> enable/disable basic auth
basicAuth:
# <string> basic auth username
basicAuthUser:
# <string> basic auth password
basicAuthPassword:
# <bool> enable/disable with credentials headers
withCredentials:
# <bool> mark as default datasource. Max one per org
isDefault:
# <map> fields that will be converted to json and stored in json_data
jsonData:
graphiteVersion: "1.1"
tlsAuth: true
tlsAuthWithCACert: true
# <string> json object of data that will be encrypted.
secureJsonData:
tlsCACert: "..."
tlsClientCert: "..."
tlsClientKey: "..."
version: 1
# <bool> allow users to edit datasources from the UI.
editable: false
Sidecar for notifiers#
If the parameter sidecar.notifiers.enabled
is set, an init container is deployed in the grafana
pod. This container lists all secrets (or configmaps, though not recommended) in the cluster and
filters out the ones with a label as defined in sidecar.notifiers.label
. The files defined in
those secrets are written to a folder and accessed by grafana on startup. Using these yaml files,
the notification channels in grafana can be imported. The secrets must be created before
helm install
so that the notifiers init container can list the secrets.
Secrets are recommended over configmaps for this usecase because alert notification channels usually contain private data like SMTP usernames and passwords. Secrets are the more appropriate cluster resource to manage those.
Example datasource config adapted from Grafana:
notifiers:
- name: notification-channel-1
type: slack
uid: notifier1
# either
org_id: 2
# or
org_name: Main Org.
is_default: true
send_reminder: true
frequency: 1h
disable_resolve_message: false
# See `Supported Settings` section for settings supporter for each
# alert notification type.
settings:
recipient: 'XXX'
token: 'xoxb'
uploadImage: true
url: https://slack.com
delete_notifiers:
- name: notification-channel-1
uid: notifier1
org_id: 2
- name: notification-channel-2
# default org_id: 1
Sidecar for alerting resources#
If the parameter sidecar.alerts.enabled
is set, a sidecar container is
deployed in the grafana pod. This container watches all configmaps (or secrets)
in the cluster (namespace defined by sidecar.alerts.searchNamespace
) and
filters out the ones with a label as defined in sidecar.alerts.label
(default
is grafana_alert
). The files defined in those configmaps are written to a
folder and accessed by grafana. Changes to the configmaps are monitored and the
imported alerting resources are updated, however, deletions are a little
more complicated (see below).
This sidecar can be used to provision alert rules, contact points, notification policies, notification templates and mute timings as shown in Grafana Documentation.
To fetch the alert config which will be provisioned, use the alert provisioning API (Grafana Documentation). You can use either JSON or YAML format.
Example config for an alert rule:
apiVersion: v1
kind: ConfigMap
metadata:
name: sample-grafana-alert
labels:
grafana_alert: "1"
data:
k8s-alert.yml: |-
apiVersion: 1
groups:
- orgId: 1
name: k8s-alert
[...]
To delete provisioned alert rules is a two step process, you need to delete the configmap which defined the alert rule and then create a configuration which deletes the alert rule.
Example deletion configuration:
apiVersion: v1
kind: ConfigMap
metadata:
name: delete-sample-grafana-alert
namespace: monitoring
labels:
grafana_alert: "1"
data:
delete-k8s-alert.yml: |-
apiVersion: 1
deleteRules:
- orgId: 1
uid: 16624780-6564-45dc-825c-8bded4ad92d3
Statically provision alerting resources#
If you don’t need to change alerting resources (alert rules, contact points,
notification policies and notification templates) regularly you could use
the alerting
config option instead of the sidecar option above.
This will grab the alerting config and apply it statically at build time for
the helm file.
There are two methods to statically provision alerting configuration in Grafana. Below are some examples and explanations as to how to use each method:
alerting:
team1-alert-rules.yaml:
file: alerting/team1/rules.yaml
team2-alert-rules.yaml:
file: alerting/team2/rules.yaml
team3-alert-rules.yaml:
file: alerting/team3/rules.yaml
notification-policies.yaml:
file: alerting/shared/notification-policies.yaml
notification-templates.yaml:
file: alerting/shared/notification-templates.yaml
contactpoints.yaml:
apiVersion: 1
contactPoints:
- orgId: 1
name: Slack channel
receivers:
- uid: default-receiver
type: slack
settings:
# Webhook URL to be filled in
url: ""
# We need to escape double curly braces for the tpl function.
text: '{{ `{{ template "default.message" . }}` }}'
title: '{{ `{{ template "default.title" . }}` }}'
The two possibilities for static alerting resource provisioning are:
Inlining the file contents as shown for contact points in the above example.
Importing a file using a relative path starting from the chart root directory as shown for the alert rules in the above example.
Important notes on file provisioning#
The format of the files is defined in the Grafana documentation on file provisioning.
The chart supports importing YAML and JSON files.
The filename must be unique, otherwise one volume mount will overwrite the other.
In case of inlining, double curly braces that arise from the Grafana configuration format and are not intended as templates for the chart must be escaped.
The number of total files under
alerting:
is not limited. Each file will end up as a volume mount in the corresponding provisioning folder of the deployed Grafana instance.The file size for each import is limited by what the function
.Files.Get
can handle, which suffices for most cases.
How to serve Grafana with a path prefix (/grafana)#
In order to serve Grafana with a prefix (e.g., http://example.com/grafana), add the following to your values.yaml.
ingress:
enabled: true
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/rewrite-target: /$1
nginx.ingress.kubernetes.io/use-regex: "true"
path: /grafana/?(.*)
hosts:
- k8s.example.dev
grafana.ini:
server:
root_url: http://localhost:3000/grafana # this host can be localhost
How to securely reference secrets in grafana.ini#
This example uses Grafana
file providers
for secret values and the extraSecretMounts
configuration flag (Additional
grafana server secret mounts) to mount the secrets.
In grafana.ini:
grafana.ini:
[auth.generic_oauth]
enabled = true
client_id = $__file{/etc/secrets/auth_generic_oauth/client_id}
client_secret = $__file{/etc/secrets/auth_generic_oauth/client_secret}
Existing secret, or created along with helm:
Include in the extraSecretMounts
configuration flag:
extraSecretMounts:
- name: auth-generic-oauth-secret-mount
secretName: auth-generic-oauth-secret
defaultMode: 0440
mountPath: /etc/secrets/auth_generic_oauth
readOnly: true
extraSecretMounts using a Container Storage Interface (CSI) provider#
This example uses a CSI driver e.g. retrieving secrets using Azure Key Vault Provider
extraSecretMounts:
- name: secrets-store-inline
mountPath: /run/secrets
readOnly: true
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: "my-provider"
nodePublishSecretRef:
name: akv-creds
Image Renderer Plug-In#
This chart supports enabling remote image rendering
imageRenderer:
enabled: true
Image Renderer NetworkPolicy#
By default the image-renderer pods will have a network policy which only allows ingress traffic from the created grafana instance
High Availability for unified alerting#
If you want to run Grafana in a high availability cluster you need to enable
the headless service by setting headlessService: true
in your values.yaml
file.
As next step you have to setup the grafana.ini
in your values.yaml
in a way
that it will make use of the headless service to obtain all the IPs of the
cluster. You should replace {{ Name }}
with the name of your helm deployment.
grafana.ini:
...
unified_alerting:
enabled: true
ha_peers: {{ Name }}-headless:9094
ha_listen_address: ${POD_IP}:9094
ha_advertise_address: ${POD_IP}:9094
alerting:
enabled: false