Sur Kubernetes, le chart Helm de Grafana transforme les dossiers de provisionnement en configuration que vous écrivez dans values.yaml. Le chart génère des ConfigMaps et des Secrets, les monte aux chemins attendus par Grafana, et redémarre ou recharge quand ils changent. Cela fait de Grafana un bon candidat pour le GitOps, puisque le fichier de valeurs est la seule chose que vous modifiez. Ce guide construit un fichier de valeurs qui provisionne une source de données, des tableaux de bord, l’alerting et les paramètres du serveur.

L’hébergement des charts évolue : certains charts de Grafana Labs migrent vers un dépôt maintenu par la communauté. Avant d’installer, consultez le README du chart pour connaître l’URL du dépôt et la version du chart à utiliser, et épinglez cette version. Les clés de valeurs ci-dessous suivent la structure documentée du chart, mais confirmez-les dans le values.yaml de la version que vous installez.

Installer

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm install grafana grafana/grafana \
  --namespace monitoring --create-namespace \
  --version <chart-version> \
  -f values.yaml

Si le chart a déménagé, remplacez l’URL du dépôt par celle du README. Gardez la commande, le --version et le fichier de valeurs dans Git pour que l’installation soit reproductible.

Paramètres du serveur : grafana.ini

Tout ce que vous mettriez dans grafana.ini va sous la clé grafana.ini, organisé par section :

grafana.ini:
  server:
    root_url: https://grafana.example.com/
  users:
    allow_sign_up: false
  analytics:
    reporting_enabled: false
    check_for_updates: false
  log:
    mode: console

Les valeurs qui ne doivent pas être commitées peuvent référencer des variables d’environnement ou des fichiers, comme dans le guide de configuration (par exemple password: $__file{/etc/secrets/db/password}).

Identifiants admin et autres secrets

Utilisez un Secret Kubernetes existant plutôt qu’un mot de passe dans les valeurs :

admin:
  existingSecret: grafana-admin
  userKey: admin-user
  passwordKey: admin-password

envFromSecret: grafana-secrets   # chaque clé devient une variable d'environnement

apiVersion: v1
kind: Secret
metadata:
  name: grafana-secrets
  namespace: monitoring
stringData:
  POSTGRES_PASSWORD: change-me
  SLACK_WEBHOOK_URL: https://hooks.slack.com/services/XXX/YYY/ZZZ

Les fichiers de provisionnement peuvent alors utiliser $POSTGRES_PASSWORD et ${SLACK_WEBHOOK_URL}. Chiffrez le Secret avec SOPS ou synchronisez-le avec External Secrets plutôt que de le commiter en YAML brut (voir le guide sur les secrets).

Sources de données

La clé datasources est transformée en fichier de provisionnement :

datasources:
  datasources.yaml:
    apiVersion: 1
    datasources:
      - name: Prometheus
        uid: prometheus
        type: prometheus
        access: proxy
        url: http://prometheus-server.monitoring.svc.cluster.local
        isDefault: true
        editable: false

Tableaux de bord : trois façons

1. En ligne, depuis des fichiers du dossier du chart. Déclarez un fournisseur et listez les tableaux de bord par source :

dashboardProviders:
  dashboardproviders.yaml:
    apiVersion: 1
    providers:
      - name: default
        orgId: 1
        folder: ''
        type: file
        disableDeletion: false
        allowUiUpdates: false
        options:
          path: /var/lib/grafana/dashboards/default

dashboards:
  default:
    node-exporter:
      gnetId: 1860
      revision: 37
      datasource: Prometheus
    kubernetes-overview:
      json: |
        { "uid": "k8s-overview", "title": "Kubernetes Overview", "panels": [] }

Les entrées peuvent provenir de grafana.com (gnetId et revision), d’une URL, ou de JSON en ligne. La clé sous dashboards (ici default) doit correspondre au nom du dossier options.path du fournisseur.

2. Depuis des ConfigMaps que vous gérez vous-même. Gardez le JSON des tableaux de bord dans leurs propres ConfigMaps (par exemple générées par Kustomize depuis le dépôt) et montez-les :

dashboardsConfigMaps:
  default: grafana-dashboards

3. Avec le sidecar. Un conteneur sidecar surveille le cluster à la recherche de ConfigMaps (ou de Secrets) portant un label et les charge comme tableaux de bord ; chaque équipe applicative peut ainsi livrer son propre tableau de bord à côté de ses manifestes :

sidecar:
  dashboards:
    enabled: true
    label: grafana_dashboard
    labelValue: "1"
    searchNamespace: ALL
    folderAnnotation: grafana_folder
    provider:
      foldersFromFilesStructure: true
  datasources:
    enabled: true
    label: grafana_datasource
  alerts:
    enabled: true
    label: grafana_alert

apiVersion: v1
kind: ConfigMap
metadata:
  name: webapp-dashboard
  namespace: webapp
  labels:
    grafana_dashboard: "1"
  annotations:
    grafana_folder: Applications
data:
  webapp.json: |
    { "uid": "webapp-overview", "title": "Webapp Overview", "panels": [] }

L’approche sidecar passe le mieux à l’échelle entre équipes : personne n’a besoin de modifier les valeurs de Grafana pour ajouter un tableau de bord.

Alerting

Les fichiers de provisionnement de l’alerting peuvent provenir de la clé alerting, en utilisant les formats YAML du guide sur l’alerting :

alerting:
  contactpoints.yaml:
    secret:
      apiVersion: 1
      contactPoints:
        - orgId: 1
          name: team-slack
          receivers:
            - uid: team-slack-1
              type: slack
              settings:
                url: ${SLACK_WEBHOOK_URL}
                recipient: '#alerts'
  policies.yaml:
    apiVersion: 1
    policies:
      - orgId: 1
        receiver: team-slack

L’enveloppe secret: place ce fichier dans un Secret plutôt que dans une ConfigMap. Consultez le values.yaml du chart pour la forme exacte dans votre version. Les règles d’alerte peuvent provenir de la même clé ou du paramètre alerts du sidecar.

Persistance et réplicas

persistence:
  enabled: true
  size: 5Gi
replicas: 1

SQLite sur un volume persistant ne prend en charge qu’un seul réplica. Pour la haute disponibilité, pointez Grafana vers PostgreSQL via grafana.ini et augmentez replicas.

Déployer avec Flux

Si vous utilisez Flux, le chart devient une HelmRelease, et les valeurs ci-dessus vont dans spec.values :

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: grafana
  namespace: monitoring
spec:
  interval: 10m
  chart:
    spec:
      chart: grafana
      version: "<chart-version>"
      sourceRef:
        kind: HelmRepository
        name: grafana
        namespace: flux-system
  valuesFrom:
    - kind: ConfigMap
      name: grafana-values

Un changement des valeurs dans Git déploie automatiquement la modification. Consultez le guide Helm de la série Flux pour HelmRepository, la remédiation et la détection de dérive.

Vérifier

kubectl get pods -n monitoring
kubectl port-forward svc/grafana 3000:80 -n monitoring &
curl -s http://localhost:3000/api/health
kubectl logs deploy/grafana -n monitoring -c grafana | grep -i provisioning

Si un tableau de bord ou une source de données manque, consultez d’abord les lignes de log de provisionnement, puis les logs du sidecar (-c grafana-sc-dashboard) pour détecter des problèmes de label ou de namespace.