arcodange
ffd52ba5ab
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
49 lines
2.6 KiB
YAML
49 lines
2.6 KiB
YAML
# -----------------------------------------------------------------------------
|
||
# MinIO — stockage objet S3 du homelab (3 × Raspberry Pi 5, arm64).
|
||
#
|
||
# Pourquoi ici : c'est une BRIQUE PARTAGÉE, au même titre que pgbouncer ou
|
||
# clickhouse — le namespace `tools` en héberge le serveur ; les buckets, quotas
|
||
# et identifiants d'une application vivent, eux, avec cette application.
|
||
#
|
||
# Premier consommateur : Kadans (ADR-012 « MinIO local d'abord », ADR-013
|
||
# « OPFS local-first, MinIO/R2 = paliers payants »). La bascule vers Cloudflare
|
||
# R2 est prévue par l'ADR-012 aux seuils : 100+ utilisateurs actifs, > 10 To/mois
|
||
# de bande passante, ou dispersion géographique.
|
||
#
|
||
# Mode STANDALONE assumé : 3 nœuds, mais la donnée servie ici est DÉRIVÉE (le
|
||
# master d'une vidéo reste sur l'appareil de son propriétaire — ADR-018 du front) ;
|
||
# la redondance de Longhorn suffit, l'erasure coding distribué de MinIO coûterait
|
||
# de la RAM et des IOPS que des Pi n'ont pas à dépenser pour ça.
|
||
#
|
||
# ⚠⚠ CE CHART EST AUTONOME DEPUIS LE 2026-09-02, ET CE N'EST PAS UN CAPRICE.
|
||
# Il dépendait du sous-chart officiel `minio/minio` 5.4.0. Ce chart N'OFFRE
|
||
# AUCUNE SONDE DE SANTÉ — vérifié sur toutes ses versions publiées, la 5.4.0
|
||
# étant la dernière : pas une clé `livenessProbe` dans ses valeurs, pas un rendu
|
||
# de sonde dans ses templates. MinIO tournait donc sans le moindre contrôle, et
|
||
# une panne totale de trois jours est passée inaperçue (arcodange-org/tools#31).
|
||
#
|
||
# 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 — huit objets,
|
||
# tous dans templates/, chacun commenté avec ce qu'il reprend à l'identique et
|
||
# ce qu'il change délibérément.
|
||
#
|
||
# CE QU'ON REPREND À NOTRE CHARGE, ET QU'IL FAUT DONC SUIVRE À LA MAIN : le
|
||
# `tag` de l'image (values.yaml), qui n'est plus tiré par la version du chart.
|
||
# -----------------------------------------------------------------------------
|
||
apiVersion: v2
|
||
name: minio
|
||
description: Stockage objet S3 du homelab — manifestes rendus ici, sans sous-chart.
|
||
|
||
# ⚠ Plus AUCUNE dépendance, et c'est délibéré :
|
||
# - `minio/minio` 5.4.0 est parti pour la raison ci-dessus ;
|
||
# - la bibliothèque `tool` n'était utilisée que par templates/helm-chart*.yaml,
|
||
# deux fichiers inertes (gardés par `tool.kind == "HelmChart"`, jamais vrai
|
||
# ici) supprimés dans le même passage.
|
||
# Effet de bord bienvenu : la synchronisation ArgoCD ne dépend plus de deux
|
||
# dépôts Helm distants — un point de panne en moins sur le stockage objet.
|
||
dependencies: []
|
||
|
||
type: application
|
||
version: 0.2.0
|
||
appVersion: "RELEASE.2024-12-18T13-15-44Z"
|