Limites des Services NodePort et LoadBalancer pour l'exposition HTTP/S

Exposition externe de base : rappel sur NodePort et LoadBalancer

Pour rendre nos applications déployées dans Kubernetes accessibles depuis l'extérieur du cluster, nous avons découvert deux types de Services principaux : `NodePort` et `LoadBalancer`. Un Service `NodePort` expose l'application sur un port statique sur chaque noeud du cluster, tandis qu'un Service `LoadBalancer` demande la création d'un équilibreur de charge externe (généralement via un fournisseur de cloud) qui pointe vers les noeuds du cluster.

Ces mécanismes sont fonctionnels et suffisants pour des cas d'usage simples, comme exposer un seul service ou des services non-HTTP. Cependant, lorsqu'il s'agit d'exposer plusieurs applications web (sites web, API REST) via les ports standards HTTP (80) et HTTPS (443), ou de mettre en place des règles de routage plus fines, les limites de `NodePort` et `LoadBalancer` deviennent apparentes.

Comprendre ces limitations est essentiel pour apprécier la valeur ajoutée et la nécessité d'une solution de niveau supérieur comme l'Ingress pour la gestion du trafic entrant HTTP/S.

Les contraintes du Service NodePort

Le type `NodePort` présente plusieurs inconvénients majeurs pour l'exposition web :

• Plage de ports limitée et non standard : Par défaut, le NodePort est choisi dans une plage élevée (ex: 30000-32767). Les clients doivent se connecter à une URL comme `http://:30080`, ce qui n'est pas pratique ni standard.
• Dépendance à l'IP du noeud : Le client doit connaître l'adresse IP d'au moins un noeud du cluster. Que se passe-t-il si ce noeud devient indisponible ?
• Nécessité d'un équilibreur de charge externe : En pratique, pour une exposition sérieuse en production, vous placerez presque toujours un équilibreur de charge externe (matériel ou logiciel) devant vos noeuds Kubernetes. Cet LB externe écoutera sur les ports 80/443 et redirigera le trafic vers les NodePorts sur les différents noeuds sains. Vous devez donc gérer cet LB externe séparément.
• Routage de niveau 4 uniquement : Un Service NodePort opère au niveau TCP/UDP. Il ne comprend pas les requêtes HTTP. Il ne peut donc pas effectuer de routage basé sur le nom d'hôte (`Host` header) ou le chemin d'URL (`/api`, `/images`...). Si vous avez plusieurs services web, vous aurez besoin d'un NodePort (et potentiellement d'une règle sur l'LB externe) pour chacun.
• Gestion TLS complexe : La terminaison TLS (déchiffrement HTTPS) doit être gérée soit par l'équilibreur de charge externe, soit directement dans les Pods de l'application, ce qui complique la gestion des certificats.

Les inconvénients du Service LoadBalancer

Le type `LoadBalancer`, bien que plus intégré (surtout dans le cloud), n'est pas non plus une solution parfaite pour tous les scénarios HTTP/S :

• Coût et consommation de ressources Cloud : Le principal inconvénient est que, par défaut, chaque Service de type `LoadBalancer` provisionne son propre équilibreur de charge cloud dédié. Si vous avez des dizaines ou des centaines de microservices web à exposer, cela peut devenir très coûteux en termes de facturation cloud et consommer un nombre important d'adresses IP publiques.
• Principalement niveau 4 : Comme NodePort, le Service `LoadBalancer` standard de Kubernetes est principalement une abstraction de niveau 4. Bien que certains fournisseurs de cloud permettent à leurs équilibreurs de charge de réaliser des fonctions de niveau 7 (routage basé sur l'hôte/chemin, terminaison TLS), la configuration de ces fonctionnalités avancées via l'objet Service Kubernetes standard est souvent limitée, non standardisée, voire impossible. Les annotations spécifiques au fournisseur sont souvent nécessaires, ce qui nuit à la portabilité.
• Pas de point d'entrée unique par défaut : Chaque Service `LoadBalancer` obtient sa propre adresse IP publique. Il n'offre pas nativement un moyen simple de consolider l'accès à plusieurs services derrière une seule adresse IP publique gérée par Kubernetes.
• Gestion TLS limitée via l'API Service : La configuration de la terminaison TLS et la gestion des certificats via les annotations de l'objet Service peuvent être moins flexibles et standardisées que les mécanismes offerts par les Ingress.

Synthèse : le besoin d'une solution de niveau 7

En résumé, ni `NodePort` ni `LoadBalancer` ne fournissent une solution native, standardisée et efficace dans Kubernetes pour les besoins courants de l'exposition de services HTTP/S :

• Routage basé sur le nom d'hôte (virtual hosting).
• Routage basé sur le chemin d'URL.
• Consolidation de plusieurs services derrière une seule adresse IP/un seul équilibreur de charge.
• Terminaison TLS centralisée et gestion des certificats au sein de Kubernetes.

Ces limitations, opérant principalement au niveau 4, rendent la gestion du trafic entrant HTTP/S complexe, coûteuse ou non portable si l'on essaie de les contourner uniquement avec les types de Service de base. C'est précisément pour combler ce manque qu'a été introduit le concept d'Ingress dans Kubernetes, offrant une abstraction standard pour le routage de niveau 7.