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:

hashicorp-vault/values.yaml

@@ -6,6 +6,36 @@ vault: &vault_config
   server:
     enabled: true
     logLevel: trace
+    # ---- NE PLUS ÊTRE LE POD LE PLUS FAIBLE DU CLUSTER -----------------------------
+    # Mesuré le 2026-09-11, avant ce changement : `priorityClassName=""`, `priority=0`,
+    # QoS `BestEffort`. Vault était donc dernier servi par le scheduler et PREMIER évincé
+    # par le kubelet sous pression mémoire — alors que le Vault Secrets Operator en dépend
+    # pour tous les Secrets du cluster, et qu'un Vault tombé repart SCELLÉ, donc muet
+    # jusqu'à ce qu'un humain vienne le desceller à la main.
+    #
+    # Contexte : 78 pods du cluster sont BestEffort contre 35 Burstable et 1 Guaranteed.
+    # Vault était noyé dans le premier groupe.
+    priorityClassName: vault-critical      # cf. templates/priorityclass.yaml
+    resources:
+      # DES REQUESTS, ET DÉLIBÉRÉMENT AUCUNE LIMITE.
+      #
+      # Ce sont les `requests` qui protègent : le kubelet évince d'abord les BestEffort,
+      # puis les Burstable qui DÉPASSENT leur requête, et en dernier ceux qui restent
+      # dessous. Vault consomme ~175 Mio (kubectl top, 11/09) : avec 512 Mio demandés il
+      # est très en dessous, donc tout en bas de la liste des candidats à l'éviction.
+      #
+      # Pourquoi pas de `limits.memory`, qui donnerait du Guaranteed : 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 de 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 : le gain marginal ne vaut pas le risque.
+      #
+      # Pourquoi pas de `limits.cpu` : le throttling CPU sur un ARM64 à 4 cœurs ralentirait
+      # les opérations de descellement et de scellement, pour un pod qui consomme 26 m.
+      requests:
+        memory: 512Mi
+        cpu: 100m
     auditStorage:
       enabled: true