Problème de DNS round-robin avec ingress nginx et service mesh

Posté par olivier61 le 29/11/2024
RÉSOLU

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

# simplified ingress config example
apiversion: networking.k8s.io/v1
kind: ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "120"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "120"
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathtype: prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

Commentaires

manon-laine

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

laurent-fabre

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

tmartins

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

manon-laine

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 ?

olivier61

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

laurent-fabre

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

tmartins

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

olivier61

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

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire