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 (R/W Timeout. No response received in 8s). À partir de là, 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 lui-même (1/1 Running, 0 restart) affichaient tous vert.
Le pod ne redémarre pas quand son système de fichiers meurt. Le processus vit ; c'est tout ce que Kubernetes regardait, faute de sonde.
Réparé par un scale --replicas=0 (« insufficient » dans les journaux : 6126 → 0), zéro donnée perdue.
⚠⚠ Pourquoi ce lot réécrit les manifestes au lieu d'ajouter trois lignes de valeurs
Le chart officiel minio/minio n'offre AUCUNE sonde — vérifié sur la 5.4.0, qui est la dernière publiée : pas une clé livenessProbe dans ses valeurs, pas un rendu de sonde dans ses templates. Ce n'était donc pas un oubli de configuration ; il n'y avait rien à configurer.
Et il n'existe aucun moyen de greffer une sonde sur le Deployment d'un sous-chart depuis un chart parent. D'où l'option retenue : rendre les manifestes nous-mêmes, huit objets dans templates/.
Le 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
Sabotage : format.json de deux disques sur quatre écrasé. Bascule de cluster entre t+20 s et t+40 s ; liven'a jamais bougé.
C'est exactement pourquoi la panne était invisible — et pourquoi la sonde vise cluster, jamais live.
⚠ failureThreshold: 6 × 30 s = 3 minutes de refus soutenu avant redémarrage. Cette grappe connaît des à-coups Longhorn de quelques secondes (le déclencheur du 29 août était un timeout de 8 s) : une sonde nerveuse redémarrerait MinIO sur un hoquet. C'est l'erreur exacte que redis a payée ici en juillet — 836 échecs de sonde, 135 redémarrages, et un .fr en 403.
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 — sans volumeName (que le contrôleur pose lui-même, et que figer empêcherait toute recréation future de se lier), et porte Prune=false en ceinture.
Vérifications, codes relevés
contrôle
résultat
helm template
code 0, 10 objets — les 11 d'ArgoCD moins le ConfigMap retiré
kubectl apply --dry-run=server
code 0, les 10 en configured, aucun en created, aucune violation de champ immuable
kubectl diff — PVC
spec intact : ni volumeName, ni taille, ni accessModes
kubectl diff — Services
selector et ports identiques sur minio et minio-console
parcours de bout en bout
GUI kadans.arcodange.fr → import → octets dans le seau → retour galerie : 1 passed, code 0
⚠ Le .helmignore ajouté n'est pas cosmétique : sans lui, helm template minio/échoue sur un poste où le Terraform a été initialisé (binaire de provider > 5 Mo). ArgoCD ne le voyait pas — .terraform est gitignoré — donc le défaut ne se manifestait qu'à la relecture locale, c'est-à-dire au pire moment.
⚠ Ce que ce lot NE règle PAS
La cause première. Le déclencheur est un timeout réseau entre répliques Longhorn, pas un disque. sdb avait rendu 10 critical medium error identiques le 15 août : c'est un motif qui se répète. Et sur pi2, ls et cat expirent après 4 s dans les sondes Longhorn (engine-image : 142 redémarrages). Ce lot rend la prochaine occurrence visible et auto-réparée en 3 minutes ; il ne l'empêche pas. Le reste de #31 le suit.
⚠ Nouveau à notre charge : le tag de l'image ne suit plus la version du chart. À relever à la main lors des mises à jour (noté dans values.yaml).
Ferme la moitié « observabilité » de #31.
## Ce qui s'est passé
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 (`R/W Timeout. No response received in 8s`). À partir de là, 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 lui-même (`1/1 Running`, `0 restart`) affichaient **tous vert**.
> **Le pod ne redémarre pas quand son système de fichiers meurt.** Le processus vit ; c'est tout ce que Kubernetes regardait, faute de sonde.
Réparé par un `scale --replicas=0` (« insufficient » dans les journaux : **6126 → 0**), zéro donnée perdue.
## ⚠⚠ Pourquoi ce lot réécrit les manifestes au lieu d'ajouter trois lignes de valeurs
**Le chart officiel `minio/minio` n'offre AUCUNE sonde** — vérifié sur la 5.4.0, qui est la dernière publiée : pas une clé `livenessProbe` dans ses valeurs, pas un rendu de sonde dans ses templates. Ce n'était donc pas un oubli de configuration ; il n'y avait **rien à configurer**.
Et il n'existe aucun moyen de greffer une sonde sur le Deployment d'un sous-chart depuis un chart parent. D'où l'option retenue : **rendre les manifestes nous-mêmes**, huit objets dans `templates/`.
## Le 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** |
Sabotage : `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`, jamais `live`.
⚠ `failureThreshold: 6 × 30 s` = **3 minutes de refus soutenu** avant redémarrage. Cette grappe connaît des à-coups Longhorn de quelques secondes (le déclencheur du 29 août était un timeout de 8 s) : une sonde nerveuse redémarrerait MinIO sur un hoquet. C'est l'erreur exacte que redis a payée ici en juillet — 836 échecs de sonde, 135 redémarrages, et un `.fr` en 403.
## 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 — **sans `volumeName`** (que le contrôleur pose lui-même, et que figer empêcherait toute recréation future de se lier), et porte `Prune=false` en ceinture.
## Vérifications, codes relevés
| contrôle | résultat |
|---|---|
| `helm template` | **code 0**, 10 objets — les 11 d'ArgoCD moins le ConfigMap retiré |
| `kubectl apply --dry-run=server` | **code 0**, les 10 en `configured`, **aucun en `created`**, aucune violation de champ immuable |
| `kubectl diff` — PVC | **`spec` intact** : ni `volumeName`, ni taille, ni `accessModes` |
| `kubectl diff` — Services | `selector` et ports **identiques** sur `minio` et `minio-console` |
| parcours de bout en bout | GUI `kadans.arcodange.fr` → import → **octets dans le seau** → retour galerie : `1 passed`, code 0 |
⚠ Le `.helmignore` ajouté n'est pas cosmétique : sans lui, `helm template minio/` **échoue** sur un poste où le Terraform a été initialisé (binaire de provider > 5 Mo). ArgoCD ne le voyait pas — `.terraform` est gitignoré — donc le défaut ne se manifestait qu'à la relecture locale, c'est-à-dire au pire moment.
## ⚠ Ce que ce lot NE règle PAS
**La cause première.** Le déclencheur est un timeout réseau entre répliques Longhorn, pas un disque. `sdb` avait rendu 10 `critical medium error` identiques le 15 août : **c'est un motif qui se répète.** Et sur pi2, `ls` et `cat` expirent après 4 s dans les sondes Longhorn (`engine-image` : 142 redémarrages). Ce lot rend la prochaine occurrence **visible et auto-réparée en 3 minutes** ; il ne l'empêche pas. Le reste de #31 le suit.
⚠ Nouveau à notre charge : le **tag de l'image** ne suit plus la version du chart. À relever à la main lors des mises à jour (noté dans `values.yaml`).
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
Trouvé en refusant de lire le vert de cette PR : elle réécrit le chart `minio`
en entier, et la CI a rendu `success` avec « Detect changed charts » ✓ et les
deux jobs de construction en `Skipped`. Aucun job `Application charts minio`
n'existait.
La cause : Gitea ne sait pas monter une matrice DYNAMIQUE, donc la matrice est
codée en dur — `chart: [tool]` et `chart: [pgcat]`. Le job `filter-chart`
calcule POURTANT la bonne réponse ; personne ne la consomme. Le `if:` vérifie
seulement si le chart codé en dur figure dans la liste détectée.
Résultat mesuré : 10 charts dans le dépôt, 2 constructibles. `minio`, `redis`,
`crowdsec`, `hashicorp-vault`, `grafana`, `prometheus`, `pgbouncer` et `chart`
ne passaient sous aucun `helm template`, et toute PR qui les touchait affichait
vert.
Le remède ne demande PAS de matrice dynamique : le `if:` filtre déjà sur la
sortie du détecteur, donc un chart non modifié reste `Skipped`. Il ne manquait
que l'ÉNUMÉRATION — les neuf applicatifs sont désormais listés.
⚠ Le mode d'échec de ce fichier est maintenant écrit dedans : ajouter un chart
au dépôt sans l'ajouter à la liste le rend invisible à la CI, en silence.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ferme la moitié « observabilité » de #31.
Ce qui s'est passé
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 (R/W Timeout. No response received in 8s). À partir de là, toute écriture rendaitEIO.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 lui-même (1/1 Running,0 restart) affichaient tous vert.Réparé par un
scale --replicas=0(« insufficient » dans les journaux : 6126 → 0), zéro donnée perdue.⚠⚠ Pourquoi ce lot réécrit les manifestes au lieu d'ajouter trois lignes de valeurs
Le chart officiel
minio/minion'offre AUCUNE sonde — vérifié sur la 5.4.0, qui est la dernière publiée : pas une clélivenessProbedans ses valeurs, pas un rendu de sonde dans ses templates. Ce n'était donc pas un oubli de configuration ; il n'y avait rien à configurer.Et il n'existe aucun moyen de greffer une sonde sur le Deployment d'un sous-chart depuis un chart parent. D'où l'option retenue : rendre les manifestes nous-mêmes, huit objets dans
templates/.Le sabotage, relevé
MinIO jetable, quatre disques, les deux moitiés dans le même pod, même image :
/health/live/health/clusterSabotage :
format.jsonde deux disques sur quatre écrasé. Bascule declusterentre t+20 s et t+40 s ;liven'a jamais bougé.C'est exactement pourquoi la panne était invisible — et pourquoi la sonde vise
cluster, jamaislive.⚠
failureThreshold: 6 × 30 s= 3 minutes de refus soutenu avant redémarrage. Cette grappe connaît des à-coups Longhorn de quelques secondes (le déclencheur du 29 août était un timeout de 8 s) : une sonde nerveuse redémarrerait MinIO sur un hoquet. C'est l'erreur exacte que redis a payée ici en juillet — 836 échecs de sonde, 135 redémarrages, et un.fren 403.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 enMulti-Attach errorjusqu'au timeout.MINIO_PROMETHEUS_AUTH_TYPEétait déclaré deux fois (kubectlle signalait à chaque application).post-jobet 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.⚠ 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
specne bouge pas d'un champ — sansvolumeName(que le contrôleur pose lui-même, et que figer empêcherait toute recréation future de se lier), et portePrune=falseen ceinture.Vérifications, codes relevés
helm templatekubectl apply --dry-run=serverconfigured, aucun encreated, aucune violation de champ immuablekubectl diff— PVCspecintact : nivolumeName, ni taille, niaccessModeskubectl diff— Servicesselectoret ports identiques surminioetminio-consolekadans.arcodange.fr→ import → octets dans le seau → retour galerie :1 passed, code 0⚠ Le
.helmignoreajouté n'est pas cosmétique : sans lui,helm template minio/échoue sur un poste où le Terraform a été initialisé (binaire de provider > 5 Mo). ArgoCD ne le voyait pas —.terraformest gitignoré — donc le défaut ne se manifestait qu'à la relecture locale, c'est-à-dire au pire moment.⚠ Ce que ce lot NE règle PAS
La cause première. Le déclencheur est un timeout réseau entre répliques Longhorn, pas un disque.
sdbavait rendu 10critical medium erroridentiques le 15 août : c'est un motif qui se répète. Et sur pi2,lsetcatexpirent après 4 s dans les sondes Longhorn (engine-image: 142 redémarrages). Ce lot rend la prochaine occurrence visible et auto-réparée en 3 minutes ; il ne l'empêche pas. Le reste de #31 le suit.⚠ Nouveau à notre charge : le tag de l'image ne suit plus la version du chart. À relever à la main lors des mises à jour (noté dans
values.yaml).