Gateway API v1.1: Neue Features für Entwickler und DevOps-Teams!
ayedo Redaktion 3 Minuten Lesezeit

Gateway API v1.1: Neue Features für Entwickler und DevOps-Teams!

Entdecken Sie die neuen Funktionen der Gateway API v1.1, inklusive Service Mesh und GRPCRoute, die Ihre Kubernetes-Anwendungen optimieren.
kubernetes kubernetes-news devops networking api

Gateway API logo

Nach der allgemeinen Freigabe der Gateway API im vergangenen Oktober freut sich das Kubernetes SIG Network, die Veröffentlichung von v1.1 der Gateway API anzukündigen. In dieser Version sind mehrere Funktionen nun im Standard Channel (GA) verfügbar, darunter die Unterstützung für Service Mesh und GRPCRoute. Zudem führen wir einige neue experimentelle Funktionen ein, wie Sitzungs-Persistenz und die Überprüfung von Client-Zertifikaten.

Was ist neu?

Graduierung zum Standard

In dieser Version sind vier sehnsüchtig erwartete Funktionen zum Standard aufgestiegen. Das bedeutet, dass sie nicht länger experimentelle Konzepte sind; die Aufnahme in den Standardrelease-Kanal zeigt ein hohes Maß an Vertrauen in die API-Oberfläche und bietet Garantien für die Abwärtskompatibilität. Natürlich können Funktionen im Standard Channel weiterhin weiterentwickelt werden, wobei wir im Laufe der Zeit mit abwärtskompatiblen Ergänzungen rechnen. Weitere Informationen dazu finden Sie in der Gateway API Versioning Policy.

Service Mesh Unterstützung

Die Unterstützung für Service Mesh in der Gateway API ermöglicht es Nutzern, die gleiche API zur Verwaltung des Ingress-Traffics und des Mesh-Traffics zu verwenden, indem die gleichen Richtlinien- und Routing-Schnittstellen wiederverwendet werden. In Gateway API v1.1 können Routen (wie HTTPRoute) nun einen Service als parentRef haben, um zu steuern, wie der Traffic zu bestimmten Services verläuft. Für weitere Informationen lesen Sie die Gateway API Service Mesh-Dokumentation oder sehen Sie sich die Liste der Implementierungen der Gateway API an.

Ein Beispiel für ein Canary Deployment eines Workloads tief im Anrufgraphen einer Anwendung könnte wie folgt aussehen:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: color-canary
  namespace: faces
spec:
  parentRefs:
    - name: color
      kind: Service
      group: ""
      port: 80
  rules:
  - backendRefs:
    - name: color
      port: 80
      weight: 50
    - name: color2
      port: 80
      weight: 50

Dies würde den Traffic, der an den color Service im faces Namespace gesendet wird, 50/50 zwischen dem ursprünglichen color Service und dem color2 Service aufteilen und dabei eine portable Konfiguration verwenden, die einfach von einem Mesh zum anderen verschoben werden kann.

GRPCRoute

Wenn Sie bereits die experimentelle Version von GRPCRoute verwenden, empfehlen wir, vor einem Upgrade auf die Standardversion von GRPCRoute zu warten, bis die von Ihnen verwendeten Controller auf GRPCRoute v1 aktualisiert wurden. Bis dahin ist es sicher, auf die experimentelle Version von GRPCRoute in v1.1 zu aktualisieren, die sowohl v1alpha2 als auch v1 API-Versionen umfasst.

ParentReference Port

Das port-Feld wurde zu ParentReference hinzugefügt, sodass Sie Ressourcen an Gateway-Listener, Services oder andere übergeordnete Ressourcen (je nach Implementierung) anhängen können. Das Binden an einen Port ermöglicht es Ihnen auch, an mehrere Listener gleichzeitig anzuhängen.

Zum Beispiel können Sie eine HTTPRoute an einen oder mehrere spezifische Listener eines Gateways anhängen, wie durch den port des Listeners angegeben, anstatt durch das Feld des Listener-Namens.

Für weitere Informationen siehe Anschluss an Gateways.

Die neue Version der Gateway API v1.1 bietet Entwicklern und DevOps-Teams viele spannende Möglichkeiten, um ihre Kubernetes-Anwendungen noch effizienter zu gestalten. ayedo ist stolz darauf, als Partner in der Kubernetes-Community aktiv zu sein und Ihnen bei der Implementierung dieser neuen Funktionen zur Seite zu stehen.


Quelle: Kubernetes Blog

Ähnliche Artikel