2 Commits

Include renames

Author	SHA1	Message	Date
arcodange	ffd52ba5ab	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
arcodangeandClaude Opus 5	84edfc8640	feat(minio) — stockage objet S3 du homelab (brique partagée de tools) ... Le fondateur : « on déploie MinIO dans le repo tools du homelab non ? » — oui, c'est bien le pattern : le dossier tools/ porte les briques PARTAGÉES (pgbouncer, clickhouse, grafana…) et le namespace tools les fait tourner ; les charts applicatifs vivent dans le repo de leur app. Décidé de longue date côté produit, jamais déployé : ADR-012 « MinIO local d'abord » (bascule R2 à 100+ utilisateurs / 10 To par mois), ADR-013 (le gratuit reste local-first, MinIO sert les paliers payants). Vérifié avant d'écrire : aucun pod ni service MinIO dans le cluster. Le chart suit la recette du repo (dépendance à la library "tool" + chart amont en SubChart, deux gardes dans templates/) : - mode STANDALONE, 1 réplique : ce qui transite est DÉRIVÉ (le master d'une vidéo reste sur l'appareil de son propriétaire, ADR-018) et Longhorn réplique déjà le volume — l'erasure coding distribué coûterait de la RAM que des Pi 5 n'ont pas à dépenser pour ça ; - 50 Gi sur longhorn ≈ 250 h de cours au palier « travail » (360p, 3,4 Mo/min) ; ⚠ Longhorn réplique : compter ×3 sur la capacité avant d'augmenter ; - ressources bornées (512 Mi / 2 Gi) : la limite protège les voisins de tools ; - API s3.arcodange.lab + console minio.arcodange.lab (Traefik) ; - bucket kadans-videos PRIVÉ — l'accès passera par des URL signées (ADR-0002) ; - identifiants JAMAIS au dépôt : iac/ les génère dans Vault (kvv2/minio/config), le Vault Secrets Operator les matérialise, le chart les lit via existingSecret. Le SA du pod est nommé "minio" (pas le "minio-sa" amont) car le module app_roles borne l'authentification au SA portant le nom de l'app. ⚠ Le workflow minio.yaml écrit ses triggers EN TOUTES LETTRES : une ancre YAML dans un trigger Gitea Actions fait taire push ET pull_request en silence (vécu sur arcodange/kadans, issues 113→117). Les workflows plausible/crowdsec/vault de ce repo en utilisent encore — à vérifier séparément, c'est probablement pourquoi ils ne partent qu'à la main. Vérifié : helm dependency update + helm template (11 ressources rendues, SA et VaultAuth cohérents) + helm lint ✓. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA	2026-07-25 16:49:34 +02:00