Vault a été re-schedulé sur un autre nœud aujourd'hui : ~9 min de chown -R au remount (event kubelet VolumePermissionChangeInProgress), puis remonté scellé (Shamir, pas d'auto-unseal). Tant que Vault est sealed, tous les VaultAuth/VaultDynamicSecret/VaultStaticSecret du cluster échouent en boucle (constaté sur crowdsec-db-credentials, kadans-api-db, kadans-api-mail, kadans-api-google, kadans-api-minio).
Ce que ça change
PodDisruptionBudget écrit à la main (hashicorp-vault/templates/vault-server-pdb.yaml) — le PDB du sous-chart vendored ne se rend qu'en mode HA (eq .mode "ha" dans server-disruptionbudget.yaml), or ce Vault tourne en standalone (storage file, un seul réplica). Le garde-fou du chart ne s'appliquait donc jamais ici.
fsGroupChangePolicy: OnRootMismatch sur le pod du statefulset — évite le chown -R complet à chaque remount quand le propriétaire racine est déjà correct. Suggestion émise par kubelet lui-même dans l'event observé.
Ce que ça ne couvre PAS
Le PDB protège des évictions volontaires (kubectl drain, descheduler) — pas d'une panne de nœud ni d'une suppression manuelle.
Toute interruption reste suivie d'un unseal manuel (pas d'auto-unseal configuré) — hors périmètre de cette PR.
La lenteur I/O constatée pendant l'incident (rebuild de réplique Longhorn en cours sur ce PVC) est un problème de couche stockage distinct, traité séparément.
Validation
helm template en local avec les sous-charts vendored restaurés depuis le checkout existant (gitignorés, non commités) : le PDB rend avec le bon sélecteur (app.kubernetes.io/name: vault, app.kubernetes.io/instance, component: server — vérifié contre l'anti-affinité déjà en place dans le statefulset), et fsGroupChangePolicy: OnRootMismatch apparaît dans le securityContext du pod aux côtés des valeurs par défaut inchangées (runAsNonRoot, runAsGroup: 1000, runAsUser: 100, fsGroup: 1000).
## Contexte
Vault a été re-schedulé sur un autre nœud aujourd'hui : ~9 min de `chown -R` au remount (event kubelet `VolumePermissionChangeInProgress`), puis remonté **scellé** (Shamir, pas d'auto-unseal). Tant que Vault est sealed, tous les `VaultAuth`/`VaultDynamicSecret`/`VaultStaticSecret` du cluster échouent en boucle (constaté sur `crowdsec-db-credentials`, `kadans-api-db`, `kadans-api-mail`, `kadans-api-google`, `kadans-api-minio`).
## Ce que ça change
1. **`PodDisruptionBudget` écrit à la main** (`hashicorp-vault/templates/vault-server-pdb.yaml`) — le PDB du sous-chart vendored ne se rend qu'en mode HA (`eq .mode "ha"` dans `server-disruptionbudget.yaml`), or ce Vault tourne en `standalone` (storage `file`, un seul réplica). Le garde-fou du chart ne s'appliquait donc jamais ici.
2. **`fsGroupChangePolicy: OnRootMismatch`** sur le pod du statefulset — évite le `chown -R` complet à chaque remount quand le propriétaire racine est déjà correct. Suggestion émise par kubelet lui-même dans l'event observé.
## Ce que ça ne couvre PAS
- Le PDB protège des évictions **volontaires** (`kubectl drain`, descheduler) — pas d'une panne de nœud ni d'une suppression manuelle.
- Toute interruption reste suivie d'un **unseal manuel** (pas d'auto-unseal configuré) — hors périmètre de cette PR.
- La lenteur I/O constatée pendant l'incident (rebuild de réplique Longhorn en cours sur ce PVC) est un problème de couche stockage distinct, traité séparément.
## Validation
`helm template` en local avec les sous-charts vendored restaurés depuis le checkout existant (gitignorés, non commités) : le PDB rend avec le bon sélecteur (`app.kubernetes.io/name: vault`, `app.kubernetes.io/instance`, `component: server` — vérifié contre l'anti-affinité déjà en place dans le statefulset), et `fsGroupChangePolicy: OnRootMismatch` apparaît dans le `securityContext` du pod aux côtés des valeurs par défaut inchangées (`runAsNonRoot`, `runAsGroup: 1000`, `runAsUser: 100`, `fsGroup: 1000`).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Contexte
Vault a été re-schedulé sur un autre nœud aujourd'hui : ~9 min de
chown -Rau remount (event kubeletVolumePermissionChangeInProgress), puis remonté scellé (Shamir, pas d'auto-unseal). Tant que Vault est sealed, tous lesVaultAuth/VaultDynamicSecret/VaultStaticSecretdu cluster échouent en boucle (constaté surcrowdsec-db-credentials,kadans-api-db,kadans-api-mail,kadans-api-google,kadans-api-minio).Ce que ça change
PodDisruptionBudgetécrit à la main (hashicorp-vault/templates/vault-server-pdb.yaml) — le PDB du sous-chart vendored ne se rend qu'en mode HA (eq .mode "ha"dansserver-disruptionbudget.yaml), or ce Vault tourne enstandalone(storagefile, un seul réplica). Le garde-fou du chart ne s'appliquait donc jamais ici.fsGroupChangePolicy: OnRootMismatchsur le pod du statefulset — évite lechown -Rcomplet à chaque remount quand le propriétaire racine est déjà correct. Suggestion émise par kubelet lui-même dans l'event observé.Ce que ça ne couvre PAS
kubectl drain, descheduler) — pas d'une panne de nœud ni d'une suppression manuelle.Validation
helm templateen local avec les sous-charts vendored restaurés depuis le checkout existant (gitignorés, non commités) : le PDB rend avec le bon sélecteur (app.kubernetes.io/name: vault,app.kubernetes.io/instance,component: server— vérifié contre l'anti-affinité déjà en place dans le statefulset), etfsGroupChangePolicy: OnRootMismatchapparaît dans lesecurityContextdu pod aux côtés des valeurs par défaut inchangées (runAsNonRoot,runAsGroup: 1000,runAsUser: 100,fsGroup: 1000).🤖 Generated with Claude Code