Kubernetes Gateway API v1.0: Sollten Sie wechseln?

Es ist über einen Monat her, seit die Kubernetes Gateway API ihre v1.0-Version veröffentlicht hat, was den Übergang zur allgemeinen Verfügbarkeit für einige ihrer wichtigsten APIs bedeutet.

Ich habe über die Gateway API geschrieben, als sie letztes Jahr den Beta-Status erreichte, aber ein Jahr später bleibt die Frage immer noch bestehen. Sollten Sie von der Ingress API zur Gateway API wechseln?

Meine Antwort vom letzten Jahr war, dass Sie es nicht sollten. Und ich hatte starke Gründe dafür.

Die Gateway API und ihre Implementierungen waren noch in den Kinderschuhen. Die Ingress API hingegen war stabil und deckte einige primäre Anwendungsfälle ab, die für die meisten Benutzer geeignet sein könnten.

Für Benutzer, die mehr Funktionen benötigen, schlug ich vor, die benutzerdefinierten Ressourcen (CRDs) zu verwenden, die von den Ingress-Controllern bereitgestellt werden, indem man Portabilität (Wechsel zwischen verschiedenen Ingress-Implementierungen) opfert.

Mit der v1.0-Version könnte sich dies ändern. Die Gateway API ist jetzt viel leistungsfähiger, und ihre 20+ Implementierungen holen schnell auf.

Wenn Sie also neu beginnen und zwischen der Ingress- und der Gateway API wählen, empfehle ich Ihnen, die Gateway API zu wählen, wenn die API und die von Ihnen gewählte Implementierung alle gewünschten Funktionen unterstützen.

Was ist mit der Ingress API falsch?

Die Ingress API funktioniert sehr gut, aber nur für eine kleine Teilmenge gängiger Anwendungsfälle. Um ihre Fähigkeiten zu erweitern, begannen Ingress-Implementierungen, benutzerdefinierte Anmerkungen (Annotations) zu verwenden.

Wenn Sie beispielsweise Nginx Ingress gewählt haben, werden Sie einige der Dutzenden von Anmerkungen verwenden, die nicht portabel sind, wenn Sie sich entscheiden, zu einer anderen Ingress-Implementierung wie Apache APISIX zu wechseln.

Diese implementierungsspezifischen Anmerkungen sind auch umständlich zu verwalten und untergraben den Zweck, Ingress auf eine Kubernetes-native Weise zu verwalten.

Schließlich begannen Ingress-Controller-Implementierungen, ihre eigenen CRDs zu entwickeln, um Kubernetes-Benutzern mehr Funktionen zu bieten. Diese CRDs sind spezifisch für den Ingress-Controller. Aber wenn Sie auf Portabilität verzichten und bei einem Ingress-Controller bleiben können, sind die CRDs einfacher zu handhaben und bieten mehr Funktionen.

Die Gateway API zielt darauf ab, dieses Problem ein für alle Mal zu lösen, indem sie die Anbieterunabhängigkeit der Ingress API und die Flexibilität der CRDs bietet. Sie ist sehr gut positioniert, um dieses Ziel zu erreichen.

Langfristig wird erwartet, dass die Ingress API keine neuen Funktionen mehr erhalten wird und alle Bemühungen darauf abzielen, mit der Gateway API zusammenzuführen. Daher kann die Übernahme der Ingress API Probleme verursachen, wenn Sie versehentlich an die Grenzen ihrer Fähigkeiten stoßen.

Offensichtliche Vorteile

Ausdrucksstark, erweiterbar und rollenorientiert sind die Schlüsselideen, die die Entwicklung der Gateway API geprägt haben.

Im Gegensatz zur Ingress API ist die Gateway API eine Sammlung mehrerer APIs (HTTPRoute, Gateway, GatewayClass usw.), die jeweils unterschiedliche organisatorische Rollen bedienen.

Beispielsweise müssen sich Anwendungsentwickler nur um die HTTPRoute-Ressource kümmern, in der sie Regeln zur Weiterleitung des Datenverkehrs definieren können. Sie können die Cluster-spezifischen Details einem Operator überlassen, der den Cluster verwaltet und sicherstellt, dass er die Anforderungen der Entwickler mithilfe der Gateway-Ressource erfüllt.

Dieses rollenorientierte Design der API ermöglicht es verschiedenen Personen, den Cluster zu nutzen, während die Kontrolle gewahrt bleibt.

Die Gateway API ist auch viel leistungsfähiger als die Ingress API. Funktionen, die in der Ingress API Anmerkungen erfordern, werden in der Gateway API out-of-the-box unterstützt.

Eine offizielle Erweiterung

Obwohl die Gateway API eine offizielle Kubernetes-API ist, wird sie als eine Reihe von CRDs implementiert.

Dies unterscheidet sich nicht von der Verwendung standardmäßiger Kubernetes-Ressourcen. Sie müssen jedoch diese CRDs installieren wie eine offizielle Erweiterung.

Dies ermöglicht eine schnelle Iteration im Vergleich zu Kubernetes, das sich langsam in Richtung langfristiger Stabilität bewegt.

Wird es sich verbreiten?

Wie dieser berühmte XKCD-Comic uns häufig in Erinnerung ruft, neigen Standards dazu, sich zu verbreiten.

Eine Version davon wurde bei den Ingress- und Gateway APIs beobachtet. Es läuft normalerweise so ab:

1. Ein Standard entsteht, um verschiedene Projekte/deren Standards zu vereinheitlichen (Kubernetes Ingress API).
2. Der vereinheitlichte Standard hat Einschränkungen, die die Implementierer überwinden möchten (Ingress API war begrenzt).
3. Implementierungen weichen aufgrund dieser Einschränkungen vom Standard ab (benutzerdefinierte CRDs, Anmerkungen).
4. Jede Implementierung hat jetzt ihren eigenen Standard (nicht portable CRDs, Anmerkungen).
5. Ein neuer Standard entsteht, um diese verschiedenen Standards zu vereinheitlichen (Kubernetes Gateway API).

Es ist vernünftig zu denken, dass die Gateway API möglicherweise nicht das Ende der Fahnenstange ist. Aber ich glaube, sie hat jede Chance, der Standard für das Routing in Kubernetes zu werden.

Wieder habe ich meine starken Gründe.

Eine breite Akzeptanz ist entscheidend, um die Verbreitung von Standards zu verhindern, da es weniger Anreize für Implementierungen gibt, an einem anderen Standard zu arbeiten. Die Gateway API hat bereits mehr als 25 Implementierungen.

Eine Implementierung kann auf verschiedenen Ebenen mit der Gateway API konform sein:

1. Kern: Alle Implementierungen sollen diese erfüllen.
2. Erweitert: Diese sind möglicherweise nur in einigen Implementierungen verfügbar, aber es handelt sich um standardisierte APIs.
3. Implementierungsspezifisch: Spezifisch für Implementierungen, aber über standardisierte Erweiterungspunkte hinzugefügt.

Eine Nischenfunktion kann von implementierungsspezifisch zu erweitert und schließlich zum Kern übergehen, wenn mehr Implementierungen diese Funktionen unterstützen. D.h., die API lässt Raum für benutzerdefinierte Erweiterungen, während sie sicherstellt, dass sie dem Standard folgt.

Das Service Mesh Interface (SMI) Projekt war ein ähnlicher Versuch, die Konfiguration von Service Meshes in Kubernetes zu standardisieren. Das Projekt erhielt jedoch nach der anfänglichen Beteiligung der Service-Mesh-Projekte wenig Aufmerksamkeit und starb langsam aus.

SMI unterstützte nicht viele gemeinsame Nennerfunktionen, die Benutzer in einem Service Mesh erwarteten. Es bewegte sich auch nicht schnell genug, um diese Funktionen zu unterstützen. Schließlich fielen Service-Mesh-Implementierungen bei der Konformität mit SMI zurück (ich habe eng mit SMI unter der CNCF TAG Network an einem Projekt gearbeitet, das die SMI-Konformität meldete).

Dies sind universelle Gründe, aber das Projekt wird jetzt durch die Gateway API wiederbelebt. Die Gateway API for Mesh Management and Administration (GAMMA) Initiative zielt darauf ab, die Gateway API für die Arbeit mit Service Meshes zu erweitern.

Das SMI-Projekt hat sich kürzlich mit der GAMMA-Initiative zusammengeschlossen, was für die Gateway API hervorragend ist. Istio, zweifellos das beliebteste Service Mesh, hat auch angekündigt, dass die Gateway API in Zukunft die Standard-API zur Verwaltung von Istio sein wird. Solche Übernahmen verhindern die Verbreitung.

Migrationsleitfaden

Die Gateway API-Dokumentation enthält einen umfassenden Leitfaden zur Migration Ihrer Ingress-Ressourcen zu Gateway-Ressourcen. Anstatt ihn zu wiederholen, versuchen wir, das ingress2gateway-Tool zu verwenden, um unsere Ingress-Ressourcen in entsprechende Gateway API-Ressourcen umzuwandeln.

Sie können die Binärdatei für Ihr Betriebssystem direkt von der Releases-Seite herunterladen und installieren.

Nehmen wir eine einfache Ingress-Ressource:

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

Dies wird den gesamten Datenverkehr mit der angegebenen Host-Adresse an den httpbin-Service weiterleiten.

Um es in eine Gateway API-Ressource umzuwandeln, können wir Folgendes ausführen:

ingress2gateway print --input_file=ingress.yaml

Diese Gateway API-Ressource wird wie folgt aussehen:

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

Lebensfähige Alternativen

Es gibt andere lebensfähige Alternativen für die Konfiguration von Gateways in Kubernetes.

In Apache APISIX können Sie es im Standalone-Modus bereitstellen und Routenkonfigurationen in einer YAML-Datei definieren. Sie können diese YAML-Datei über traditionelle Workflows aktualisieren, und sie kann in Szenarien hilfreich sein, in denen die Verwaltung der Gateway-Konfiguration über die Kubernetes-API nicht erforderlich ist.

Implementierungsspezifische benutzerdefinierte CRDs sind ebenfalls lebensfähige Alternativen, wenn Sie nicht planen, zu einer anderen Lösung zu wechseln oder wenn Ihre Konfiguration klein genug ist, um leicht zu migrieren.

In jedem Fall ist die Gateway API hier, um zu bleiben.