Le 14/09, pi2 tourne à 109 % de mémoire, sans swap. Le moteur Longhorn du volume minio (il vit sur le nœud du pod) manque son délai de 8 s (R/W Timeout. No response received in 8s, 07:07 CEST).
Les écritures de MinIO restent bloquées ~23 s et reviennent au noyau en critical medium error. ext4 fait Aborting journal on device sdb-8 puis Remounting filesystem read-only (07:19:41). Le même incident avait eu lieu à 04:05.
Le montage mort n'a jamais été démonté : un redémarrage de conteneur rouvre le même montage. Le renommage .minio.sys/tmp → tmp-old/<uuid> échoue, MinIO dit « drive is faulty ». Résultat : 325 redémarrages en 27 h, aucune vidéo ne se sauvegarde ni ne se relit.
Preuve
Pod de débogage en lecture seule (créé puis supprimé) : volume à 16 %, inodes à 0 %, tout en 1000:1000, .minio.sys complet, tmp-old absent.
/sys/fs/ext4/sdb/errors_count = 2 sur pi2 ; Longhorn voit le volume healthy, trois répliques running (pi1, pi2, pi3).
Écartés, mesures à l'appui : volume plein, disque Longhorn plein (49 %), droits changés, changement Git/ArgoCD (aucun depuis le 02/09).
Ce que fait la PR
minio/templates/deployment.yaml : affinity.nodeAffinityrequisekubernetes.io/hostname NotIn [pi2], préférence pi3 (59 % de mémoire, pi1 80 %, relevé kubectl top nodes du jour).
Rendu helm template minio/ comparé avant/après : seul le bloc affinity (et son commentaire) change. Stratégie Recreate confirmée dans le rendu.
Appliquée par ArgoCD (auto-sync) : l'ancien pod s'arrête, le volume se détache de pi2, se rattache sur pi3 (ou pi1), et ext4 rejoue son journal au remontage.
Ce qu'elle ne fait pas
Aucune suppression de volume, PVC, réplique ou objet ; aucun nettoyage de .minio.sys/tmp (il n'est pas en cause).
Aucun fsck : si le remontage échoue sur des erreurs ext4, on s'arrête et le fondateur décide.
Elle ne traite pas le terrain : pi2 sature en mémoire et d'autres volumes Longhorn y vivent (loki est tombé au même moment).
## Cause (prouvée, voir tools#49)
- Le **14/09**, pi2 tourne à **109 % de mémoire, sans swap**. Le moteur Longhorn du volume `minio` (il vit sur le nœud du pod) manque son délai de 8 s (`R/W Timeout. No response received in 8s`, 07:07 CEST).
- Les écritures de MinIO restent bloquées ~23 s et reviennent au noyau en `critical medium error`. ext4 fait `Aborting journal on device sdb-8` puis `Remounting filesystem read-only` (07:19:41). Le même incident avait eu lieu à 04:05.
- **Le montage mort n'a jamais été démonté** : un redémarrage de conteneur rouvre le même montage. Le renommage `.minio.sys/tmp → tmp-old/<uuid>` échoue, MinIO dit « drive is faulty ». Résultat : **325 redémarrages en 27 h**, aucune vidéo ne se sauvegarde ni ne se relit.
## Preuve
- Pod de débogage en lecture seule (créé puis supprimé) : volume à **16 %**, inodes à 0 %, tout en `1000:1000`, `.minio.sys` complet, `tmp-old` absent.
- `/sys/fs/ext4/sdb/errors_count = 2` sur pi2 ; Longhorn voit le volume `healthy`, trois répliques `running` (pi1, pi2, pi3).
- Écartés, mesures à l'appui : volume plein, disque Longhorn plein (49 %), droits changés, changement Git/ArgoCD (aucun depuis le 02/09).
## Ce que fait la PR
- `minio/templates/deployment.yaml` : `affinity.nodeAffinity` **requise** `kubernetes.io/hostname NotIn [pi2]`, **préférence** pi3 (59 % de mémoire, pi1 80 %, relevé `kubectl top nodes` du jour).
- Rendu `helm template minio/` comparé avant/après : **seul le bloc `affinity` (et son commentaire) change**. Stratégie `Recreate` confirmée dans le rendu.
- Appliquée par ArgoCD (auto-sync) : l'ancien pod s'arrête, le volume se détache de pi2, se rattache sur pi3 (ou pi1), et ext4 **rejoue son journal** au remontage.
## Ce qu'elle ne fait pas
- Aucune suppression de volume, PVC, réplique ou objet ; aucun nettoyage de `.minio.sys/tmp` (il n'est pas en cause).
- Aucun `fsck` : si le remontage échoue sur des erreurs ext4, on s'arrête et le fondateur décide.
- Elle ne traite pas le terrain : **pi2 sature en mémoire** et d'autres volumes Longhorn y vivent (loki est tombé au même moment).
- Aucune suspension d'ArgoCD.
Refs arcodange-org/tools#49
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Le 14/09, pi2 (109 % de mémoire, sans swap) a fait manquer au moteur
Longhorn son délai de 8 s. Les écritures sont revenues au noyau en
« critical medium error », ext4 a abandonné son journal et remonté le
système de fichiers en lecture seule. Ce montage mort n'a jamais été
démonté : MinIO échoue en boucle sur « drive is faulty » depuis 27 h.
Une affinité requise `kubernetes.io/hostname NotIn [pi2]` (préférence
pi3) : avec la stratégie Recreate, l'ancien pod s'arrête, le volume se
détache de pi2 et se rattache ailleurs, où ext4 rejoue son journal.
Refs arcodange-org/tools#49
Co-Authored-By: Claude Opus 5 <[email protected]>
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.
Cause (prouvée, voir tools#49)
minio(il vit sur le nœud du pod) manque son délai de 8 s (R/W Timeout. No response received in 8s, 07:07 CEST).critical medium error. ext4 faitAborting journal on device sdb-8puisRemounting filesystem read-only(07:19:41). Le même incident avait eu lieu à 04:05..minio.sys/tmp → tmp-old/<uuid>échoue, MinIO dit « drive is faulty ». Résultat : 325 redémarrages en 27 h, aucune vidéo ne se sauvegarde ni ne se relit.Preuve
1000:1000,.minio.syscomplet,tmp-oldabsent./sys/fs/ext4/sdb/errors_count = 2sur pi2 ; Longhorn voit le volumehealthy, trois répliquesrunning(pi1, pi2, pi3).Ce que fait la PR
minio/templates/deployment.yaml:affinity.nodeAffinityrequisekubernetes.io/hostname NotIn [pi2], préférence pi3 (59 % de mémoire, pi1 80 %, relevékubectl top nodesdu jour).helm template minio/comparé avant/après : seul le blocaffinity(et son commentaire) change. StratégieRecreateconfirmée dans le rendu.Ce qu'elle ne fait pas
.minio.sys/tmp(il n'est pas en cause).fsck: si le remontage échoue sur des erreurs ext4, on s'arrête et le fondateur décide.Refs arcodange-org/tools#49
🤖 Generated with Claude Code