DEV Community: zakaria zermani

Von Ingress API zu Gateway API: Warum sich der Wechsel lohnt

zakaria zermani — Sun, 26 Jul 2026 17:29:55 +0000

Kubernetes-Nutzer kennen die Ingress API seit Jahren als Standardweg, um HTTP(S)-Traffic ins Cluster zu routen. Aber die Ingress API zeigt inzwischen deutliche Grenzen – und genau deshalb hat sich die Gateway API als moderner, flexiblerer Nachfolger etabliert. In diesem Artikel schauen wir uns an, warum sich der Umstieg lohnt, was sich konzeptionell ändert und wie sich konkrete Ingress-Features auf die Gateway API übertragen lassen.

Warum überhaupt wechseln?

Die Ingress API hat drei grundlegende Schwachstellen, die im Alltag schnell spürbar werden:

1. Eingeschränkte Funktionalität

Die Ingress API unterstützt nur TLS-Terminierung und einfaches, inhaltsbasiertes Routing von HTTP-Traffic. TCP, UDP oder gRPC-Routing? Fehlanzeige. Um trotzdem erweiterte Funktionen anzubieten, greifen Ingress-Controller auf Annotationen zurück – proprietäre Erweiterungen, die außerhalb des eigentlichen Standards liegen.

Das Problem dabei: Jede Implementierung (NGINX, Traefik, Envoy, …) bringt ihre eigenen Annotationen mit, die nicht zwangsläufig zu anderen Controllern kompatibel sind. Wer den Ingress-Controller wechselt, muss:

Alle verwendeten Annotationen identifizieren,
die entsprechenden Funktionen im neuen Controller suchen,
und die Konfiguration manuell nachbauen.

Das macht den Wechsel zwischen Implementierungen mühsam bis unmöglich.

2. Fehlendes Berechtigungsmodell

Das klassische Ingress-Modell wurde um eine einzige zentrale Ressource herum entworfen. Dadurch gibt es faktisch nur eine Hauptrolle: die Person, die die Ingress-Ressource erstellt. Diese kann gleichzeitig Routing-Regeln definieren, TLS konfigurieren und teilweise sogar Einfluss auf die zugrunde liegende Load-Balancing-Infrastruktur nehmen.

In kleinen Clustern mit einem Team ist das kein Problem. Aber stell dir folgendes Szenario vor:

Team A betreibt einen Shop
Team B betreibt eine API
Team C betreibt ein Kundenportal
Alle teilen sich denselben Load Balancer bzw. Ingress Controller

Mit dem Ingress-Modell fehlt eine saubere Trennung zwischen Infrastruktur-Verantwortlichen, Applikations-Administratoren und Entwicklern. Entwickler können dadurch potenziell Konfigurationen erstellen, die sich auf die gemeinsam genutzte Infrastruktur auswirken – ohne dass es dafür ein standardisiertes Rollenmodell gibt.

3. Unhandliches API-Design

Annotationen sind einfache Key-Value-Strings und werden pauschal im Metadata-Block gesetzt statt strukturiert im relevanten Teil der Spec. Sobald viele Annotationen zusammenkommen, wird eine Ingress-Ressource schnell unübersichtlich.

Die Kernunterschiede:

Personas

Einer der größten konzeptionellen Sprünge der Gateway API ist ein sauber definiertes Rollenmodell.

Bei der Ingress API gibt es im Kern nur eine explizite Persona:

Der User: Besitzer der Ingress-Ressourcen

Implizit kommen dazu:

Infrastructure Provider: verwaltet einen providerseitig bereitgestellten Ingress-Controller
Cluster Operator/Admin: verwaltet selbst gehostete Ingress-Controller

Beide wurden erst mit der späten Einführung der IngressClass-Ressource zu offiziellen Personas.

Bei der Gateway API ist die Rollenverteilung von Anfang an klar strukturiert:

Application Developer: definiert Routing-Regeln für seine Anwendungen
Application Admin: definiert Entry Points für externen Client-Traffic inkl. TLS-Terminierung
Cluster Operator: definiert ebenfalls Entry Points und TLS-Konfiguration
Infrastructure Provider: stellt GatewayClass/Controller bereit

Diese Aufteilung passt zu Organisationen, in denen mehrere Teams sich dieselbe Load-Balancing-Infrastruktur teilen. Wichtig: Das Self-Service-Modell muss dadurch nicht aufgegeben werden – es lässt sich weiterhin eine einzelne RBAC-Rolle definieren, die alle drei Verantwortlichkeiten (Developer, Admin, Operator) übernimmt.

Funktionsumfang und Erweiterbarkeit

Die Gateway API deckt sämtliche Ingress-Features ab – plus viele Funktionen, die bei Ingress nur über Annotationen erreichbar waren. Dadurch ist sie deutlich portabler.

Für Features, die nicht standardisiert werden können (z. B. Authentifizierung, Connection Timeouts, Health Checks), bietet die Gateway API drei definierte Extension Points:

External References

Ein Feld einer Gateway-API-Ressource kann auf eine implementierungsspezifische Custom Resource verweisen. So bleibt der Standard schlank, während Hersteller wie Envoy Gateway oder Istio eigene Spezialfunktionen anbieten können:

HTTPRoute
   |
   +--> Standardisierte Gateway API Felder
   |
   +--> Hersteller-spezifische Erweiterungsfelder (Custom Resource)

Beispiel: Ein HTTPRouteFilter kann über extensionRef auf eine herstellerspezifische Ressource verweisen, etwa eine JWT-Authentifizierung, die kein Standardfilter ist:

filters:
- type: ExtensionRef
  extensionRef:
    group: gateway.envoyproxy.io
    kind: JwtAuthentication
    name: company-auth

Custom Implementations

Manche Features werden bewusst der jeweiligen Implementierung überlassen – etwa der RegularExpression-Typ von HTTPPathMatch. Diese gelten als „implementation-specific" bzw. „custom" im Konformitätslevel.

Policies

Für Data-Plane-Funktionen wie Authentifizierung, Autorisierung, Rate Limiting, WAF-Regeln oder Caching können Hersteller eigene Policy-Ressourcen definieren. Die Gateway API schreibt dabei nicht vor, wie diese Ressourcen aussehen – aber sie schreibt vor, wie eine Policy an eine Gateway-Ressource angebunden wird. Das sorgt für eine einheitliche UX über verschiedene Hersteller hinweg.

Der entscheidende Unterschied zu External References: Bei Policies referenziert die Policy die Route, nicht umgekehrt.

Statt:

kind: HTTPRoute
spec:
  auth:
    enabled: true

sieht das bei Gateway API so aus:

kind: HTTPRoute
metadata:
  name: webshop
---
kind: AuthenticationPolicy
spec:
  targetRef:
    kind: HTTPRoute
    name: webshop

Annotationen als Extension Point sind bei der Gateway API übrigens explizit nicht vorgesehen und werden für Implementierungen stark abgeraten.

Feature-Mapping: Von Ingress zu Gateway API

Ingress-Konzept	Gateway-API-Äquivalent
Entry Points	Müssen explizit als Listener in einer `Gateway`-Ressource definiert werden
TLS-Terminierung	Eigenschaft des Gateway-Listeners; Zertifikat weiterhin im Secret
Routing-Regeln	Path-Matching wandert 1:1 in die `HTTPRoute`
Default Backend	Kein direktes Äquivalent – muss explizit als Routing-Regel (`/`-Prefix) definiert werden
IngressClass	`parentRef` in der `HTTPRoute` verweist auf das jeweilige `Gateway`

Routing im Detail: hostnamespezifisch vs. global

Ein wichtiger Unterschied: Bei Ingress besitzt jeder Hostname seinen eigenen Regelblock:

spec:
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /
        backend: shop-service
  - host: api.example.com
    http:
      paths:
      - path: /
        backend: api-service

Bei der HTTPRoute gelten die Regeln automatisch für alle angegebenen Hostnamen:

spec:
  hostnames:
  - shop.example.com
  - api.example.com
  rules:
  - matches:
      - path:
          value: /
    backendRefs:
      - name: app

Merging & Conflict Resolution

Bei Ingress ist weder das Zusammenführen von Regeln noch die Konfliktauflösung standardisiert – jeder Controller kann das anders handhaben. Die Gateway API hingegen legt genau fest, wie Regeln gemergt und Konflikte aufgelöst werden.

Was ist mit Annotationen?

Annotationen sind naturgemäß implementierungsspezifisch, deshalb hängt ihre Migration sowohl vom alten Ingress-Controller als auch vom neuen Gateway-Implementation ab.

Nehmen wir NGINX als Beispiel:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

Diese Annotationen versteht ausschließlich der NGINX Ingress Controller – andere Controller ignorieren sie oder nutzen eigene Pendants.

Die gute Nachricht: Viele früher annotationsbasierte Funktionen sind heute Teil des offiziellen Standards. Aus

annotations:
  nginx.ingress.kubernetes.io/ssl-redirect: "true"

wird bei Gateway API ein offizieller Filter:

filters:
- type: RequestRedirect

Für alles, was implementierungsspezifisch bleibt (JWT-Auth, WAF-Regeln, spezielle Envoy-Features), gilt: Ab in die Doku der jeweiligen Gateway-Implementierung, um den passenden Extension Point zu finden.

Implementierungen und Konformität

Die Gateway API unterscheidet zwei Implementierungsprofile:

Gateway: für North-South-Traffic
Mesh: für East-West-Traffic innerhalb eines Clusters oder Cluster-Sets

Jedes Profil hat eigene Konformitätstests. Aktuell gibt es drei Konformitätsstufen:

Conformant: z. B. Traefik (Controller), Cilium (Controller & Mesh)
Partially Conformant: z. B. Envoy Gateway (u. a. im Einsatz bei Giant Swarm)
Stale: z. B. Azure Application Gateway for Containers (Controller)

Automatisierte Migration

Für die tatsächliche Migration muss man nicht bei null anfangen: Das ingress2gateway-Projekt von Kubernetes SIGs konvertiert bestehende Ingress-Ressourcen automatisiert in Gateway-API-Ressourcen und nimmt einem damit einen guten Teil der manuellen Arbeit ab.

Fazit

Die Gateway API löst die drei größten Schwachstellen der Ingress API auf einmal: mehr Features out-of-the-box, ein klares Rollenmodell für Multi-Team-Cluster und ein sauberes, strukturiertes API-Design statt eines Annotations-Wildwuchses. Wer aktuell mit vielen implementierungsspezifischen Annotationen kämpft oder mehrere Teams über dieselbe Ingress-Infrastruktur koordinieren muss, sollte sich die Migration ernsthaft anschauen – idealerweise mit Unterstützung durch ingress2gateway als Ausgangspunkt.

Entwicklung auf SAP BTP: Struktur, Tools & Deployment im Überblick

zakaria zermani — Sun, 04 May 2025 20:24:27 +0000

Einführung in SAP BTP

Was ist SAP Business Technology Platform?

Die SAP Business Technology Platform (SAP BTP) ist eine integrierte Plattform-as-a-Service (PaaS), die es Unternehmen ermöglicht, Anwendungen und Erweiterungen effizient zu entwickeln, zu integrieren und bereitzustellen. SAP BTP kombiniert Datenbankdienste, Analytik, Integrationsfunktionen sowie Anwendungsentwicklungstools in einer zentralen Umgebung. Sie unterstützt verschiedene Laufzeitumgebungen, darunter Cloud Foundry, Kyma und ABAP.

Warum auf SAP BTP entwickeln?

Die Entwicklung auf SAP BTP bietet zahlreiche Vorteile: Entwickler:innen können Anwendungen schnell in der Cloud erstellen, bestehende SAP-Lösungen erweitern und gleichzeitig moderne Technologien wie Machine Learning oder Event-driven Architecture nutzen. Durch die nahtlose Integration mit SAP S/4HANA, SAP SuccessFactors und anderen Systemen wird die BTP zur idealen Plattform für unternehmensweite Innovationen.

Die SAP BTP Account-Struktur verstehen

Global Account, Subaccount & Directories

Die Account-Struktur von SAP BTP ist hierarchisch aufgebaut. An oberster Stelle steht der Global Account, dem Subaccounts untergeordnet sind. Innerhalb des global accounts oder der Subaccounts können sogenannte Directories erstellt werden, um eine strukturierte Organisation zu ermöglichen – etwa nach Teams, Projekten oder Regionen.

Cloud Foundry Subaccount: Aufbau und Organisation

Ein Subaccount in der Cloud Foundry (CF) Umgebung entspricht einer eigenen Entwicklungs- und Laufzeitumgebung. Innerhalb eines CF-Subaccounts wird automatisch eine Organisation (Org) erstellt, zu der mehrere Spaces gehören können. Diese Spaces ermöglichen die Aufteilung von Ressourcen, Rollen und Deployments, z. B. für Entwicklung, Test und Produktion.

Orgs und Spaces: Hierarchie und Struktur

In der CF-Umgebung gilt eine 1:1-Beziehung zwischen Subaccount und Org. Eine Org kann jedoch beliebig viele Spaces beinhalten. Diese Trennung erlaubt eine granulare Zuweisung von Ressourcen (z. B. Quota, Memory) und fördert die Kollaboration in Projektteams. Spaces sind also essenziell für eine strukturierte und skalierbare Entwicklungslandschaft auf BTP.

Beispielhafte Struktur: Eine Skizze zur Visualisierung

Visuelle Darstellung der Account-Hierarchie

Zur besseren Verständlichkeit bietet sich eine grafische Skizze an, die die Hierarchie von Global Account → Subaccount → Directory → Org → Space darstellt. Diese Struktur bildet das Fundament für die technische Umsetzung von Berechtigungen, Ressourcenmanagement und Anwendungsbereitstellung auf SAP BTP.

Quelle: https://developers.sap.com/tutorials/cp-trial-quick-onboarding.html

Empfohlene Aufteilung nach Use Case

Ein bewährtes Modell ist die Aufteilung der Subaccounts nach Region oder Business Unit, kombiniert mit einer projektbezogenen Nutzung der Directories und Spaces. So lassen sich verschiedene Anwendungsfälle – von ABAP-Entwicklung bis zu UI5-Webapps – klar trennen und effizient verwalten.

Entitlements vs. Quotas

Was sind Entitlements?

In SAP BTP bezeichnen Entitlements die Zuweisung von Diensten und Ressourcen an Subaccounts. Sie legen fest, welche Services überhaupt genutzt werden dürfen – zum Beispiel SAP HANA Cloud, Business Application Studio oder die ABAP Environment. Diese Berechtigungen werden auf der Ebene des Global Accounts verwaltet.

Quota Management im globalen Account

Quotas bestimmen, in welchem Umfang ein Dienst innerhalb eines Subaccounts verwendet werden darf. Während ein Entitlement lediglich die grundsätzliche Nutzung erlaubt, limitiert die Quota die konkrete Ressourcennutzung (z. B. Anzahl der Serviceinstanzen oder Speichermenge). Ein gutes Quota-Management ist entscheidend, um Performance und Kosten im Griff zu behalten.

Regionale Bindung eines Subaccounts

Jeder Subaccount ist genau einer Region zugeordnet. Diese Region beeinflusst unter anderem die Verfügbarkeit von Diensten, Latenzzeiten und die rechtliche Rahmenbedingungen bezüglich Datenhaltung. Daher ist es sinnvoll, Subaccounts strategisch nach geografischer Nähe zu Nutzern oder regulatorischen Anforderungen auszuwählen.

Tools für Entwickler:innen auf SAP BTP

Was ist die BTP CLI?

Die BTP Command Line Interface (BTP CLI) ist ein zentrales Tool zur Verwaltung von globalen Accounts, Subaccounts, Directories und Diensten. Im Gegensatz zur CF CLI, die ausschließlich für die Cloud Foundry Umgebung zuständig ist, adressiert die BTP CLI die gesamte Plattformstruktur und erlaubt unter anderem die Aktivierung von Diensten, Zuweisung von Entitlements und das Konfigurieren von Directories.

Unterschiede zur CF CLI

Die CF CLI ist spezialisiert auf die Interaktion mit der Cloud Foundry Umgebung – also auf das Deployment, die Verwaltung von Apps, Services, Orgs und Spaces. Die BTP CLI hingegen deckt übergeordnete Plattformebenen ab, wie die Einrichtung von Subaccounts, Service-Plänen und globalen Rollen. Für ein vollständiges Management der BTP-Struktur ist die Nutzung beider CLIs oft notwendig.

BTP CLI: Kontextbasiertes Arbeiten (global, subaccount, directory)

Ein zentraler Aspekt der BTP CLI ist das Arbeiten im kontextbasierten Modus. Dabei kann ein spezifischer Kontext (z. B. ein bestimmter Subaccount oder ein Directory) als Ziel gesetzt werden. Wenn Sie also den Kontext, in dem Befehle ausgeführt werden, auf ein Directory oder ein Subaccount ändern wollen, können Sie dies mit dem Befehl **btp target** tun.

Arbeiten mit dem SAP Business Application Studio

Dev Spaces erstellen und nutzen

Das SAP Business Application Studio (BAS) ist eine moderne, webbasierte Entwicklungsumgebung auf der SAP BTP. Entwickler:innen können darin sogenannte Dev Spaces erstellen – vorinstallierte, isolierte Entwicklungsumgebungen, die sofort einsatzbereit sind. Je nach gewähltem Szenario (z. B. SAP Fiori, CAP, ABAP) sind die entsprechenden Tools, Extensions und Laufzeitumgebungen bereits integriert.

Voraussetzungen und Subscription

Um mit dem BAS arbeiten zu können, muss der Dienst zunächst über den Subaccount abonniert werden. Dies setzt voraus, dass im Global Account entsprechende Entitlements vergeben wurden. Die Nutzung ist sowohl im kostenlosen Trial als auch im Enterprise Account möglich. Nach der Aktivierung kann direkt mit der Erstellung und Verwaltung von Dev Spaces begonnen werden.

Entwicklungsumgebungen nach Szenarien

Jede Dev Space Type ist auf ein bestimmtes Anwendungsszenario optimiert. Zum Beispiel beinhaltet ein „SAP Fiori“-Space UI5-Toolkit, OData-Editoren und Deployment-Tools, während ein „CAP“-Space Node.js-basierte CAP-Runtime, SQLite und CDS-Kommandos enthält. Diese maßgeschneiderte Bereitstellung spart Zeit, reduziert manuelle Konfiguration und verbessert die Produktivität erheblich.

Deployment in der Cloud Foundry Umgebung

Was ist das Manifest.yml?

Beim Deployment von Anwendungen in der Cloud Foundry Umgebung spielt die Datei manifest.yml eine zentrale Rolle. Sie beschreibt die App-Konfiguration, darunter Name, Speicherbedarf, Instanzanzahl, Buildpack, Hostname und Services. Das Manifest automatisiert und standardisiert den Deployment-Prozess, wodurch Fehlerquellen minimiert werden.

App-URL und Hostname-Regeln im SAP BTP Umfeld

Der Hostname einer App muss innerhalb einer Region eindeutig sein. Eine beispielhafte URL für eine App mit dem Hostnamen myapp in der Region EU10 lautet: myapp.cfapps.eu10.hana.ondemand.com. Entwickler:innen sollten bei der Namensgebung daher auf Kollisionen achten oder alternativ mit zufälligen Routen arbeiten.

Automatisch generierte Routen mit random-route

Ein praktisches Attribut in der manifest.yml ist die random-route: true, um eine eindeutige Routen-URL generieren zu lassen. Dadurch wird der App-Hostname automatisch um eine zufällige Zeichenfolge erweitert, was die eindeutige Adressierung vereinfacht. Diese Option ist besonders nützlich in Test- und Entwicklungsszenarien, in denen die exakte URL zweitrangig ist.

Routing zur Dev Space und Mapping zur App

Für den externen Zugriff auf die Anwendung muss eine Route zur entsprechenden Dev Space eingerichtet und mit der App verknüpft werden. Dies erfolgt in der Regel automatisch beim Deployment, kann aber auch manuell angepasst werden. Eine korrekt konfigurierte Route stellt sicher, dass Benutzer:innen und externe Systeme zuverlässig auf die Anwendung zugreifen können.

Fazit: Effiziente Entwicklung auf SAP BTP

Zusammenfassung der wichtigsten Punkte

SAP BTP bietet eine leistungsstarke und flexible Plattform für die moderne Anwendungsentwicklung in der Cloud. Durch die klare Account-Hierarchie – von Global Account über Subaccount bis zu Spaces – wird eine strukturierte Ressourcennutzung ermöglicht. Mit Tools wie der BTP CLI und dem SAP Business Application Studio lassen sich Entwicklungsprojekte effizient umsetzen, erweitern und verwalten.

Besonderes Augenmerk sollte auf die korrekte Konfiguration von Entitlements, Quotas und Deployment-Prozessen gelegt werden. Gerade für ABAP-Entwickler:innen eröffnet SAP BTP mit der Steampunk-Umgebung neue Perspektiven für zukunftssichere Cloud-Lösungen.

Best Practices für den Einstieg

Plane die Account-Struktur frühzeitig und regionsbezogen
Nutze Dev Spaces passend zum jeweiligen Anwendungsszenario
Verwalte Entitlements zentral über den Global Account

Häufig gestellte Fragen (FAQ)

Was ist der Unterschied zwischen einem Subaccount und einer Org in SAP BTP?

Ein Subaccount ist Teil der globalen Accountstruktur von SAP BTP und stellt eine Umgebung für Projekte bereit. Innerhalb eines Subaccounts wird automatisch eine Organisation (Org) für die Cloud Foundry Umgebung erstellt, die wiederum in Spaces unterteilt werden kann.

Wie kann ich ABAP-Anwendungen auf SAP BTP entwickeln?

Dazu wird ein Subaccount mit Cloud Foundry Umgebung benötigt, in dem ein Space für die ABAP Environment angelegt wird. Über das SAP Business Application Studio oder Eclipse ADT können Anwendungen mit dem RAP-Modell entwickelt und bereitgestellt werden.

Welche Vorteile bietet die Nutzung von Dev Spaces im Business Application Studio?

Dev Spaces sind sofort einsatzbereite, isolierte Entwicklungsumgebungen in der Cloud, die alle nötigen Tools für spezifische Szenarien enthalten – z. B. Fiori, CAP oder ABAP. Das spart Konfigurationszeit und verbessert die Produktivität.

Wie funktioniert das Deployment einer App in SAP BTP Cloud Foundry?

Das Deployment erfolgt meist über ein manifest.yml, das die Konfiguration der App beschreibt. Mittels CF CLI kann die App dann in einem bestimmten Space deployed und mit Services wie Logging oder Datenbanken verbunden werden.

Was sind Entitlements und warum sind sie wichtig?

Entitlements sind Dienst-Berechtigungen, die im Global Account verwaltet und an Subaccounts vergeben werden. Ohne Entitlement kann ein Dienst nicht aktiviert oder genutzt werden – sie sind also essenziell für die Ressourcenplanung.