Membre depuis le 06/06/2019
salut. si t'as istio c'est lui le maître dns pour les services internes. t'as ptete une virtualservice ou un destinationrule qui override le comportement dns normal ou qui a des hostnames mal configurés. check tes configs istio pour voir comment il résout le fqdn de tes ingresses
Membre depuis le 16/11/2024
yep et même sans istio, le dns caching au niveau des clients (les pods qui appellent l'ingress) peut être un souci. si ton pod k8s a un dns policy de type "default" il va utiliser le dns du node et c'est pas toujours optimal pour le round-robin des svc. t'as testé avec "ClusterFirst" ou "None" avec un resolv.conf custom dans tes pods clients
Membre depuis le 25/04/2020
ouais et l'ingress nginx lui-même comment il résout les noms des services backend. par défaut il utilise le dns interne de k8s. si tes svc sont stateless et derrière un service k8s normal, il devrait faire du round-robin correct. c'est ptete un souci avec le resolver interne de l'ingress
Membre depuis le 06/06/2019
effectivement pour le resolver de l'ingress, regarde la directive resolver dans ta config nginx. par défaut il utilise /etc/resolv.conf. t'as mis une ip dns fixe ou le service dns k8s (kube-dns/coredns) direct ?
Membre depuis le 21/07/2024
ok je vois. j'ai checké istio et y'avait rien de spécial. par contre le dns policy des pods clients était en "default". je suis passé en "ClusterFirst" et j'ai re-déployé. ça a l'air un peu mieux mais encore des latences
Membre depuis le 16/11/2024
et au niveau de la config ingress elle-même, t'as regardé la directive
nginx.ingress.kubernetes.io/upstream-hash-by: $request_uri ? si tu forces un hash, ça peut coller à un backend. si y'a rien c'est du round-robin pur mais des fois les clients ou le dns cache fausse la donne
Membre depuis le 25/04/2020
et le cas échéant, si tu peux, essaie de passer ton service ingress en headless. comme ça tes clients attaquent directement les pods ingresses sans passer par le kube-proxy. mais attention ça demande de gérer la découverte de service côté client ou avec istio
Membre depuis le 21/07/2024
bon j'ai trouvé. c'était un mélange des deux. le dns policy "default" + le caching dns au niveau du node + istio qui ne propageait pas bien les updates de dns pour les svc ingresses à cause d'une vieille config de sidecar qui trainait. après avoir tout nettoyé et forcé le dns policy à "ClusterFirst" et redéployé les ingress controllers ça roule. merci à tous
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
olivier61
Membre depuis le 21/07/2024
yo la team ! on a un souci avec notre setup k8s. on a plusieurs ingress nginx qui load-balancent vers des services, et on a un service mesh (istio) dessus. le dns round-robin entre les ingresses marche bizarrement, des fois ça colle à une seule instance d'ingress pendant des minutes avant de bouger. on voit des délais bizarres entre les pods qui appellent les ingresses et les ingresses qui forwardent. genre les appels sont pas répartis comme il faut