Comparaison des API Kubernetes Gateway et Ingress

Il y a quelques mois, la nouvelle API Gateway de Kubernetes est passée en version bêta.

Pourquoi avez-vous besoin d'une autre API pour gérer le trafic externe alors que vous disposez de l'API stable Kubernetes Ingress et de dizaines d'implémentations ? Quels problèmes de l'API Ingress la nouvelle API Gateway résout-elle ? Cela signifie-t-il la fin de l'API Ingress ?

Je vais essayer de répondre à ces questions dans cet article en explorant ces API et en examinant leur évolution.

Standardisation de l'accès externe aux services : L'API Ingress

L'API Kubernetes Ingress a été créée pour standardiser l'exposition des services Kubernetes au trafic externe. L'API Ingress a surmonté les limitations des types de services par défaut, NodePort et LoadBalancer, en introduisant des fonctionnalités comme le routage et la terminaison SSL.

Il existe plus de 20 implémentations de contrôleurs Ingress disponibles. Dans cet article, j'utiliserai Apache APISIX et son contrôleur Ingress pour les exemples.

Vous pouvez créer une ressource Ingress pour configurer APISIX ou toute autre implémentation Ingress.

L'exemple ci-dessous montre comment vous pouvez router le trafic entre deux versions d'une application avec APISIX Ingress :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-routes
spec:
  ingressClassName: apisix
  rules:
    - host: local.navendu.me
      http:
        paths:
          - backend:
              service:
                name: bare-minimum-api-v1
                port:
                  number: 8080
            path: /v1
            pathType: Prefix
          - backend:
              service:
                name: bare-minimum-api-v2
                port:
                  number: 8081
            path: /v2
            pathType: Prefix

Astuce : Vous pouvez consulter ce tutoriel pratique pour en savoir plus sur la configuration d'Ingress sur Kubernetes avec le contrôleur Ingress Apache APISIX.

Comme l'API Ingress n'est pas liée à une implémentation spécifique de contrôleur, vous pouvez remplacer APISIX par n'importe quel autre contrôleur Ingress, et cela fonctionnera de la même manière.

Cela convient pour un routage simple. Mais l'API est limitée, et si vous souhaitez utiliser toutes les fonctionnalités offertes par votre contrôleur Ingress, vous êtes contraint d'utiliser des annotations.

Par exemple, l'API Kubernetes Ingress ne fournit pas de schéma pour configurer les réécritures. Les réécritures sont utiles lorsque l'URL de votre backend diffère du chemin configuré dans votre règle Ingress.

APISIX prend en charge cette fonctionnalité, et vous devez utiliser des annotations personnalisées pour en tirer parti :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-routes
  annotations:
    k8s.apisix.apache.org/rewrite-target-regex: "/app/(.*)"
    k8s.apisix.apache.org/rewrite-target-regex-template: "/$1"
spec:
  ingressClassName: apisix
  rules:
    - host: local.navendu.me
      http:
        paths:
          - backend:
              service:
                name: bare-minimum-api
                port:
                  number: 8080
            path: /app
            pathType: Prefix

Cela crée une ressource Ingress qui configure APISIX pour router toutes les requêtes avec le préfixe /app vers le backend en supprimant le préfixe. Par exemple, une requête vers /app/version sera redirigée vers /version.

Les annotations sont spécifiques à votre choix de contrôleur Ingress. Ces extensions "propriétaires" limitent la portabilité initialement prévue avec l'API Ingress.

Les CRDs personnalisés > L'API Ingress

Être contraint d'utiliser des annotations sacrifie également la facilité d'utilisation des contrôleurs Ingress.

Les contrôleurs ont donc résolu les limitations de l'API Ingress en créant leurs propres ressources personnalisées. L'exemple ci-dessous montre la configuration d'Ingress pour router le trafic entre deux versions d'une application en utilisant la ressource personnalisée d'APISIX :

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: api-routes
spec:
  http:
    - name: route-1
      match:
        hosts:
          - local.navendu.me
        paths:
          - /v1
      backends:
        - serviceName: bare-minimum-api-v1
          servicePort: 8080
    - name: route-2
      match:
        hosts:
          - local.navendu.me
        paths:
          - /v2
      backends:
        - serviceName: bare-minimum-api-v2
          servicePort: 8081

Ces CRDs ont rendu la configuration d'Ingress beaucoup plus facile, mais vous êtes lié à l'implémentation spécifique du contrôleur Ingress. Sans évolution de l'API Ingress, vous deviez choisir entre la facilité d'utilisation ou la portabilité.

Extension d'Ingress et évolution vers l'API Gateway

L'API Ingress n'était pas cassée ; elle était limitée. L'API Gateway a été conçue pour surmonter ces limitations.

(L'API Gateway) vise à faire évoluer le réseau de services Kubernetes grâce à des interfaces expressives, extensibles et orientées rôle...

Elle s'inspire des CRDs personnalisés des différents contrôleurs Ingress mentionnés précédemment.

L'API Gateway ajoute de nombreuses fonctionnalités "en plus" des capacités de l'API Ingress. Cela inclut la correspondance basée sur les en-têtes HTTP, la répartition pondérée du trafic, et d'autres fonctionnalités qui nécessitent des annotations propriétaires personnalisées avec l'API Ingress.

Répartition du trafic avec la ressource Ingress APISIX (voir ApisixRoute/v2 reference) :

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: traffic-split
spec:
  http:
    - name: rule-1
      match:
        hosts:
          - local.navendu.me
        paths:
          - /get*
      backends:
        - serviceName: bare-minimum-api-v1
          servicePort: 8080
          weight: 90
        - serviceName: bare-minimum-api-v2
          servicePort: 8081
          weight: 10

Répartition du trafic avec l'API Gateway (voir Canary traffic rollout) :

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: traffic-split
spec:
  hostnames:
  - local.navendu.me
  rules:
  - backendRefs:
    - name: bare-minimum-api-v1
      port: 8080
      weight: 90
    - name: bare-minimum-api-v2
      port: 8081
      weight: 10

Une autre amélioration par rapport à l'API Ingress est la manière dont l'API Gateway sépare les préoccupations. Avec Ingress, le développeur d'application et l'opérateur du cluster travaillent sur le même objet Ingress, ignorant les responsabilités de l'autre et ouvrant la porte à des erreurs de configuration.

L'API Gateway sépare les configurations en objets Route et Gateway, offrant ainsi une autonomie au développeur d'application et à l'opérateur du cluster. Le diagramme ci-dessous explique cela clairement :

Est-ce la fin de l'API Ingress ?

L'API Gateway est relativement nouvelle, et ses implémentations sont en constante évolution. En revanche, l'API Ingress est en version stable et a fait ses preuves.

Si votre cas d'utilisation ne concerne que le routage simple et si vous êtes d'accord pour utiliser des annotations personnalisées pour obtenir des fonctionnalités supplémentaires, l'API Ingress reste un choix solide.

Avec l'API Gateway étant un sur-ensemble de l'API Ingress, il pourrait être logique de consolider les deux. Grâce à la communauté SIG Network, l'API Gateway continue de croître et sera bientôt prête pour la production.

La plupart des contrôleurs Ingress et des maillages de services ont déjà implémenté l'API Gateway ainsi que l'API Ingress, et à mesure que le projet évolue, d'autres implémentations verront le jour.

Personnellement, au moins pour l'instant, je resterais avec les CRDs personnalisés fournis par les contrôleurs Ingress comme Apache APISIX plutôt qu'avec l'API Ingress ou Gateway.