Comment choisir ? Passerelle API vs. Contrôleur d’entrée vs. Maillage de services

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

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

• Les contrôleurs d’entrée et les maillages de services peuvent répondre à de nombreux cas d’utilisation de passerelle API.
• Certains fournisseurs positionnent leur outil de passerelle API comme une alternative à l’utilisation d’un contrôleur Ingress ou d’un maillage de services – ou ils regroupent les trois fonctionnalités dans un seul outil.

Dans ce blog, nous abordons les différences entre ces outils et celui à utiliser pour les cas d’utilisation de passerelle API spécifiques à Kubernetes. Pour une analyse plus approfondie, y compris des démonstrations, regardez le webinaire Cas d'utilisation d'API Gateway pour Kubernetes .

Définitions

À la base, les passerelles API, les contrôleurs d’entrée et les maillages de services sont chacun un type de proxy, conçu pour faire circuler le trafic dans et autour de vos environnements.

Qu'est-ce qu'une passerelle API ?

Une passerelle API achemine les requêtes API d'un client vers les services appropriés. Mais une grande idée fausse concernant cette définition simple est qu’une passerelle API est une pièce de technologie unique. Ce n’est pas le cas. Au contraire, « passerelle API » décrit un ensemble de cas d’utilisation qui peuvent être mis en œuvre via différents types de proxys – le plus souvent un ADC ou un équilibreur de charge et un proxy inverse, et de plus en plus un contrôleur d’entrée ou un maillage de services.

Il n’existe pas vraiment de consensus au sein du secteur sur les capacités « indispensables » pour qu’un outil puisse servir de passerelle API. Nous voyons généralement des clients nécessitant les capacités suivantes (regroupées par cas d’utilisation) :

Cas d'utilisation de la résilience

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

Cas d'utilisation de la gestion du trafic

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

Cas d'utilisation de la sécurité

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

Presque tous ces cas d’utilisation sont couramment utilisés dans Kubernetes. La transformation du protocole et la manipulation de l’en-tête et du corps des requêtes/réponses sont moins courantes car elles sont généralement liées à des API héritées qui ne sont pas bien adaptées aux environnements Kubernetes et aux microservices.

Pour en savoir plus sur les cas d’utilisation de la passerelle API, consultez Déploiement de NGINX en tant que passerelle API, partie 1 sur notre blog.

Qu'est-ce qu'un contrôleur d'entrée ?

Un contrôleur d'entrée (également appelé contrôleur d'entrée Kubernetes – KIC en abrégé) est un proxy de couche 4 et de couche 7 spécialisé qui fait circuler le trafic vers Kubernetes, vers les services et vers l'extérieur (appelé trafic entrant-sortant ou nord-sud). Outre la gestion du trafic, les contrôleurs Ingress peuvent également être utilisés pour la visibilité et le dépannage, la sécurité et l'identité, ainsi que pour tous les cas d'utilisation de passerelle API, à l'exception des plus avancés.

Découvrez comment vous pouvez utiliser un contrôleur d'entrée pour bien plus que la simple gestion du trafic dans Guide de choix d'un contrôleur d'entrée, partie 1 : Identifiez vos besoins sur notre blog.

Qu'est-ce qu'un Service Mesh ?

Un maillage de services gère le trafic circulant entre les services Kubernetes (appelé trafic de service à service ou est-ouest) et est couramment utilisé pour obtenir un chiffrement de bout en bout (E2EE). L’adoption du service mesh est faible mais augmente à mesure que de plus en plus d’organisations lancent des déploiements avancés ou ont des exigences en matière de E2EE. Un service mesh peut être utilisé comme une passerelle API distribuée (légère) très proche des applications, rendue possible au niveau du plan de données par les sidecars du service mesh.

Pour en savoir plus sur le service mesh (et quand vous serez prêt à en adopter un), consultez Comment choisir un service mesh sur notre blog.

Utiliser les outils natifs de Kubernetes pour les environnements Kubernetes

Comme nous l'avons entendu de Mark Church dans son discours d'ouverture de NGINX Sprint 2.0 sur Kubernetes et l'avenir des réseaux d'applications , « les passerelles API, les équilibreurs de charge et les maillages de services continueront de se ressembler de plus en plus et de fournir des capacités similaires ». Nous sommes entièrement d’accord avec cette affirmation et ajoutons en outre qu’il s’agit de choisir le bon outil pour le travail en fonction de l’endroit (et de la manière) où vous allez l’utiliser. Après tout, une machette et un couteau à beurre sont tous deux utilisés pour couper, mais vous n'utiliserez probablement pas le premier sur votre toast du matin.

Alors, comment décider quel outil vous convient le mieux ? Nous allons simplifier les choses : si vous avez besoin d’une fonctionnalité de passerelle API dans Kubernetes, il est généralement préférable de choisir un outil qui peut être configuré à l’aide d’outils de configuration Kubernetes natifs tels que YAML. En général, il s’agit d’un contrôleur d’entrée ou d’un maillage de services. Mais nous vous entendons dire : « Mon outil de passerelle API a tellement plus de fonctionnalités que mon contrôleur Ingress (ou mon maillage de services) – est-ce que je ne rate pas quelque chose ? » Non! Plus de fonctionnalités ne signifie pas nécessairement un meilleur outil, en particulier dans Kubernetes où la complexité des outils peut être un facteur décisif.

Note: Kubernetes-native (différent de Knative ) fait référence aux outils qui ont été conçus et créés pour Kubernetes. En règle générale, ils fonctionnent avec la CLI 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 avec Kubernetes, car cela évite les modifications de l’expérience de développement ou de GitOps. Un outil compatible YAML offre trois avantages majeurs :

• YAML est un langage familier pour les équipes Kubernetes, donc la courbe d’apprentissage est faible, voire inexistante, si vous utilisez un outil Kubernetes existant pour la fonctionnalité de passerelle API. Cela permet à vos équipes de travailler dans le cadre de leurs compétences existantes sans avoir besoin d’apprendre à configurer un nouvel outil qu’elles pourraient n’utiliser qu’occasionnellement.
• Vous pouvez automatiser un outil compatible YAML de la même manière que vos autres outils Kubernetes. Tout ce qui s’intègre parfaitement dans vos flux de travail sera populaire auprès de votre équipe, augmentant ainsi la probabilité qu’elle l’utilise.
• Vous pouvez réduire votre pile 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 de défaillance uniques. Et bien sûr, réduire le nombre de technologies déployées dans Kubernetes est également bon pour votre budget et votre sécurité globale.

Cas d'utilisation de la passerelle API Nord-Sud : Utiliser un contrôleur d'entrée

Les contrôleurs d’entrée ont le potentiel de permettre de nombreux cas d’utilisation de passerelle API. En plus de ceux décrits dans les définitions , nous constatons que les organisations apprécient particulièrement un contrôleur d'entrée capable de mettre en œuvre :

• Déchargement de l'authentification et de l'autorisation
• Routage basé sur l'autorisation
• Routage et correspondance de niveau 7 (HTTP, HTTP/S, en-têtes, cookies, méthodes)
• Compatibilité des protocoles (HTTP, HTTP/2, WebSocket, gRPC)
• Limitation de débit

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

Vous souhaitez implémenter la correspondance et le routage au niveau de la méthode, en utilisant le contrôleur Ingress pour rejeter la méthode POST dans les requêtes API.

Certains attaquants recherchent des vulnérabilités dans les API en envoyant des types de requêtes qui ne sont pas conformes à une définition d'API, par exemple en envoyant des requêtes POST à une API définie pour accepter uniquement les requêtes GET . Les pare-feu d'applications Web (WAF) ne peuvent pas détecter ces types d'attaques : ils examinent uniquement les chaînes et les corps de requête pour détecter les attaques. Il est donc recommandé d'utiliser une passerelle API au niveau de la couche d'entrée pour bloquer les mauvaises requêtes.

À 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 ajoutant l’API au champ en amont .

Version de l'API : k8s.nginx.org/v1kind : VirtualServer
métadonnées :
nom : café
spécification :
hôte : café.exemple.com
tls :
secret : café-secret
en amont :
-nom : thé
service : thé-svc
port : 80
-nom : café
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 et ajoutez deux conditions qui utilisent la variable $request_method pour faire la distinction entre les requêtes GET et POST . Tout trafic utilisant la méthode HTTP GET est transmis automatiquement au service café . Le trafic utilisant la méthode POST est dirigé vers une page d'erreur avec le message « Vous êtes rejeté ! » Et comme ça, vous avez protégé la nouvelle API du trafic POST indésirable.

itinéraires : - chemin : /coffee/{coffee-store}/brand
correspondances :
- conditions :
- variable : $request_method
valeur : POST
action :
retour :
code : 403
type : texte/plain
corps : "Vous êtes rejeté !"
- conditions :
- variable : $request_method
valeur : OBTENIR
action :
passer : café
- chemin : /thé
action :
passer : thé

Pour plus de détails sur la manière dont vous pouvez utiliser le routage au niveau de la méthode et la correspondance avec les pages d’erreur, consultez la documentation de NGINX Ingress Controller . Pour un exemple lié à la sécurité d’utilisation d’un contrôleur Ingress pour la fonctionnalité de passerelle API, lisez Implémentation de l’authentification OpenID Connect pour Kubernetes avec Okta et NGINX Ingress Controller sur notre blog.

Cas d'utilisation de la passerelle API Est-Ouest : Utiliser un Service Mesh

Un maillage de services n’est pas requis – ni même initialement utile – pour la plupart des cas d’utilisation de passerelle API, car la plupart de ce que vous souhaitez accomplir peut, et doit, se produire au niveau de la couche d’entrée. Mais à mesure que votre architecture devient plus complexe, vous aurez plus de chances de tirer profit de l’utilisation d’un maillage de services. Les cas d’utilisation que nous trouvons les plus bénéfiques sont liés au E2EE et à la répartition du trafic , tels que les tests A/B, les déploiements Canary et les déploiements bleu-vert.

Exemple de scénario : Déploiement de Canary

Vous souhaitez configurer un déploiement Canary entre des services avec un routage conditionnel basé sur des critères HTTP/S.

L’avantage est que vous pouvez déployer progressivement les modifications de l’API (telles que de nouvelles fonctions ou versions) sans impacter la majeure partie de votre trafic de production.

Actuellement, votre contrôleur d'entrée NGINX achemine le trafic entre deux services gérés par NGINX Service Mesh : Café.frontdoor.svc et Thé.frontdoor.svc . Ces services reçoivent le trafic de NGINX Ingress Controller et l'acheminent vers les fonctions d'application appropriées, notamment Tea.cream1.svc . Vous décidez de refactoriser Tea.cream1.svc , en appelant la nouvelle version Tea.cream2.svc . Vous souhaitez que vos bêta-testeurs fournissent des commentaires sur la nouvelle fonctionnalité. Vous configurez donc une répartition du trafic canari basée sur le cookie de session unique des bêta-testeurs, garantissant ainsi que vos utilisateurs réguliers ne découvrent que Tea.cream1.svc .

En utilisant NGINX Service Mesh, vous commencez par créer une répartition du trafic entre tous les services dirigés par Tea.frontdoor.svc , y compris Tea.cream1.svc et Tea.cream2.svc . Pour activer le routage conditionnel, créez une ressource HTTPRouteGroup (nommée tea-hrg ) et associez-la à la répartition du trafic, le résultat étant que seules les requêtes de vos utilisateurs bêta (requêtes avec le cookie de session défini sur version=beta ) sont acheminées de Tea.frontdoor.svc vers Tea.cream2.svc . Vos utilisateurs réguliers continuent de bénéficier uniquement des services de la version 1 derrière Tea.frontdoor.svc .

Version de l'API : split.smi-spec.io/v1alpha3kind : TrafficSplit
métadonnées :
nom : tea-svc
spécification :
service : tea.1
backends :
- service : tea.1
poids : 0
- service : thé.2
poids : 100
correspondances :
- type : HTTPRouteGroup
nom : tea-hrg

version de l'API : specs.smi-spec.io/v1alpha3
type : HTTPRouteGroup
métadonnées :
nom : tea-hrg
espace de noms : par défaut
spécification :
correspondances :
- nom : beta-session-cookie
en-têtes :
- cookie : « version=beta »

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

Consultez notre documentation pour plus de détails 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 back-end. Cette configuration n'est actuellement pas prise en charge par la spécification Service Mesh Interface ( smi-spec ) ; cependant, la spécification est actuellement en version alpha et sujette à changement.

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

Bien que la plupart des cas d'utilisation de passerelle API pour Kubernetes puissent (et doivent) être traités par un contrôleur Ingress ou un maillage de services, il existe certaines situations spécialisées dans lesquelles un outil de passerelle API – tel que NGINX Plus – est adapté.

Exigences commerciales

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 en fonction de chaque environnement, il existe des raisons pour lesquelles vous pouvez choisir de déployer une passerelle API dédiée dans Kubernetes plutôt que d'exploiter le contrôleur Ingress existant. L’utilisation d’un contrôleur Ingress et d’une passerelle API dans Kubernetes peut offrir aux organisations la flexibilité nécessaire pour répondre aux exigences commerciales. Certains scénarios incluent :

• Votre équipe de passerelle API n’est pas familière avec Kubernetes et n’utilise pas YAML. Par exemple, s’ils sont à l’aise avec la configuration NGINX, cela facilite les frictions et réduit la courbe d’apprentissage s’ils déploient NGINX Plus en tant que passerelle API dans Kubernetes.
• Votre équipe Platform Ops préfère dédier le contrôleur Ingress à la gestion du trafic des applications uniquement.
• Vous disposez d’un cas d’utilisation de passerelle API qui s’applique uniquement à l’un des services de votre cluster. Au lieu d’utiliser un contrôleur d’entrée pour appliquer une politique à tout votre trafic nord-sud, vous pouvez déployer une passerelle API pour appliquer la politique uniquement là où elle est nécessaire.

Migration des API vers les environnements Kubernetes

Lors de la migration d’API existantes vers des environnements Kubernetes, vous pouvez publier ces API sur un outil de passerelle API déployé en dehors de Kubernetes. Dans ce scénario, le trafic API est généralement acheminé via un équilibreur de charge externe (pour équilibrer la charge entre les clusters), puis vers un équilibreur de charge configuré pour servir de passerelle 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 – en partie parce que les services et API RESTful ou gRPC sont capables de tirer pleinement parti de la plateforme Kubernetes – il se peut que certaines API SOAP n’aient pas été réarchitecturées. Bien que les API SOAP ne soient pas recommandées pour Kubernetes car elles ne sont pas optimisées pour les microservices, vous devrez peut-être déployer une API SOAP dans Kubernetes jusqu’à ce qu’elle puisse être réarchitecturée. Il est probable que l’API doive communiquer avec des clients API basés sur REST, auquel cas vous avez besoin d’un moyen de traduction entre les protocoles SOAP et REST. Bien que vous puissiez exécuter cette fonctionnalité avec un contrôleur Ingress, nous ne le recommandons pas car cela nécessite énormément de ressources. Au lieu de cela, nous vous recommandons de déployer un outil de passerelle API en tant que proxy par pod ou par service pour effectuer la traduction entre SOAP et REST.

Gestion du trafic API à l'intérieur et à l'extérieur de Kubernetes

Un nombre relativement restreint de nos clients sont intéressés par la gestion d’API s’étendant à l’intérieur et à l’extérieur des environnements Kubernetes. Si une stratégie de gestion des API est une priorité plus élevée que la sélection d’outils natifs de Kubernetes, alors une passerelle API « compatible avec Kubernetes » (qui peut s’intégrer à une solution de gestion des API) déployée dans Kubernetes peut être le bon choix.

Note: Contrairement aux outils natifs de Kubernetes, les outils compatibles avec Kubernetes (parfois appelés également adaptés à Kubernetes ) n'ont pas été conçus pour Kubernetes et ne peuvent pas être gérés à l'aide des 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 étendues.

Premiers pas avec NGINX

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

Outils natifs de Kubernetes :

• NGINX Ingress Controller – Contrôleur d’entrée basé sur NGINX Plus pour Kubernetes qui gère le contrôle et la mise en forme avancés du trafic, la surveillance et la visibilité, ainsi que l’authentification et l’authentification unique (SSO) .
• NGINX Service Mesh – Service mesh léger, clé en main et convivial pour les développeurs avec 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, et téléchargez le NGINX Service Mesh toujours gratuit.

Pour une passerelle API compatible avec Kubernetes à l'intérieur ou à l'extérieur de vos environnements Kubernetes :

• NGINX Plus – L'équilibreur de charge tout-en-un , le proxy inverse, le serveur Web et la passerelle API avec des 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 une solution de cycle de vie API complète.

Pour en savoir plus sur l'utilisation de NGINX Plus comme passerelle API, demandez votre essai gratuit de 30 jours et consultez Déploiement de NGINX en tant que passerelle API .