MinIO quitte pi2 : son volume y avait perdu son journal ext4, et aucun redémarrage ne le démontait #50

Merged
arcodange merged 1 commits from arcodange/incident-minio into main 2026-09-15 10:35:01 +02:00
Showing only changes of commit 3c3690a26b - Show all commits
+29
View File
@@ -56,6 +56,35 @@ spec:
release: minio release: minio
spec: spec:
serviceAccountName: minio serviceAccountName: minio
# ---------------------------------------------------------------
# ⚠⚠ JAMAIS SUR pi2 (incident arcodange-org/tools#49, 2026-09-14).
#
# pi2 tourne à ~110 % de mémoire, sans swap. Le moteur Longhorn d'un
# volume vit sur le nœud du POD : sur pi2, il a manqué son délai de 8 s
# (`R/W Timeout`), les écritures sont revenues au noyau en
# `critical medium error`, et ext4 a ABANDONNÉ son journal (04:05 puis
# 07:19). Le montage mort n'est jamais démonté par un redémarrage de
# conteneur : 314 redémarrages sur « drive is faulty » en 26 h.
#
# Même mécanisme que tools#31. Déplacer le pod déplace le moteur, et le
# déplacement démonte le volume — ext4 rejoue son journal au remontage.
# ---------------------------------------------------------------
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: NotIn
values: [pi2]
preferredDuringSchedulingIgnoredDuringExecution:
# pi3 est le moins chargé en mémoire (58 % au 2026-09-15, pi1 81 %).
- weight: 50
preference:
matchExpressions:
- key: kubernetes.io/hostname
operator: In
values: [pi3]
securityContext: securityContext:
# Repris tel quel : la donnée déjà écrite sur le volume appartient à # Repris tel quel : la donnée déjà écrite sur le volume appartient à
# 1000:1000. Changer ces valeurs rendrait le bucket illisible. # 1000:1000. Changer ces valeurs rendrait le bucket illisible.