Files
tools/minio/templates/deployment.yaml
T
arcodange ffd52ba5ab
Helm Charts / Detect changed charts (pull_request) Successful in 1m2s
Helm Charts / Library charts tool (pull_request) Skipped
Helm Charts / Application charts pgcat (pull_request) Skipped
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
2026-09-03 00:21:42 +02:00

173 lines
7.7 KiB
YAML
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# -----------------------------------------------------------------------------
# MinIO — Deployment écrit À LA MAIN, et voici pourquoi.
#
# ⚠⚠ LE CHART OFFICIEL `minio/minio` N'OFFRE AUCUNE SONDE DE SANTÉ.
# Vérifié sur la 5.4.0 (la dernière au 2026-09-02) : aucune clé `livenessProbe`
# dans ses `values.yaml`, aucun rendu de sonde dans ses `templates/`. Ce n'était
# donc pas un oubli de configuration de notre part — il n'y avait rien à
# configurer. On reprend le manifeste à notre charge pour pouvoir poser la sonde.
#
# CE QUE ÇA A COÛTÉ, MESURÉ (arcodange-org/tools#31) :
# le 2026-08-29 à 14 h 11, les répliques Longhorn se perdent de vue sur le réseau
# (`R/W Timeout. No response received in 8s`) ; le moteur les marque `ERR` une à
# une ; à 15 h 32 le périphérique bloc disparaît sous MinIO ; à 17 h 54 **ext4
# abandonne son journal** (`comm minio: Detected aborted journal`). À partir de
# là, toute écriture rend `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. Trois jours de panne totale du stockage objet, et pas
# un seul indicateur rouge.
#
# ⚠ 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.
# -----------------------------------------------------------------------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: minio
namespace: tools
labels:
app: minio
release: minio
spec:
replicas: 1
# ⚠ IMMUABLE, et repris À L'IDENTIQUE de ce que le sous-chart avait posé :
# changer un `selector` sur un Deployment existant fait ÉCHOUER l'application,
# et ArgoCD le recréerait — donc détacherait puis rattacherait le volume.
selector:
matchLabels:
app: minio
release: minio
strategy:
# ⚠ `Recreate`, PAS `RollingUpdate` : le volume est ReadWriteOnce. Un
# roulement voudrait deux pods à la fois, le second resterait en
# `ContainerCreating` sur un `Multi-Attach error` jusqu'au timeout, et le
# déploiement paraîtrait « en cours » pendant des minutes. Le chart amont
# posait `maxSurge: 100%`, ce qui est le mauvais réglage pour un RWO.
type: Recreate
template:
metadata:
labels:
app: minio
release: minio
spec:
serviceAccountName: minio
securityContext:
# Repris tel quel : la donnée déjà écrite sur le volume appartient à
# 1000:1000. Changer ces valeurs rendrait le bucket illisible.
runAsUser: 1000
runAsGroup: 1000
fsGroup: 1000
fsGroupChangePolicy: OnRootMismatch
terminationGracePeriodSeconds: 30
containers:
- name: minio
image: "{{ .Values.minio.image.repository }}:{{ .Values.minio.image.tag }}"
imagePullPolicy: {{ .Values.minio.image.pullPolicy }}
command:
- /bin/sh
- -ce
- /usr/bin/docker-entrypoint.sh minio server /export -S /etc/minio/certs/ --address :9000 --console-address :9001
env:
# Identifiants JAMAIS dans le dépôt : le secret est matérialisé par
# le Vault Secrets Operator depuis kvv2/minio/config.
- name: MINIO_ROOT_USER
valueFrom:
secretKeyRef:
name: {{ .Values.minio.existingSecret }}
key: rootUser
- name: MINIO_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: {{ .Values.minio.existingSecret }}
key: rootPassword
{{- range $cle, $valeur := .Values.minio.environment }}
- name: {{ $cle }}
value: {{ $valeur | quote }}
{{- end }}
ports:
- name: http
containerPort: 9000
protocol: TCP
- name: http-console
containerPort: 9001
protocol: TCP
# ---------------------------------------------------------------
# LES SONDES — la raison d'être de ce fichier.
#
# ⚠ `/minio/health/live` NE SUFFIT PAS, et c'est mesuré : il répond
# 200 sur un magasin QUI NE PEUT PLUS ÉCRIRE. C'est précisément
# pourquoi la panne du 29 août est restée invisible trois jours.
#
# `/minio/health/cluster` vérifie le QUORUM D'ÉCRITURE — la propriété
# qu'on veut réellement garder.
#
# SABOTAGE RELEVÉ (2026-09-02, 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é. La bascule
# de `cluster` est survenue entre t+20 s et t+40 s. `live` n'a jamais
# bougé. Les DEUX moitiés comptent : la sonde rougit quand la propriété
# est violée, ET reste verte sinon.
# ---------------------------------------------------------------
startupProbe:
# Au démarrage on interroge `live` : tant que MinIO monte, `cluster`
# répond 503 pour une raison légitime, et l'interroger ici tuerait
# le pod avant qu'il ait fini de démarrer.
# 24 × 5 s = 2 min accordées au démarrage.
httpGet:
path: /minio/health/live
port: 9000
periodSeconds: 5
timeoutSeconds: 5
failureThreshold: 24
readinessProbe:
# Retire MinIO du Service quand il ne peut plus écrire : les clients
# reçoivent un refus franc au lieu d'un dépôt qui part dans le vide.
httpGet:
path: /minio/health/cluster
port: 9000
periodSeconds: 15
timeoutSeconds: 5
failureThreshold: 3
livenessProbe:
# ⚠ C'EST CELLE-CI QUI AURAIT LEVÉ LA PANNE : le remède au journal
# ext4 abandonné est un démontage, donc un redémarrage du pod.
#
# ⚠ 6 × 30 s = 3 MINUTES de refus SOUTENU avant de redémarrer. Cette
# grappe connaît des à-coups Longhorn de quelques secondes (le
# déclencheur du 29 août était un `R/W 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 2026-07 — 836 échecs de sonde, 135
# redémarrages, et un `.fr` en 403 (voir redis/values.yaml).
httpGet:
path: /minio/health/cluster
port: 9000
periodSeconds: 30
timeoutSeconds: 5
failureThreshold: 6
resources:
{{- toYaml .Values.minio.resources | nindent 12 }}
volumeMounts:
- name: export
mountPath: /export
- name: minio-user
mountPath: /tmp/credentials
readOnly: true
volumes:
- name: export
persistentVolumeClaim:
claimName: minio
- name: minio-user
secret:
secretName: {{ .Values.minio.existingSecret }}