Introduction aux Ingress : Routage L7 (HTTP/S)

Ingress : la réponse K8s au routage HTTP/S intelligent

Face aux limitations des Services de type `NodePort` et `LoadBalancer` pour gérer efficacement le trafic web entrant (coût, complexité, manque de fonctionnalités de niveau 7), Kubernetes propose une solution plus puissante et flexible : l'objet Ingress.

Un Ingress est une ressource API (`kind: Ingress`) qui agit comme une couche de configuration pour un proxy inverse ou un équilibreur de charge intelligent à l'entrée du cluster. Il est spécifiquement conçu pour gérer le trafic de niveau 7 (L7), c'est-à-dire les protocoles applicatifs comme HTTP et HTTPS. Il permet de définir des règles sophistiquées pour acheminer les requêtes externes vers les Services appropriés à l'intérieur du cluster.

Pensez à l'Ingress comme au contrôleur de trafic aérien pour vos services web : il examine les caractéristiques de la requête entrante (comme le nom d'hôte demandé ou le chemin d'URL) et la dirige vers la bonne piste d'atterrissage (le bon Service Kubernetes).

Déclarer les règles du jeu : le rôle de l'objet Ingress

L'objet Ingress lui-même ne fait que déclarer un ensemble de règles de routage. Il ne contient pas le code ou la logique pour appliquer ces règles. Il décrit *comment* le trafic HTTP/S entrant doit être traité.

Les fonctionnalités clés que vous pouvez définir via les règles d'un objet Ingress incluent :

• Routage basé sur l'hôte (Virtual Hosting) : Diriger le trafic vers différents Services en fonction du nom d'hôte demandé dans l'en-tête `Host` de la requête HTTP (ex: `api.example.com` vers le service API, `blog.example.com` vers le service du blog).
• Routage basé sur le chemin : Diriger le trafic vers différents Services en fonction du chemin d'URL demandé (ex: `/api` vers le service API, `/ui` vers le service frontend).
• Service backend par défaut : Définir un Service qui recevra tout le trafic qui ne correspond à aucune règle spécifique.
• Terminaison TLS/SSL : Gérer les certificats HTTPS et déchiffrer le trafic TLS au niveau de l'Ingress, avant de le transmettre (potentiellement en HTTP simple) aux Services internes.

Essentiellement, l'Ingress agit comme un point d'entrée unique et configurable pour le trafic web externe, capable de le distribuer intelligemment aux différents services applicatifs tournant dans le cluster.

Le moteur indispensable : le contrôleur Ingress

C'est un point absolument crucial : définir un objet `Ingress` dans Kubernetes ne suffit pas pour que le routage fonctionne. Vous avez besoin d'un contrôleur Ingress actif dans votre cluster.

Le contrôleur Ingress est un composant logiciel (généralement déployé comme un ou plusieurs Pods dans le cluster) qui surveille l'API Kubernetes à la recherche d'objets `Ingress`. Lorsqu'il détecte une ressource Ingress (ou une modification), il lit les règles définies et configure dynamiquement un équilibreur de charge ou un proxy inverse sous-jacent (par exemple Nginx, Traefik, HAProxy, Envoy, ou un équilibreur de charge cloud spécifique) pour implémenter ces règles.

Sans contrôleur Ingress, vos objets Ingress sont simplement ignorés. Il existe de nombreuses implémentations de contrôleurs Ingress, certaines gérées par la communauté (comme Nginx Ingress, très populaire), d'autres fournies par des éditeurs tiers (Traefik, Kong...) ou intégrées par les fournisseurs de cloud (AWS Load Balancer Controller, GKE Ingress Controller...). Vous devez choisir et déployer un contrôleur Ingress adapté à votre environnement.

Avantages clés de l'utilisation d'Ingress

• Consolidation des points d'entrée : Permet d'exposer de nombreux services via une seule adresse IP publique et un seul équilibreur de charge (celui utilisé par le contrôleur Ingress), réduisant les coûts et la complexité par rapport à l'utilisation d'un Service `LoadBalancer` par service.
• Routage L7 flexible : Offre des capacités de routage avancées basées sur les hôtes et les chemins, impossibles avec les Services de base.
• Gestion centralisée des règles : Les règles de routage sont définies de manière déclarative via l'API Kubernetes, facilitant la gestion, l'automatisation et le versionnement (GitOps).
• Terminaison TLS centralisée : Simplifie la gestion des certificats HTTPS en la concentrant au niveau de l'Ingress, plutôt que dans chaque application.
• Standardisation (de l'API) : L'objet API `Ingress` est standardisé dans Kubernetes, même si les fonctionnalités exactes peuvent varier légèrement entre les différents contrôleurs Ingress (souvent via des annotations spécifiques).

Conclusion : la voie royale pour le trafic web

L'Ingress Kubernetes, associé à un contrôleur Ingress fonctionnel, fournit la solution standard et la plus flexible pour gérer le trafic HTTP et HTTPS entrant dans un cluster. En offrant des capacités de routage de niveau 7 et une gestion centralisée, il surmonte les limitations des Services `NodePort` et `LoadBalancer` pour les applications web.

Maintenant que nous avons compris le concept, les prochaines étapes consistent à examiner de plus près le rôle et l'installation des contrôleurs Ingress, puis à apprendre comment définir concrètement les règles de routage et la terminaison TLS dans les manifestes Ingress.