5 commentaires
yo t'as check les resolv.conf à l'intérieur de tes pods problématiques ils pointent bien vers le service ip de coredns k8s faut pas qu'ils aient un resolv.conf custom ou hérité du host
ah ouais bonne idée je l'avais pas fait ! sur certains pods je vois des adresses dns différentes. ptete un souci avec un daemonset ou un sidecar qui modifie le resolv.conf
bingo ! on a un agent de sécu qui s'injecte et modifie les resolv.conf dans certains namespaces. je vais voir avec le dev pour exclure notre namespace api gateway ou configurer correctement son dns
merci les gars ! c'était bien l'agent de sécu qui foutait le bordel. on l'a configuré pour pas toucher au resolv.conf de nos pods critiques et maintenant c stable. thx !
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la team
on a déployé un nouveau service (un api gateway) dans notre cluster k8s et on a des soucis de résolution dns interne. depuis certains pods dans le même namespace le service est résolu nickel mais depuis d'autres pods ou d'autres namespaces c'est aléatoire genre un coup ça passe un coup ça timeout
les logs de coredns sont cleans coté k8s et j'ai vérifié les NetworkPolicies tout semble ouvert
une idée où regarder