7 commentaires
hello. "context canceled" ça peut pointer vers des problèmes de ressources cpu/mémoire sur le pod vault. t'as mis des limits et requests assez généreuses ? un oomkill ou un throttle cpu ça peut faire planter le raft
check aussi les performances de tes PV. gp3 c'est ok mais si tu as des burst de writes sur le Raft log et que tes IOPS sont insuffisantes ça peut déstabiliser le cluster. regarde les métriques d'IOPS et de throughput sur tes EBS
les ressources sont pas mal on a 4 vCPU et 8 Go de RAM. et les EBS gp3 on est à 3000 IOPS et 125 MB/s de provisionné. je vois pas de throttle cpu ni d'oomkill dans les events. les métriques EBS sont OK pour l'instant pas de saturation
ok un autre truc à voir c'est la stabilité réseau entre tes nodes. si le Raft leader perd la connectivité avec une majorité de ses followers même pour une microcoupure il peut se considérer comme partitionné et se down. t'as des métriques de latence/perte de paquets entre tes nodes k8s ?
et une dernière piste : les clock skews entre tes nodes. si les horloges sont pas bien synchronisées ça peut foirer les timeouts du Raft. ntp doit être impeccable
vous êtes chauds ! c'était bien un mix. la latence inter-nodes était ok mais un des nodes avait un souci de ntp et sa clock était décalée de quelques secondes. une fois resynchronisé et j'ai aussi rajouté un peu plus de CPU aux pods Vault par précaution le leader est stable depuis 2h. thx les gars !
top ! bon à savoir pour le ntp ça arrive plus souvent qu'on croit
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut à tous ! On a un Vault HA sur k8s avec Raft en backend et notre leader actuel se crashe régulièrement. Le pod passe en CrashLoopBackOff. Quand il redémarre il devient follower puis un autre prend le lead et finit par planter aussi. On a 3 instances de Vault. Les logs sont pas super clairs ça parle de "context canceled" ou "Raft unexpected error".
On est sur un cluster EKS avec des EBS gp3 comme PV pour Raft. Y'a une idée d'où chercher ?