7 commentaires
salut. si vault est unsealed et que l'api répond pas c'est ptete un truc au niveau de la config du service k8s de vault. t'as un ingress ? un service mesh type istio ? des fois les selectors du service bougent ou les règles de routage se pètent la gueule après un reboot massif. vérifie que ton service k8s pointe bien sur le bon pod
c'est peut-être la persistence storage qui a eu un coup. si vault utilise un pvc ou un backend externe genre consul s3 ou gcs. le reboot a pu impacter la dispo du storage sous-jacent. vault est unsealed mais si le backend est lent ou hs l'api répond pas bien
non le storage backend (consul) est nickel, j'ai checké il est up et les données vault sont là. on a un istio mais pas d'ingress direct pour vault, c'est des services internes qui l'appellent. j'ai vérifié les serviceentry et virtualservice ils ont l'air ok. aucune erreur dans les logs istio-proxy des pods vault
ah ! j'ai curl l'ip du pod direct ça marche ! donc c'est bien le service k8s ou istio. je viens de regarder les serviceentry istio en détail. en fait l'ip interne de vault avait changé après le reboot du node où il est tombé, et une de nos serviceentry (configurée en ip statique pour une raison obscure) pointait toujours sur l'ancienne. je la mets à jour, et ça devrait être bon !
c'est ça ! j'ai corrigé la serviceentry et tout est revenu à la normale. merci à tous pour les pistes c'était une bonne galère
Laisser une réponse
Vous devez être connecté pour poster un message !
Yo la gang. Gros souci ce matin après un reboot d'urgence de tout le cluster K8s. Notre instance de Vault (deployée en helm) ne répond plus. Le pod est up, les logs disent qu'il est "sealed" comme d'hab. On a unsealed manuellement, les logs disent "Vault is unsealed and ready to go". Mais impossible de taper l'API, les services qui dépendent de Vault timeout. Le service K8s est là, les endpoints sont ok, j'ai vérifié les NetworkPolicies. Rien ne semble bloquer au niveau réseau habituel. Je sèche.