Vergleich der Kubernetes Gateway- und Ingress-APIs

Vor ein paar Monaten hat die neue Kubernetes Gateway API den Beta-Status erreicht.

Warum benötigen Sie eine weitere API zur Handhabung von externem Traffic, wenn es bereits die stabile Kubernetes Ingress API und Dutzende von Implementierungen gibt? Welche Probleme der Ingress API löst die neue Gateway API? Bedeutet dies das Ende der Ingress API?

Ich werde versuchen, diese Fragen in diesem Artikel zu beantworten, indem ich mich praktisch mit diesen APIs beschäftige und ihre Entwicklung betrachte.

Standardisierung des externen Zugriffs auf Dienste: Die Ingress API

Die Kubernetes Ingress API wurde geschaffen, um die Bereitstellung von Diensten in Kubernetes für externen Traffic zu standardisieren. Die Ingress API überwand die Einschränkungen der Standarddiensttypen NodePort und LoadBalancer, indem sie Funktionen wie Routing und SSL-Terminierung einführte.

Es gibt über 20 Implementierungen von Ingress-Controllern. In diesem Artikel werde ich Apache APISIX und seinen Ingress-Controller für Beispiele verwenden.

Sie können eine Ingress-Ressource erstellen, um APISIX oder andere Ingress-Implementierungen zu konfigurieren.

Das folgende Beispiel zeigt, wie Sie Traffic zwischen zwei Versionen einer Anwendung mit APISIX Ingress routen können:

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

Tipp: Sie können dieses praktische Tutorial ausprobieren, um mehr über die Einrichtung von Ingress auf Kubernetes mit dem Apache APISIX Ingress-Controller zu erfahren.

Da die Ingress API nicht an eine bestimmte Controller-Implementierung gebunden ist, können Sie APISIX durch einen anderen Ingress-Controller ersetzen, und es wird ähnlich funktionieren.

Dies ist für einfaches Routing in Ordnung. Aber die API ist begrenzt, und wenn Sie die vollen Funktionen Ihres Ingress-Controllers nutzen möchten, sind Sie auf Annotations angewiesen.

Beispielsweise bietet die Kubernetes Ingress API kein Schema zur Konfiguration von Rewrites. Rewrites sind nützlich, wenn sich Ihre Upstream-/Backend-URL vom in Ihrer Ingress-Regel konfigurierten Pfad unterscheidet.

APISIX unterstützt diese Funktion, und Sie müssen benutzerdefinierte Annotations verwenden, um sie zu nutzen:

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

Dies erstellt eine Ingress-Ressource, die APISIX so konfiguriert, dass Anfragen mit dem Präfix /app an das Backend weitergeleitet werden, wobei das Präfix entfernt wird. Beispielsweise wird eine Anfrage an /app/version an /version weitergeleitet.

Annotations sind spezifisch für Ihre Wahl eines Ingress-Controllers. Diese "proprietären" Erweiterungen schränkten den ursprünglich mit der Ingress API beabsichtigten Portabilitätsumfang ein.

Benutzerdefinierte CRDs > Ingress API

Die Beschränkung auf Annotations beeinträchtigt auch die Benutzerfreundlichkeit der Ingress-Controller.

Daher haben Controller die Einschränkungen der Ingress API gelöst, indem sie eigene benutzerdefinierte Ressourcen erstellt haben. Das folgende Beispiel zeigt die Konfiguration von Ingress, um Traffic zwischen zwei Versionen einer Anwendung mit der benutzerdefinierten Ressource von APISIX zu routen:

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

Diese CRDs machten die Konfiguration von Ingress viel einfacher, aber Sie sind an die spezifische Ingress-Controller-Implementierung gebunden. Ohne eine Weiterentwicklung der Ingress API mussten Sie zwischen Benutzerfreundlichkeit und Portabilität wählen.

Erweiterung der Ingress API und Entwicklung zur Gateway API

Die Ingress API war nicht kaputt; sie war begrenzt. Die Gateway API wurde entwickelt, um diese Einschränkungen zu überwinden.

(Gateway API) zielt darauf ab, das Kubernetes-Service-Netzwerk durch ausdrucksstarke, erweiterbare und rollenorientierte Schnittstellen weiterzuentwickeln ...

Sie lässt sich von den benutzerdefinierten CRDs verschiedener Ingress-Controller inspirieren, die zuvor erwähnt wurden.

Die Gateway API fügt viele Funktionen "on top" der Fähigkeiten der Ingress API hinzu. Dazu gehören HTTP-Header-basiertes Matching, gewichtete Traffic-Aufteilung und andere Funktionen, die mit der Ingress API proprietäre Annotations erfordern.

Traffic-Aufteilung mit APISIX Ingress-Ressource (siehe ApisixRoute/v2 Referenz):

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

Traffic-Aufteilung mit Gateway API (siehe 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

Eine weitere Verbesserung gegenüber der Ingress API ist, wie die Gateway API Aufgaben trennt. Bei Ingress arbeiten der Anwendungsentwickler und der Cluster-Operator am selben Ingress-Objekt, ohne sich der Verantwortlichkeiten des anderen bewusst zu sein, was die Tür für Fehlkonfigurationen öffnet.

Die Gateway API trennt die Konfigurationen in Route- und Gateway-Objekte, was Autonomie für den Anwendungsentwickler und den Cluster-Operator bietet. Das folgende Diagramm erklärt dies deutlich:

Ist dies das Ende der Ingress API?

Die Gateway API ist relativ neu, und ihre Implementierungen sind ständig im Wandel. Im Gegensatz dazu ist die Ingress API stabil und hat sich bewährt.

Wenn Ihr Anwendungsfall nur einfaches Routing umfasst und Sie mit der Verwendung benutzerdefinierter Annotations für zusätzliche Funktionen einverstanden sind, ist die Ingress API immer noch eine solide Wahl.

Da die Gateway API eine Obermenge der Ingress API ist, könnte es sinnvoll sein, beide zu konsolidieren. Dank der SIG Network-Community wächst die Gateway API weiter und wird bald produktionsreif sein.

Die meisten Ingress-Controller und Service Meshes haben die Gateway API bereits zusammen mit der Ingress API implementiert, und im Laufe der Projektentwicklung werden weitere Implementierungen auftauchen.

Persönlich würde ich mich zumindest vorerst an die benutzerdefinierten CRDs halten, die von Ingress-Controllern wie Apache APISIX bereitgestellt werden, anstatt die Ingress- oder Gateway API zu verwenden.