vault ha pas de bascule auto en cas de crash

rrenaud 24/12/2025
RÉSOLU
rrenaud
Auteur
Avatar de rrenaud
rrenaud
Auteur

salut la team vault

on a monté un cluster vault en ha sur k8s avec un backend consul. quand je tue le pod leader, vault devient inaccessible pendant un moment et il bascule pas auto sur un standby. faut que je fasse un vault operator step-down manuel ou redémarrer le pod pour qu'il reprenne le travail. c'est pas censé être auto ? on est en version 1.12.3


# config simplifiée de notre statefulset vault
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: vault
spec:
  serviceName: vault
  replicas: 3
  template:
    spec:
      containers:
      - name: vault
        image: hashicorp/vault:1.12.3
        args:
          - server
          - -config=/vault/config/vault.hcl
        ports:
          - containerPort: 8200
          - containerPort: 8201
        volumeMounts:
          - name: config
            mountPath: /vault/config
24/12/2025 à 18:35

8 commentaires

daniel-garcia
Membre Actif
Avatar de daniel-garcia
daniel-garcia
Membre Actif

hmm ça sent le problème de heartbeat ou de latence réseau entre vault et consul. le leader doit notifier régulièrement consul qu'il est vivant. si la communication est coupée ou trop lente, consul ne le voit plus comme sain et la bascule est lente ou échoue

25/12/2025 à 17:45
ebenoit
Membre Actif Secouriste
Avatar de ebenoit
ebenoit
Membre Actif Secouriste

vérifie aussi la config du storage backend dans vault.hcl. t'as bien mis l'adresse de ton cluster consul ? et les droits rbac dans k8s pour vault sur consul sont bons ?


storage "consul" {
  address = "consul-server:8500"
  path    = "vault/"
}
26/12/2025 à 16:39
wfernandez
Membre
Avatar de wfernandez
wfernandez
Membre

autre chose, t'as mis des liveness et readiness probes sur tes pods vault dans k8s ? si le liveness probe est trop agressif ou le grace period trop court, k8s pourrait tuer le pod avant que vault ait eu le temps de notifier consul de son état ou de basculer

27/12/2025 à 14:17
rrenaud
Auteur
Avatar de rrenaud
rrenaud
Auteur

les probes sont là ouais mais pas ultra agressives. le network entre vault et consul est clean en théorie. mais c'est vrai que la latence entre les noeuds k8s peut jouer j'y avais pas pensé. je vais regarder les logs de consul et vault pour les heartbeats

28/12/2025 à 10:46
daniel-garcia
Membre Actif
Avatar de daniel-garcia
daniel-garcia
Membre Actif

t'as des ressources cpu/mem suffisantes pour tes pods vault et consul ? un manque de ressources peut faire ramer les heartbeats et le processus de bascule

29/12/2025 à 09:47
ebenoit
Membre Actif Secouriste
Avatar de ebenoit
ebenoit
Membre Actif Secouriste

check aussi le ttl de la session consul pour vault. c'est ce qui définit combien de temps consul attend avant de considérer que le leader est down. si c'est trop long ça retarde la bascule


listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = true
}

non pardon c pas dans le listener c dans le storage block du consul backend


storage "consul" {
  ...
  ha_lease_duration = "10s" # regarde ce paramètre
}
30/12/2025 à 04:06
wfernandez
Membre
Avatar de wfernandez
wfernandez
Membre

et une dernière vérif : les horloges de tes serveurs k8s et consul sont bien synchronisées ? un drift horaire peut foutre le boxon dans les logs et le timing des heartbeats

31/12/2025 à 01:46
rrenaud
Auteur
Avatar de rrenaud
rrenaud
Auteur

alors c'était bien la ha_lease_duration dans la config consul de vault, elle était sur 15s et on avait un peu de lag réseau sporadique. j'ai réduit à 5s et maintenant la bascule est quasi instantanée. thx les experts vous êtes des boss

31/12/2025 à 23:03

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire