Comparaison des API Kubernetes Gateway et Ingress

Il y a quelques mois, la nouvelle API Kubernetes Gateway est passée en version bêta, ce qui signifie probablement que vous avez plusieurs questions, telles que :

Pourquoi avez-vous besoin d’une autre API pour gérer le trafic externe alors que vous disposez de l’API Kubernetes Ingress stable 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 me familiarisant avec ces API et en examinant comment elles ont évolué.

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

L’API Kubernetes Ingress a été créée pour normaliser l’exposition des services dans Kubernetes au trafic externe. L’API Ingress a surmonté les limitations des types de services par défaut, NodePort et LoadBalanceren introduisant des fonctionnalités telles que le routage et la terminaison SSL.

Il existe plus de vingt implémentations de contrôleurs Ingress disponibles. Dans cet article, j’utiliserai Apache APISIX et son contrôleur Ingress comme 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 acheminer 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

Étant donné que l’API Ingress n’est liée à aucune implémentation de contrôleur particulière, vous pouvez échanger APISIX avec n’importe quel autre contrôleur Ingress, et cela fonctionnera de la même manière.

C’est correct pour un routage simple. Cependant, l’API est limitée et si vous souhaitez utiliser toutes les fonctionnalités fournies par votre contrôleur Ingress, vous êtes coincé avec 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 votre URL en amont/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 acheminer toutes les requêtes avec le /app préfixe au backend avec le préfixe supprimé. Par exemple, une demande de /app/version sera transmis à /version.

Les annotations sont spécifiques à votre choix de contrôleur Ingress. Ces extensions « propriétaires » limitaient la portée de la portabilité initialement prévue avec l’API Ingress.

CRD personnalisés > API d’entrée

Être coincé avec des annotations sacrifie également la convivialité 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 comment configurer Ingress pour acheminer le trafic entre deux versions d’une application à l’aide de la ressource personnalisée d’APISIX :

apisix-ingress-manifest.yamlapiVersion: 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 CRD ont facilité la configuration d’Ingress, mais vous êtes lié à l’implémentation spécifique du contrôle d’Ingress. Sans que l’API Ingress n’évolue, il fallait choisir entre convivialité ou portabilité.

Extension d’Ingress et d’Evolution à l’API Gateway

L’API d’entrée n’était pas cassée ; c’était limité. L’API Gateway a été conçue pour surmonter ces limitations.

(Gateway API) vise à faire évoluer la mise en réseau des services Kubernetes grâce à des interfaces expressives, extensibles et axées sur les rôles…

—Source: « Qu’est-ce que l’API de passerelle ? »

Il s’inspire des CRD 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 l’en-tête 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 APISIX Ingress :

apisix-ingress-manifest.yamlapiVersion: 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 :

kubernetes-gateway-manifest.yamlapiVersion: 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 façon 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 itinéraire et passerelle objets, offrant une autonomie au développeur de l’application et à l’opérateur du cluster. Le schéma ci-dessous l’explique clairement :

Conclusion

Est-ce la fin de l’API Ingress ?

L’API Gateway est relativement nouvelle et ses implémentations se cassent constamment. Au contraire, l’API Ingress est en version stable et a résisté à l’épreuve du temps.

Si votre cas d’utilisation n’implique qu’un routage simple et que vous êtes d’accord avec l’utilisation d’annotations personnalisées pour obtenir des fonctionnalités supplémentaires, l’API Ingress reste un choix solide.

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

La plupart des contrôleurs Ingress et des maillages de services ont déjà implémenté l’API Gateway avec l’API Ingress, et à mesure que le projet évolue, d’autres implémentations apparaîtront.

Personnellement, du moins pour l’instant, je m’en tiendrai aux CRD personnalisés fournis par les contrôleurs Ingress comme au lieu de l’API Ingress ou Gateway.