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.