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

Question

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

manon-laine · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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

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

8 commentaires

Laisser une réponse

La supervision dans kubernetes

Notre première infrastructure AWS depuis Terraform

Retirer des utilisateurs sur GitLab pour sécuriser votre projet

Les Pages Wiki sur GitLab pour centraliser votre documentation

Le Grand Rapatriement : Le Cloud Native est-il un Échec ?

Rejoindre la communauté