Prometheus quitte pi1 pour pi3 : son volume y avait perdu son journal ext4 le même jour que MinIO

Le 14/09 à 05:16Z, le volume `prometheus-server` (moteur sur pi1, une
réplique sur pi2 saturé en mémoire) a vu ext4 abandonner son journal et
remonter en lecture seule. Prometheus a échoué à écrire son WAL pendant
27 h, puis panique en boucle (« Unable to create mmap-ed active query
log ») depuis que la sonde de vivacité l'a redémarré. Un redémarrage de
conteneur ne démonte pas le volume.

Affinité requise `NotIn [pi2]` et préférence forte pour pi3 : recréé sur
un autre nœud, le volume est détaché puis rattaché, et ext4 rejoue son
journal. Sur le même nœud, le pod neuf pourrait réutiliser le montage de
staging mort.

Refs arcodange-org/tools#49

Co-Authored-By: Claude Opus 5 <[email protected]>

prometheus/values.yaml

@@ -493,7 +493,37 @@ prometheus: &prometheus_config
 
     ## Pod affinity
     ##
-    affinity: {}
+    # ---------------------------------------------------------------
+    # ⚠⚠ JAMAIS SUR pi2, ET LE RECRÉER AILLEURS QUE SUR LE NŒUD DU MONTAGE MORT
+    # (incident arcodange-org/tools#49, 2026-09-14 → 15).
+    #
+    # Le 14/09 à 05:16Z, le volume `prometheus-server` (moteur sur pi1, une
+    # réplique sur pi2 à ~110 % de mémoire) a vu son journal ext4 ABANDONNÉ :
+    # système de fichiers remonté en lecture seule, `write to WAL: input/output
+    # error` pendant 27 h, puis `panic: Unable to create mmap-ed active query
+    # log` en boucle. Un redémarrage de conteneur ne démonte PAS le volume.
+    #
+    # Même mécanisme que MinIO (#50). La préférence pour pi3 n'est pas
+    # décorative : avec `Recreate`, un pod recréé sur le MÊME nœud peut
+    # réutiliser le montage de staging encore en place (le nouveau pod arrive
+    # dès que l'ancien est terminal, avant le démontage) — et donc le montage
+    # mort. Un autre nœud force détachement, rattachement et rejeu du journal.
+    # ---------------------------------------------------------------
+    affinity:
+      nodeAffinity:
+        requiredDuringSchedulingIgnoredDuringExecution:
+          nodeSelectorTerms:
+            - matchExpressions:
+                - key: kubernetes.io/hostname
+                  operator: NotIn
+                  values: [pi2]
+        preferredDuringSchedulingIgnoredDuringExecution:
+          - weight: 100
+            preference:
+              matchExpressions:
+                - key: kubernetes.io/hostname
+                  operator: In
+                  values: [pi3]
 
     ## Pod anti-affinity can prevent the scheduler from placing Prometheus server replicas on the same node.
     ## The value "soft" means that the scheduler should *prefer* to not schedule two replica pods onto the same node but no guarantee is provided.