Unternehmen vollziehen derzeit rasch den Übergang von KI-Experimenten zum operativen KI-Einsatz. Dadurch verändern sich die Anforderungen von Organisationen an die Infrastruktur für die Anwendungsbereitstellung.
Jahrelang wurde das Kubernetes-Traffic-Management häufig als technisches Implementierungsdetail betrachtet. Plattformteams wählten einen Ingress-Controller aus, Anwendungsteams konfigurierten Routen und Sicherheitsteams ergänzten, wo immer möglich, entsprechende Kontrollen. Dieses Modell funktionierte, solange die größte Herausforderung darin bestand, Webanwendungen und APIs bereitzustellen. Es reicht jedoch nicht mehr aus, wenn dieselbe Plattform nun moderne Anwendungen, verteilte APIs, Sicherheitsrichtlinien und KI-Inferenz-Workloads unterstützen muss, die knappe und kostspielige Rechenressourcen beanspruchen.
Der „F5 State of Application Strategy Report 2026“ zeigt, warum dies gerade jetzt von Bedeutung ist: 78 % der Unternehmen betreiben KI-Inferenz selbst, und 52 % nutzen die Orchestrierung mehrerer Modelle, um ihre KI-Modelle anzupassen und zu erweitern. In der Praxis bedeutet dies, dass Unternehmen nicht einfach nur ein einzelnes Modell über einen einzelnen Dienst aufrufen. Sie führen Inferenzen über verschiedene Umgebungen hinweg aus, koordinieren mehrere Modelle und machen KI zu einem Bestandteil ihrer produktiven Anwendungsarchitektur.
KI verleiht einer seit Langem bestehenden Herausforderung für Unternehmen neue Dringlichkeit: Wie lässt sich Teams die nötige Geschwindigkeit ermöglichen und zugleich Governance, Sicherheit und betriebliche Konsistenz gewährleisten?
F5 NGINX Gateway Fabric trägt zur Beantwortung dieser Frage bei, indem es drei wichtige Funktionen vereint: Konformität mit Gateway API 1.5, Integration mit F5 WAF for NGINX und Unterstützung für die Gateway API Inference Extension. Zusammen ermöglichen diese Funktionen einen stärker standardisierten, sicheren und KI-fähigen Ansatz für das Kubernetes-Traffic-Management.
“Das Gateway dient längst nicht mehr nur dazu, Datenverkehr in einen Cluster zu leiten. Es entwickelt sich zu einem zentralen Kontrollpunkt dafür, wie moderne Anwendungen, APIs und KI-Dienste bereitgestellt, geschützt und in großem Maßstab betrieben werden.”
Warum Standards wichtig sind
Die Gateway API entwickelt sich zu einem wichtigen Standard für das Kubernetes-Traffic-Management, da sie eine bekannte Herausforderung in Unternehmen angeht: Zu viele Teams lösen dasselbe Problem auf unterschiedliche Weise.
Herkömmliche Ingress-Ansätze stützen sich häufig stark auf implementierungsspezifische Annotationen und benutzerdefinierte Konfigurationen. Für einzelne Teams kann das funktionieren, doch auf Unternehmensebene wird die Steuerung zunehmend schwieriger. Richtlinien lassen sich nur schwer überprüfen. Migrationspfade werden komplexer. Plattformteams haben möglicherweise Schwierigkeiten, Self-Service anzubieten, ohne dabei die Kontrolle aufzugeben. Anwendungsteams können zwar schnell vorankommen, doch das Betriebsmodell wird zunehmend fragmentiert.
Die Gateway API führt ein stärker rollenorientiertes, Kubernetes-natives Modell ein. Plattformteams können die gemeinsam genutzte Gateway-Infrastruktur verwalten. Anwendungsteams können das Routing für ihre eigenen Services definieren. Sicherheits- und Betriebsteams erhalten eine klarere Struktur für die Umsetzung von Richtlinien. Der Mehrwert liegt nicht nur in der technischen Eleganz, sondern auch in einem klareren Betriebsmodell.
Die Konformität von NGINX Gateway Fabric mit Gateway API 1.5 ist in diesem Zusammenhang von Bedeutung. Konformität bedeutet weder, dass jede Implementierung identisch ist, noch macht sie Architekturentscheidungen überflüssig. Sie gibt Unternehmen jedoch mehr Sicherheit, dass sie auf einem Standard aufbauen, der zunehmend ausgereift ist und im gesamten Kubernetes-Ökosystem getestet wird.
Die Bedeutung liegt auf der Hand. Standards reduzieren vermeidbare Komplexität. Sie erleichtern es, Plattformentscheidungen team- und clusterübergreifend zu skalieren. Sie verringern das Risiko, jeden Workflow an ein proprietäres Modell zu binden. Und sie schaffen eine Grundlage für eine langfristige Modernisierung, bei der Teams neuere Modelle für das Traffic-Management einführen können, ohne alle Anwendungen gleichzeitig migrieren zu müssen.
Das ist von Bedeutung, weil Kubernetes in großen Unternehmen nur selten auf einen einzelnen Cluster beschränkt ist. Unternehmen betreiben häufig mehrere Cluster über verschiedene Geschäftsbereiche, Regionen, Entwicklungsphasen und Cloud-Umgebungen hinweg. Ohne einen gemeinsamen Ansatz kann jeder Cluster zu einem Sonderfall werden. Die über NGINX Gateway Fabric implementierte Gateway API bietet Plattformteams die Möglichkeit, Konsistenz zu gewährleisten, ohne die Anwendungsbereitstellung zu verlangsamen.
Sicherheit dort, wo Anwendungen ausgeführt werden
Sicherheit ist häufig dann am wirksamsten, wenn sie direkt in die Plattform integriert und nicht erst nach der Bereitstellung nachträglich hinzugefügt wird. Das gilt insbesondere für Kubernetes, wo Anwendungsteams Self-Service und schnelle Release-Zyklen erwarten.
Die Integration von NGINX Gateway Fabric und F5 WAF for NGINX bringt die Sicherheit von Unternehmensanwendungen näher an die Kubernetes-Gateway-Schicht. Mit dieser Integration können Sicherheitsteams Richtlinien zum Schutz von Anwendungen definieren und verwalten, während Plattformteams diese Schutzmaßnahmen über Kubernetes-native Workflows bereitstellen.
Der geschäftliche Nutzen besteht nicht darin, dass jede IT-Führungskraft die technischen Details der Richtlinienzuweisung verstehen muss. Entscheidend ist vielmehr, dass Sicherheitsteams die Verantwortung für Schutzrichtlinien behalten können, während Plattform- und Anwendungsteams weiterhin schnell vorankommen.
Diese Trennung der Verantwortlichkeiten ist von entscheidender Bedeutung. Wenn die Sicherheit davon abhängt, dass jedes Anwendungsteam die Kontrollen korrekt implementiert, führt dies im gesamten Unternehmen zu einem uneinheitlichen Schutzniveau. Wenn Sicherheitsvorgaben jede Veröffentlichung verzögern, suchen die Teams nach Möglichkeiten, sie zu umgehen. Ein besseres Modell ist eine gemeinsame Governance: Sicherheitsteams definieren und verwalten Richtlinien, Plattformteams stellen den Durchsetzungspunkt bereit und Anwendungsteams liefern weiterhin Software aus.
Dies ist besonders relevant, da immer mehr kundenorientierte Anwendungen, APIs und KI-gestützte Dienste auf Kubernetes verlagert werden. Je strategisch wichtiger die Plattform wird, desto größer wird auch das Risikoprofil. Angriffe auf Webanwendungen, Fehlkonfigurationen, nicht verwaltete Routen und eine uneinheitliche Sicherheitslage sind nicht nur technische Probleme, sondern betreffen auch die Geschäftskontinuität, Compliance und Reputation.
Ein WAF-Modell auf Gateway-Ebene ersetzt weder sichere Entwicklungspraktiken noch umfassendere Programme für Anwendungssicherheit. Es bietet Unternehmen jedoch eine praxisnahe Durchsetzungsebene in unmittelbarer Nähe zur Bereitstellung der Anwendungen. Dadurch kann Sicherheit zu einem Bestandteil der Plattformarchitektur werden, anstatt ein separater Prozess zu sein, der bei jeder Bereitstellung nachgezogen werden muss.
Vorbereitung auf KI-Inferenz
KI-Inferenz verändert das Traffic-Management, da sich KI-Workloads anders verhalten als herkömmliche Webanfragen.
Eine herkömmliche Webanfrage ist in der Regel kurzlebig und relativ vorhersehbar. Inferenzanfragen können sich hinsichtlich Dauer, Nutzlastgröße, Kosten und Ressourcenbedarf erheblich unterscheiden. Eine einzige Anfrage kann kostspielige GPU-Kapazitäten über längere Zeit binden. Für unterschiedliche Aufgaben können mehrere Modelle zum Einsatz kommen. Einige Modelle sind möglicherweise auf niedrige Kosten, andere auf hohe Leistung und wieder andere auf hohe Genauigkeit optimiert. Die Routing-Entscheidung kann sich auf die Benutzererfahrung, die Infrastrukturauslastung und die Betriebskosten auswirken.
Deshalb ist die Gateway API Inference Extension so wichtig. Sie ermöglicht ein modellbewusstes Routing, sodass Anfragen anhand von Modellversion, Modelltyp und Kosten-Leistungs-Profil weitergeleitet werden können. Mit der Unterstützung von NGINX Gateway Fabric können Unternehmen die Benutzererfahrung und Infrastrukturauslastung verbessern und gleichzeitig weniger wichtige oder latenzunempfindliche Anfragen an kosteneffizientere Modelle weiterleiten.
Entscheidend ist nicht der zugrunde liegende Scheduling-Mechanismus, sondern dass die Bereitstellung von KI operative Reife erfordert. Wenn 78 % der Unternehmen KI-Inferenz selbst betreiben, ist Inferenz nicht mehr nur ein Thema für die Datenwissenschaft. Sie wird Teil des Stacks für die Bereitstellung von Unternehmensanwendungen. Und wenn 52 % eine Multi-Modell-Orchestrierung nutzen, muss das Traffic-Management einer dynamischeren KI-Umgebung Rechnung tragen.
Die Unterstützung der Inference Extension durch NGINX Gateway Fabric hilft Plattform- und Machine-Learning-Teams dabei, KI-Workloads in ein vertrautes Kubernetes-Betriebsmodell zu integrieren. Anstatt eine separate Bereitstellungsarchitektur für KI zu schaffen, können Unternehmen KI-Dienste gemeinsam mit Anwendungen und APIs verwalten und dabei einen standardkonformen Gateway-Ansatz nutzen.
Das bedeutet nicht, dass sich jede KI-Herausforderung in Unternehmen am Gateway lösen lässt. Modell-Governance, Daten-Governance, Sicherheitstests, Kostenmanagement und Compliance erfordern weiterhin umfassendere Kontrollmechanismen. Das Routing ist jedoch ein grundlegender Bestandteil der KI-Produktionsumgebung. Wenn Anfragen nicht effizient weitergeleitet, Infrastruktursignale ignoriert werden oder jedes Team einen eigenen Zugang zur Inferenz entwickelt, nimmt die Komplexität schnell zu.
Der wichtigste Wandel betrifft die Architektur: KI wird zu einer weiteren Kategorie produktiver Workloads, die sicher, transparent und richtliniengesteuert bereitgestellt werden müssen.
Moderne Anwendungsbereitstellung für das KI-Zeitalter
NGINX Gateway Fabric sollte nicht nur als Kubernetes-Netzwerkkomponente bewertet werden. Vielmehr sollte es als Teil einer umfassenderen Plattformstrategie für die moderne Anwendungsbereitstellung betrachtet werden.
Die Kombination aus Gateway-API-1.5-Konformität, der Integration von F5 WAF for NGINX und der Unterstützung für Inference Extension ist von Bedeutung, da sie drei Prioritäten miteinander verbindet:
- Standardisierung: Reduzierung der Fragmentierung durch die Ausrichtung des Kubernetes-Datenverkehrsmanagements an einem zunehmend ausgereiften Community-Standard.
- Sicherheit: Wenden Sie den Schutz von Unternehmensanwendungen näher an dem Ort an, an dem Kubernetes-Anwendungen zugänglich gemacht werden.
- KI-Bereitschaft: Bereiten Sie die Bereitstellungsebene auf Inferenz-Workloads vor, die dynamischer, ressourcenintensiver und geschäftskritischer sind als herkömmliche Dienste.
Der praktische Vorteil liegt in einem einheitlicheren Betriebsmodell. Das Plattform-Engineering kann eine gemeinsam genutzte Infrastruktur und Self-Service-Muster bereitstellen. Anwendungsteams können schneller vorankommen, ohne ein eigenes Modell für die Datenverkehrssteuerung entwickeln zu müssen. Sicherheitsteams können Richtlinien mithilfe etablierter Kontrollen durchsetzen. ML-Teams können Inferenz-Workloads in Kubernetes integrieren, ohne für die Bereitstellung von KI eine einmalige Sonderarchitektur schaffen zu müssen.
Das ist wichtig, denn die nächste Phase der KI-Einführung wird nicht nur daran gemessen werden, wie viele Pilotprojekte ein Unternehmen startet. Entscheidend wird vielmehr sein, wie zuverlässig, sicher und effizient KI-gestützte Anwendungen im Produktivbetrieb laufen.
Viele Unternehmen verfügen bereits über die nötigen Bausteine: Kubernetes-Plattformen, Infrastrukturen für die Anwendungsbereitstellung, Sicherheitsprogramme, KI-Initiativen und jeweils dafür zuständige Teams. Die Herausforderung besteht darin, diese Komponenten so zusammenzuführen, dass sie skalierbar sind. NGINX Gateway Fabric unterstützt Unternehmen dabei, indem es eine standardkonforme Gateway-Schicht bereitstellt, die herkömmliche Anwendungen, APIs, Sicherheitsrichtlinien und neue Muster für KI-Inferenz unterstützt.
Das ist ein konkretes Nutzenversprechen. Unternehmen müssen weder von vorn anfangen noch ihre Architektur für die Anwendungsbereitstellung von Grund auf neu aufbauen. Sie können das Kubernetes-Traffic-Management hin zu einem Modell weiterentwickeln, das einheitlicher, sicherer und besser auf KI-Workloads vorbereitet ist. Damit erhalten sie einen Weg, das Kubernetes-Traffic-Management hin zu einem Modell weiterzuentwickeln, das einheitlicher, sicherer und besser auf KI-Workloads vorbereitet ist.
Mit der zunehmenden Integration von KI in Unternehmensanwendungen muss sich auch die Diskussion über die Infrastruktur weiterentwickeln. Beim Gateway geht es längst nicht mehr nur darum, Datenverkehr in einen Cluster zu leiten. Es entwickelt sich zu einem zentralen Kontrollpunkt dafür, wie moderne Anwendungen, APIs und KI-Dienste bereitgestellt, geschützt und in großem Maßstab betrieben werden.
Weitere Informationen finden Sie auf der Webseite zu F5 NGINX Gateway Fabric.
Nehmen Sie außerdem unbedingt am F5 AI Summit teil, einer dreistündigen virtuellen Veranstaltung am Dienstag, den 23. Juni. Dort sprechen wir in der Session „KI auf Kubernetes mit F5 NGINX bereitstellen“ ausführlich über die Bereitstellung von KI-Workloads auf Kubernetes.
Über den Autor
Ähnliche Blogbeiträge
Kubernetes-native WAF für das Gateway-Zeitalter: F5 WAF for NGINX lässt sich jetzt in F5 NGINX Gateway Fabric integrieren
F5 erweitert WAFs, um mit F5 NGINX Gateway Fabric und F5 NGINX Ingress Controller einen konsistenten, skalierbaren Schutz über Cluster und Umgebungen hinweg bereitzustellen.
Von Regeln zu Risiken: Die Entwicklung von WAFs und der Aufstieg KI-gestützter Ergebnisse
WAF-Programme geraten oft an einem bekannten Punkt ins Stocken: Der Blockierungsmodus wird verzögert aktiviert, weil die Feinabstimmung aufwendig ist.
Erklärbarkeit: Licht ins Dunkel der KI-Blackbox bringen
Einblicke von James White, CTO bei CalypsoAI: Dank GenAI verstehen wir inzwischen gut, wie Antworten generiert und an uns zurückgegeben werden. Vereinfacht gesagt basiert KI auf einer Transformer-Architektur – sie wählt die beste Vorhersage für das nächste Wort und den nächsten Satz aus und liefert anhand der ihr vorliegenden Informationen die wahrscheinlichste Antwort […]
Die neue KI-Risikolandschaft: unsichtbar, autonom und bereits im Unternehmen
James White, VP Engineering, F5 Zur Jahresmitte 2025 ist es an der Zeit, eine Momentaufnahme der KI-Nutzung in Unternehmen und des aktuellen Stands der KI-Sicherheit zu erstellen. Der Einsatz generativer KI ist in Unternehmen mittlerweile Standard Unternehmen verfügen inzwischen durchweg zumindest über ein grundlegendes Verständnis von generativer KI. Sie wissen, was sie ist und wo sie […]
Die KI-Grenzen sichern: Strategien zur Bekämpfung von Datenexfiltration
Da Unternehmen zunehmend Modelle der generativen KI (GenAI) und große Sprachmodelle (LLMs) in ihre digitalen Systeme integrieren, sind sie mit neuen und erhöhten Risiken konfrontiert. Wenig überraschend stehen dabei Risiken im Zusammenhang mit Datenexfiltration – der unbefugten Übertragung von Daten aus einem Unternehmen an ein externes Ziel – meist ganz oben auf der Prioritätenliste der Sicherheitsteams. Ein Verständnis […]
Everest Group-Bericht: Aktuelle Trends und Zukunftsaussichten bei der Einführung von GenAI in der Industrie
Wir freuen uns, einen wesentlichen Beitrag zu einem wegweisenden neuen Bericht der Everest Group, einem weltweit führenden Forschungsunternehmen, geleistet zu haben. Der Bericht mit dem Titel „Generative AI Adoption – Examining Real-world Use in Horizontal Functions and Future Outlook“ bietet eine eingehende Analyse der Einführung generativer KI (GenAI) in verschiedenen Branchen. Dem Bericht zufolge ist die IT […]