4 commentaires
yo. le classique sur k8s avec CoreDNS c'est le ndots dans le resolv.conf des pods. si t'as trop peu de points dans tes hostnames (genre mon-service au lieu de mon-service.mon-namespace.svc.cluster.local), le dns resolver du pod essaie plein de search domains et ça peut le faire timeout ou échouer. vérifie ton configMap de coredns ou tes dnsConfig dans le pod
regarde aussi les logs de tes pods CoreDNS. est-ce qu'ils voient les requêtes dns ? est-ce qu'ils ont des erreurs ? des fois c'est juste le CoreDNS qui est sous-dimensionné pour la charge dns du cluster, il est pas scalé assez ou il est sur un noeud crevé. regarde le cpu et mem usage de CoreDNS
un truc bête mais ça arrive : t'as pas des NetworkPolicies qui bloquent le trafic udp 53 vers les pods coredns depuis certains namespaces ou pods ? ça peut expliquer les échecs aléatoires si seulement certains pods sont affectés ou certaines requêtes. un tcpdump sur l'interface du pod CoreDNS pendant une tentative de résolution ça te donnera l'heure
d'acc les gars merci. c'était bien le ndots en fait. nos dev utilisaient des noms courts genre mon-service et le resolv.conf par défaut forçait trop de recherches ce qui causait des timeouts aléatoires. j'ai mis un ndots: 1 dans la dnsConfig de quelques déploiements et ça a résolu pas mal de soucis. et on va sensibiliser les dev à utiliser les fqdn ou au moins mon-service.mon-namespace. thx encore !
Laisser une réponse
Vous devez être connecté pour poster un message !
salut. on a des soucis de résolution
dnsaléatoires pour nos services internes dans notre clusterEKS. les pods n'arrivent plus à résoudre certains hostnames de services qui sont pourtant dans le même namespace ou d'autres namespaces du cluster. desdigdepuis les pods renvoientnxdomainouno servers could be reached.CoreDNStourne bien pourtant on dirait.