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/Chart.yaml

@@ -14,27 +14,35 @@
 # master d'une vidéo reste sur l'appareil de son propriétaire — ADR-018 du front) ;
 # la redondance de Longhorn suffit, l'erasure coding distribué de MinIO coûterait
 # de la RAM et des IOPS que des Pi n'ont pas à dépenser pour ça.
+#
+# ⚠⚠ CE CHART EST AUTONOME DEPUIS LE 2026-09-02, ET CE N'EST PAS UN CAPRICE.
+# Il dépendait du sous-chart officiel `minio/minio` 5.4.0. Ce chart N'OFFRE
+# AUCUNE SONDE DE SANTÉ — vérifié sur toutes ses versions publiées, la 5.4.0
+# étant la dernière : pas une clé `livenessProbe` dans ses valeurs, pas un rendu
+# de sonde dans ses templates. MinIO tournait donc sans le moindre contrôle, et
+# une panne totale de trois jours est passée inaperçue (arcodange-org/tools#31).
+#
+# 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 — huit objets,
+# tous dans templates/, chacun commenté avec ce qu'il reprend à l'identique et
+# ce qu'il change délibérément.
+#
+# CE QU'ON REPREND À NOTRE CHARGE, ET QU'IL FAUT DONC SUIVRE À LA MAIN : le
+# `tag` de l'image (values.yaml), qui n'est plus tiré par la version du chart.
 # -----------------------------------------------------------------------------
 apiVersion: v2
 name: minio
-description: A Helm chart for Kubernetes
+description: Stockage objet S3 du homelab — manifestes rendus ici, sans sous-chart.
 
-dependencies:
-- name: tool
-  version: 0.1.0
-  repository: https://gitea.arcodange.lab/api/packages/arcodange-org/helm
-- name: minio
-  version: 5.4.0
-  repository: https://charts.min.io/
+# ⚠ Plus AUCUNE dépendance, et c'est délibéré :
+# - `minio/minio` 5.4.0 est parti pour la raison ci-dessus ;
+# - la bibliothèque `tool` n'était utilisée que par templates/helm-chart*.yaml,
+#   deux fichiers inertes (gardés par `tool.kind == "HelmChart"`, jamais vrai
+#   ici) supprimés dans le même passage.
+# Effet de bord bienvenu : la synchronisation ArgoCD ne dépend plus de deux
+# dépôts Helm distants — un point de panne en moins sur le stockage objet.
+dependencies: []
 
-# A chart can be either an 'application' or a 'library' chart.
-#
-# Application charts are a collection of templates that can be packaged into versioned archives
-# to be deployed.
-#
-# Library charts provide useful utilities or functions for the chart developer. They're included as
-# a dependency of application charts to inject those utilities and functions into the rendering
-# pipeline. Library charts do not define any templates and therefore cannot be deployed.
 type: application
-version: 0.1.0
-appVersion: "latest"
+version: 0.2.0
+appVersion: "RELEASE.2024-12-18T13-15-44Z"