Sobes.tech
Middle+

Comment la redirection du trafic vers l'ingress depuis l'intérieur du cluster est-elle effectuée?

sobes.tech IA

Réponse de l'IA

Pour rediriger le trafic depuis l’intérieur du cluster vers Ingress, on utilise le nom DNS du service du contrôleur Ingress. Dans la configuration standard, le contrôleur Ingress est déployé en tant que Service de type LoadBalancer ou NodePort.

  1. Découverte du service : L’application à l’intérieur du cluster utilise le nom DNS du Service, qui expose (rend visible) le contrôleur Ingress. Par exemple, nginx-ingress-controller.ingress-nginx.svc.cluster.local, si nginx-ingress est utilisé avec le nom de Service correspondant.

  2. IP du Service/ClusterIP : Le serveur DNS du cluster Kubernetes (par exemple, CoreDNS) résout ce nom DNS en ClusterIP du Service du contrôleur Ingress.

  3. kube-proxy : kube-proxy sur le nœud où l’application est en cours d’exécution intercepte le trafic destiné au Service ClusterIP du contrôleur Ingress.

  4. iptables/ipvs : kube-proxy utilise des règles iptables ou ipvs pour router le trafic vers l’un des pods du contrôleur Ingress.

  5. Traitement dans le contrôleur Ingress : Les pods du contrôleur Ingress reçoivent le trafic et, selon les règles des ressources Ingress, le redirigent vers le service correspondant à l’intérieur du cluster.

Exemple de requête depuis un pod :

# Requête au service via Ingress, en utilisant le DNS interne
curl http://my-app.example.com

Ici, my-app.example.com est résolu par le serveur DNS du cluster en ClusterIP du Service du contrôleur Ingress, si les enregistrements appropriés sont configurés ou si le contrôleur Ingress est configuré pour gérer ces requêtes directement (moins courant pour le trafic interne). La majorité du trafic interne accède au service par son nom DNS. Si vous souhaitez explicitement passer par Ingress depuis l’intérieur du cluster, il faut s’assurer que le contrôleur Ingress est accessible via ClusterIP ou IP local des pods et que l’enregistrement DNS ou le mécanisme de routage le dirige vers lui.

Le modèle le plus courant pour la communication entre services dans le cluster est d’accéder directement au service par son nom DNS (<nom-du-service>.<namespace>.svc.cluster.local), en évitant Ingress. La redirection du trafic vers Ingress depuis l’intérieur du cluster est généralement nécessaire pour les tests ou scénarios de routage spécifiques.