2 Commits

Include renames

Author	SHA1	Message	Date
arcodangeandClaude Opus 5	01901e5903	Vault est resté scellé onze jours en silence, et c'était le pod le plus faible du cluster ... INCIDENT Le 30/08 à 11:35, pi3 passe de 3,6 Gio de mémoire disponible à 1,7 en cinq minutes. À 11:45 node-exporter ne répond plus, à 11:48 le nœud est NotReady, et 300 s plus tard — la tolérance `node.kubernetes.io/unreachable:NoExecute` — le node-lifecycle controller supprime quatre pods, dont hashicorp-vault-0. Vault repart SCELLÉ, comme le prévoit Shamir 1/1 sans auto-unseal. Personne ne le redescelle. Pendant onze jours le VSO répond 503 « Vault is sealed » et plus aucun Secret n'est réconcilié — découvert par hasard, en enquêtant sur autre chose. Ce qui a fonctionné ce jour-là : `NoeudInjoignable` a tiré à 11:46. L'infra a parlé. Ce qui a manqué : la CONSÉQUENCE. Le nœud est revenu, les pods ont été recréés, l'alerte s'est éteinte, et personne n'a su que Vault, lui, resterait scellé. Ce n'était ni un crash ni un OOMKill : `lastState: {}` et `restartCount: 0` sur un pod vieux de 11 jours. Et le StatefulSet n'a aucune livenessProbe — seulement une readiness `exec: vault status`, dont l'échec ne redémarre rien. D'où 196 906 events Unhealthy pour zéro redémarrage. 1. L'ALERTE QUI MANQUAIT — VaultIndisponible `kube_pod_status_ready{namespace="tools", pod=~"hashicorp-vault-[0-9]+"} == 0` pendant 10 min, avec `or absent(...)` pour couvrir la disparition du pod. Pourquoi kube-state-metrics et pas `vault_core_unsealed` : Vault n'expose ses métriques que via /v1/sys/metrics, qui exige un token ou l'ouverture d'un endpoint non authentifié. Or la readinessProbe du chart est littéralement `vault status` : un Vault scellé est NotReady. kube-state-metrics est déjà scrapé, ça ne coûte rien et ça ne touche pas à la configuration de Vault. ⚠ Le sélecteur est ancré sur `[0-9]+`, et c'est une correction, pas un détail : ma première version utilisait `hashicorp-vault-.*`, qui attrape aussi les pods du Vault Secrets Operator — dont un exemplaire terminé traîne en permanence. La règle tirait donc en continu. Vérifié contre le Prometheus du cluster : avec `[0-9]+` elle ne rend que hashicorp-vault-0 et ne tire pas. 2. VAULT N'EST PLUS LE POD LE PLUS FAIBLE DU CLUSTER Mesuré avant : `priorityClassName=""`, `priority=0`, QoS `BestEffort`. Dernier servi par le scheduler, premier évincé par le kubelet. Sur 114 pods, 78 sont BestEffort — Vault était noyé dedans, alors que tout le cluster dépend de lui et qu'il exige une intervention humaine pour revenir. - PriorityClass `vault-critical` à 900000000. Sous `longhorn-critical` (1000000000) parce que Vault stocke sur un PVC : le stockage doit survivre à Vault. Au-dessus de tout le reste. - `requests: {memory: 512Mi, cpu: 100m}`. Vault consomme 175 Mio : très en dessous de sa requête, donc tout en bas de la liste d'éviction. AUCUNE LIMITE, DÉLIBÉRÉMENT. Une limite trop basse déclenche un OOMKill, et un OOMKill sur ce pod coûte un descellement manuel. Or je n'ai pas pu établir de pic mémoire fiable : les séries cAdvisor de ce cluster rendent huit valeurs contradictoires pour ce pod, jusqu'à 2,3 Gio, ce qui est invraisemblable pour un Vault en storage "file". On ne pose pas une limite sur un chiffre auquel on ne croit pas. 3. LE PDB EXISTANT : GARDÉ, MAIS SON PIÈGE EST MAINTENANT ÉCRIT `maxUnavailable: 0` sur un StatefulSet à un réplica donne ALLOWED DISRUPTIONS: 0 en permanence. Un `kubectl drain` du nœud qui héberge Vault ne se terminera donc jamais. C'est le comportement voulu — il force à traiter Vault consciemment — mais la sortie de secours (`--disable-eviction`, ou suppression manuelle du pod) n'était écrite nulle part. Elle l'est. CE QUE ÇA NE RÉSOUT PAS, ET IL FAUT LE DIRE Ni la priorité ni les requests n'empêchent la suppression par le node-lifecycle controller quand un nœud devient injoignable — c'est exactement ce qui est arrivé le 30/08, et aucun réglage de pod ne l'évite. Ce cas-là est traité par l'alerte, pas par la protection. L'auto-unseal reste écarté : décision assumée, documentée dans factory vibe/guidebooks/lab-ecosystem/secrets-and-vault.md. Le descellement restera manuel ; c'est le délai de détection qui passe de onze jours à dix minutes. ⚠ APPLICATION : le StatefulSet est en `updateStrategy: OnDelete`. Les réglages du point 2 ne prendront effet qu'à la prochaine suppression du pod — laquelle rescellera Vault. À faire au moment choisi, clé sous la main. Vérifié : `helm template` rend la PriorityClass, le PDB et un StatefulSet portant `priorityClassName: vault-critical` et les requests ; `helm lint` passe ; la requête de l'alerte testée contre le Prometheus du cluster. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-11 12:56:19 +02:00
arcodange	5ac60c54fa	fix(vault) — un PDB pour les évictions volontaires, OnRootMismatch pour les remounts ... Ce Vault tourne en standalone (Shamir, un seul réplica, pas d'auto-unseal) : toute interruption de pod exige un unseal humain ensuite. Le PDB du sous-chart vendored ne se rend qu'en mode HA (server.ha.disruptionBudget, gardé par `eq .mode "ha"`), donc jamais ici — il en fallait un écrit à la main. Par ailleurs chaque remount du volume déclenchait un chown -R complet du fsGroup, mesuré à ~9 min sur ce PVC (event kubelet VolumePermissionChangeInProgress, suggestion du kubelet lui-même). Avec OnRootMismatch, un remount dont le propriétaire racine est déjà correct saute ce chown. Le PDB ne protège que des évictions volontaires (drain, descheduler) — pas d'une panne de nœud ni d'une suppression manuelle.	2026-08-11 13:15:13 +02:00