Kubernetes Gateway API v1.0 : Devriez-vous passer à cette version ?

Cela fait plus d'un mois que l'API Gateway de Kubernetes a publié sa version v1.0, marquant ainsi son passage au statut de disponibilité générale pour certaines de ses API clés.

J'ai écrit sur l'API Gateway lorsqu'elle est passée en bêta l'année dernière, mais un an plus tard, la question demeure. Devriez-vous passer de l'API Ingress à l'API Gateway ?

Ma réponse de l'année dernière était que vous ne devriez pas. Et j'avais de solides raisons.

L'API Gateway et ses implémentations en étaient encore à leurs balbutiements. L'API Ingress, quant à elle, était stable et couvrait certains cas d'utilisation primaires qui pourraient convenir à la plupart des utilisateurs.

Pour les utilisateurs nécessitant plus de fonctionnalités, je suggérais d'utiliser les ressources personnalisées fournies par les contrôleurs Ingress en échange de la portabilité (changement entre différentes implémentations Ingress).

Avec la version v1.0, cela pourrait changer. L'API Gateway est désormais bien plus performante, et ses 20+ implémentations rattrapent rapidement leur retard.

Ainsi, si vous démarrez un nouveau projet et devez choisir entre l'API Ingress et l'API Gateway, je vous suggère de choisir l'API Gateway si l'API et l'implémentation que vous choisissez prennent en charge toutes les fonctionnalités dont vous avez besoin.

Qu'est-ce qui ne va pas avec l'API Ingress ?

L'API Ingress fonctionne très bien, mais uniquement pour un petit sous-ensemble de cas d'utilisation courants. Pour étendre ses capacités, les implémentations Ingress ont commencé à utiliser des annotations personnalisées.

Par exemple, si vous choisissez Nginx Ingress, vous utiliserez certaines de ses dizaines d'annotations qui ne sont pas portables si vous décidez de passer à une autre implémentation Ingress comme Apache APISIX.

Ces annotations spécifiques à l'implémentation sont également fastidieuses à gérer et vont à l'encontre de l'objectif de gestion de l'Ingress de manière native à Kubernetes.

Finalement, les implémentations de contrôleurs Ingress ont commencé à développer leurs propres CRD pour exposer plus de fonctionnalités aux utilisateurs de Kubernetes. Ces CRD sont spécifiques au contrôleur Ingress. Mais si vous pouvez sacrifier la portabilité et vous en tenir à un seul contrôleur Ingress, les CRD sont plus faciles à utiliser et offrent plus de fonctionnalités.

L'API Gateway vise à résoudre ce problème une fois pour toutes en offrant l'indépendance vis-à-vis des fournisseurs de l'API Ingress et la flexibilité des CRD. Elle est très bien positionnée pour atteindre cet objectif.

À long terme, l'API Ingress ne devrait pas recevoir de nouvelles fonctionnalités, et tous les efforts seront concentrés sur la convergence avec l'API Gateway. Ainsi, adopter l'API Ingress peut poser des problèmes lorsque vous atteignez involontairement les limites de ses capacités.

Avantages évidents

Expressif, extensible et orienté rôle sont les idées clés qui ont façonné le développement de l'API Gateway.

Contrairement à l'API Ingress, l'API Gateway est une collection de plusieurs API (HTTPRoute, Gateway, GatewayClass, etc.), chacune répondant à différents rôles organisationnels.

Par exemple, les développeurs d'applications ne doivent se soucier que de la ressource HTTPRoute, où ils peuvent définir des règles pour router le trafic. Ils peuvent déléguer les détails au niveau du cluster à un opérateur qui gère le cluster et s'assure qu'il répond aux besoins des développeurs en utilisant la ressource Gateway.

Cette conception orientée rôle de l'API permet à différentes personnes d'utiliser le cluster tout en conservant le contrôle.

L'API Gateway est également bien plus performante que l'API Ingress. Les fonctionnalités qui nécessitent des annotations dans l'API Ingress sont prises en charge nativement dans l'API Gateway.

Une extension officielle

Bien que l'API Gateway soit une API officielle de Kubernetes, elle est implémentée sous forme d'un ensemble de CRD.

Cela ne diffère pas de l'utilisation des ressources Kubernetes par défaut. Mais vous devez simplement installer ces CRD comme une extension officielle.

Cela permet une itération rapide par rapport à Kubernetes, qui évolue lentement vers une stabilité à long terme.

Va-t-elle proliférer ?

Comme cette célèbre bande dessinée XKCD nous le rappelle fréquemment, les standards ont tendance à proliférer.

Une version de cela a été observée avec les API Ingress et Gateway. Cela se passe généralement ainsi :

1. Un standard émerge pour unifier différents projets/leurs standards (API Ingress de Kubernetes).
2. Le standard unifié a des limites que les implémenteurs souhaitent dépasser (l'API Ingress était limitée).
3. Les implémentations divergent du standard en raison de ces limites (CRD personnalisées, annotations).
4. Chaque implémentation a maintenant son propre standard (CRD, annotations non portables).
5. Un nouveau standard émerge pour unifier ces différents standards (API Gateway de Kubernetes).

Il est raisonnable de penser que l'API Gateway pourrait ne pas être la fin de l'histoire ici. Mais je crois qu'elle a toutes les chances de devenir le standard pour le routage dans Kubernetes.

Encore une fois, j'ai mes solides raisons.

Une adoption large est essentielle pour éviter la prolifération des standards, car il y a moins d'incitations pour les implémentations à travailler sur un autre standard. L'API Gateway compte déjà plus de 25 implémentations.

Une implémentation peut se conformer à l'API Gateway à différents niveaux :

1. Core : Toutes les implémentations sont censées se conformer à ces éléments.
2. Extended : Ces éléments pourraient ne être disponibles que dans certaines implémentations, mais ce sont des API standard.
3. Spécifique à l'implémentation : Spécifique aux implémentations mais ajouté via des points d'extension standard.

Une fonctionnalité de niche peut passer de spécifique à l'implémentation à étendue, puis à core, à mesure que plus d'implémentations prennent en charge ces fonctionnalités. C'est-à-dire que l'API permet des extensions personnalisées tout en garantissant qu'elle suit le standard.

Le projet Service Mesh Interface (SMI) était une tentative similaire de standardiser la configuration des maillages de services dans Kubernetes. Cependant, le projet a reçu peu d'adhésion après l'implication initiale des projets de maillage de services et a lentement disparu.

SMI ne prenait pas en charge de nombreuses fonctionnalités communes que les utilisateurs attendaient d'un maillage de services. Il n'a pas non plus évolué assez rapidement pour prendre en charge ces fonctionnalités. Finalement, les implémentations de maillage de services ont pris du retard dans la conformité à SMI (j'ai travaillé étroitement avec SMI sous le CNCF TAG Network sur un projet qui rapportait la conformité SMI).

Ce sont des raisons universelles, mais le projet est maintenant ressuscité via l'API Gateway. L'initiative Gateway API for Mesh Management and Administration (GAMMA) vise à étendre l'API Gateway pour qu'elle fonctionne avec les maillages de services.

Le projet SMI a récemment fusionné avec l'initiative GAMMA, ce qui est excellent pour l'API Gateway. Istio, sans aucun doute le maillage de services le plus populaire, a également annoncé que l'API Gateway sera l'API par défaut pour gérer Istio à l'avenir. De telles adoptions empêchent la prolifération.

Guide de migration

La documentation de l'API Gateway propose un guide complet sur la migration de vos ressources Ingress vers des ressources Gateway. Au lieu de le répéter, essayons d'utiliser l'outil ingress2gateway pour convertir nos ressources Ingress en ressources API Gateway correspondantes.

Vous pouvez télécharger et installer le binaire pour votre système d'exploitation directement depuis la page des versions.

Prenons une ressource Ingress simple :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-route
spec:
  ingressClassName: apisix
  rules:
    - host: local.httpbin.org
      http:
        paths:
          - backend:
              service:
                name: httpbin
                port:
                  number: 80
            path: /
            pathType: Prefix

Cela routera tout le trafic avec l'adresse hôte fournie vers le service httpbin.

Pour le convertir en ressource API Gateway, nous pouvons exécuter :

ingress2gateway print --input_file=ingress.yaml

Cette ressource API Gateway sera comme ci-dessous :

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: httpbin-route
spec:
  hostnames:
  - local.httpbin.org
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: httpbin
      port: 80

Alternatives viables

Il existe d'autres alternatives viables pour configurer des passerelles dans Kubernetes.

Dans Apache APISIX, vous pouvez le déployer en mode autonome et définir les configurations de route dans un fichier yaml. Vous pouvez mettre à jour ce fichier yaml via des workflows traditionnels, et cela peut être très utile dans les scénarios où la gestion de la configuration de la passerelle via l'API Kubernetes n'est pas nécessaire.

Les CRD spécifiques à l'implémentation sont également des alternatives viables si vous ne prévoyez pas de passer à une autre solution ou si votre configuration est suffisamment petite pour être migrée facilement.

Dans tous les cas, l'API Gateway est là pour rester.