9 commentaires
salut. vérifie les logs exacts des coredns qui crash. souvent c'est OOMkill. regarde les métriques mémoire et cpu de ces pods dans prometheus/cloudwatch. et check si t'as pas des requêtes DNS bizarres qui les spamment.
ok je regarde ça. les logs donnent pas grand chose à part "panic: runtime error: index out of range [0] with length 0" ou des trucs du genre avant le crash. pas de OOMKill visible. cpu/mem sont ok sur le papier pas de spikes anormaux. par contre on a pas mal de services et ça spamme pas mal le control plane pour le service discovery.
panics d'index ça ressemble à un bug de coredns. t'as quelle version exacte ? 1.8.6 c'est pas la dernière. regarde les release notes ou issues github. des fois une mise à jour mineure corrige des trucs de stabilité.
ouais et check tes nodes. pas de problèmes de conntrack tables full ? genre un truc qui bloque les connexions aux coredns ?
conntrack bonne piste j'y avais pas pensé. on a pas mal de traf. je vais monitorer ça. pour la version j'ai vu que la 1.9.3 est sortie mais j'hésite à upgrader en prod sans être sûr que ça fix le problème. et on a pas de dns masq ou node local dns cache. c du direct coredns.
merci j'ai creusé la config. le Corefile est standard pas de plugins exotiques. par contre j'ai vu des alertes sur le nombre de files descriptors open par les coredns pods. ça monte grave avant un crash. j'ai augmenté la limite dans le daemonset pour voir.
ah ça c intéressant. fd limits ça peut causer des comportements étranges. si tu gères beaucoup de connexions concourantes ou si t'as des clients dns qui gardent les connexions ouvertes longtemps ça peut saturer vite. bon shot pour le fix.
bon c'était bien ça ! l'augmentation des fd limits a stabilisé le tout. plus aucun crashloop sur les coredns depuis que j'ai mis la nouvelle config. thx pour les pistes c'était bien utile !
Laisser une réponse
Vous devez être connecté pour poster un message !
yo la team, on a un truc chelou sur notre cluster EKS de prod. on a des pods qui n'arrivent plus à résoudre de noms dns genre d'un coup. on check les logs de coredns et on voit qu'ils crashloopent par intermittence. pas de pattern clair pour le moment on a des core-dns en 1.8.6. les pods qui tombent sont pas forcément des gros consommateurs de dns.