Le réseau sous Kubernetes est un sujet vaste et complexe. Mais il existe une ressource qui a énormément simplifié la gestion de l’accès externe aux services : Ingress.

Les ingresses sont des ressources Kubernetes qui permettent de gérer l’accès externe aux services dans un cluster, en gros, ce sont elles qui font le lien entre l’extérieur et les services internes. Elles permettent de définir des règles de routage basées sur des URL, des hôtes, etc.

C’est quoi un Ingress ? Et la différence avec un LoadBalancer ?

Comme on l’a présenté dans un précédent article, un LoadBalancer est un type de service Kubernetes qui expose un service à l’extérieur du cluster en utilisant un équilibreur de charge. Cet équilibreur de charge est généralement fourni par un cloud provider (AWS, GCP, Azure, etc.) ou par un service tiers comme MetalLB pour les clusters bare-metal.

Image explicative Load balancer

Au début on faisait tout avec des LoadBalancer, c’était la belle époque. Dès qu’on avait une nouvelle application, on créait un nouveau service de type LoadBalancer. On avait une adresse IP publique qu’on pouvait utiliser comme on voulait et où on voulait, DNS, etc. Mais cette approche a ses limites :

  • Coût : Chaque service de type LoadBalancer coûte de l’argent, pensez au cloud, dans le cloud chaque ressource est payante.
  • Complexité : Imaginons dans un cluster on a 10 applications, chacune avec son LoadBalancer, on se retrouve avec 10 adresses IP publiques, 10 règles de firewall, etc. Ce n’est pas sympa pour l’administrateur système de gérer tout ça.
  • Scalabilité : Si on veut ajouter une nouvelle application, on doit créer un nouveau LoadBalancer, ce qui peut devenir ingérable à grande échelle.

C’est pour cela qu’on s’est dit qu’il nous fallait une solution plus flexible, un genre de reverse proxy avec lequel on pourrait avoir une seule adresse IP publique et router le trafic vers les différents services en fonction de certains paramètres comme l’URL, l’hôte, etc. Et c’est là qu’intervient Ingress.

Comment ça marche ?

Déjà il faut faire la différence entre un Ingress et un Ingress Controller. Un Ingress est une ressource Kubernetes officielle qui définit les règles de routage, tandis qu’un Ingress Controller est une implémentation qui applique ces règles et gère le trafic entrant.

C’est comme si vous aviez un Ingress qui est le plan (l’architecte) et un Ingress Controller qui est celui qui va appliquer le plan de l’architecte (l’ouvrier).

Voilà à quoi ça ressemble un Ingress :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
    name: example-ingress
spec:
    rules:
    - host: makhal.fr
        http:
            paths:
            - path: /
                pathType: Prefix
                backend:
                    service:
                        name: example-service
                        port:
                            number: 80

En gros, on lui dit que dès qu’il reçoit une requête pour l’hôte makhal.fr, il doit router la requête vers le service example-service sur le port 80. C’est simple, non ?

alt text

Il ne faut pas croire non plus, que dès qu’on utilise ingress on délaisse totalement les LoadBalancer, on peut toujours les utiliser pour exposer l’Ingress Controller lui-même. En fait, c’est souvent la meilleure pratique de le faire, car cela permet de centraliser la gestion du trafic entrant.

Comme suit :

apiVersion: v1
kind: Service
metadata:
    name: ingress-nginx-controller
spec:
    type: LoadBalancer
    ports:
    - port: 80
        targetPort: 80
    - port: 443
        targetPort: 443
    selector:
        app: ingress-nginx

Dans cet exemple, on expose l’Ingress Controller via un service de type LoadBalancer, ce qui permet d’avoir une adresse IP publique unique pour accéder à tous les services gérés par l’Ingress.

Il existe plusieurs Ingress Controllers disponibles (par exemple NGINX, Traefik, HAProxy, etc.), chacun avec ses propres fonctionnalités et configurations. Mais le truc sympa, c’est que notre seul fichier Ingress reste le même. Tous comprennent l’architecte mais chacun a sa propre manière de construire la maison.

Conclusion

Ingress est une brique essentielle dans le monde Kubernetes. Il permet de centraliser et simplifier l’accès à vos services, en évitant la multiplication de LoadBalancers ou de NodePorts.

Mais attention : créer une ressource Ingress ne suffit pas. Pour que ça fonctionne, il faut déployer un Ingress Controller, qui va appliquer les règles de routage.

C’est justement ce qu’on verra dans un prochain article : Comment déployer un Ingress Controller (comme NGINX ou Traefik) dans un cluster Kubernetes, et rediriger le trafic HTTP vers vos applications.

Jusque-là, n’hésitez pas à tester Ingress dans vos clusters, et à partager vos expériences ou questions dans les commentaires LinkedIn !