Kubernetes ist längst keine experimentelle Spielwiese für Early Adopter mehr. Es ist das Betriebssystem moderner Unternehmen. Weltweit entwickeln fast 20 Millionen Cloud-native-Entwickler auf dieser Basis. Prognosen zufolge werden bis 2027 mehr als 90 % der Unternehmen weltweit containerisierte Anwendungen produktiv betreiben. Und zwei Drittel der Unternehmen, die generative KI einsetzen, führen bereits Inferenz-Workloads auf Kubernetes aus. Container-Orchestrierung ist damit endgültig geschäftskritisch.
Doch die unbequeme Wahrheit ist: Nur 38 % der Unternehmen, die Kubernetes produktiv einsetzen, haben einen unternehmenstauglichen Reifegrad erreicht. Das zeigt der Bericht Stand der Kubernetes-Strategie in Unternehmen 2026, der auf einer von F5 gesponserten Studie von SlashData basiert. Etwa die Hälfte – 51 % – gilt als „etabliert“, hat aber weiterhin erhebliche Lücken bei Governance, Observability, Resilienz oder der Software-Lieferkette. Die übrigen 11 % befinden sich noch in der Standardisierungsphase.
Damit Unternehmen den erforderlichen Kubernetes-Reifegrad auf Enterprise-Niveau erreichen können, bietet die F5 Application Delivery and Security Platform (ADSP) eine einheitliche Architektur, die die betriebliche Trennung zwischen externen Load Balancern und clusterinternem Ingress aufhebt und störanfällige Toolchains verschiedener Anbieter durch eine durchgängige Architektur auf Enterprise-Niveau ersetzt.
Eine gemeinsame Grundlage, die Teams zusammenbringt
Kubernetes erfüllt seine Aufgaben bemerkenswert gut. Es plant Workloads, skaliert Rechenressourcen flexibel, stellt ausgefallene Pods automatisch wieder her und abstrahiert die zugrunde liegende Hardware in Hybrid- und Multicloud-Umgebungen. Doch die Orchestrierung von Containern ist nur die halbe Miete. Die andere Hälfte besteht darin, den Datenverkehr zu steuern und abzusichern.
Kubernetes wurde nie dafür konzipiert, den Anwendungs- und KI-Datenverkehr in verteilten Unternehmensumgebungen zu steuern. Es trifft keine Routing-Entscheidungen in Echtzeit auf Basis globaler Netzwerkbedingungen, setzt Sicherheitsrichtlinien des Unternehmens nicht durchgängig für eingehenden und ausgehenden Datenverkehr durch und gewährleistet auch bei großem Umfang keine strikte Isolierung des Datenverkehrs zwischen Mandanten.
Und das macht das Problem noch komplexer: Für Kubernetes-Traffic und -Sicherheit ist nicht nur eine einzelne Rolle verantwortlich. Ein Plattform-Engineer, der Microservices über GitOps bereitstellt, ein Netzwerkarchitekt, der clusterübergreifendes Border-Gateway-Protocol-Peering (BGP) und DPU-Offloading verwaltet, und ein CISO, der KI-gestützte Zero-Day-Exploits abwehrt, haben grundlegend unterschiedliche betriebliche Anforderungen.
Alle Beteiligten zur Nutzung eines einzigen Universaltools zu zwingen, scheitert immer – entweder ist es für Entwickler zu schwerfällig oder es bietet den Infrastrukturteams im Unternehmen nicht die nötige Funktionstiefe. F5 ADSP verfolgt einen anderen Ansatz: mit speziell entwickelten, cloudnativen Lösungen, die darauf abgestimmt sind, wie die jeweilige Rolle den Datenverkehr tatsächlich steuert und absichert. Alle Lösungen basieren auf einer gemeinsamen Grundlage, die Teams zusammenbringt, ohne jemanden zu Kompromissen zu zwingen.
Unterschiedliche Teams, unterschiedliche Prioritäten für Traffic und Sicherheit
Mit der zunehmenden Skalierung von Kubernetes – insbesondere wenn Unternehmen von zustandslosen Webanwendungen zu zustandsbehafteten KI-Workloads mit hohem Durchsatz übergehen – kristallisieren sich vier unterschiedliche Rollen heraus, die jeweils vor ganz eigenen Herausforderungen stehen.
- Für die Plattform- und DevOps-Leitung stehen Geschwindigkeit, Self-Service und Kubernetes-native YAML-Workflows im Vordergrund. Allzu oft beginnt sie mit einem kostenlosen Community-Controller – etwa dem kürzlich eingestellten Community-Projekt ingress-nginx – und muss schließlich Software ohne Support in Dutzenden von Produktionsclustern warten, wodurch wertvolle Engineering-Kapazitäten für aufwendige Betriebsroutine gebunden werden.
- Die Leitung für NetOps und Infrastruktur verlangt effizientes Routing, leistungsfähiges TLS-Offloading, strikte Mandantenisolierung und durchgängige Transparenz. Sobald Datenverkehr in einen Cluster gelangt, verlieren Netzwerkteams oft den Überblick über das Geschehen. Die Folge sind vierstündige Krisensitzungen, in denen sie nachzuweisen versuchen, ob die Ursache eines Ausfalls im Netzwerk oder im Pod liegt.
- Der Verantwortliche für die KI-Infrastruktur hat Millionen in GPU-Cluster investiert, die oft nicht ausgelastet sind – nicht etwa, weil es an Rechenleistung fehlt, sondern weil der Engpass darin liegt, Tokens effizient ein- und auszugeben, Anfragen intelligent auf verschiedene Modelle zu verteilen und den GPU-Datenverkehr verschiedener Mandanten voneinander zu isolieren.
- Der CISO und die SecOps-Leitung sorgen sich um nicht quantifizierbare Sicherheitsrisiken in kurzlebigen Clustern, uneinheitliche Sicherheitsrichtlinien für Web Application Firewalls (WAF) und APIs sowie die Geschwindigkeit, mit der moderne Schwachstellen ausgenutzt werden.
Anstatt von DevOps zu verlangen, wie NetOps zu denken – oder von NetOps, YAML-Konfigurationen für Anwendungen zu verwalten –, stellt F5 jedem Team die passende cloudnative Daten- und Steuerungsebene bereit.
“F5 verfolgt einen anderen Ansatz und bietet speziell entwickelte, cloudnative Lösungen, die darauf zugeschnitten sind, wie die einzelnen Rollen den Datenverkehr tatsächlich steuern und absichern. Eine gemeinsame Grundlage verbindet dabei die Teams, ohne dass jemand Kompromisse eingehen muss.”
Für DevOps- und Plattformteams: schlanke, Kubernetes-native Agilität
Plattformingenieure und Entwickler wünschen sich eine schlanke Lösung, die schnelle Entwicklungszyklen ermöglicht, nativ in Kubernetes läuft und sich nahtlos in CI/CD- und GitOps-Pipelines integriert. Genau dafür sind F5 Ingress Controller for NGINX und F5 Gateway Fabric for NGINX konzipiert, die beide Teil von F5 ADSP sind.
Bewährt in Millionen cloudnativer Bereitstellungen, ist F5 NGINX die naheliegende Wahl für ein standardisiertes Management des Anwendungs- und API-Datenverkehrs innerhalb von Clustern. Ob Ihre Teams Kubernetes-Ingress-Ressourcen oder den modernen Kubernetes-Gateway-API-Standard nutzen – einschließlich der Gateway API Inference Extension für KI-Workloads –, die NGINX-Lösungen von F5 bieten höchste Geschwindigkeit bei geringem Ressourcenbedarf und sind dabei entwicklerfreundlich.
Was die Ressourceneffizienz betrifft, steigt der Speicherbedarf konkurrierender Proxys bei der Verarbeitung von KI-Prompts mit langem Kontext oder Streaming-Nutzdaten stark an. F5 Gateway Fabric for NGINX hingegen hält den Speicherbedarf unabhängig von der Größe der Nutzdaten konstant und vorhersehbar.
Für Unternehmen, die vom eingestellten Community-Projekt ingress-nginx migrieren, bietet F5 einen durch Enterprise-Support und SLAs abgesicherten Weg mit automatisierter Konfigurationsübersetzung – damit der Umstieg reibungslos gelingt.
Und Sicherheit wird nicht erst nachträglich hinzugefügt. Teams können F5 WAF-Produkte, API-Sicherheit, Authentifizierung (OIDC, JWT), Ratenbegrenzung und Echtzeit-Schutzmechanismen für KI-Prompts und -Antworten direkt in ihre Kubernetes-Manifeste integrieren und so den Datenverkehr von Anwendungen und LLMs im Tempo der Codebereitstellung absichern.
Für Infrastruktur- und KI-Architekten: Multi-Cluster-Isolierung und ausgehender Datenverkehr
Ein schlanker clusterinterner Proxy ist ideal für Anwendungsteams. Große Unternehmensumgebungen, Telekommunikationsanbieter und KI-Fabriken benötigen jedoch Skalierbarkeit auf Carrier-Niveau, strikte Mandantenisolierung und bidirektionale Datenverkehrssteuerung. Hier kommt F5 BIG-IP Next for Kubernetes ins Spiel.
BIG-IP Next for Kubernetes basiert auf dem container-nativen Traffic Management Microkernel (TMM) von F5 und wurde für den Betrieb auf Standard-Worker-Knoten oder die Auslagerung auf NVIDIA BlueField-3-DPUs entwickelt. Damit bringt die Lösung Traffic-Steuerung und Sicherheit auf Infrastrukturniveau direkt in Kubernetes.
Die meisten Kubernetes-Tools konzentrieren sich ausschließlich auf den eingehenden Datenverkehr. BIG-IP Next for Kubernetes steuert und schützt sowohl den eingehenden als auch den ausgehenden Datenverkehr. Da Microservices und KI-Agenten auf externe APIs, vorgelagerte Datenbanken, Model Context Protocol (MCP)-Server und clusterübergreifende Dienste zugreifen, wird unkontrollierter ausgehender Datenverkehr zu einem erheblichen blinden Fleck im Hinblick auf Datenexfiltration. BIG-IP Next for Kubernetes setzt deterministisches Egress-Routing, SNAT, Namespace-basierte Firewall-Regeln und Zero-Trust-Mikrosegmentierung durch.
In Multi-Cluster- und Multi-Tenant-Umgebungen stellt BIG-IP Next for Kubernetes über BGP direkte Peering-Verbindungen mit Kernnetzwerken her und beschleunigt auf DPUs das L4–L7-Traffic-Management, die Auslagerung kryptografischer mTLS-Operationen und das präfixbasierte Token-Routing. Das Ergebnis: strikte Mandantentrennung, entlastete Host-CPUs und maximale GPU-Auslastung.
NetOps- und Plattformteams zusammenbringen
Was passiert also, wenn NetOps F5 BIG-IP am Netzwerkrand verwaltet und dabei hardwaregestützte DDoS-Abwehr, globales Traffic-Management und Compliance übernimmt, während das Plattformteam F5 Gateway Fabric for NGINX oder F5 Ingress Controller for NGINX innerhalb des Clusters betreibt?
F5 BIG-IP Container Ingress Services (CIS) verbindet ihre Workflows automatisch.
Als automatisierter, Kubernetes-nativer Konnektor überwacht BIG-IP CIS die APIs von Kubernetes und OpenShift – einschließlich Ingress, Gateway API, Routes und F5 IngressLink/GatewayLink-Ressourcen – und konfiguriert externe BIG-IP-Systeme dynamisch in Echtzeit.
Entwickler bleiben in Kubernetes und definieren clusterinternes Traffic-Routing, TLS und L7-Richtlinien in Standard-YAML. NetOps behält die Kontrolle über den Netzwerkperimeter, während CIS Änderungen am Cluster automatisch erkennt und virtuelle Server, Pool-Mitglieder sowie clusterübergreifendes DNS/GTM auf dem externen BIG-IP aktualisiert – ganz ohne manuell erstellte Tickets. Beide Teams behalten die Verantwortung für ihre jeweiligen Bereiche und nutzen dabei gemeinsame Ende-zu-Ende-Telemetriedaten vom Perimeter-VIP bis zum Pod. Bei wachsenden Anforderungen steht ein Upgrade-Pfad zu BIG-IP Next for Kubernetes zur Verfügung.
Für SecOps und CISOs: gehärtete Releases für Open Source und Enterprise
Jeder Nutzergruppe die passende Traffic-Architektur bereitzustellen, ist entscheidend. Doch Ihre Data-Plane-Software muss auch einer durch KI beschleunigten Bedrohungslandschaft standhalten.
Betrachten wir die Zahlen. Im Jahr 2018 hatten Sicherheitsverantwortliche nach der Offenlegung einer CVE durchschnittlich 771 Tage Zeit, bevor ein Exploit für Angriffe einsatzbereit war. Heute können offensive KI-Agenten Schwachstellen innerhalb von Minuten für Angriffe nutzbar machen, während ein durchschnittliches Unternehmen noch immer mehrere Wochen benötigt, um einen Patch einzuspielen. In öffentlichen Open-Source-Repositories ist jeder Sicherheits-Commit im Grunde eine Anleitung für Angreifer: KI-Tools können Codeunterschiede analysieren und Exploits generieren – Wochen bevor nachgelagerte Distributionen ihre Pakete neu bauen.
F5 liefert sicherheitsgehärtete Versionen, damit Sie Ihre Software mit Vertrauen bereitstellen können – zum Schutz sowohl kommerzieller Kunden als auch der Open-Source-Community. F5 setzt kontinuierlich ein internes KI-gestütztes Sicherheitstest-Framework für die Codebasen von BIG-IP, BIG_IP Next for Kubernetes und NGINX ein, um Schwachstellen proaktiv zu erkennen und zu beheben.
Vertrauliche, gehärtete Versionen werden kommerziellen Kunden von NGINX Enterprise, BIG-IP und BIG-IP Next for Kubernetes als gezielte, reine Sicherheitsupdates bereitgestellt – ohne Funktionsänderungen oder die Abkündigung von APIs. Etwa sechs Wochen später veröffentlicht F5 dann seine Sicherheitsmitteilung und stellt gleichzeitig CVE-Details sowie Patches für NGINX Open Source bereit. So erhalten Unternehmen einen sicheren zeitlichen Vorsprung, um ihre Infrastruktur zu patchen.
So greift alles ineinander: Skalierung einer mandantenfähigen GPU-as-a-Service-Plattform
Wie diese Komponenten in der Praxis zusammenspielen, zeigt die jüngste Bereitstellung bei einem führenden E-Commerce- und Logistikriesen im asiatisch-pazifischen Raum.
Nachdem das Unternehmen jahrelang umfangreiche interne KI-Workloads betrieben hatte, plante es die Einführung einer kommerziellen GPU-as-a-Service-Cloud (GPUaaS) auf Basis großer, lokal betriebener Kubernetes-Cluster mit NVIDIA DGX-Systemen. Bei der Umwandlung interner Cluster in eine mandantenfähige Cloud ergaben sich unmittelbar drei Herausforderungen.
Erstens benötigten externe Unternehmenskunden gleichzeitigen Zugriff auf gemeinsam genutzte Cluster, ohne dass Datenverkehr zwischen den Mandanten übertrat. Zweitens brauchte das Plattformteam cloudnatives L7-Routing, TLS-Terminierung und Namespace-Isolierung über mehr als 100 Knoten hinweg, ohne manuell Netzwerktickets erstellen zu müssen. Und drittens fehlten den Open-Source-Controllern aus der Community schlicht das robuste Traffic-Management und der Rund-um-die-Uhr-Support, die zur Erfüllung eines kommerziellen SLA erforderlich waren.
Das Unternehmen implementierte eine zweistufige Kubernetes-Traffic-Architektur, die F5 BIG-IP rSeries LTM, BIG-IP CIS und F5 Ingress Controller for NGINX über 100 Kubernetes-Knoten hinweg kombiniert. Am Netzwerkrand bieten BIG-IP rSeries-Appliances L4-Lastverteilung mit hohem Durchsatz und eine strikte Isolation virtueller Load Balancer – mit dedizierten vCPUs, Arbeitsspeicher und Routing-Partitionen. Dabei wird jede Mandantendomäne im Verhältnis eins zu eins einer isolierten virtuellen IP-Adresse zugeordnet.
Mithilfe von F5 IngressLink überwacht BIG-IP CIS die Kubernetes-API und verknüpft externe virtuelle BIG-IP-Server automatisch mit NGINX-Pods innerhalb des Clusters – ganz ohne manuell erstellte Tickets. Innerhalb des Clusters terminieren mandantenspezifische NGINX Ingress Controller-Pods TLS-Verbindungen, entschlüsseln den Datenverkehr und setzen L7-Routing sowie Authentifizierung durch. So leiten sie den Datenverkehr in den isolierten Namespace und zu den GPU-Ressourcen des jeweiligen Mandanten.
Indem das Unternehmen NetOps eine hardwarebasierte Isolierung mit BIG-IP am Edge und seinen Plattformingenieuren die Cloud-native Agilität von NGINX innerhalb des Clusters bereitstellte und beides mit BIG-IP CIS verband, konnte es seine GPUaaS-Plattform planmäßig einführen – und zugleich den Weg zu BIG-IP Next for Kubernetes für die weitere Skalierung seiner KI-Fabrik ebnen.
Traffic-Steuerung und Sicherheit – abgestimmt auf die Arbeitsweise Ihrer Teams
Laut The State of Enterprise Kubernetes Strategy 2026 werden 24 % der Unternehmen durch eine einzige Lücke daran gehindert, Kubernetes-Reife zu erreichen – meist bei der Observability oder der Admission Control. Der Unterschied zwischen „etabliert“ und „für den Unternehmenseinsatz geeignet“ ist kein Plattformproblem. Es ist ein Problem der Datenverkehrssteuerung, der Sicherheit und der Abstimmung zwischen den Teams.
F5 schließt diese Lücke für alle Rollen. Wechseln Sie vom eingestellten Community-Projekt ingress-nginx zu einer Lösung mit Enterprise-Support. Verknüpfen Sie NetOps- und Plattform-Workflows automatisch mit BIG-IP CIS. Steuern Sie den ein- und ausgehenden Datenverkehr mandantenfähiger KI-Cluster mit BIG-IP Next for Kubernetes. Und härten Sie Ihre gesamte Umgebung mit reinen Sicherheitsreleases, die Wochen vor der öffentlichen Bekanntgabe von CVEs bereitgestellt werden. Mit einer einheitlichen Architektur, die den Anforderungen unterschiedlicher Teams gerecht wird, bietet F5 ADSP die operative Kubernetes-Reife, die Unternehmen benötigen, um Kubernetes auch im großen Maßstab sicher und effizient zu betreiben.
Sie möchten mehr erfahren? Besuchen Sie uns vom 9. bis 12. November am F5-Stand Nr. 100 auf der KubeCon in Salt Lake City. Tauschen Sie sich direkt mit unseren Engineers aus, um Engpässe in Ihrem Kubernetes-Netzwerk zu beheben, erleben Sie interaktive Demos, erhalten Sie praxisnahe Einblicke und lösen Sie Ihre Kubernetes-Engpässe.
Lesen Sie unseren Blogbeitrag „Warum die meisten Unternehmen noch keine Sicherheit auf Enterprise-Niveau erreicht haben“.
Melden Sie sich außerdem unbedingt für unser Webinar „Was eine Kubernetes-Strategie auf Enterprise-Niveau von anderen unterscheidet“ an.
Über die Autoren
Ä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 […]