Anfang 2018 führte ich immer wieder ähnliche Gespräche mit Freunden und Kollegen, die Experten für Netzwerktechnologien und die neuen 5G-Standards waren. Uns allen bereitete ein wenig Unbehagen, dass wir auf einen Wandel mit SEHR vielen Unbekannten zusteuerten. Uns war klar, dass 5G den Übergang zu Containern und einer Cloud-nativen Architektur vorantreiben würde. Gleichzeitig wussten wir aber auch, dass Kubernetes und andere Cloud-native Tools ursprünglich für völlig andere Anwendungsfälle entwickelt worden waren. Wir alle sahen – und wahrscheinlich bemerkten das auch viele, die diesen Beitrag lesen –, dass unsere Branche auf einen schmerzhaften Zusammenstoß zusteuerte.
Seit jenen von Besorgnis geprägten Tagen haben Kommunikationsdienstleister (Communication Service Providers, CSPs) mit der eigentlichen Migration zu einer Cloud-nativen Infrastruktur begonnen. Die Vorreiter dieser Implementierungen stoßen tatsächlich auf unerwartete Hürden, da zentrale Bereiche der ursprünglich konzipierten Kubernetes-Netzwerkarchitektur den Anforderungen der Anwendungsfälle von Dienstanbietern nicht gerecht werden können. Unabhängig davon, ob das Ziel des Telekommunikationsanbieters die Einführung eines eigenständigen 5G-Kernnetzes (5G Standalone Core, SA Core) oder eine Modernisierungsinitiative mit einer verteilten Cloud-Architektur ist: Die Anpassung von Kubernetes zur Unterstützung von Netzwerkinteroperabilität, Skalierbarkeit auf Netzbetreiberniveau und Sicherheitsrichtlinien für Netzbetreiber ist eine entscheidende Voraussetzung für die gesamte Cloud-native Infrastruktur.
Da Kubernetes seitdem hauptsächlich mit Blick auf Web- und IT-Anwendungsfälle weiterentwickelt wurde, die in der Public Cloud oder in Unternehmensumgebungen ausgeführt werden, ist es verständlich, dass die besonderen Anforderungen und Protokolle für die Bereitstellung von Anwendungsfällen für Kommunikationsdienstleister ursprünglich nicht berücksichtigt wurden. Glücklicherweise haben die Kubernetes-Architekten jedoch solide Entwurfsmuster geschaffen, die Kubernetes erweiterbar machen und damit den Weg für grundlegende Telekommunikationsanwendungsfälle ebnen: für die Verwaltung, Transparenz und Kontrolle des Netzwerkverkehrs sowie für die erweiterte Unterstützung von Protokollen wie HTTP/2, GTP, SIP und Diameter.
Bevor wir beschreiben, welche Erweiterungen erforderlich sind, um Kubernetes für die heutigen Anwendungsfälle von Serviceprovidern fit zu machen, wollen wir zunächst die besonderen Anforderungen eines Serviceprovider-Netzwerks ermitteln.
Kubernetes muss sich in ein größeres Ökosystem einfügen
Zunächst muss ein Kubernetes-Cluster in das übergeordnete Netzwerk und den Betrieb des Service-Providers integriert werden. Architekturentscheidungen können langfristige Auswirkungen haben und die Betriebskosten sowie die Komplexität erhöhen. Netzwerkarchitekten müssen verschiedene Anwendungsfälle von Telekommunikationsunternehmen, die Unterstützung älterer Protokolle und die möglichen Auswirkungen dynamischer Änderungen innerhalb von Kubernetes auf die bestehende Netzwerktopologie berücksichtigen, da dies potenziell zu einer höheren Komplexität führen kann.
Zweitens unterscheiden sich Telekommunikations-Workloads (Netzwerkfunktionen) von IT-Workloads. Die Netzwerke von Dienstanbietern und deren Netzwerkfunktionen nutzen mehr als nur die Standardprotokolle HTTP/HTTPS oder TCP. Für Mobilfunkanbieter wird es entscheidend sein, dass ihre Netzwerke sowohl ältere 3G-/4G-Protokolle wie SIP, GTP, SCTP usw. als auch HTTP/2 für 5G unterstützen. Im Vergleich zu IT-Workloads verfügen Telekommunikations-Workloads zudem über eine zusätzliche Standardisierungsebene, die auf den herkömmlichen Netzwerkschichten aufsetzt.
Zu guter Letzt – und keineswegs weniger wichtig – hat die Sicherheit angesichts all der neuen potenziellen Angriffspunkte, die neue Automatisierungs-, Transparenz- und Verwaltungsfunktionen erfordern, höchste Priorität. Sicherheitsmaßnahmen müssen auf allen Ebenen implementiert werden und bei der Einführung neuer Technologien gemeinsam mit den neuen Clustern funktionieren. Die SecOps-Teams der Serviceprovider suchen stets nach Möglichkeiten, die Angriffsfläche zu reduzieren und eine einheitliche Sicherheitskontrolle zu gewährleisten. Darüber hinaus müssen die übergreifenden Sicherheitsrichtlinien des Netzwerks aktualisiert werden und im Laufe der Zeit anpassbar sein.
Zwei aktuelle Ansätze zur Behebung dieser Funktionslücken
Kubernetes-Muster umgehen
Die Umgehung cloudnativer Muster ist ein Anzeichen dafür, dass Architekten notgedrungen Behelfslösungen entwickeln müssen, da Kubernetes von Haus aus nicht über die erforderlichen Werkzeuge zur Verarbeitung von Telekommunikations-Workloads verfügt. Wir haben mehrere bedenkliche Vorgehensweisen beobachtet, mit denen Telekommunikationsunternehmen diese Muster durchbrechen:
- Umgehung der Kubernetes-Netzwerkfunktionen – Die überwiegende Mehrheit der CNFs platziert eine oder mehrere Schnittstellen außerhalb der Kontrolle von Kubernetes. Diese CNFs benötigen direkten Netzwerkzugriff (häufig in Form einer Anforderung für „Multus“, um eine zusätzliche, direkte Schnittstelle nach außen zu ermöglichen). Ohne eine zentrale Instanz zur Netzwerksteuerung wird dadurch die interne Komplexität von Kubernetes für das externe Netz des Dienstanbieters offengelegt. Dies führt zu einer höheren betrieblichen Komplexität und höheren Kosten sowie zu einer größeren Angriffsfläche. Zudem steigen die Anforderungen an alle Entwickler von Anwendungen bzw. Netzwerkfunktionen und an die Netzbetreiber, da sie IP-Adressen verwalten und mit der dynamischen Natur von Containern in Kubernetes umgehen müssen, die nun nach außen hin sichtbar ist.
- Separate Cluster für jede Netzwerkfunktion – Kubernetes-Netzwerke bieten von Haus aus keinen zentralen Punkt für den ein- und ausgehenden Netzwerkverkehr. Kubernetes ermöglicht zwar eine gewisse Steuerung des eingehenden Datenverkehrs, berücksichtigt den ausgehenden Datenverkehr jedoch so gut wie gar nicht. Zudem gibt es keine integrierte Möglichkeit, die Netzwerksteuerung für ein- und ausgehenden Datenverkehr miteinander zu verknüpfen. Wir haben mehrere Bereitstellungen gesehen, bei denen jede Netzwerkfunktion in einem eigenen Cluster ausgeführt wird, um die IP-Adressen der Server den IP-Adressen der Netzwerkfunktionen zuordnen zu können. Dies führt zu einem zusätzlichen Ressourcenbedarf und höheren Investitionsausgaben (CapEx). Gleichzeitig erhöht sich die betriebliche Komplexität, was wiederum höhere Betriebsausgaben (OpEx) zur Folge hat.
An Kubernetes-Mustern ausrichten
Ein alternativer Ansatz besteht darin, sich an den Kubernetes-Entwurfsmustern zu orientieren und einen Service-Proxy einzuführen, der eine zentrale Übersicht über die Ingress-/Egress-Netzwerkkommunikation und die Sicherheit des Kubernetes-Clusters gegenüber der Außenwelt bietet. Ziel eines Service-Proxys ist es, die funktionalen Lücken zu schließen, die Kubernetes beim Einsatz in einer Service-Provider-Umgebung aufweist. Ein Service-Proxy sollte:
- Kubernetes-native Muster verwenden zur Erweiterung der Kubernetes-Netzwerkfunktionen (benutzerdefinierte Ressourcendefinitionen, K8s-Kontrollschleife)
- Anbindung an das übergeordnete Netzwerk (BGP-Routing, Zuweisung ausgehender SNAT-IP-Adressen, IPv4-/IPv6-Übersetzung)
- Ingress und Egress verknüpfen individuell für jede CNF
- Umfassende L4-/L7-Unterstützung bieten (TCP, UDP, SCTP, NGAP, HTTP/2, Diameter, GTP, SIP)
- Eine Sicherheitsebene bereitstellen (TLS-Terminierung, Firewall, DDoS-Schutz, Web Application Firewall)
- Konsistente CNF bereitstellen, wobei hochdynamische Kubernetes-Ereignisse verborgen werden
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 entwickeln, der die fehlende Funktionalität bereitstellt. Aufgrund unserer jahrzehntelangen Erfahrung im Traffic-Management und in der Sicherheit sind wir überzeugt, dass diese Funktion für groß angelegte Cloud-native-Migrationen unverzichtbar ist. Mit dem BIG-IP Next Service Proxy for Kubernetes (SPK) haben wir ein produktionsreifes und ab sofort verfügbares Cloud-native-Infrastrukturprodukt entwickelt, das die Schwächen von Kubernetes direkt behebt und es Serviceprovidern ermöglicht, Ressourcen zu erstellen, die in einem unveränderten Standard-Kubernetes fehlen. SPK vereinfacht und schützt die Architektur mithilfe eines Frameworks, das Prozesse automatisiert und sich nahtlos in übergreifende Netzwerk- und Sicherheitsrichtlinien integriert. Dieser Kubernetes-Ansatz für Telekommunikationsanbieter wird auch künftig die Komplexität und die Betriebskosten senken und zugleich für eine resilientere und sicherere Infrastruktur sorgen. Da sich der Übergang zu 5G SA derzeit verlangsamt (Telekommunikationsanbieter scheitern an 5G SA, so GlobalData), ist davon auszugehen, dass er ohne die Einführung eines geeigneten Service-Proxys noch weiter ins Stocken geraten wird. Telekommunikationskunden, die SPK bereits im Produktivbetrieb einsetzen und sich mitten in einer umfassenden digitalen Modernisierung befinden, stellen fest, dass SPK genau die Kubernetes-Lösung für das Problem der 5G-Netzwerkarchitektur ist, von dem sie nicht einmal wussten, dass sie es hatten.
F5 SPK ist jetzt allgemein verfügbar (GA) und wird derzeit bei großen Telekommunikationsunternehmen produktiv eingesetzt. Achten Sie auf kommende Veranstaltungen, bei denen wir die Funktionen von SPK im Vergleich zu anderen Ansätzen demonstrieren und zeigen, wie sich CNFs auf unserer Plattform zertifizieren lassen. Weitere Informationen finden Sie auf dieser Seite, und wenn Sie direkt mit einem Mitglied des F5-Teams sprechen möchten, kontaktieren Sie uns.
Über den Autor
Ähnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...