Gateway API de Kubernetes
Introduction
Alors que Kubernetes est devenu la plateforme d’orchestration standard pour le déploiement d’applications natives du cloud, la mise en réseau et la gestion du trafic sont apparues comme des défis essentiels lors de la gestion de l’accès aux services et à l’infrastructure. La ressource principale Ingress de Kubernetes répond aux besoins de routage de base de la couche 7 (L7), mais présente des limites en termes de flexibilité, de fonctionnalité et de normalisation. En tant que successeur d’Ingress, le projet Gateway API introduit un nouvel ensemble de ressources de gestion de réseau portables, une évolution au-delà des capacités traditionnelles d’Ingress.
Qu’est-ce qu’Ingress dans Kubernetes ?
Ingress fournit un moyen centralisé de gérer l’accès externe aux services s’exécutant à l’intérieur d’un cluster Kubernetes, généralement le trafic HTTP/HTTPS au niveau de la couche L7. Au lieu de répartiteurs de charge individuels par service, Ingress fournit un mécanisme centralisé pour gérer toutes les demandes entrantes vers les applications dorsales.
La ressource Ingress définit les règles de routage qui régissent la façon dont les demandes externes sont dirigées vers les services Kubernetes. Les règles peuvent inclure des noms d’hôtes, des chemins et des configurations TLS utilisés pour mapper le trafic. Un contrôleur Ingress est responsable de l’application finale des configurations de routage décrites par les ressources Ingress à un plan de données (par exemple, un proxy inverse, un équilibreur de charge, etc.
De nombreuses organisations ayant des capacités de développement de logiciels proxy traditionnels de couche 7 fournissent leurs propres implémentations de contrôleurs Ingress, tirant parti de leur expertise pour traduire les ressources Ingress en configurations de serveurs proxy adaptées à l’écosystème Kubernetes.
Ingress fait abstraction d’un composant clé de la mise en réseau des services, ce qui permet aux équipes Kubernetes de simplifier la gestion de l’accès externe. La spécification du routage souhaité au niveau d’Ingress permet aux services individuels de rester découplés des dépendances externes. Ingress centralise le contrôle afin que les services se concentrent sur la livraison des applications plutôt que sur les détails de la mise en réseau.
Limites d’Ingress
Si les contrôleurs Ingress répondent à d’importants besoins en matière de réseau et de gestion du trafic dans les clusters Kubernetes, la ressource Ingress elle-même présente certaines limites découlant de son manque de standardisation entre les différentes implémentations de contrôleurs.
La principale limitation d’Ingress est qu’il ne fonctionne qu’au niveau de la couche 7, en optimisant spécifiquement le trafic HTTP et HTTPS. Les autres protocoles de la couche 7 (comme gRPC) et les protocoles non-L7 (comme TCP et UDP) doivent être gérés à l’aide d’extensions de contrôleur personnalisées plutôt qu’à l’aide des capacités natives d’Ingress. Cela conduit à une fragmentation, car les fonctions d’activation telles que l’authentification, les politiques de limitation de débit et la gestion avancée du trafic reposent sur des annotations personnalisées spécifiques au fournisseur ou à la plateforme. Par exemple, les contrôleurs Ingress de NGINX utilisent une syntaxe et un ensemble d’extensions différents de ceux des implémentations Ingress de HAProxy.
En outre, la spécification de base d’Ingress ne prend pas en charge de manière intégrée de nombreuses fonctions avancées de gestion du trafic nécessaires dans les scénarios de production. Par conséquent, les solutions pour des cas d’utilisation tels que les tests A/B, les déploiements de canaris, le traçage distribué, etc. finissent par être verrouillées par le fournisseur plutôt que d’être portables. La ressource Ingress elle-même se concentre sur l’exposition des routes HTTP, alors que les fonctions critiques du réseau reposent sur le contrôleur Ingress sous-jacent. Il faut donc configurer le contrôleur séparément de l’Ingress pour obtenir des capacités de niveau production.
Présentation de l’API Gateway dans Kubernetes
Gateway API est un projet officiel de Kubernetes axé sur le routage L4 et L7 dans Kubernetes. Ce projet représente la prochaine génération d’API Kubernetes Ingress, Load Balancing et Service Mesh. Dès le départ, il a été conçu pour être générique, expressif et orienté vers les rôles.
L’API Kubernetes Gateway est introduite pour résoudre certains problèmes urgents avec Kubernetes Ingress :
- Fonctionnalité limitée** : Le système K8s Ingress natif n’offre qu’une fonctionnalité de base d’équilibrage de la charge. Les fonctionnalités avancées de routage du trafic, telles que le routage basé sur le chemin, nécessitent que les DevOps configurent des annotations personnalisées fastidieuses fournies par leur contrôleur Ingress respectif.
- Manque de normalisation** : Les fournisseurs de contrôleurs d’entrée ont leurs propres spécifications d’annotation. Si DevOps doit changer de contrôleur Ingress, il devra apprendre à connaître les CRD et les annotations propres à chaque fournisseur. En outre, ils devront réécrire les spécifications du fournisseur actuel en utilisant les nouvelles. Il faut un temps raisonnable pour écrire et tester les annotations avant de les mettre en œuvre.
- Ressource d’entrée unique** : En général, dans une entreprise, il n’y a qu’une seule ressource Ingress et plusieurs équipes travaillent dessus. Un administrateur créera au maximum plusieurs objets Ingress pour différentes équipes d’application, mais il est toujours difficile de mettre en œuvre des contrôles d’accès basés sur les rôles sur n’importe quel objet. En l’absence de politiques RBAC appropriées, les équipes risquent de perturber la configuration des itinéraires. Gateway API ne résout pas seulement les problèmes au niveau de la passerelle et de l’entrée, elle pourrait également évoluer pour gérer le trafic de service à service et est-ouest au sein du même cluster.
Gateway API est orientée sur les rôles
Dans la conception originale de Kubernetes, les ressources Ingress et Service étaient basées sur un modèle d’utilisation dans lequel les développeurs qui créent des services et des Ingress contrôlaient tous les aspects de la définition et de l’exposition de leurs applications à leurs utilisateurs.
Dans la pratique, cependant, les clusters et leur infrastructure ont tendance à être partagés, ce que le modèle original d’Ingress ne capture pas très bien. Un facteur critique est que lorsque l’infrastructure est partagée, tous ceux qui l’utilisent n’ont pas les mêmes préoccupations, et pour réussir, un projet d’infrastructure doit répondre aux besoins de tous les utilisateurs.
Cela soulève un défi fondamental : comment fournir la flexibilité nécessaire aux utilisateurs de l’infrastructure, tout en maintenant le contrôle des propriétaires de l’infrastructure ?
Gateway API définit plusieurs rôles distincts, chacun avec un persona associé, en tant qu’outil pour faire apparaître et discuter les différents besoins des différents utilisateurs afin d’équilibrer la facilité d’utilisation, la flexibilité et le contrôle. Le travail de conception au sein de Gateway API est délibérément conçu en fonction de ces personas.
L’API Gateway définit trois rôles et personas :
Fournisseur d’infrastructure, responsable de l’entretien et de l’alimentation d’un ensemble d’infrastructures qui permet à plusieurs clusters isolés de servir plusieurs tenants.
Opérateur de cluster, responsable de la gestion des clusters pour s’assurer qu’ils répondent aux besoins de leurs différents utilisateurs. Il s’occupe généralement des politiques, de l’accès au réseau, des autorisations d’utilisation des applications, etc.
Développeur d’application, responsable de la création et de la gestion d’une application fonctionnant dans un cluster. Du point de vue de l’API Gateway, il devra gérer la configuration (par exemple, les délais, la correspondance des demandes/filtres) et la composition des services (par exemple, l’acheminement des chemins vers les backends).
L’avenir de Gateway API
La spécification Gateway API vise à normaliser et à développer les capacités de gestion du trafic de base disponibles via Kubernetes Ingress. Elle introduit un ensemble commun d’objets et de définitions pour activer de manière cohérente la prise en charge des protocoles L4 et L7, des fonctionnalités avancées de contrôle du trafic, une personnalisation étendue des règles basée sur les en-têtes, et plus encore. Cela permet une plus grande portabilité pour les cas d’utilisation tels que le maillage de services à travers différentes plateformes de contrôleurs d’entrée, à la fois dans le nuage et sur site.
Gateway API complétera les contrôleurs d’entrée existants plutôt que de les remplacer. Les contrôleurs d’ingres qui ont traditionnellement mis en œuvre Ingress peuvent également mettre en œuvre Gateway API. Au fil du temps, Gateway API remplacera les implémentations d’Ingress spécifiques à un fournisseur au fur et à mesure de sa maturation. Les équipes peuvent désormais choisir entre une fonctionnalité Ingress de base mais fragmentée et l’adoption de Gateway API pour les besoins à l’échelle de la production concernant la prise en charge de plusieurs protocoles, la gestion avancée du trafic portable et l’infrastructure de la prochaine génération dans des environnements publics et privés.
