Machen Sie GPU-Kapazität zum Geschäftsmodell mit Managed Kubernetes
Neocloud-Anbieter, die Managed Kubernetes und GPU-as-a-Service anbieten, müssen jeden Mandanten im Netzwerk isolieren, ihm einen eigenen, kontrollierten Pfad für ein- und ausgehenden Datenverkehr bereitstellen und sicherstellen, dass kein anderer Mandant auf ihn zugreifen kann. F5 bietet all das und noch mehr.
Unternehmenskunden fragen zuerst, wie ihre Mandanten isoliert werden
Ein Neocloud-Anbieter, der über Bare Metal hinausgeht, übernimmt die Netzwerkfunktionen, die seine Mandanten bisher selbst aufgebaut haben: die Isolation zwischen Kunden, die Kontrolle des ein- und ausgehenden Datenverkehrs, Firewall-Funktionen und die entsprechenden Protokolle als Nachweis. Open-Source-Proxys und Skripte bringen einen ersten Cluster zum Laufen, doch für jeden neuen Mandanten muss eine neue Lösung aufgebaut werden. F5 stellt diese Schicht als unterstützte Komponente der F5 Application Delivery and Security Platform bereit.
Mandanten im Netzwerk isolieren
Separate Routing-Domänen pro Mandant mit EVPN-VXLAN und VRFs statt nur Namespaces und Labels.
Kontrollieren Sie den ein- und ausgehenden Datenverkehr
Mandantenspezifischer eingehender und ausgehender Datenverkehr mit festen Quelladressen sowie eine Firewall am Netzwerkrand der Knoten.
Host-Kerne wieder für umsatzgenerierende Aufgaben nutzen
Im DPU-Modus sank die Anzahl der benötigten Host-Kerne in von The Tolly Group validierten Tests von 12 auf 2.
Starten Sie mit Ihren vorhandenen Servern
Läuft auf Standard-Host-CPUs; ergänzen Sie BlueField-DPUs, wenn Host-Kerne wertvoller sind.
Wie F5 Neoclouds dabei hilft, mehr als nur GPU-Stunden zu verkaufen
Mandantenisolierung
Namespaces und Netzwerkrichtlinien trennen Mandanten innerhalb von Kubernetes voneinander, doch das zugrunde liegende Netzwerk nutzen sie weiterhin gemeinsam – und das wissen auch die Sicherheitsteams in Unternehmen. BIG-IP Next for Kubernetes ordnet jedem Mandanten mithilfe von BGP EVPN-VXLAN mit VRFs eine eigene Routing-Domäne zu, sodass der Datenverkehr jedes Mandanten über seine eigene VRF in den Cluster gelangt und ihn wieder verlässt. Neue Mandanten lassen sich so durch Konfiguration hinzufügen, statt einen Neuaufbau zu erfordern. Das Plattformteam betreibt dabei eine einzige Schicht statt jeweils eines Proxys, eines Routers und einer Firewall pro Kunde.
Netzwerklösungen für Kubernetes entdeckenBIG-IP Next for Kubernetes
Mandantenisolierung auf Netzwerkebene und mandantenspezifische Richtlinien an der Clustergrenze.
BIG-IP Next for Kubernetes auf NVIDIA BlueField DPUs bereitgestellt
Durchsetzung der Mandantentrennung auf der DPU, unabhängig vom Host-Betriebssystem.
Eingehender und ausgehender Datenverkehr und Firewall
Jeder Mandant benötigt kontrollierte Ein- und Ausgangswege. BIG-IP Next for Kubernetes bietet mandantenspezifischen Ingress über die Kubernetes Gateway API, Egress über feste, mandantenspezifische Quelladressen, die externe Systeme in ihre Positivlisten aufnehmen können, sowie eine Firewall am Netzwerkrand der Knoten mit einem eigenen Logstream für jeden Mandanten. Standardmäßig verwendet ausgehender Pod-Traffic die Adresse des Knotens, sodass externe Systeme die Mandanten nicht voneinander unterscheiden können. Mit F5 erhalten Mandanten die Kontrollmöglichkeiten, die ihre Sicherheitsteams benötigen, und der Anbieter erhält die entsprechenden Nachweise, um sie ihnen vorzulegen.
Netzwerklösungen für Kubernetes entdeckenBIG-IP Next for Kubernetes
Mandantenisolierung auf Netzwerkebene und mandantenspezifische Richtlinien an der Clustergrenze.
NGINX Gateway Fabric
Gateway-API-Implementierung für den Anwendungsverkehr innerhalb von Mandanten-Clustern.
Mit Host-Kernen wieder Umsatz erzielen
Auf einem Standardserver laufen Netzwerkverarbeitung, Verschlüsselung und Richtliniendurchsetzung auf Host-CPU-Kernen, die nicht in Rechnung gestellt werden. Bei der Bereitstellung auf NVIDIA BlueField DPUs im DPU-Modus verlagert BIG-IP Next for Kubernetes diesen Datenpfad auf die DPU. In von The Tolly Group validierten Tests sank die Zahl der beanspruchten Host-Kerne pro Server von 12 auf 2, gemessen mit einem kleinen Modell. Über ein ganzes Rack hinweg ergibt sich daraus Kapazität, die Sie verkaufen können, statt sie selbst zu verbrauchen. Beginnen Sie auf dem Host und wechseln Sie zur DPU, sobald diese Kerne als verkaufbare Kapazität mehr wert sind.
Tolly-Bericht lesenBIG-IP Next for Kubernetes auf NVIDIA BlueField-DPUs bereitgestellt
Durchsetzung der Mandantenrichtlinien auf der DPU, unabhängig vom Host-Betriebssystem.
BIG-IP Next for Kubernetes
Mandantenisolierung auf Netzwerkebene und mandantenspezifische Richtlinien an der Clustergrenze.
Die Fabrik versorgen und schützen
Trainingsmandanten beziehen Daten aus Objektspeichern über mehrere Standorte und Clouds hinweg. Stockt der Datenfluss, stehen ihre GPUs still – auf Ihre Kosten. Öffentliche Inferenz-Endpunkte und Mandanten-APIs sind über das Internet erreichbar, und eine Überlastung kann teuer werden. F5 BIG-IP verteilt und sichert den S3-Datenverkehr zu den GPUs und bietet an der Außengrenze der KI-Fabrik DDoS-Schutz, Firewall-Funktionen und globale Datenverkehrssteuerung – auf Hardware, die für die Größenordnung von Serviceprovidern ausgelegt ist.
Datenbereitstellung für KI entdeckenBIG-IP LTM
Lastverteilung und Failover über mehrere S3-Speicherendpunkte hinweg.
BIG-IP DNS
Globale Steuerung von Nutzern und Datenverkehr über mehrere Standorte hinweg.
BIG-IP DNS
Globale Steuerung von Benutzern und Datenverkehr über mehrere Standorte hinweg.
BIG-IP DNS
Globale Steuerung von Nutzern und Datenverkehr über mehrere Standorte hinweg.
BIG-IP DNS
Globale Steuerung von Nutzern und Datenverkehr über mehrere Standorte hinweg.
BIG-IP DNS
Globale Steuerung von Nutzern und Datenverkehr über mehrere Standorte hinweg.
Ressourcen
Referenzarchitekturen
Entdecken Sie die KI-Referenzarchitektur
Berichte
Lösungsübersichten
GPUaaS und KI-Inferenzdienste mit F5 und NVIDIA ermöglichen
Häufig gestellte Fragen
Eine Neocloud ist ein Cloud-Anbieter, dessen Angebot auf GPU-Kapazitäten für KI statt auf universell einsetzbare Rechenleistung ausgerichtet ist. Die meisten begannen mit der stundenweisen Vermietung von Bare-Metal-GPU-Servern und erweitern ihr Angebot nun um Managed Kubernetes, GPU-as-a-Service und teilweise auch Inferenzdienste. So erhalten Unternehmenskunden eine Plattform statt reiner Server. Dieser Wandel erhöht den möglichen Umsatz pro GPU-Stunde – und zugleich die Erwartungen der Mandanten an die zugrunde liegende Netzwerkinfrastruktur.
Die Isolation erfolgt auf mehreren Ebenen. Namespaces und rollenbasierte Zugriffskontrolle grenzen ein, was die einzelnen Mandanten verwalten können, während virtuelle Cluster jedem Mandanten eine eigene Steuerungsebene bereitstellen. Die Isolation auf Netzwerkebene – in der Regel EVPN-VXLAN mit einer dedizierten VRF pro Mandant – sorgt dafür, dass der Datenverkehr jedes Mandanten beim Eintritt in den Cluster und beim Verlassen des Clusters in seiner eigenen Routing-Domäne bleibt. Mandantenspezifische Ingress-, Egress- und Firewall-Richtlinien an der Cluster-Grenze regeln dann, auf welche Ziele die einzelnen Mandanten zugreifen können.
Bei Bare Metal werden komplette Server vermietet, auf denen der Mieter seinen eigenen Software-Stack bereitstellt und betreibt. GPU as a Service und Managed Kubernetes ergänzen dies um eine Plattform mit Ressourcenplanung, Netzwerkfunktionen, Mandantenisolierung, ein- und ausgehendem Datenverkehr sowie Support. Der Anbieter übernimmt mehr Verantwortung und kann pro GPU-Stunde höhere Preise verlangen. Unternehmenskunden erwarten zunehmend eine solche Plattform statt reiner Server.
Geben Sie jedem Mandanten einen eigenen Pfad für ausgehenden Datenverkehr. Mandantenspezifischer Egress mit festen Quelladressen ermöglicht es externen Systemen, einen Mandanten anhand seiner Adresse in eine Zulassungsliste aufzunehmen. So wird verhindert, dass der Datenverkehr eines Mandanten scheinbar von einem anderen stammt. Zudem lassen sich ausgehende Verbindungen einfach nach Ziel protokollieren und überprüfen. Kubernetes-Netzwerkrichtlinien helfen dabei, greifen jedoch auf der Ebene von Pods und IP-Blöcken innerhalb des Clusters.
Nein. BIG-IP Next for Kubernetes läuft auf Standard-Host-CPUs, auf denen auch Mandantenisolierung, Ingress und Egress funktionieren. NVIDIA BlueField DPUs verlagern den Datenpfad vom Host und setzen Richtlinien außerhalb des Host-Betriebssystems durch. Das lohnt sich zunehmend, wenn die Zahl der Mandanten wächst und Host-Kerne als vermarktbare Kapazität an Wert gewinnen. Die im DPU-Modus gemessenen Ergebnisse lassen sich nicht auf Host-basierte Bereitstellungen übertragen.