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/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