MinIO tournait sans une seule sonde — trois jours de panne invisible

Le 29 août à 17 h 54, ext4 a abandonné son journal sous MinIO
(`comm minio: Detected aborted journal`), après que les répliques Longhorn
se soient perdues de vue sur le réseau. Toute écriture rendait `EIO`.

Longhorn s'est rétabli TOUT SEUL le 30 août à 11 h 50. Mais un journal ext4
abandonné ne se répare jamais seul : il le reste jusqu'au démontage. MinIO est
donc resté assis sur un montage mort DEUX JOURS APRÈS la réparation du
stockage, pendant que Longhorn (`healthy`), les répliques (`RW`), les nœuds,
ArgoCD (`Synced, Healthy`) et le pod (`1/1 Running`, `0 restart`) affichaient
tous vert. Le remède a été un `scale --replicas=0` : « insufficient » dans les
journaux, 6126 → 0.

Le pod ne redémarre pas quand son système de fichiers meurt : le processus
vit, et c'est tout ce que Kubernetes regardait — faute de sonde.

⚠⚠ Et ce n'était pas un oubli de configuration : LE CHART OFFICIEL
`minio/minio` N'OFFRE AUCUNE SONDE, dans aucune de ses versions (5.4.0 est la
dernière). Pas une clé `livenessProbe` dans ses valeurs, pas un rendu de sonde
dans ses templates. Il n'existe aucun moyen de greffer une sonde sur le
Deployment d'un sous-chart depuis un chart parent : on rend donc les
manifestes nous-mêmes.

SABOTAGE RELEVÉ (MinIO jetable, quatre disques, LES DEUX MOITIÉS DANS LE MÊME
POD, même image) :

  | état du magasin         | /health/live | /health/cluster |
  |-------------------------|--------------|-----------------|
  | 4 disques sains         |     200      |     **200**     |
  | quorum d'écriture perdu |   **200**    |     **503**     |

`format.json` de deux disques sur quatre écrasé ; bascule de `cluster` entre
t+20 s et t+40 s ; `live` n'a JAMAIS bougé. C'est exactement pourquoi la panne
était invisible — et pourquoi la sonde vise `cluster`, pas `live`.

Ce que le lot change d'autre, délibérément :
- `RollingUpdate (maxSurge 100%)` → `Recreate` : le volume est ReadWriteOnce,
  un roulement laissait le second pod en `Multi-Attach error` jusqu'au timeout
- `MINIO_PROMETHEUS_AUTH_TYPE` était déclaré DEUX FOIS (kubectl le signalait à
  chaque application)
- le `post-job` et son ConfigMap de 25 Ko disparaissent : `buckets` était vide
  et le ConfigMap n'était monté par AUCUN conteneur (vérifié sur le Deployment
  vivant avant de le retirer)
- plus aucune dépendance Helm : un point de panne distant en moins sur le
  chemin de synchronisation du stockage objet

⚠ Le PVC est l'objet dangereux de ce lot : ne pas le rendre ici l'aurait fait
ÉLAGUER par ArgoCD, avec les vidéos dedans. Il est rendu à l'identique (son
`spec` ne bouge pas d'un champ, vérifié par `kubectl diff`), sans `volumeName`
— que le contrôleur pose lui-même — et porte `Prune=false` en ceinture.

Vérifications, codes relevés :
- `helm template` : code 0, 10 objets (les 11 d'ArgoCD moins le ConfigMap)
- `kubectl apply --dry-run=server` : code 0, les 10 en `configured`, aucun en
  `created`, aucune violation de champ immuable
- `kubectl diff` : le `spec` du PVC intact, les `selector` et ports des deux
  Services identiques

Refs: arcodange-org/tools#31

minio/templates/pvc.yaml

@@ -0,0 +1,39 @@
+# -----------------------------------------------------------------------------
+# Le volume de données. ⚠⚠ C'EST L'OBJET LE PLUS DANGEREUX DE CE LOT.
+#
+# Il était rendu par le sous-chart `minio/minio`. En reprenant les manifestes à
+# notre charge, si on avait OUBLIÉ de le rendre ici, ArgoCD l'aurait ÉLAGUÉ —
+# c'est-à-dire supprimé, avec les vidéos dedans.
+#
+# ⚠ `volumeName` n'est VOLONTAIREMENT pas déclaré : c'est le contrôleur qui
+# pose ce champ à la liaison. ArgoCD ignore ce qui existe en vie sans être
+# déclaré, donc la liaison actuelle (pvc-ebb2605f-…) survit ; et le figer ici
+# empêcherait toute recréation future de se lier à un autre volume.
+#
+# ⚠ La plupart des champs d'un PVC sont IMMUABLES. Ce fichier reproduit à
+# l'identique ce que le sous-chart avait posé — le modifier n'aurait pas l'effet
+# qu'on croit, il ferait échouer l'application.
+# -----------------------------------------------------------------------------
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: minio
+  namespace: tools
+  labels:
+    app: minio
+    release: minio
+  annotations:
+    # Ceinture ET bretelles : même si ce manifeste disparaissait un jour du
+    # dépôt, ArgoCD ne supprimerait pas le volume de lui-même.
+    argocd.argoproj.io/sync-options: Prune=false
+spec:
+  accessModes:
+    - ReadWriteOnce
+  storageClassName: {{ .Values.minio.persistence.storageClass }}
+  volumeMode: Filesystem
+  resources:
+    requests:
+      # 50 Gi ≈ 250 heures de cours au palier « travail » de Kadans (360p,
+      # 3,4 Mo/min — ADR-018 du front). Longhorn réplique ce volume sur les
+      # nœuds : compter ×3 sur la capacité du cluster avant d'augmenter.
+      storage: {{ .Values.minio.persistence.size }}