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.
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.
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.
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.
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