MinIO quitte pi2 : son volume y avait perdu son journal ext4, et aucun redémarrage ne le démontait #50
@@ -56,6 +56,35 @@ spec:
|
||||
release: minio
|
||||
spec:
|
||||
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:
|
||||
# Repris tel quel : la donnée déjà écrite sur le volume appartient à
|
||||
# 1000:1000. Changer ces valeurs rendrait le bucket illisible.
|
||||
|
||||
Reference in New Issue
Block a user