In diesem TechUp schauen wir uns an, wie man einen API-Gateway mit der Gateway-API aufbaut und wieso der kombinierte Einsatz Sinn macht. Zudem werden wir uns anhand eines konkreten Beispiels die Cilium Gateway API Implementation genauer anschauen. 🚀

Was ist ein API-Gateway?

Ein API-Gateway ist die zentrale Komponente einer Microservice-Architektur, welche den Traffic zu unterschiedlichen Backend-Systemen verwaltet.

Man kann sich einen API-Gateway wie einen Verkehrslotsen vorstellen; alle grünen Autos werden in eine Richtung, alle gelben in eine andere Richtung geschickt. Ausserdem werden Autos ohne Dach abgewiesen (es ist Regen gemeldet) und Fussgänger werden komplett abgeblockt.

Figure: Einfache Architektur

Grundlegende Aufgaben eines API-Gateways

Kommunikationsverbindungen vereinfachen und zentralisiert verwalten

Ohne einen API-Gateway müsste jeder Konsument, jedes Frontend etc. jede Adresse aller z.B. Microservices kennen. Dies wird zusätzlich problematisch, wenn man einen bestehenden Service aufteilen will, da jeder Client zuerst bspw. die neue Adresse implementieren muss. Somit implementiert ein API-Gateway eine lose Kopplung zwischen zwei Services.

Same-Origin-Policy

Mit dem Einsatz einen API-Gateways fallen lästige CORS (Cross-Origin Resource Sharing) Probleme und Ausnahmen weg, da sämtlicher Traffic “path-based” gemacht werden kann.

Schutz bestimmter API Ressourcen

Ein API-Gateway kann einfach bestimmen, ob ein Client Zugriff auf einen Pfad erhält, oder nicht. Dies geschieht anhand von unterschiedlichen Merkmalen wie Domainname, Namespace, Headers, Tokens oder anderen Authentifizierungsinformationen. Auch Schutz vor Angriffen durch bspw. Rate Limiting sind wichtige Funktionen eines API-Gateways.

Routing

Einfach gesagt ist ein API-Gateway ein mächtiger Reverse Proxy: Er leitet Traffic an die entsprechende Zielinstanz weiter.

Hierbei kann ein API-Gateway auch Traffic Splitting (wie beispielsweise Canary oder Blue-Green Rollouts) betreiben oder bspw. nur 10 % der Requests auf eine neue Version eines Backend-Microservices leiten.

Überwachung, Monitoring

Eine dauerhafte Überwachung aller API-Schnittstellen ist ebenfalls ein zentraler Bestandteil. So können Störungen, Performance-Probleme oder Ausfälle sehr schnell erkannt und abgefangen werden.

Weitere Informationen zum Thema Proxy findet ihr hier in einem früheren TechUp. 😁

Wann macht die Nutzung eines API-Gateways Sinn?

Bereits im “kleinen Stil”, also bei kleineren Projekten und Architekturen macht der Einsatz eines API-Gateways durchaus Sinn! Die Konsumenten von APIs haben einen gewohnten Anlaufpunkt - Dinge wie Management, Aufbau, Tools, Systeme, und vor allem die Adressen dahinter sind ihnen salopp gesagt egal.

Was ist Gateway API?

Moment, gerade haben wir über einen API-Gateway gesprochen, und nun geht es um Gateway-API? 🤯

Die Kubernetes Gateway API ist ein Open-Source-Projekt, welches von der SIG-Network Community betrieben wird. Sie definieren dabei unterschiedliche Ressourcen, um Service Networking in Kubernetes standardisiert zu modellieren. Hierbei geht es “nur” um Custom Resource Definitions (CRDs), welche Layer 4 und Layer 7 Routing für Kubernetes unabhängig standardisieren. Ziel ist es, einen standardisierten Layer zu schaffen, um verschiedene API-Gateway Funktionalitäten in einem Kubernetes-Cluster zu implementieren, ohne einen kompletten “Vendor Lock-In” machen zu müssen.

Mit Gateway API können wir also vereinfacht gesagt API-Gateways in einem standardisierten Format definieren.

Gateway API ist seit Juli 2022 im Beta-Status und liegt aktuell in einer v1beta1-Version vor, der erste Release geht zurück ins Jahr 2020.

Gateway API Specification

Folgende Komponenten beschreibt die Gateway API Spec (unter anderem):

• GatewayClasses: Ein Template, welches einem Infrastructure Provider erlaubt, Templates zu definieren (beispielsweise Internet oder Private als Template, je nachdem ob der Traffic public ist oder nicht)
• Gateway: Die Instanz einer GatewayClass, beispielsweise ein TLS Gateway, welcher direkt die richtigen Zertifikate hinterlegt hat
• HTTPRoute (Layer 7): Eine HTTP Route wird zum multiplexen von HTTP-Requests verwendet. Routing kann beispielsweise anhand eines Headers passieren
• GRPCRoute (Layer 7): Wird genutzt um gRPC Requests zu routen
• TLSRoute: Routing von TLS, z.B. HTTPS-Traffic wo eine Überprüfung vom HTTP Request nicht nötig ist
• TCPRoute/UDPRoute (Layer 4): Wird genutzt, um einen Port auf ein Backend zu mappen
• ReferenceGrant: Eine Art Handshake um Cross-Namespace-Kommunikation zu erlauben, sodass bspw. der Gateway in einem Namespace die Routes eines anderen Namespaces lesen und nutzen darf
• Service: Der Kubernetes Service, welcher den Traffic schlussendlich empfängt

Gateway und Routes sind getrennt voneinander angelegt. Dies erlaubt es, den Gateway-Controller auszutauschen, ohne etwas an den Routes machen zu müssen. Durch diesen modularen Aufbau ergeben sich klar definierte Verantwortungsbereiche für einen Infrastruktur-Provider, einen Cluster Operator sowie einen Application Developer.

Schauen wir uns die Komponenten anhand eines Beispiels an:

Figure: Quelle: https://gateway-api.sigs.k8s.io/

Hier ist schön zu sehen, dass ein Gateway “foo” unterschiedliche HTTPRoutes in unterschiedlichen Namespaces kennt, und den Traffic entsprechend zum korrekten Service leitet.

An dieser Stelle ist zu erwähnen, dass Gateway API kein Replacement für die Kubernetes Ingress API ist. Im Gegensatz zur Gateway API zielt die Ingress API meist auf das Exponieren unterschiedlicher HTTP Routes ab. Gateway API hingegen bietet mehrere Möglichkeiten als nur HTTP an und ist in den Infrastrukturkomponenten besser integriert, was für ein besseres Management für Cluster Provider sorgen soll.

Beispielsweise gibt es aktuell u.a. folgende Implementationen:

• Cilium
• Istio
• Envoy Gateway
• Emissary-Ingress (Ambassador API-Gateway)
• HashiCorp Consul
• Google Kubernetes Engine
• HAProxy
• NGINX Kubernetes Gateway

Cilium Gateway API

Die Cilium Gateway API Implementation wollen wir uns nun genauer anschauen. An dieser Stelle sei erwähnt, dass deren Status noch in der “Work in progress” Phase steht.

Falls dir Cilium, eBPF und ähnliches noch kein Begriff ist, hier erfährst du alles, was du wissen musst!

• eBPF-basiertes Networking mit Cilium - Was ist das und was kann es?
• eBPF-Logik mit Bumblebee einfach bauen und teilen
• Stärke dein System mit Tetragon’s eBPF-basierten Security-Observability und Runtime-Enforcement Fähigkeiten

Mit der aktuell verfügbaren Version von Cilium 1.12 wurde im Juli 2022 der Support für Gateway API integriert, welcher stetig weiterentwickelt wird. Mit Version 1.13 soll es hier zahlreiche Updated geben. Stay tuned!

Cilium Service Mesh

Cilium selbst nutzt Gateway API als Teil ihres Service Mesh Konzepts. Ziel ist es, Cilium über diesen offenen Standard kompatibel mit anderen Service Mesh Providern wie z.B. Istio zu machen.

Figure: Quelle: https://isovalent.com/blog/post/cilium-service-mesh/

Cilium Gateway API Beispiel

Was genau bedeutet es, Cilium als Gateway API Implementation aufzusetzen?

Voraussetzungen:

• Neuste Cilium Version, z.B. v1.13.0-rc4
• Cilium muss als CNI eingesetzt werden
• Cilium muss als KubeProxyReplacement fungieren (Mode partial oder strict)
• Die Gateway API CRDs müssen vorher installiert werden

Cilium installiert dann automatisch eine GatewayClass, wohinter sich der “io.cilium/gateway-controller” verbirgt.

Anschliessend können wir unseren ersten Gateway und eine HTTP Route erstellen:

• Wir definieren einen Gateway mit einem Listener auf Port 80, welcher auf alle Routes im selben Namespace hört
• Mittels des “gatewayClassName” referenzieren wir die Cilium Implementation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-b-nova-gateway
spec:
  gatewayClassName: cilium
  listeners:
  - protocol: HTTP
    port: 80
    name: web-b-nova-gw
    allowedRoutes:
      namespaces:
        from: Same

• Anschliessend definieren wir zwei HTTP Routes für unsere Gateway (via parentRefs)
• hello-Route
  • Traffic auf /hello (auf Port 80, im Gateway definiert) wird an den hello Service auf Port 9080 gerouted
• b-nova-page-Route
  • Traffic, welcher auf / mit dem Header user=tom und den Queryparam secretcode=123 kommt wird an den b-nova-page-Service auf Port 9080 geleitet

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: http-b-nova-app-1
spec:
  parentRefs:
  - name: my-b-nova-gateway
    namespace: default
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /hello
    backendRefs:
    - name: hello
      port: 9080
  - matches:
    - headers:
      - type: Exact
        name: user
        value: tom
      queryParams:
      - type: Exact
        name: secretcode
        value: 123
      path:
        type: PathPrefix
        value: /
      method: GET
    backendRefs:
    - name: b-nova-page
      port: 9080

Du willst mehr über die Gateway API, Cilium oder generell DevSevOps und Cloud-Native-Themen erfahren? Höre unsere Podcast decodify oder melde dich direkt bei uns! 🎉

Fazit

Use Gateway API! 👌

Auch wenn die Kubernetes Gateway API noch in Kinderschuhen bzw. der Beta-Phase steckt, empfiehlt sich jetzt schon der Einsatz davon, da immer mehr und mehr Provider, Frameworks, Plugins und Tools den Standard unterstützen. Das Role Base Model erleichtert das Management von zentralen Gateways mit dedizierten Routes in einzelnen Namespaces und sorgt so für eine klare Trennung der Verantwortlichkeiten. Der Cluster-Admin kann den Gateway, das Loadbalancing o.ä. komplett umstellen, ohne das der Developer oder der Service selbst etwas davon mitbekommt oder gar ändern muss!

Stay tuned für weitere spannende Cilium Themen! :)