Vault est resté scellé onze jours en silence, et c'était le pod le plus faible du cluster (#46)

Co-authored-by: Gabriel Radureau <[email protected]>

hashicorp-vault/templates/priorityclass.yaml

@@ -0,0 +1,33 @@
+{{/*
+  F—: VAULT NE DOIT PLUS ÊTRE LE POD LE PLUS FAIBLE DU CLUSTER.
+
+  Constat du 2026-09-11, mesuré : `priorityClassName=""`, `priority=0`, QoS `BestEffort`.
+  Autrement dit Vault était littéralement dernier servi et premier évincé, alors que le
+  Vault Secrets Operator en dépend pour TOUS les Secrets du cluster. Quand il tombe, il
+  repart scellé (Shamir 1/1, pas d'auto-unseal — décision assumée) et plus rien ne se
+  réconcilie jusqu'à ce qu'un humain vienne le desceller.
+
+  POURQUOI 900000000. Il existe déjà `longhorn-critical` à 1000000000. Vault stocke ses
+  données sur un PVC : si Longhorn tombe, Vault ne repart pas. Le stockage doit donc rester
+  AU-DESSUS. En dessous de Vault, tout le reste — applications comprises.
+
+  CE QUE ÇA ACHÈTE, ET CE QUE ÇA N'ACHÈTE PAS. La priorité joue sur la préemption par le
+  scheduler et sert de critère de tri à l'éviction par le kubelet sous pression. Elle
+  n'empêche PAS la suppression décidée par le node-lifecycle controller quand un nœud
+  devient injoignable — c'est exactement ce qui s'est produit le 30/08 et aucun réglage de
+  pod ne l'évite. Ce qui traite ce cas-là, c'est l'alerte VaultIndisponible.
+*/}}
+apiVersion: scheduling.k8s.io/v1
+kind: PriorityClass
+metadata:
+  name: vault-critical
+  labels:
+    app.kubernetes.io/managed-by: {{ .Release.Service }}
+    app.kubernetes.io/part-of: hashicorp-vault
+value: 900000000
+globalDefault: false
+preemptionPolicy: PreemptLowerPriority
+description: >-
+  Vault et son opérateur : tout le cluster en dépend pour ses Secrets, et un Vault tombé
+  repart scellé, donc muet jusqu'à intervention humaine. Sous longhorn-critical (le
+  stockage doit survivre à Vault), au-dessus de tout le reste.

hashicorp-vault/templates/vault-server-pdb.yaml

@@ -8,6 +8,17 @@
 # d'une panne de nœud ni d'une suppression manuelle. Avec un seul réplica et
 # aucun auto-unseal, toute interruption exige un unseal humain ensuite ; ce PDB
 # réduit seulement les interruptions évitables.
+#
+# ⚠ CONSÉQUENCE À CONNAÎTRE AVANT LA PROCHAINE MAINTENANCE D'UN NŒUD.
+# `maxUnavailable: 0` sur un StatefulSet à UN réplica donne `ALLOWED DISRUPTIONS: 0`
+# en permanence — vérifié : `kubectl get pdb -n tools` le montre depuis 20 jours.
+# Un `kubectl drain <nœud>` sur le nœud qui héberge Vault ne se terminera donc JAMAIS,
+# il bouclera en silence sur « cannot evict pod as it would violate the budget ».
+# C'est le comportement voulu — il force à traiter Vault consciemment — mais il faut
+# savoir en sortir :
+#     kubectl drain <nœud> --disable-eviction        # contourne le PDB (supprime le pod)
+#   ou kubectl delete pod -n tools hashicorp-vault-0  # puis descellement à la main
+# Dans les deux cas Vault repart scellé : avoir la clé sous la main AVANT de drainer.
 apiVersion: policy/v1
 kind: PodDisruptionBudget
 metadata: