# Le sous-chart vendored `vault` ne rend son PodDisruptionBudget qu'en mode HA
# (server.ha.disruptionBudget.enabled, gardé par `eq .mode "ha"` dans
# server-disruptionbudget.yaml). Ce Vault tourne en standalone (storage "file",
# un seul réplica, scellement Shamir sans auto-unseal) : le garde-fou du chart
# ne s'applique jamais ici, d'où ce PDB écrit à la main dans le chart parapluie.
#
# Il ne protège que des évictions VOLONTAIRES (kubectl drain, descheduler) — pas
# 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:
  name: {{ .Release.Name }}-server
  namespace: {{ .Release.Namespace }}
  labels:
    app.kubernetes.io/name: vault
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
spec:
  maxUnavailable: 0
  selector:
    matchLabels:
      app.kubernetes.io/name: vault
      app.kubernetes.io/instance: {{ .Release.Name }}
      component: server