Comment choisir ? Passerelle API, contrôleur Ingress ou maillage de services

Jenn GileResponsable du marketing produit, NGINX

Dans presque tous les webinaires sur les contrôleurs Ingress et les maillages de services que nous avons organisés au cours de l’année 2021, nous avons entendu différentes variantes des questions suivantes : « En quoi cet outil est-il différent d’une passerelle d’API ? » ou « Ai-je besoin à la fois d’une passerelle d’API et d’un contrôleur Ingress (ou d’un maillage de services) dans Kubernetes ? »

Cette confusion est tout à fait compréhensible pour deux raisons :

• Les contrôleurs Ingress et les maillages de services peuvent répondre à de nombreux cas d’usage des passerelles API.
• Certains fournisseurs présentent leur passerelle d’API comme une alternative à l’utilisation d’un contrôleur Ingress ou d’un maillage de services, tandis que d’autres réunissent ces trois fonctionnalités au sein d’un même outil.

Dans cet article, nous examinons les différences entre ces outils et déterminons lesquels utiliser pour les cas d’usage de passerelle API propres à Kubernetes. Pour approfondir le sujet et découvrir des démonstrations, regardez le webinaire « Cas d’usage des passerelles API pour Kubernetes ».

Définitions

Fondamentalement, les passerelles d’API, les contrôleurs Ingress et les maillages de services sont tous des types de proxys conçus pour acheminer le trafic vers vos environnements et au sein de ceux-ci.

Qu’est-ce qu’une passerelle API ?

Une passerelle d’API achemine les requêtes API d’un client vers les services appropriés. Cependant, cette définition simple donne souvent lieu à un malentendu majeur : l’idée qu’une passerelle d’API serait une technologie spécifique. Ce n’est pas le cas. En réalité, le terme « passerelle d’API » désigne un ensemble de cas d’usage pouvant être mis en œuvre au moyen de différents types de proxys, le plus souvent un contrôleur de mise à disposition d’applications (ADC) ou un équilibreur de charge et un proxy inverse, et de plus en plus fréquemment un contrôleur Ingress ou un maillage de services.

Le secteur ne s’accorde guère sur les fonctionnalités « indispensables » qu’un outil doit offrir pour faire office de passerelle API. En règle générale, nos clients exigent les capacités suivantes (regroupées par cas d’usage) :

Cas d’usage liés à la résilience

• Tests A/B, déploiements canary et déploiements bleu-vert
• Transformation de protocole (entre JSON et XML, par exemple)
• Limitation du débit
• Découverte de services

Cas d’usage de la gestion du trafic

• Routage et mise en correspondance basés sur la méthode
• Manipulation des en-têtes et du corps des requêtes/réponses
• Routage des requêtes au niveau de la couche 7

Cas d’usage de sécurité

• Application du schéma d’API
• Authentification et autorisation des clients
• Réponses personnalisées
• Contrôle d’accès granulaire
• Terminaison TLS

La quasi-totalité de ces cas d’usage sont courants dans Kubernetes. La transformation des protocoles ainsi que la manipulation des en-têtes et du corps des requêtes et des réponses sont moins fréquentes, car elles sont généralement liées à des API héritées peu adaptées aux environnements Kubernetes et de microservices.

Pour en savoir plus sur les cas d’usage des passerelles API, consultez l’article « Déployer NGINX en tant que passerelle API, partie 1 » sur notre blog.

Qu’est-ce qu’un contrôleur Ingress ?

Un contrôleur Ingress (également appelé contrôleur Ingress Kubernetes, ou KIC) est un proxy spécialisé de couches 4 et 7 qui achemine le trafic entrant dans Kubernetes vers les services, puis le trafic sortant (on parle de trafic ingress-egress ou nord-sud). Outre la gestion du trafic, les contrôleurs Ingress peuvent également servir à assurer la visibilité et le dépannage, la sécurité et la gestion des identités, ainsi qu'à répondre à presque tous les cas d'usage d'une passerelle API, à l'exception des plus avancés.

Découvrez comment utiliser un contrôleur Ingress pour aller au-delà de la simple gestion du trafic dans notre article de blog « Guide pour choisir un contrôleur Ingress, 1re partie : identifier vos besoins ».

Qu’est-ce qu’un maillage de services ?

Un maillage de services gère le trafic circulant entre les services Kubernetes (appelé trafic de service à service ou trafic est-ouest) et est couramment utilisé pour assurer le chiffrement de bout en bout (E2EE). L’adoption des maillages de services reste limitée, mais progresse à mesure que davantage d’organisations mettent en place des déploiements avancés ou ont besoin d’un chiffrement E2EE. Un maillage de services peut servir de passerelle API distribuée (légère), au plus près des applications, grâce aux side-cars du maillage de services au niveau du plan de données.

Pour en savoir plus sur le maillage de services et savoir quand vous serez prêt à en adopter un, consultez l’article « Comment choisir un maillage de services » sur notre blog.

Utilisez des outils natifs de Kubernetes pour les environnements Kubernetes

Comme l’a expliqué Mark Church lors de sa présentation phare au NGINX Sprint 2.0 sur Kubernetes et l’avenir de la mise en réseau des applications, « les passerelles d’API, les équilibreurs de charge et les maillages de services continueront à se ressembler de plus en plus et à offrir des fonctionnalités similaires ». Nous partageons pleinement ce point de vue et ajouterons que l’essentiel est de choisir l’outil adapté à la tâche en fonction de l’endroit où — et de la manière dont — vous comptez l’utiliser. Après tout, une machette et un couteau à beurre servent tous deux à couper, mais vous n’allez probablement pas utiliser la première pour tartiner votre pain grillé le matin.

Alors, comment choisir l’outil qui vous convient ? Pour faire simple, si vous avez besoin de fonctionnalités de passerelle API dans Kubernetes, mieux vaut généralement opter pour un outil configurable à l’aide des outils de configuration natifs de Kubernetes, tels que YAML. Il s’agit généralement d’un contrôleur Ingress ou d’un maillage de services. Mais nous vous entendons déjà dire : « Mon outil de passerelle API offre tellement plus de fonctionnalités que mon contrôleur Ingress (ou mon maillage de services) ; est-ce que je ne risque pas d’y perdre ? » Non ! Un plus grand nombre de fonctionnalités ne signifie pas que l’outil est meilleur, surtout dans Kubernetes, où la complexité d’un outil peut être rédhibitoire.

Remarque : Natif de Kubernetes (à ne pas confondre avec Knative) désigne les outils conçus et développés pour Kubernetes. En général, ils fonctionnent avec l’interface de ligne de commande de Kubernetes, peuvent être installés à l’aide de Helm et s’intègrent aux fonctionnalités de Kubernetes.

La plupart des utilisateurs de Kubernetes préfèrent les outils qu’ils peuvent configurer de manière native pour Kubernetes, car cela évite de modifier l’expérience de développement ou GitOps. Un outil compatible avec YAML offre trois avantages majeurs :

• YAML est un langage bien connu des équipes Kubernetes. La courbe d’apprentissage est donc faible, voire inexistante, si vous utilisez un outil Kubernetes existant pour assurer les fonctionnalités de passerelle API. Vos équipes peuvent ainsi s’appuyer sur leurs compétences actuelles sans avoir à apprendre à configurer un nouvel outil qu’elles n’utiliseront peut-être qu’occasionnellement.
• Vous pouvez automatiser un outil compatible avec YAML de la même manière que vos autres outils Kubernetes. Tout outil qui s’intègre parfaitement à vos workflows sera bien accueilli par votre équipe, ce qui augmentera la probabilité qu’elle l’utilise.
• Vous pouvez alléger votre panoplie d’outils de gestion du trafic Kubernetes en utilisant votre contrôleur Ingress, votre maillage de services, ou les deux. Après tout, chaque saut supplémentaire compte, et il n’y a aucune raison d’ajouter une latence inutile ou des points uniques de défaillance. Et bien sûr, réduire le nombre de technologies déployées dans Kubernetes est également bénéfique pour votre budget et votre sécurité globale.

Cas d’usage d’une passerelle API nord-sud : utiliser un contrôleur Ingress

Les contrôleurs Ingress peuvent répondre à de nombreux cas d’usage de passerelle API. Outre ceux présentés dans la section « Définitions », nous constatons que les entreprises privilégient avant tout un contrôleur Ingress capable de mettre en œuvre les fonctionnalités suivantes :

• Délégation de l’authentification et de l’autorisation
• Routage basé sur les autorisations
• Routage et mise en correspondance au niveau de la couche 7 (HTTP, HTTP/S, en-têtes, cookies, méthodes)
• Compatibilité des protocoles (HTTP, HTTP/2, WebSocket, gRPC)
• Limitation du débit

Exemple de scénario : routage au niveau de la méthode

Vous souhaitez mettre en œuvre une mise en correspondance et un routage au niveau des méthodes, en utilisant le contrôleur Ingress pour rejeter la méthode POST dans les requêtes d’API.

Certains attaquants recherchent des vulnérabilités dans les API en envoyant des types de requêtes non conformes à leur définition, par exemple des requêtes POST à une API conçue pour n’accepter que les requêtes GET. Les pare-feu d’applications web (WAF) ne peuvent pas détecter ce type d’attaque, car ils examinent uniquement les chaînes de requête et les corps des requêtes à la recherche d’attaques. Il est donc recommandé d’utiliser une passerelle API au niveau de la couche Ingress afin de bloquer les requêtes malveillantes.

À titre d’exemple, supposons que la nouvelle API /coffee/{coffee-store}/brand vient d’être ajoutée à votre cluster. La première étape consiste à exposer l’API à l’aide de NGINX Ingress Controller, simplement en l’ajoutant au champ upstreams.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
tls:
secret: cafe-secret
upstreams:
-name: tea
service: tea-svc
port: 80
-name: coffee
service: coffee-svc
port: 80

Pour activer la correspondance au niveau de la méthode, ajoutez un chemin /coffee/{coffee-store}/brand au champ routes, ainsi que deux conditions utilisant la variable $request_method pour distinguer les requêtes GET des requêtes POST. Tout trafic utilisant la méthode HTTP GET est automatiquement transmis au service coffee. Le trafic utilisant la méthode POST est redirigé vers une page d’erreur affichant le message « Vous êtes rejeté ! ». Et voilà, vous avez protégé la nouvelle API contre le trafic POST indésirable.

routes: - path: /coffee/{coffee-store}/brand
matches:
- conditions:
- variable: $request_method
value: POST
action:
return:
code: 403
type: text/plain
body: "Votre requête est rejetée !"
- conditions:
- variable: $request_method
value: GET
action:
pass: coffee
- path: /tea
action:
pass:tea

Pour en savoir plus sur l’utilisation du routage et de la mise en correspondance au niveau des méthodes avec des pages d’erreur, consultez la documentation de NGINX Ingress Controller. Pour découvrir un exemple axé sur la sécurité illustrant l’utilisation d’un contrôleur Ingress comme passerelle d’API, lisez l’article Mise en œuvre de l’authentification OpenID Connect pour Kubernetes avec Okta et NGINX Ingress Controller sur notre blog.

Cas d’usage d’une passerelle API Est-Ouest : utiliser un maillage de services

Un maillage de services n’est pas nécessaire — ni même utile dans un premier temps — pour la plupart des cas d’usage d’une passerelle d’API, car l’essentiel de ce que vous pourriez vouloir accomplir peut, et devrait, être réalisé au niveau de la couche Ingress. Toutefois, à mesure que votre architecture se complexifie, l’utilisation d’un maillage de services est davantage susceptible de vous apporter de la valeur. Les cas d’usage que nous jugeons les plus avantageux concernent le chiffrement de bout en bout et la répartition du trafic — notamment les tests A/B, les déploiements canary et les déploiements bleu-vert.

Exemple de scénario : déploiement canari

Vous souhaitez mettre en place un déploiement canari entre des services, avec un routage conditionnel basé sur des critères HTTP/S.

L’avantage est que vous pouvez déployer progressivement des modifications de l’API, telles que de nouvelles fonctionnalités ou versions, sans affecter la majeure partie de votre trafic de production.

Actuellement, votre NGINX Ingress Controller achemine le trafic entre deux services gérés par NGINX Service Mesh : Coffee.frontdoor.svc et Tea.frontdoor.svc. Ces services reçoivent le trafic provenant de NGINX Ingress Controller et l’acheminent vers les fonctions applicatives appropriées, notamment Tea.cream1.svc. Vous décidez de remanier Tea.cream1.svc et nommez la nouvelle version Tea.cream2.svc. Vous souhaitez que vos bêta-testeurs vous fassent part de leurs commentaires sur la nouvelle fonctionnalité. Vous configurez donc une répartition canary du trafic basée sur le cookie de session unique des bêta-testeurs, afin que vos utilisateurs habituels continuent d’utiliser exclusivement Tea.cream1.svc.

Avec NGINX Service Mesh, vous commencez par répartir le trafic entre tous les services exposés par Tea.frontdoor.svc, notamment Tea.cream1.svc et Tea.cream2.svc. Pour activer le routage conditionnel, vous créez une ressource HTTPRouteGroup (nommée tea-hrg) et l’associez à la répartition du trafic. Ainsi, seules les requêtes de vos utilisateurs bêta (celles dont le cookie de session est défini sur version=beta) sont acheminées de Tea.frontdoor.svc vers Tea.cream2.svc. Vos utilisateurs habituels continuent d’accéder uniquement aux services de version 1 derrière Tea.frontdoor.svc.

apiVersion: split.smi-spec.io/v1alpha3kind: TrafficSplit
metadata:
name: tea-svc
spec:
service: tea.1
backends:
- service: tea.1
weight: 0
- service: tea.2
weight: 100
matches:
- kind: HTTPRouteGroup
name: tea-hrg

apiVersion: specs.smi-spec.io/v1alpha3
kind: HTTPRouteGroup
metadata:
name: tea-hrg
namespace: default
spec:
matches:
- name: beta-session-cookie
headers:
- cookie: "version=beta"

Cet exemple démarre votre déploiement canari avec une répartition de 0 à 100, ce qui signifie que tous vos bêta-testeurs utilisent Tea.cream2.svc. Vous pouvez bien sûr commencer avec le ratio qui correspond à votre stratégie de bêta-test. Une fois vos bêta-tests terminés, vous pouvez utiliser un déploiement canari simple (sans routage par cookie) pour tester la résilience de Tea.cream2.svc.

Consultez notre documentation pour en savoir plus sur la répartition du trafic avec NGINX Service Mesh. La configuration de répartition du trafic ci-dessus est autoréférentielle, car le service racine est également répertorié comme service backend. Cette configuration n’est actuellement pas prise en charge par la spécification Service Mesh Interface (smi-spec) ; toutefois, cette spécification est encore en version alpha et susceptible d’évoluer.

Quand (et comment) utiliser un outil de passerelle API pour les applications Kubernetes

Bien que la plupart des cas d’usage d’une passerelle d’API pour Kubernetes puissent (et doivent) être pris en charge par un contrôleur Ingress ou un maillage de services, certaines situations particulières justifient l’utilisation d’un outil de passerelle d’API, tel que NGINX Plus.

Exigences métier

Bien que plusieurs équipes ou projets puissent partager un ensemble de contrôleurs Ingress, ou que les contrôleurs Ingress puissent être spécialisés pour chaque environnement, certaines raisons peuvent vous amener à déployer une passerelle d’API dédiée dans Kubernetes plutôt qu’à utiliser le contrôleur Ingress existant. L’utilisation conjointe d’un contrôleur Ingress et d’une passerelle d’API dans Kubernetes peut offrir aux organisations la flexibilité nécessaire pour répondre à leurs exigences métier. Voici quelques exemples de scénarios :

• Votre équipe chargée de la passerelle d’API ne connaît pas bien Kubernetes et n’utilise pas YAML. Par exemple, si elle maîtrise la configuration de NGINX, le déploiement de NGINX Plus en tant que passerelle d’API dans Kubernetes facilite la transition et réduit la courbe d’apprentissage.
• Votre équipe chargée des opérations de la plateforme préfère réserver le contrôleur Ingress à la seule gestion du trafic applicatif.
• Vous avez un cas d’usage de passerelle API qui ne s’applique qu’à l’un des services de votre cluster. Plutôt que d’utiliser un contrôleur Ingress pour appliquer une politique à l’ensemble de votre trafic nord-sud, vous pouvez déployer une passerelle API afin d’appliquer cette politique uniquement là où elle est nécessaire.

Migration des API vers des environnements Kubernetes

Lors de la migration d’API existantes vers des environnements Kubernetes, vous pouvez publier ces API sur un outil de passerelle d’API déployé en dehors de Kubernetes. Dans ce scénario, le trafic des API est généralement acheminé via un équilibreur de charge externe (pour répartir la charge entre les clusters), puis vers un équilibreur de charge configuré pour servir de passerelle d’API, et enfin vers le contrôleur Ingress au sein de votre cluster Kubernetes.

Prise en charge des API SOAP dans Kubernetes

Bien que la plupart des API modernes soient créées à l’aide de REST – notamment parce que les services et API RESTful ou gRPC peuvent tirer pleinement parti de la plateforme Kubernetes –, il se peut que vous disposiez encore d’API SOAP qui n’ont pas été réarchitecturées. Les API SOAP ne sont pas recommandées pour Kubernetes, car elles ne sont pas optimisées pour les microservices. Vous devrez néanmoins peut-être déployer une API SOAP dans Kubernetes en attendant de pouvoir la réarchitecturer. Il est probable que l’API doive communiquer avec des clients d’API REST. Dans ce cas, vous avez besoin d’un moyen d’assurer la conversion entre les protocoles SOAP et REST. Bien que vous puissiez mettre en œuvre cette fonctionnalité à l’aide d’un contrôleur Ingress, nous ne le recommandons pas, car cette solution est extrêmement gourmande en ressources. Nous vous conseillons plutôt de déployer un outil de passerelle d’API en tant que proxy par pod ou par service afin d’assurer la conversion entre SOAP et REST.

Gestion du trafic des API à l’intérieur comme à l’extérieur de Kubernetes

Un nombre relativement restreint de nos clients souhaitent gérer des API couvrant à la fois des environnements Kubernetes et des environnements externes. Si la stratégie de gestion des API est prioritaire par rapport au choix d’outils natifs de Kubernetes, une passerelle API « compatible avec Kubernetes » (pouvant s’intégrer à une solution de gestion des API) déployée dans Kubernetes pourrait être le bon choix.

Remarque : Contrairement aux outils natifs de Kubernetes, les outils compatibles avec Kubernetes (aussi parfois appelés outils adaptés à Kubernetes) n’ont pas été conçus pour Kubernetes et ne peuvent pas être gérés à l’aide de configurations Kubernetes. Cependant, ils sont agiles et légers, ce qui leur permet de fonctionner dans Kubernetes sans ajouter de latence significative ni nécessiter de solutions de contournement complexes.

Bien démarrer avec NGINX

NGINX propose des options pour les trois types de scénarios de déploiement.

Outils natifs de Kubernetes :

• Contrôleur Ingress NGINX – Contrôleur Ingress pour Kubernetes basé sur NGINX Plus, qui assure le contrôle et la gestion avancés du trafic, la surveillance et la visibilité, ainsi que l’authentification et l’authentification unique (SSO).
• NGINX Service Mesh – Maillage de services léger, clé en main et convivial pour les développeurs, intégrant NGINX Plus comme side-car d’entreprise.

Commencez par demander votre essai gratuit de 30 jours de NGINX Ingress Controller avec NGINX App Protect WAF et DoS, puis téléchargez NGINX Service Mesh, toujours gratuit.

Pour une passerelle API adaptée à Kubernetes, à l’intérieur ou à l’extérieur de vos environnements Kubernetes :

• NGINX Plus – L’équilibreur de charge, proxy inverse, serveur web et passerelle d’API tout-en-un, doté de fonctionnalités de niveau entreprise telles que la haute disponibilité, les contrôles d’intégrité actifs, la découverte du système DNS, la persistance des sessions et une API RESTful. S’intègre à NGINX Controller [désormais F5 NGINX Management Suite] pour offrir une solution couvrant l’ensemble du cycle de vie des API.

Pour en savoir plus sur l’utilisation de NGINX Plus comme passerelle d’API, demandez votre essai gratuit de 30 jours et consultez Déployer NGINX comme passerelle d’API.

À propos de l’auteur

Jenn GileResponsable du marketing produit, NGINX

Autres articles de Jenn Gile