Ce qu'un pod a dit lui survit — Loki et Alloy, sous plafond (#38)

Le cluster n'avait AUCUNE collecte de journaux : la seule lecture possible
était `kubectl logs`, c'est-à-dire le tampon du kubelet, qui tourne. Mesuré
le 2026-09-07 en demandant à chaque journal jusqu'où il remonte :

  kube-system/traefik   pod démarré il y a 12 j — journal remontant à 10 MIN
  tools/clickhouse-0    pod démarré il y a  8 j — journal remontant à  2 MIN

Les deux composants les plus bavards du cluster gardent entre deux et dix
minutes d'histoire. C'est pire que ce que l'issue supposait.

Ce lot pose Loki (binaire unique, stockage fichier sur Longhorn) et Alloy
(l'agent, un pod par nœud), et branche la source de données au Grafana qui
tourne déjà.

L'AGENT : Alloy, pas Promtail — et c'est mesuré, pas une préférence. L'index
Helm de Grafana marque le chart `promtail` `deprecated: true`, dernière
publication 2025-10-31. Alloy : 2026-08-27. On n'installe pas à neuf un agent
que l'amont a déjà rangé.

LA RÉTENTION : 30 jours, sur un débit mesuré de ~305 Mio/jour bruts pour tout
le cluster, soit 0,9 à 1,8 Gio compressés. 7 jours auraient perdu le début des
deux pannes qui motivent ce lot (kadans#1033, des SEMAINES ; tools#36, 3 jours).

LES PLAFONDS NE SONT PAS OPTIONNELS : pi2 est mesuré à 108 % de sa mémoire
allouable. Les défauts amont du chart Loki y auraient posé un memcached
réclamant 8 Gio (`chunksCache.allocatedMemory: 8192`), un second memcached, un
nginx, un DaemonSet canari et trois jeux de répliques. Chaque extinction est
nommée dans `loki/values.yaml`, avec sa raison.

⚠ La CI de ce dépôt monte une matrice CODÉE EN DUR : un chart absent de la
liste n'est jamais construit et sa PR est verte quand même (tools#32). `loki`
et `alloy` y sont ajoutés — sans ça, ce lot n'aurait aucune preuve.

Deux découvertes faites en déployant, pas en lisant :
  - `admin_api_directory` est accepté par le chart mais REFUSÉ par le binaire
    OSS (champ d'édition entreprise) : CrashLoopBackOff jusqu'à ce qu'on l'ôte ;
  - le chart ajoute un side-car `loki-sc-rules` SANS aucune limite de
    ressources — un conteneur non plafonné dans un pod plafonné annule le
    plafond. Éteint (le ruler est à 0 réplique).

Closes #38

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Fable 5.1 <[email protected]>

loki/Chart.yaml

@@ -0,0 +1,35 @@
+apiVersion: v2
+name: loki
+description: >-
+  Le garde-mémoire des journaux du cluster — Loki en binaire unique, stockage
+  fichier sur Longhorn. Ce qu'un pod a dit continue de se lire après sa mort.
+
+# ⚠ PAS de dépendance au registre Helm interne, CONTRAIREMENT à grafana et
+# prometheus — et c'est délibéré.
+#
+# La bibliothèque `tool` ne sert QUE via les gabarits `templates/helm-chart*.yaml`,
+# eux-mêmes gardés par `{{- if eq .Values.tool.kind "HelmChart" -}}`. Avec
+# `kind: SubChart` — le mode de grafana, de prometheus, et le nôtre — ces
+# gabarits ne rendent RIEN : la bibliothèque est un poids mort.
+#
+# Or ce poids mort a un coût mesuré : le runner de CI ne résout pas
+# `gitea.arcodange.lab` (relevé du 2026-09-07, run 6728, `curl` code 6). Un
+# repli sur `GITHUB_SERVER_URL` a été posé dans `helmcharts.yaml`, mais il reste
+# un point de panne EN AMONT du `helm template`. Si la dépendance ne se
+# télécharge pas, l'étape qui éprouve VRAIMENT ce chart ne s'exécute jamais et
+# le job meurt sur une cause étrangère au chart.
+#
+# On ne dépend donc que de `grafana.github.io`, dont le même relevé a constaté
+# qu'il répond depuis ce runner. Le jour où l'on veut basculer en
+# `kind: HelmChart` (CRD k3s), on rajoute la dépendance ET les deux gabarits.
+dependencies:
+  - name: loki
+    version: 7.3.0
+    repository: https://grafana.github.io/helm-charts
+
+type: application
+version: 0.1.0
+# ⚠ 3.6.11, PAS 3.6.12. L'index Helm annonce `appVersion: 3.6.12` pour le chart
+# 7.3.0, mais le chart épingle `loki.image.tag: 3.6.11` dans ses valeurs — et
+# c'est le tag qui est tiré. Vérifié sur le pod déployé.
+appVersion: "3.6.11"