8 commentaires
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
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
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
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
}
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
Laisser une réponse
Vous devez être connecté pour poster un message !
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