Membre depuis le 13/12/2024
salut les experts k8s
on a un service k8s de type externalName qui pointe vers un endpoint externe (genre une url d'une api tierce). le service est créé mais de temps en temps la résolution dns depuis nos pods ne marche plus. un nslookup depuis le pod retourne un non-existent domain ou un timeout. puis ça revient à la normale tout seul. on dirait que c'est aléatoire mais ça pose problème pour les connexions. la config est super basique
apiVersion: v1
kind: Service
metadata:
name: my-external-api
spec:
type: ExternalName
externalName: api.externalprovider.com
ports:
- port: 80
on utilise coredns par défaut sur le cluster. des idées sur ce qui cloche ?
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
Commentaires
turpin-henriette
Membre depuis le 08/07/2024
yo
un ExternalName c'est juste un CNAME. donc la résolution finale dépend de coredns qui va query les dns récursifs externes configurés. ça sent le souci côté dns provider externe ou un problème de reachability de coredns vers ces dns externes
renee49
Membre depuis le 21/07/2024
t'as regardé les logs de coredns ? ça pourrait donner des infos sur les échecs de résolution. aussi, si ton external provider est derrière un firewall, vérifie qu'il n'y a pas de rate limiting sur les requêtes DNS ou de filtrage géographique
aime30
Membre depuis le 13/12/2024
les logs coredns montrent des timeouts ou des "server returned NXDOMAIN" pour api.externalprovider.com. l'api est pas derrière un firewall connu. ce qui est bizarre c'est que ça marche bien 90% du temps
turpin-henriette
Membre depuis le 08/07/2024
le 90% du temps qui marche ça me fait penser à un souci de cache dns. soit côté coredns, soit côté dns récursifs. t'as combien de réplicas de coredns ? si un des pods coredns a un souci de cache ou de connexion et que le pod client tombe dessus, ça foire
marc-blanchard
Membre depuis le 03/05/2024
vérifie aussi la configuration des
/etc/resolv.confdans tes pods clients. est-ce qu'ils pointent bien vers le service coredns du cluster ? des fois un init container ou un truc peut modifier ça. et si coredns est surchargé, il peut commencer à rater des requêtesrenee49
Membre depuis le 21/07/2024
si t'as plusieurs serveurs dns dans ton resolv.conf externe pour coredns, ptete qu'un des serveurs est flakey. ou que le ttl du domaine api.externalprovider.com est super bas et qu'il y a trop de requêtes à faire pour coredns
turpin-henriette
Membre depuis le 08/07/2024
un truc à essayer pour debugger : faire un
dig +tcp api.externalprovider.com @depuis un pod pour voir si le tcp change quelque chose, des fois c'est un souci udp avec le dnsmarc-blanchard
Membre depuis le 03/05/2024
et regarde si tes nodes ont des problèmes réseau quand ça arrive, ptete que c'est pas coredns mais la connectivité de la node elle-même qui a des micro-coupures vers l'extérieur.
mtrvers un dns public peut montrer çaaime30
Membre depuis le 13/12/2024
ok un grand merci pour toutes ces pistes. j'ai regardé les logs de coredns de plus près et j'ai vu des erreurs liées à un de nos dns récursifs externes qui était parfois injoignable, ça correspondait aux timings des problèmes. j'ai viré ce dns de la config de coredns et depuis ça a l'air stable. le cache aussi, le TTL est faible. je vais creuser pour augmenter le TTL si possible. vraiment utile !