{{/*
  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.