API Gateway de Kubernetes

 (romaglushko.com)
4 points par GN⁺ 4 시간 전 | 2 commentaires | Partager sur WhatsApp
  • En novembre 2025, Kubernetes a annoncé la dépréciation en mars 2026 de NGINX Ingress Controller, utilisé sur plus de 40 % de l’ensemble des clusters ; cette décision a marqué un tournant en positionnant Gateway API comme successeur de l’Ingress API
  • Gateway API couvre un large éventail de fonctions nécessaires à la gestion du trafic entrant, avec une expressivité supérieure à celle de l’Ingress API et une séparation des responsabilités plus claire entre les équipes
  • Parmi les limites de l’Ingress API figurent un périmètre API étroit, une extensibilité rigide, l’absence d’application des politiques, des frontières de propriété floues et l’absence de prise en charge sécurisée du cross-namespace
  • Gateway API fournit un modèle de ressources séparées — GatewayClass, Gateway, Listener, Route — ainsi que des mécanismes de sécurité et d’extension comme ReferenceGrant et le Policy attachment
  • Les CVE à répétition de NGINX Ingress Controller proviennent de défauts structurels et, à long terme, la migration vers Gateway API constitue la seule solution de fond

Évolution d’Ingress

  • Dans les premières versions de Kubernetes en 2014, la ressource Service était le moyen de base pour exposer une application
    • ClusterIP ne fournissait qu’un nom DNS interne au cluster, sans accès externe
    • NodePort ouvrait un port spécifique sur tous les nœuds pour recevoir le trafic externe ; si l’IP du nœud était exposée, l’accès depuis l’extérieur devenait possible
    • LoadBalancer provisionnait un load balancer externe avec une IP publique pour acheminer le trafic
    • ExternalName fournissait un alias interne au cluster pour un service externe via un enregistrement CNAME
  • Parmi ces quatre options, seules NodePort et LoadBalancer permettaient une exposition externe directe
    • NodePort est un primitive de base, mais trop bas niveau : il faut implémenter soi-même l’équilibrage de charge externe entre nœuds et le routage basé sur les chemins
  • LoadBalancer ajoute au-dessus de NodePort un load balancer L4 (TCP/UDP) avec provisionnement automatique, pris en charge par le Cloud Controller Manager
    • Mais il faut gérer de nombreuses IP publiques et de nombreux load balancers, ce qui augmente les coûts, sans point central de gestion du trafic
  • Au lieu d’un load balancer distinct par Service, l’idée de faire recevoir tout le trafic par un unique Service de type LoadBalancer, puis de le transmettre à un Deployment de reverse proxy comme NGINX pour le router selon le chemin ou le nom d’hôte, est à l’origine de l’Ingress API et de l’Ingress Controller

Ingress Controller

  • En 2015, l’équipe Kubernetes a introduit l’Ingress API comme moyen de définir des règles de routage du trafic HTTP(S) externe vers des Services internes

  • L’Ingress API se compose de deux ressources, IngressClass et Ingress, et ne définit qu’une interface commune ; pour le comportement réel, il faut installer un Ingress Controller

  • IngressClass

    • Ressource cluster-wide qui indique quel contrôleur doit traiter un ensemble donné de ressources Ingress
    • Elle permet d’exploiter en parallèle plusieurs Ingress Controllers dans un même cluster ; chaque contrôleur ne surveille que les ressources sélectionnées via son IngressClass
    • Le contrôleur a besoin des autorisations ClusterRole pour lire et utiliser IngressClass

  • Ressource Ingress

    • Ingress est la ressource principale de l’Ingress API et combine plusieurs éléments
      • définition du routage vers des Services internes avec des règles de correspondance basées sur les chemins (exact/prefix) et les hôtes
      • définition de la configuration TLS du trafic entrant
    • Lors de la création de la ressource, l’Ingress Controller la détecte, met à jour sa propre configuration et applique les règles de routage

  • Problèmes de l’Ingress API

    • En environnement de production réel, les problèmes suivants apparaissent : périmètre API très limité, extensibilité rigide, absence d’application des politiques, frontières de propriété floues, absence de prise en charge sécurisée du cross-namespace

  • Périmètre API très limité

    • L’Ingress API n’est pas simplement simple, elle est simpliste, car elle ne couvre que le strict minimum nécessaire à la configuration du trafic entrant
    • Elle ne prend pas directement en charge les fonctions suivantes, pourtant courantes avec NGINX
      • request timeout, CORS, limite de taille maximale du body, sessions sticky cookie, répartition de trafic canary, rate limiting, routage basé sur les headers, les query parameters ou les cookies, modification des headers
    • En conséquence, les annotations personnalisées sont devenues la méthode standard pour transmettre des réglages supplémentaires, et certains contrôleurs comme Traefik utilisent leurs propres CRD
    • Quand plusieurs Ingress Controllers sont utilisés simultanément, l’absence de méthode de configuration unifiée et les annotations différentes selon le contrôleur dégradent la portabilité
    • Ingress ne traite que le routage HTTP(S) ; gRPC (L7), TCP et UDP (L4) sont gérés par des annotations personnalisées selon l’implémentation

  • Extensibilité rigide

    • Les annotations personnalisées ne sont que des paires clé-valeur sous forme de chaîne ; comme les configurations complexes doivent être sérialisées en texte, l’expressivité est insuffisante

  • Absence d’application des politiques

    • Les équipes applicatives peuvent ajouter des annotations arbitraires à une ressource Ingress ; par exemple, elles peuvent désactiver un rate limiting que l’équipe plateforme attend sur toutes les routes
    • Comme l’Ingress API elle-même ne fournit aucun mécanisme pour imposer un comportement global, elle dépend de moteurs de politiques externes comme Kyverno ou OPA Gatekeeper

  • Frontières de propriété floues

    • La ressource Ingress mélange plusieurs types de configuration
      • les règles de routage relèvent généralement de l’équipe applicative
      • les réglages de hostname et de port relèvent de l’équipe plateforme, qui gère DNS, load balancers et réseau
      • les réglages TLS relèvent de l’équipe plateforme, en charge du provisionnement des certificats
      • les annotations personnalisées peuvent relever de l’une ou l’autre équipe
    • Dans les systèmes complexes déployés via un umbrella Helm chart, Ingress se trouve généralement dans un subchart applicatif, alors que l’équipe plateforme doit aussi pouvoir en mettre à jour ou en imposer certains aspects
    • Du point de vue du principe de responsabilité unique, Ingress a plus d’une raison de changer ; il est donc préférable de le scinder en ressources plus ciblées
    Publicité

  • Absence de prise en charge sécurisée du cross-namespace

    • Une ressource Ingress ne peut pas référencer un Service ou un secret TLS en dehors de son propre namespace, et rules[].backend.service ne contient même pas de champ pour spécifier un namespace
    • Comme contournement, on peut créer dans le même namespace un Service ExternalName pointant vers le nom DNS interne au cluster du Service cible
    • Mais cette méthode introduit immédiatement un problème relevant d’une confused deputy attack

Gateway API

  • Gateway API est la nouvelle génération de l’Ingress API et lève ces limites grâce aux éléments suivants
    • elle couvre un éventail bien plus large de fonctions nécessaires à la gestion du trafic entrant, avec une expressivité renforcée
    • elle clarifie la séparation des responsabilités entre les équipes en reflétant les schémas habituels de propriété des ressources
    • elle inclut un mécanisme d’extension défini appelé policies, ainsi que des références d’objets cross-namespace flexibles

GatewayClass

  • À l’image d’IngressClass, il définit un ensemble de Gateways appartenant à un déploiement donné de Gateway Controller ; son sens et sa structure sont en pratique les mêmes qu’IngressClass
  • Il peut référencer une custom resource contenant des paramètres supplémentaires propres à l’implémentation du Gateway
    • mode d’exposition du proxy Gateway, paramètres par défaut de bootstrap et d’exécution, stratégie de rollout et de scaling du déploiement, ainsi que d’autres options propres au contrôleur

Gateway

  • La ressource Gateway représente un edge gateway provisionné dynamiquement, abstraction d’infrastructure qui reçoit le trafic entrant et le route vers les services backend appropriés

    • dans la conception d’Ingress, c’est l’Ingress Controller qui jouait ce rôle ; on peut donc le voir comme une instance de Gateway provisionnée statiquement

  • Chaque Gateway référence une GatewayClass pour indiquer quel contrôleur doit le provisionner et le gérer ; son composant le plus important est la liste des listeners

  • Listeners

    • Définit la manière dont un Gateway accepte le trafic entrant ; chaque listener est un point d’entrée distinct, décrit par une combinaison port·protocole·hostname
    • La configuration de la terminaison TLS est possible ; dans l’univers Ingress, cette information se trouvait dans la ressource Ingress
    • L’unité la plus fine à laquelle une Route peut être attachée sur un Gateway

  • ListenerSet

    • Les listeners sont utiles pour centraliser la configuration des points d’entrée, mais ne conviennent pas lorsqu’il en faut des centaines
    • Le cas principal est celui de listeners HTTPS avec des paramètres hostname·TLS propres à chaque service, au lieu d’un unique certificat TLS wildcard ; on peut alors se retrouver avec autant de listeners que de microservices
    • Deux problèmes apparaissent lorsqu’on modélise cela avec un seul Gateway
      • Un Gateway ne prend en charge que 64 listeners au maximum
      • Si plusieurs équipes gèrent les listeners·TLS, le Gateway devient un goulot d’étranglement de coordination
    • Pour distribuer cela et le rendre multi-tenant, on utilise la ressource ListenerSet

  • Listeners et Routes autorisés

    • Une fois les concepts de Gateway et de Route séparés, un nouveau problème apparaît : contrôler quels tenants peuvent attacher quelles Routes à quels listeners
    • Les listeners constituent une infrastructure partagée aux usages différents ; par exemple, il n’est pas approprié d’attacher une HTTPRoute au listener tls-passthrough-db, qui sert de canal passthrough vers une base de données, et il n’est pas non plus approprié d’y attacher une Route depuis un namespace autre que db
    • Comme les Routes sont ajoutées de manière autonome, on utilise le mécanisme allowedRoutes pour éviter les mauvaises configurations
    • allowedRoutes établit une relation de confiance entre un Gateway·ListenerSet et des Routes de certains namespaces·types de route

Routes

  • Les listeners reçoivent le trafic, mais ne savent pas comment le traiter ensuite ; c’est le rôle des ressources Route, au cœur de la flexibilité de la Gateway API

  • Il existe cinq types de ressources Route pour gérer plusieurs protocoles

    • HTTPRoute : routage du trafic HTTP renforcé et étendu
    • GRPCRoute : routage conscient de gRPC
    • TLSRoute : routage basé sur le SNI TLS
    • TCPRoute·UDPRoute : transmission directe du trafic TCP/UDP d’un port listener vers un backend
    Publicité

  • Toutes les ressources Route (appelées collectivement xRoutes) partagent une structure d’enveloppe similaire

    • parentRefs est une référence d’objet typée vers la ressource parente qui accueille la Route (le plus souvent un Gateway, un ListenerSet, un Service de service mesh, etc.) ; les options sectionName·port permettent de cibler un listener précis
    • rules contient les règles de routage, filtres et paramètres propres au protocole ; chaque rule se compose de matches, de filters optionnels et de backendRefs optionnels ; si un filtre traite entièrement la requête, backendRefs peut être omis
    • Si le protocole l’autorise, le champ hostnames permet un routage basé sur l’hôte au niveau de la Route

  • HTTPRoute

    • Définit des règles de routage du trafic HTTP(S) au niveau L7

    • Correspondance du trafic

      • Prend en charge un routage par path·host similaire à Ingress, ainsi que des règles de correspondance basées sur les headers, les query parameters et la méthode
      • Exemple : il est possible d’orienter, via une correspondance basée sur les headers, une release canary réservée aux clients internes vers un déploiement de test
      • Le data plane applique la règle la plus spécifique ; l’ordre de définition des règles n’a donc pas d’importance

    • Réécriture d’URL

      • Des filtres permettent de réécrire une partie de l’URL de la requête avant qu’elle n’atteigne le backend

    • Modifications des headers

      • Un filtre HeaderModifier est fourni pour ajouter, supprimer ou modifier les headers de requête·réponse
      • Un filtre CORS dédié est fourni pour la configuration du Cross-Origin Resource Sharing ; conceptuellement, c’est un cas particulier de modification des headers de réponse, mais il est exposé comme un type de filtre distinct

    • Redirections

      • Il est possible de renvoyer au client une réponse de redirection au lieu de transmettre au backend, avec prise en charge des redirections basées sur le path en 3xx et des redirections HTTP→HTTPS

    • Contrôle du trafic

      • Le poids permet de répartir le trafic entre plusieurs services backend, ce qui est utile pour les déploiements blue-green ou les tests A/B
      • Le traffic mirroring envoie une copie du trafic de production vers un backend supplémentaire, configuré avec le filtre RequestMirror, tandis que la requête d’origine continue vers le backend principal
      • Le mirroring est un composant clé du tap-and-compare testing, qui consiste à comparer les résultats de l’ancienne et de la nouvelle version lors d’une refactorisation ou d’une migration

    • Sessions persistantes

      • La persistance de session est prise en charge ; un cookie ou un header peut servir de marqueur de session afin d’acheminer de manière cohérente les requêtes d’un même client vers la même instance backend

    • Authentification externe

      • Prise en charge d’un filtre expérimental d’authentification externe basé sur gRPC ou HTTP ; le Gateway envoie les headers de la requête à un service d’authentification externe avant la transmission au backend, et le corps de la requête n’est envoyé qu’en cas d’activation explicite
      • Dans le cas de gRPC, le service d’authentification externe doit implémenter l’API protobuf ext_authz d’Envoy
      • Dans le cas de HTTP, un 200 indique une authentification réussie ; tout autre statut est traité comme un échec d’authentification

    • Retries et timeouts

      • Il est possible de configurer des retries pour une route donnée, et BackendTrafficPolicy fournit un budget global de retries afin d’éviter les retry storms

  • GRPCRoute

    • Comme gRPC repose sur HTTP/2, il peut aussi être géré avec HTTPRoute, mais il existe plusieurs raisons de le modéliser comme une ressource distincte
      • Cela permet de séparer les options sans sens pour gRPC, comme la réécriture d’URL, et de faire évoluer chaque ressource indépendamment selon son protocole
      • Une réponse gRPC peut renvoyer un HTTP 200 tout en exprimant une erreur applicative via les headers grpc-status et grpc-message, ce qui est important pour les retries corrects et les métriques
      • Définir les règles avec une terminologie gRPC de plus haut niveau améliore l’expérience utilisateur
    • Le path matcher de HTTPRoute est remplacé par un method matcher ; en interne, c’est toujours le path qui est comparé, mais il est exposé sous la forme service·method
    • Le traitement des headers de requête·réponse est possible, mais le payload gRPC n’est pas décodé ; il n’est donc pas possible de router selon certains champs protobuf
    • Prend en charge une partie des filtres de HTTPRoute, comme le traffic mirroring, le weighted load balancing et la modification des headers

  • TCPRoute et UDPRoute

    • Le trafic arrivant sur le port listener est simplement transmis au service backend ; les matchers et filtres ne sont actuellement pas pris en charge
    • Les deux types prennent en charge le weighted load balancing entre plusieurs backends

  • TLSRoute

    • Route le trafic TLS chiffré vers un backend en se basant sur le SNI fourni pendant le handshake TLS
    • Principalement utilisé pour le TLS passthrough : le Gateway inspecte le SNI pour choisir le backend, puis transmet la connexion chiffrée sans terminer TLS, la terminaison étant assurée par le backend
    • Certaines implémentations comme Envoy Gateway ou kgateway prennent aussi en charge la terminaison TLS en edge, mais il s’agit d’une extension
    • La Route doit spécifier un hostname, qui doit correspondre à la valeur SNI et avoir une intersection avec le hostname du listener du Gateway ; les matchers et filtres ne sont pas pris en charge, mais le weighted load balancing l’est

  • Extensions de filtres Route

    • HTTPRoute et GRPCRoute incluent, via le filtre extensionRef, un mécanisme d’extension pour les filtres personnalisés et le traitement des requêtes/réponses, qui pointe vers une autre ressource au moyen d’une référence d’objet typée
    • Exemple : Envoy Gateway fournit une CRD HTTPRouteFilter capable de renvoyer directement une réponse sans service backend

  • Cibles backend

    • Prend en charge par défaut Service standard (le cas le plus courant) et ServiceImport pour le multicluster comme cibles backend
    • Comme elles sont désignées via une référence d’objet typée, elles peuvent être étendues avec des custom resources propres à chaque implémentation
    • Exemple : Envoy Gateway prend en charge une custom resource Backend pointant vers des upstreams externes comme des FQDN, des IP ou des sockets UNIX
    Publicité

  • ReferenceGrant

    • Gateway API traite les références inter-espaces de noms comme un concept de premier plan dans sa conception standard, mais cela présente des risques de sécurité
    • Cas d’attaque de type confused deputy attack : si un attaquant prend le contrôle d’un namespace, il peut exploiter les droits de création sur Ingress, Service et EndpointSlice pour détourner l’accès à des services protégés
      • Un nouvel Ingress pointe vers un nouveau Service du namespace compromis
      • Ce Service n’a pas de selector ; il ne correspond donc à aucun deployment et permet de fournir manuellement un EndpointSlice
      • L’attaquant falsifie un EndpointSlice pour y inclure les IP de pods backend protégés d’un autre namespace, puis crée par alignement de ports une seconde voie d’accès à l’API protégée
      • Le même résultat peut aussi être obtenu avec un Service ExternalName
    • Pour atténuer cela, la ressource ReferenceGrant a été introduite : il s’agit d’un mécanisme de confiance bidirectionnel par lequel un namespace définit quels autres namespaces sont autorisés à référencer ses ressources
    • Le Gateway Controller prend ReferenceGrant en compte lors des références inter-espaces de noms vers une cible backend ou un secret TLS, ce qui rend la confused deputy attack plus difficile
    • Toutefois, ReferenceGrant ne garantit que la légitimité de la référence et n’intervient pas dans le comportement après l’acheminement du trafic ; on peut compléter cela en bloquant l’accès au port de l’API protégée avec des NetworkPolicies

Policies

  • L’attachement de Policy est un puissant modèle d’extension qui applique des comportements et des effets hiérarchiquement à un ou plusieurs composants de Gateway API sans modifier la ressource d’origine
  • L’authentification en est l’exemple le plus représentatif
    • Si l’on applique une authentification à l’ensemble d’un Gateway (ou d’un ListenerSet), elle affecte hiérarchiquement toutes les Route actuellement et ultérieurement attachées, tout en permettant des exceptions au niveau Route, comme des routes publiques
    • L’authentification peut être contrôlée par une équipe indépendante de Gateway et de Route, de sorte que ces ressources n’ont pas besoin d’être modifiées directement
    • Même s’il existe des standards comme OAuth 2 et OIDC, la configuration de l’authentification dépend fortement des implémentations ; il est donc difficile de créer une abstraction commune à toutes
  • Exemple : avec la ressource SecurityPolicy d’Envoy Gateway, on configure la validation des tokens JWT ; les Policy remplacent de manière moderne et plus expressive les configurations basées sur des annotations de l’ère Ingress
  • Il n’existe que deux Policy fournies en standard
    • BackendTLSPolicy : indique au Gateway de se connecter au backend upstream en TLS
    • BackendTrafficPolicy : définit le retry budget d’un backend donné ; si l’allocation globale de retries est dépassée, un 503 est renvoyé ; cela agit comme un circuit breaker et évite les retry storms

Ownership

  • Dans un cluster, les ressources Gateway API appartiennent généralement à deux équipes
    • La Platform team définit GatewayClass, Gateway, ListenerSet ainsi que les paramètres de LoadBalancer et de TLS, et peut gérer des Policy globales appliquées à une partie ou à l’ensemble des Gateway
    • L’Application/Service team se concentre principalement sur ses propres ressources Route et applique si nécessaire des Policy au niveau Route
  • La flexibilité est élevée, ce qui permet aussi de mettre en place différents modèles de propriété, par exemple en regroupant les Route dans un namespace détenu par la platform team

Architecture typique

  • Gateway API ne présuppose pas fortement une architecture d’implémentation, mais l’approche la plus courante est la séparation entre control plane et data plane
  • Le Gateway Controller joue le rôle de control plane sous forme d’opérateur Kubernetes ; il observe les ressources Gateway API et les CRD pour composer la configuration souhaitée du data plane, et a besoin de privilèges étendus pour lire et modifier les ressources
  • Le data plane du Gateway est un proxy qui traite le trafic selon la configuration ; on utilise souvent Envoy Proxy, NGINX ou Traefik, avec selon les implémentations soit un proxy provisionné par Gateway, soit un proxy mutualisé
  • La séparation control plane/data plane constitue un choix de conception avantageux pour éviter les failles de sécurité fondamentales observées dans NGINX Ingress Controller

Migration depuis Ingress

  • Il existe quatre options pour répondre à la dépréciation de NGINX Ingress Controller, à examiner dans l’ordre croissant d’intrusivité

  • Ne rien faire

    • Ce n’est pas l’idéal, mais c’est envisageable dans certains cas ; dans un homelab, la motivation peut être faible

    • En entreprise, cela est difficilement acceptable à cause des cadres réglementaires, de sécurité et de conformité qui attendent l’exploitation de logiciels maintenus et corrigés

      • ISO 27001 : attend la gestion des vulnérabilités, l’application des correctifs et le suivi de l’EOL
      • SOC 2 Type II : attend des scans de vulnérabilités, la gestion des correctifs et des SLA de remédiation
      • HIPAA Security Rule : impose d’inclure les logiciels hérités ou non corrigés dans l’analyse des risques
      • PCI DSS v4.0.1 : exige l’identification des composants non pris en charge, un plan de remédiation et fixe des délais de traitement pour les vulnérabilités critiques
      • FedRAMP : attend le remplacement des logiciels non pris en charge par des alternatives maintenues, avec des délais de remédiation selon la gravité

    • Dans la plupart des cadres, un logiciel en fin de vie devient un vrai problème dès que de nouvelles vulnérabilités sont publiées

    • Analyse des CVE

      • Situation des CVE de NGINX Ingress Controller sur les 5 dernières années
        • 20 vulnérabilités au total
        • En 2021, 4 vulnérabilités High liées à des fuites de secrets
        • En 2022, 1 vulnérabilité High liée à une fuite d’identifiants du contrôleur
        • En 2023~2024, 3 vulnérabilités High
        • En 2025, 6 vulnérabilités, dont 1 Critical (IngressNightmare) et 4 High liées à l’injection de configuration NGINX
        • En 2026, 6 vulnérabilités, dont 3 High liées à l’injection de configuration NGINX
      • Les CVE de 2021~2022 concernaient surtout des configurations NGINX fournies par l’utilisateur et non assainies dans les annotations, provoquant injection de configuration, divulgation d’informations et fuite de secrets ; Kubernetes a ajouté de la validation
      • Les CVE de 2023~2024 étaient principalement des contournements de cette validation des annotations
      • IngressNightmare (CVE-2025-1974) a aggravé la situation : auparavant, il fallait des droits de création ou de modification sur les ressources Ingress, mais un simple accès réseau à l’admission controller suffisait désormais pour obtenir une exécution de code à distance dans le contexte du contrôleur ingress-nginx via un bug proche de l’injection de configuration ; ensuite, les Secrets accessibles par le contrôleur pouvaient être exfiltrés
      • La vague de 2026 poursuit elle aussi le même schéma d’injection de configuration via annotations, chemins et commentaires
      • Ces vulnérabilités visent de manière répétée la même faiblesse de conception
        • Le contrôleur est très flexible et expose un large éventail de fonctionnalités NGINX, rendant une validation parfaite difficile et favorisant la répétition des injections de configuration
        • Le contrôleur exécute le control plane et le data plane dans le même pod et partage le système de fichiers, ce qui élargit l’impact en cas d’incident
        • Le contrôleur a souvent accès aux Secrets à l’échelle du cluster ; une injection de configuration réussie peut donc entraîner une fuite de secrets à l’échelle du cluster
      • En raison de ces problèmes structurels, d’autres CVE sont probables à l’avenir ; rester sur le contrôleur d’origine sans plan de migration est un choix risqué
      Publicité

  • Utiliser un fork du contrôleur NGINX

    • La voie la plus simple consiste à passer à un fork maintenu
      • Le fork de Chainguard ne semble pas fournir d’images préconstruites, ce qui paraît faire partie de son offre commerciale
    • Cela permet de réduire le risque d’exposition à de nouvelles CVE et de maintenir le système sans changements majeurs, mais ce n’est qu’une solution de court terme
    • Chainguard n’entend pas poursuivre le développement du contrôleur comme projet de long terme ; l’objectif est plutôt de fournir, sur la base du best effort, des correctifs CVE pour laisser aux utilisateurs le temps de migrer

  • Utiliser un autre Ingress Controller

    • La ressource Ingress elle-même n’est pas deprecated, donc migrer vers un autre Ingress Controller maintenu reste une option valable, notamment HAProxy·Istio·Traefik
    • Une migration des annotations à l’échelle du système est nécessaire, avec une difficulté variable selon le niveau de dépendance aux fonctionnalités spécifiques à NGINX
    • À l’avenir, davantage de projets migreront vers Gateway API et la part d’Ingress diminuera, mais Ingress reste tout à fait acceptable pour le moment

  • Migration vers Gateway API

    • La seule option viable à long terme est de passer de l’API Ingress à Gateway API
      • Installer les CRD et l’implémentation de Gateway API
      • Configurer les ressources GatewayClass, Gateway et, si nécessaire, Policy
      • Migrer les ressources Ingress existantes vers des Route
    • La CLI ingress2gateway créée par l’équipe Kubernetes fournit une conversion automatique en best-effort, mais les annotations custom doivent ensuite être revérifiées manuellement
    • Il faut migrer précisément les timeouts, les limites d’upload de fichiers, les limites de taille du body, etc. ; sinon des oublis ou de mauvais mappings peuvent casser discrètement les hypothèses de l’application
    • Il faut planifier avec soin le basculement du trafic depuis le LoadBalancer de l’Ingress Controller vers le LoadBalancer du nouveau proxy Gateway, sans qu’un big-bang soit nécessaire
      • Il est possible de conserver temporairement l’Ingress Controller comme point d’entrée public et de n’envoyer qu’une partie du trafic vers le data plane Gateway API afin de tester en trafic réel avant une transition progressive

Quel Gateway choisir

  • Une fois la migration décidée, la première grande question est de savoir quelle implémentation de Gateway API utiliser

  • Dans cet article, le cas d’usage d’un API Gateway générique est défini comme une passerelle scalable pour le trafic public North-South, déployée dans un environnement entièrement maîtrisé, avec des schémas d’authentification courants et un rate limiting flexible fournis par défaut

  • Il existe aussi des LLM Gateway et des Agent Gateway, mais cette section se concentre sur l’API Gateway classique

  • Gateway API Conformance

    • L’équipe Kubernetes a mis en place des tests de conformance standard pour vérifier la justesse du traitement des protocoles essentiels par les implémentations ; ils portent surtout sur le comportement fonctionnel et n’incluent pas les aspects non fonctionnels comme la fiabilité, les performances, la scalabilité ou la complexité opérationnelle
    • Il est préférable de privilégier les implémentations conformant, et si les résultats n’apparaissent pas sur le site officiel, il est recommandé de demander le rapport de conformance aux mainteneurs

  • Benchmarks publics

    • En plus des tests officiels, il existe des benchmarks publics portant sur la fiabilité et les performances. John Howard, contributeur à Istio et employé de Solo.io, a réalisé des benchmarks sur les principales implémentations ; Solo.io est la maison mère de kgateway
    • Ils incluent des cas de test utiles sur le route attachment, la propagation, la montée en charge et les performances de traitement du trafic standard ; comme ils reposent sur son expérience, ils peuvent être biaisés vers certains cas d’usage, mais restent utiles comme angle d’évaluation

  • OSS vs propriétaire

    • Il existe aujourd’hui de nombreuses implémentations OSS de Gateway API solides et prêtes pour la production, à considérer sérieusement lors de l’évaluation ; pour beaucoup d’organisations, l’OSS constitue le point de départ naturel
    • Des fonctionnalités naguère suffisantes pour justifier un achat commercial, comme OAuth2 ou OIDC, sont devenues des commodities, et les contrôleurs OSS les fournissent aussi nativement
    • Avec l’OSS, on peut évaluer directement la qualité avant de s’engager, alors qu’avec le commercial il faut faire confiance au vendor très tôt

  • Recommandations

    • Regroupement par data plane

      • Basés sur Envoy Proxy : Envoy Gateway, Istio, Cilium, kgateway, etc.
      • Basés sur NGINX : NGINX Gateway Fabric, Kong
      • Autres proxy : HAProxy Ingress, Traefik

    • Envoy Gateway

      • Contrôleur Gateway API open source basé sur Envoy Proxy, développé par l’équipe Envoy Proxy ; il mappe les fonctionnalités d’Envoy vers Gateway API aussi directement que possible, avec moins d’abstractions spécifiques au produit qu’Istio, ce qui le rend plus facile à comprendre
      • L’API Ingress n’est pas prise en charge, mais il peut étendre ses fonctionnalités vers des LLM, un gateway MCP et des Inference Pools via Envoy AI Gateway
      • Léger et simple à déployer comme à exploiter, il se concentre sur l’API Gateway (North-South) et prend en charge
        • des schémas de sécurité comme l’authentification externe, la validation JWT, l’authorization basée sur les claims JWT, OIDC, l’allowlisting d’IP, l’authentification par clé API statique et l’injection de credentials
        • une policy flexible de global rate limit avec configuration globale ou au niveau des routes, shadow mode, paramétrage du coût des requêtes, etc.
        • des limites de connexions, de bande passante et de taille de fichiers, le routage tenant compte des availability zones, le multicluster natif basé sur ServiceImport, la compression de réponse Brotli·gzip·zstd, ainsi que direct response et response override
        Publicité
      • Il est aussi très extensible : il est possible d’écrire des services gRPC pour modifier les requêtes, les réponses et la configuration xDS, ainsi que des plugins en Lua ou dans des langages compilables en WASM (Go·Rust)
      • Il inclut une ressource custom Backend capable de pointer vers des ressources externes FQDN·IP ainsi que vers des sockets UNIX pour sidecar
      • Il est actuellement listé comme partially conformant en raison de certains tests ignorés, mais couvre en pratique presque tous les points fonctionnels et s’intègre à des projets CNCF comme KEDA ou KNative
      • Si l’on a seulement besoin d’un API Gateway riche en fonctionnalités, c’est un bon choix

    • Istio

      • Service mesh basé sur Envoy Proxy et projet CNCF Graduated, listé comme conformant aux tests Gateway API
      • C’est un ensemble qui inclut un Ingress Controller, un contrôleur Gateway API et un service mesh ; avec l’intégration agentgateway, il peut aussi fournir des fonctions de gateway LLM, MCP et A2A
      • Il prend en charge le multicluster avancé via Admiral, etc., dispose de profils de déploiement variés, d’une grande communauté et de nombreuses ressources comme des ouvrages O'Reilly ; son chiffrement pod-to-pod en mTLS est utile dans les environnements gouvernementaux ou FedRAMP
      • En contrepartie, le mode sidecar consomme beaucoup de ressources et son grand nombre de concepts propres implique une courbe d’apprentissage raide
      • Le ambient mode propose une configuration plus légère, mais peut être moins complet que le sidecar pour les cas L7 avancés ; si des policies plus fortes ou un contrôle L7 plus poussé sont nécessaires, on peut envisager d’utiliser Envoy Gateway en complément comme ingress gateway et waypoint proxy
      • C’est le meilleur choix quand le service mesh est prioritaire et Gateway API secondaire ; si l’on ne cherche qu’un API gateway, il peut sembler un peu excessif

    • kgateway

      • Gateway open source CNCF Sandbox basé sur le projet Gloo, avec prise en charge de Envoy Proxy et de agentgateway (fonctionnalités d’AI gateway) comme data plane, et possibilité d’utiliser des instances de data plane propres gérées à l’extérieur
      • Il affiche une conformance Gateway API parfaite, en étant presque le seul à satisfaire tous les points
      • Sur le data plane Envoy, il expose la validation JWT, OAuth2/OIDC, l’authentification externe, le contrôle d’accès IP, le global rate limiting d’Envoy, ainsi que le traitement des requêtes et réponses via ext_proc, mais il ne semble pas exposer les plugins Lua·WASM ni la modification directe brute de xDS
      • Son puissant moteur de transformation basé sur les templates MiniJinja permet de définir déclarativement, dans les ressources TrafficPolicy, des transformations de headers, de body de réponse et de status
      • Il peut s’intégrer à Istio comme edge proxy, mais ne joue pas lui-même le rôle de service mesh ; il prend en charge les Route hiérarchiques, où une Route délègue le traitement du trafic à une autre Route, et dispose d’une CRD custom AwsLambda pour appeler directement AWS Lambda
      • Malgré les affirmations du vendor sur l’ampleur de son déploiement, les retours indépendants restent encore limités ; du point de vue de la communauté publique, le projet semble donc encore en phase de croissance

  • Traefik

    • Reverse proxy open source populaire écrit en Go, prenant en charge à la fois l’Ingress API et la Gateway API, particulièrement apprécié dans la communauté homelab grâce à une excellente documentation, une base de code bien structurée, une configuration simple et un déploiement facile

    • Prend en charge les fonctionnalités essentielles de la Gateway API ainsi que quelques fonctions supplémentaires, mais ListenerSet et le traffic mirroring via la Gateway API ne sont pas encore pris en charge (le mirroring reste possible avec un backend TraefikService personnalisé)

    • Le modèle d’extension repose sur les middleware : les filtres ExtensionRef relient les Routes aux CRD Middleware, et les middleware intégrés fournissent notamment ForwardAuth (délégation d’authentification externe, similaire à Envoy ext_authz), l’allowlisting IP et le CORS, les limites de connexion, retry et circuit breaker, ainsi que la compression et les pages d’erreur personnalisées

    • Les middleware Plugin permettent de brancher des plugins YAEGI et WASM personnalisés (principalement pour modifier les requêtes et réponses), mais la validation JWT, OIDC et OAuth2 Client Credentials ne sont disponibles que sous forme de plugins payants

    • Le CRD Middleware prend en charge un rate limiting distribué de base (compartiments par IP, host et header), mais la configuration manque de souplesse et, comme il est attaché via ExtensionRef plutôt que via un policy attachment, une hiérarchisation du type application globale puis surcharge au niveau des routes est difficile

    • L’absence de séparation claire entre control plane et data plane donne une architecture plus proche de NGINX Ingress : le même pod surveille les ressources et traite le trafic, un proxy n’est pas provisionné dynamiquement pour chaque Gateway, et un déploiement unique gère tous les Gateway du namespace surveillé, ce qui peut créer un point de défaillance unique, réduire l’isolation et poser des problèmes de résilience à grande échelle

    • En cas de choix de Traefik, il est recommandé d’effectuer des tests de charge selon le trafic attendu, d’autant plus que des critiques sur ses performances existent

    • NGINX Gateway Fabric

      • Implémentation officielle de la Gateway API par F5 basée sur NGINX (NGF), avec une conformance solide ; les versions récentes ajoutent la prise en charge de Gateway API 1.5 ainsi que du CORS et de la modification des en-têtes de requête/réponse via les filtres HTTPRoute standard
      • Certaines fonctionnalités, comme l’authentification JWT et OIDC, la persistance de session basée sur les cookies ou la mise à jour des upstreams sans rechargement NGINX, restent dépendantes de NGINX Plus, alors qu’il s’agit d’exigences courantes pour un API Gateway
      • Les SnippetsPolicy et SnippetsFilter personnalisés permettent d’injecter des configurations NGINX personnalisées à différents niveaux de la configuration générée, ce qui facilite la migration sans avoir à réécrire les nombreuses configurations personnalisées existantes de NGINX Ingress
      • Le RateLimitPolicy personnalisé prend en charge le rate limiting, mais il s’agit de local rate limiting : l’état réside donc dans le data plane NGINX, et lorsqu’on exécute plusieurs réplicas NGF, la limite effective varie selon le nombre d’instances, ce qui complique l’application stricte de limites par utilisateur
      • Comme échappatoire d’extension propre à NGINX, il propose des scripts légers en JavaScript et Lua, auth_request pour déléguer l’authentification externe (similaire à Envoy ext_authz et Traefik ForwardAuth), ainsi que des modules C personnalisés ; en revanche, la modification des requêtes/réponses via un service externe de type ext_proc n’est pas prise en charge
      • Avec NGF 2.0, l’architecture a été remaniée pour séparer control plane et data plane et prendre en charge plusieurs ressources Gateway ; auparavant, l’architecture constituait une préoccupation majeure

    • Cilium Service Mesh

      • De nombreux clusters utilisent Cilium comme CNI ; son service mesh sidecar-less basé sur eBPF inclut une implémentation de la Gateway API fondée sur Envoy Proxy, ce qui permet de réduire le nombre de composants et d’alléger la pile technique
      • Cela reste toutefois principalement centré sur la conformance Gateway API, et des fonctions Envoy utiles hors Gateway API ne sont pas exposées comme configurations de premier plan ; par exemple, il n’existe pas de prise en charge de premier plan pour les extensions et plugins Envoy, l’allowlisting IP, la validation JWT, l’autorisation basée sur les claims ou OIDC
      • À moins d’être certain que les fonctionnalités actuelles de la Gateway API dans Cilium suffisent, il n’est pas recommandé comme API Gateway généraliste face à des options plus riches comme Envoy Gateway, kgateway ou Istio

    • Kong

      • API Gateway populaire basé sur NGINX, dont le Kong Operator prend en charge à la fois l’Ingress et la Gateway API
      • La principale inquiétude concerne la stratégie OSS : il semble que la publication d’images Docker précompilées pour les nouvelles versions de la Gateway open source ait été interrompue, et que les images OSS se soient arrêtées autour de la branche de release 3.10, ce qui pourrait imposer de construire, corriger, renforcer et maintenir soi-même
      • Il existe des spéculations publiques selon lesquelles cette décision viserait à limiter le départ de clients enterprise ; cela ne peut pas être tenu pour un fait établi, mais l’orientation OSS paraît moins prévisible
      • En conséquence, cela n’est pas recommandé à moins d’acheter une licence enterprise ou d’être prêt à assumer soi-même le packaging et la maintenance de la version OSS

Summary

  • Retrace l’évolution du modèle d’ingress Kubernetes, depuis ses débuts jusqu’à l’ère de la Gateway API, et examine en profondeur le protocole Gateway API lui-même
  • GAMMA (extension des idées de la Gateway API au service mesh) et Inference Extension (définition et optimisation des workloads d’inférence Kubernetes) sont volontairement exclus du périmètre, car ils méritent une analyse approfondie distincte
  • Passe également en revue les implémentations disponibles de la Gateway API et les critères de choix

À lire aussi

2 commentaires

 
click 1 시간 전

L’an dernier, j’avais voulu essayer NGF, mais comme il n’y avait aucun moyen de mettre en place une authentification basée sur l’en-tête Authorization, j’étais finalement passé à envoy.
Je préfère nginx à envoy, donc si la prise en charge complète de la Gateway API arrive, je me dis que j’essaierai peut-être NGF la prochaine fois.
 
hmmhmmhm 2 시간 전

Envoy va donc encore gagner en importance.