Verbessern Sie die Telco 5G-Netzwerkarchitektur mit Service Proxy für Kubernetes

Anfang 2018 führte ich immer wieder ähnliche Gespräche mit Freunden und Kollegen, die Experten für Netzwerke und die aufkommenden 5G-Standards waren. Uns alle empfand ich ein vages Unbehagen bei dem Gedanken, dass wir auf einen Übergang zusteuerten, bei dem es eine MENGE Unbekanntes gab. Uns allen war klar, dass 5G den Übergang zu Containern und Cloud-nativer Architektur vorantreiben würde. Doch uns war auch klar, dass Kubernetes und andere Cloud-native Tools ursprünglich für völlig andere Anwendungsfälle entwickelt wurden. Was wir alle sahen (und wahrscheinlich auch viele, die diesen Beitrag lesen), war, dass unsere Branche auf Kollisionskurs mit Sodbrennen war.

Seit diesen Tagen der Besorgnis haben die Kommunikationsdienstleister (Communication Service Providers, CSPs) mit der eigentlichen Arbeit begonnen, nämlich der Migration zu einer Cloud-nativen Infrastruktur. Tatsächlich stoßen die ersten Pioniere dieser Implementierungen auf unerwartete Hindernisse, da kritische Bereiche der Kubernetes-Netzwerke in ihrer ursprünglichen Form den Anforderungen der Anwendungsfälle von Dienstanbietern nicht gerecht werden können. Unabhängig davon, ob das Ziel des Telekommunikationsunternehmens die Bereitstellung eines 5G Stand Alone (SA) Core ist oder ob es sich um eine Modernisierungsinitiative mit einer verteilten Cloud-Architektur handelt, ist die Anpassung von Kubernetes zur Unterstützung der Netzwerkinteroperabilität, der Skalierbarkeit auf Carrier-Niveau und der Sicherheitsrichtlinien der Carrier wichtige Funktionen, die in der gesamten Cloud-nativen Infrastruktur benötigt werden.

Da sich Kubernetes seitdem vor allem auf Web- und IT-Anwendungsfälle konzentriert, die in öffentlichen Clouds oder in Unternehmensumgebungen ausgeführt werden, ist es verständlich, dass die einzigartigen Anforderungen und Protokolle zur Bereitstellung von Anwendungsfällen für Dienstanbieter nie geplant waren. Glücklicherweise haben die Architekten von Kubernetes jedoch eine Reihe solider Designmuster implementiert, die Kubernetes erweiterbar machen und einen Weg für grundlegende Anwendungsfälle im Telekommunikationsbereich schaffen: für Netzwerk-Datenverkehrsverwaltung, Sichtbarkeit und Kontrolle sowie erweiterte Protokollunterstützung wie die Protokolle HTTP/2, GTP, SIP und Diameter.

Bevor wir beschreiben, welche Verbesserungen erforderlich sind, um Kubernetes für die heutigen Anwendungsfälle von Dienstanbietern geeignet zu machen, wollen wir zunächst die besonderen Anforderungen identifizieren, die ein Dienstanbieternetzwerk mit sich bringt.

Kubernetes muss in ein größeres Ökosystem passen

Erstens muss ein Kubernetes-Cluster in das größere Netzwerk und die Abläufe des Dienstanbieters integriert werden. Architekturentscheidungen können langfristige Auswirkungen im Hinblick auf höhere Betriebskosten und Komplexität haben. Netzwerkarchitekten müssen mehrere Telko-Anwendungsfälle und die Unterstützung älterer Protokolle berücksichtigen sowie wissen, wie sich dynamische Änderungen innerhalb von Kubernetes auf die vorhandene Netzwerktopologie auswirken können – was möglicherweise zu einer erhöhten Komplexität führt.

Zweitens unterscheiden sich Telko-Workloads (Netzwerkfunktionen) von IT-Workloads. Die Netzwerke der Dienstanbieter und ihre Netzwerkfunktionen nutzen mehr als nur das Standard-HTTP/HTTPS oder TCP. Für Mobilfunkanbieter wird es von entscheidender Bedeutung sein, Netzwerkunterstützung sowohl für ältere 3G/4G-Protokolle wie SIP, GTP, SCTP usw. als auch für 5G HTTP2 zu haben. Telko-Workloads verfügen im Vergleich zu IT-Workloads außerdem über eine zusätzliche Ebene von Standards, die auf den herkömmlichen Netzwerkebenen liegen.

Und schließlich, und das ist sicher nicht das unwichtigste, ist die Sicherheit bei allen neuen Angriffspunkten von größter Bedeutung, die neue Automatisierungs-, Transparenz- und Verwaltungsfunktionen erfordern. Sicherheit muss auf allen Ebenen eingesetzt werden und bei der Einführung neuer Technologien mit den neuen Clustern zusammenarbeiten . Die SecOps-Teams der Dienstanbieter suchen ständig nach Möglichkeiten, die Angriffsfläche zu verringern und eine konsistente Sicherheitskontrolle zu gewährleisten. Darüber hinaus müssen umfassendere Sicherheitsrichtlinien des Netzwerks im Laufe der Zeit aktualisiert und angepasst werden.

Zwei aktuelle Ansätze zur Bewältigung dieser Funktionslücken

Umgehen Sie Kubernetes-Muster

Die Umgehung Cloud-nativer Muster ist ein Hinweis darauf, dass Architekten notgedrungen Hacks erstellen, da Kubernetes nicht von Haus aus über die Tools verfügt, die zur Handhabung von Telko-Workloads erforderlich sind. Wir haben mehrere beunruhigende Beispiele dafür beobachtet, dass Telekommunikationsunternehmen die Muster durchbrechen:

• Umgehung der Kubernetes-Netzwerke – Die große Mehrheit der CNFs platziert eine oder mehrere Schnittstellen außerhalb der Kontrolle von Kubernetes. Diese CNFs erfordern direkten Netzwerkzugriff (oft als Anforderung für „Multus“ gestellt, um eine zusätzliche, direkte Schnittstelle nach außen zu ermöglichen). Ohne eine zentrale Netzwerksteuerung wird die interne Komplexität von Kubernetes dem Netzwerk externer Dienstanbieter ausgesetzt, was zu einer erhöhten Betriebskomplexität und höheren Kosten sowie einer größeren Angriffsfläche für die Sicherheit führt. Darüber hinaus werden für alle App-/Netzwerkfunktionsentwickler und Netzwerkbetreiber höhere Anforderungen an die Verwaltung von IP-Adressen sowie an die Handhabung der dynamischen Natur von Containern in Kubernetes gestellt, die nun der Außenwelt ausgesetzt sind.
• Separate Cluster für jede Netzwerkfunktion – Kubernetes-Netzwerke bieten nicht von Haus aus einen zentralen Punkt für den ein- und ausgehenden Netzwerkverkehr. Kubernetes stellt eine gewisse Eingangskontrolle bereit, ignoriert jedoch den ausgehenden Datenverkehr fast vollständig und es gibt keine integrierte Möglichkeit, Eingangs- und Ausgangsnetzwerke zu verknüpfen. Wir haben mehrere Bereitstellungen gesehen, bei denen jede Netzwerkfunktion in ihrem eigenen Cluster ausgeführt wird, um eine Korrelation zwischen den IP-Adressen der Server und den IP-Adressen der Netzwerkfunktionen zu ermöglichen. Dies führt zu einem zusätzlichen Ressourcenaufwand und höheren Investitionsausgaben, während gleichzeitig die betriebliche Komplexität zunimmt und die Betriebsausgaben steigen.

An Kubernetes-Mustern ausrichten

Ein alternativer Ansatz besteht darin, sich an den Kubernetes-Entwurfsmustern auszurichten und einen Service-Proxy einzuführen, der eine zentrale Schnittstelle für die Ein- und Ausgangsnetzwerke und die Sicherheit des Kubernetes-Clusters gegenüber der Außenwelt bereitstellt. Das Ziel eines Service-Proxys besteht darin, die funktionalen Lücken zu schließen, die Kubernetes bei der Verwendung in einer Service-Provider-Umgebung aufweist. Ein Serviceproxy sollte:

• Verwenden Sie Kubernetes-native Muster , um das Kubernetes-Netzwerk zu erweitern (benutzerdefinierte Ressourcendefinitionen, K8s-Kontrollschleife).
• Schnittstelle zum größeren Netzwerk (BGP-Routing, ausgehende SNAT-IP-Zuweisungen, IPv4/v6-Übersetzung)
• Verknüpfen Sie Eingang und Ausgang einzeln für jeden CNF
• Bietet umfassende L4/L7-Unterstützung (TCP, UDP, SCTP, NGAP, HTTP/2, Diameter, GTP, SIP)
• Bereitstellung einer Sicherheitsebene (TLS-Terminierung, Firewall, DDoS, Web Application Firewall)
• Präsentieren Sie konsistente CNF und verbergen Sie hochdynamische Kubernetes-Ereignisse

Der Ansatz von F5 – Einführung des Service-Proxys

F5 hat sich für das oben beschriebene zweite Szenario entschieden, um Kubernetes zu erweitern und diesen Service-Proxy zu erstellen, der diese fehlende Funktionalität bereitstellt. Aufgrund unserer jahrzehntelangen Erfahrung im Bereich Verkehrsmanagement und Sicherheit sind wir davon überzeugt, dass es sich hierbei um eine kritische Funktion handelt, die zur Unterstützung einer Cloud-nativen Migration im großen Maßstab erforderlich ist. Wir haben den BIG-IP Next Service Proxy für das Cloud-native Infrastrukturprodukt Kubernetes (SPK) entwickelt, das produktionsreif und ab sofort verfügbar ist. Damit beheben wir die Mängel von Kubernetes direkt und ermöglichen Dienstanbietern die Erstellung von Ressourcen, die dem „normalen“ Kubernetes fehlen. SPK vereinfacht und sichert die Architektur mit einem Framework, das die Automatisierung und reibungslose Integration in umfassendere Netzwerk- und Sicherheitsrichtlinien ermöglicht. Dieser Kubernetes-Ansatz für Telekommunikationsunternehmen wird weiterhin zu geringerer Komplexität und geringeren Betriebskosten sowie einer widerstandsfähigeren und sichereren Infrastruktur führen. Da wir heute eine Verlangsamung beim Übergang zu 5G SA beobachten ( GlobalData stellt fest: Telekommunikationsbetreiber scheitern bei 5G SA ), kann man davon ausgehen, dass der Übergang ohne die Einführung eines geeigneten Service-Proxys weiter ins Stocken geraten wird. In der Produktion befindliche Telkokunden, die sich mitten in einer groß angelegten digitalen Modernisierung befinden, stellen fest, dass sich SPK als die Kubernetes-Lösung für das 5G-Netzwerkarchitekturproblem erweist, von dem sie nicht einmal wussten, dass sie es hatten.

Das SPK von F5 ist nun allgemein verfügbar und wird derzeit bei großen Telekommunikationsunternehmen produziert. Halten Sie Ausschau nach bevorstehenden Veranstaltungen, bei denen wir die Fähigkeiten von SPK im Vergleich zu anderen Ansätzen demonstrieren und zeigen, wie CNFs auf unserer Plattform zertifiziert werden. Weitere Informationen finden Sie auf dieser Seite . Wenn Sie direkt mit einem F5-Teammitglied sprechen möchten, kontaktieren Sie uns .