Sujet :
Intermittent DNS lookup failures microservices derriere un LB interne
RÉSOLU
Liste des sujets Répondre Créer un sujet
Membre depuis le 25/03/2024
salut la gang ! j'ai un truc qui me rend fou. on a des microservices en k8s qui communiquent entre eux via des internal load balancers (AWS ALB). de temps en temps une poignée de pods n'arrivent plus à résoudre le nom DNS de l'autre service. ça dure quelques secondes puis ça revient. pas de changement dans le LB pas de déploiement récent. les logs côté service appelant donnent Name lookup failed
# exemple dans un pod qui foire
curl http://my-internal-service.internal.mydomain.com
curl: (6) Could not resolve host: my-internal-service.internal.mydomain.com
c'est super aléatoire et ça impacte notre uptime. des idées sur où chercher ?
Répondre
vous devez être connecté pour poster un message !
Rejoindre la communauté
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
laure23
Membre depuis le 14/03/2025
hello. t'as vérifié les dns servers configurés dans ton vpc ? genre si t'as le dns resolver par défaut d'aws (vpc cidr + 2) ou si tu utilises des custom dns. et le nombre de dns servers. parfois si y en a qu'un et qu'il est surchargé ça peut donner ça. aussi check la dns support de tes pods est-ce qu'ils ont bien le dns policy kubernetes par défaut ou autre chose ?
veronique28
Membre depuis le 23/07/2024
et aussi vérifie le nombre de requêtes DNS que tes pods génèrent. si tu as des services qui font des millions de lookups par seconde ça peut saturer le resolver DNS. des fois c'est pas le DNS en lui-même qui foire mais le client DNS dans le pod qui a un cache un peu trop agressif ou qui gère mal les timeouts
ldupre
Membre depuis le 15/08/2024
franchement j'ai déjà vu ça quand des pods avaient leur propre
/etc/resolv.confqui était pas sync ou qui pointait vers des dns resolvers lents ou pas à jour. ou alors unndots:trop élevé dans resolv.conf qui fait que le dns cherche trop longtemps des suffixes avant de tenter le lookup directmaggie18
Membre depuis le 25/03/2024
merci pour toutes les pistes ! après investigation il s'avère que certains de nos pods faisaient du cache DNS côté applicatif (un lib java un peu old school) et ne rafraichissaient pas bien leur cache quand le DNS changeait (ce qui arrive avec des lbs k8s). en désactivant ce cache ou en forçant le ttl ça a résolu le souci. c'était pas le resolver mais le client. un grand merci pour le coup de main !