fix(grafana): startupProbe + liveness grace pour les migrations SQLite

Grafana tourne en SQLite sur emptyDir → migration complète du schéma à chaque démarrage de pod, > 160 s sur Raspberry Pi. La liveson (initialDelay 60 + 10×10s) tuait Grafana en pleine migration → CrashLoop du nouveau pod à chaque rollout (révélé par le rollout du dashboard prospection). Ajoute une startupProbe (~10 min) et relève failureThreshold de la liveness (filet si le chart n'expose pas startupProbe). Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-07-08 20:14:56 +02:00
parent e9998e3b48
commit e419cb6307
1 changed files with 14 additions and 1 deletions
@@ -69,13 +69,26 @@ grafana: &grafana_config
      path: /api/health
      port: 3000

+  # Base Grafana en SQLite sur emptyDir → migration complète du schéma à CHAQUE démarrage du
+  # pod, lente sur Raspberry Pi (> 160 s). Sans garde suffisante, la liveness tuait Grafana en
+  # pleine migration → CrashLoop au moindre rollout. startupProbe : ~10 min avant d'armer la
+  # liveness. failureThreshold de liveness relevé aussi (filet de sécurité si le chart n'expose
+  # pas startupProbe). Fix pérenne : DB persistante (PVC) ou externe (postgres) — hors scope ici.
+  startupProbe:
+    httpGet:
+      path: /api/health
+      port: 3000
+    initialDelaySeconds: 30
+    periodSeconds: 10
+    failureThreshold: 60
+
  livenessProbe:
    httpGet:
      path: /api/health
      port: 3000
    initialDelaySeconds: 60
    timeoutSeconds: 30
-    failureThreshold: 10
+    failureThreshold: 60

  ## Use an alternate scheduler, e.g. "stork".
  ## ref: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/