Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 6 Min.

Service Mesh für die OSI-Layer 2 und 3: Netzwerk-Lego


Linux Magazin - epaper ⋅ Ausgabe 1/2020 vom 05.12.2019

Im April 2018 akzeptierte die Cloud Native Computing Foundation ein neues Sandboxing-Projekt: Network Service Mesh. Worin es einem Service Mesh gleicht und was es davon unterscheidet, erklärt der Artikel.


Artikelbild für den Artikel "Service Mesh für die OSI-Layer 2 und 3: Netzwerk-Lego" aus der Ausgabe 1/2020 von Linux Magazin. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Linux Magazin, Ausgabe 1/2020

Für Netzwerker ist Kubernetes nicht unbedingt die helle Freude: Komplexere Netzwerkszenarien, wie sie bei ISPs, in Telekommunikationsunternehmen und in fortgeschrittenen Enterprise-Netzen auftreten, bildet Kubernetes nicht ab. Das Container Network Interface (CNI) legt beim Erzeugen der Pods und Nodes lediglich die benötigten Netzwerkschnittstellen für die Container an, um diese beim Löschen wieder zu ...

Weiterlesen
epaper-Einzelheft 5,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Linux Magazin. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 1/2020 von News: Steams Linux-Client erhält Container-Support. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
News: Steams Linux-Client erhält Container-Support
Titelbild der Ausgabe 1/2020 von Kurznachrichten. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Kurznachrichten
Titelbild der Ausgabe 1/2020 von Zahlen & Trends. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Zahlen & Trends
Titelbild der Ausgabe 1/2020 von Notizen von der Open Source Monitoring Conference 2019: Neue Lösungen gefragt. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Notizen von der Open Source Monitoring Conference 2019: Neue Lösungen gefragt
Titelbild der Ausgabe 1/2020 von Bericht vom Linux-Gipfel in Lyon: Pinguin-Rendezvous. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Bericht vom Linux-Gipfel in Lyon: Pinguin-Rendezvous
Titelbild der Ausgabe 1/2020 von Umfrage unter Cloud-Anbietern zum Thema Service Mesh: Vom Nutzen der Netze. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Umfrage unter Cloud-Anbietern zum Thema Service Mesh: Vom Nutzen der Netze
Vorheriger Artikel
Umfrage unter Cloud-Anbietern zum Thema Service Mesh: Vom Nutzen …
aus dieser Ausgabe
Nächster Artikel Wie Cloud Foundry ein Service Mesh realisiert: Wegscheide fü…
aus dieser Ausgabe

Für Netzwerker ist Kubernetes nicht unbedingt die helle Freude: Komplexere Netzwerkszenarien, wie sie bei ISPs, in Telekommunikationsunternehmen und in fortgeschrittenen Enterprise-Netzen auftreten, bildet Kubernetes nicht ab. Das Container Network Interface (CNI) legt beim Erzeugen der Pods und Nodes lediglich die benötigten Netzwerkschnittstellen für die Container an, um diese beim Löschen wieder zu entfernen[1] .
Die Flexibilität von Kubernetes steckt im Bereich der Applikationen. Application Service Meshes wie Istio erlauben es, die OSI-Schichten 4 (TCP-Streams und UDP-Datagramme) und 7 (HTTP/ Anwendungsprotokolle) umfassend zu konfigurieren. Auf die darunterliegenden Layer-2- und Layer-3-Netzwerke (Frames und IP-Pakete) trifft das jedoch nicht zu.

Wer braucht das?

Das zu ändern, schreiben sich die Entwickler[2] des Network Service Mesh (NSM[3] ) auf die Fahnen. Sie wollen ihren an Kubernetes orientierten Ansatz für Unternehmen attraktiv machen, die Cloud-Native-Modelle für NFV (Network Function Virtualization[4] ), 5G-Netzwerke, Edge Computing oder IoT nutzen möchten. Laufen die Network Functions der Telcos aktuell noch virtualisiert auf Hardware (VNFs), sollen sie künftig zu CNFs werden[5] und in Containern zu Hause sein. Noch befindet sich das NSM-Projekt in einem recht frühen Stadium, Version 0.1.0 (Codename „Andromeda”) erschien erst im August 2019. Dennoch stehen einige Eckpunkte der geplanten Marschroute für das Network Service Mesh bereits fest.
Theoretisch wäre es auch möglich, Subnetze, Schnittstellen, Switches und so weiter in virtueller Form als Container oder Pods in Kubernetes zu reproduzieren. Das aber betrachten die Projektleiter eher skeptisch als Cloud 1.0, weil in diesem Fall viele Vorteile von Cloud-Native- Anwendungen wegfielen. Will ein Entwickler in einem solchen Szenario zum Beispiel einen Pod mit einer VPN Schnittstelle versehen, damit dieser sich mit dem VPN seiner Firma verbindet, müsste er sich im Detail um die verwendeten IP-Adressen, Subnetze, Routen und so weiter kümmern.

Auftritt Service Mesh

Diese Komplexität will das NSM-Projekt reduzieren, indem es das vorhandene Service-Mesh-Modell von Kubernetes so anpasst, dass es auch Verbindungen auf den Netzwerkschichten 2 und 3 erlaubt. Dazu führt es drei Konzepte ein: Network Services, Network Service Endpoints und Connection Interfaces.
Ein illustratives Beispiel liefert das Projekt auch gleich[6] . Ein Pod oder Network Service Client (der einer Userin namens Sarah gehört) soll auf ein Firmen-VPN zugreifen (Abbildung 1). Also fordert der Pod einen Network Service an.
Dieser trägt im Beispiel den Namen »secure‑intranet‑connectivity « und kapselt einen oder mehrere Pods im Netzwerk, die ihrerseits die Bezeichnung Network Service Endpoints tragen. Solch ein Network Service lässt sich, ähnlich wie die Services in Kubernetes, im YAML-Format definieren und sieht dann beispielsweise so aus wie in Listing 1.
Im Beispiel besteht der Network Service zunächst aus einem Pod, der als Network Service Endpoint ein VPN-Gateway anbietet. Der Client-Pod soll sich nun mit dem VPN-Gateway verbinden und darüber auf das Firmen-VPN zugreifen, wie es Abbildung 1 visualisiert.

Suchen und Finden

Damit der Client-Pod den Network Service mit dem VPN-Gateway tatsächlich findet, gibt sich der VPN-Pod über ein sogenanntes Destination Label im Netzwerk zu erkennen: »app=vpn‑gateway«. Der Client-Pod kann wiederum seinen Anfragen solch ein Destination Label mit auf den Weg geben (»app:vpn‑gateway«). So findet der Pod das Gateway.

Abbildung 1: Um die Funktionsweise eines Network Service Mesh zu erklären, hält das Projekt eine gut gemachte Präsentation parat. Darin will Nutzerin Sarah ihren Pod mit einem Unternehmens-VPN verbinden.


Gute Connection

Das wirft die Frage auf, wie die Verbindung zwischen dem Client-Pod und dem VPN-Gateway als Network Service Endpoint zustande kommt. Wer verteilt IP-Adressen, erzeugt die richtigen Subnetze, konfiguriert Interfaces und stellt Routen ein? Das erledigt der Network Service Manager (»nsmd«). Er läuft als Daemon-Set auf jedem Node und verknüpft im Beispiel den Client-Pod mit dem VPN-Gateway. Das setzt zudem voraus, dass im anfragenden Client-Pod auch ein sogenannter »NSM InitContainer « läuft.
Der Nsmd erhält über das gRPC-Protokoll[7] eine Anfrage des Client-Pods, der eine Verbindung zum VPN-Gateway sucht. Der Manager leitet die Anfrage an den VPN-Gateway-Pod weiter. Kommt von diesem eine Rückmeldung, erzeugt Nsmd im sogenannten Forwarder (ehemals Data Plane) die passenden Interfaces. Beim Forwarder handelt es sich um ein privilegiertes Interface mit Kernel- Zugriff. Er erzeugt zuerst ein passendes Interface für das Gateway und stöpselt es an den Gateway-Pod. Dann generiert er eine Schnittstelle für den Client-Pod, injiziert diese ebenfalls in den Pod und schickt schließlich eine Bestätigung an den Client-Pod (Abbildung 2). Nun stellen Client und VPN-Gateway eine Punktzu- Punkt- Verbindung her. Wichtig zu wissen: Alle Verbindungen im Network Service Mesh bauen auf solchen Punktzu- Punkt-Verbindungen auf.
Das Ganze klappt auch über Nodes hinweg. In diesem Fall erhält der Manager von Node 1 (Nsmd1) über den API-Server von Kubernetes Kenntnis über die in Node 2 vorhandenen Network Services und Network Service Endpoints. Nsmd1 nimmt dann Kontakt zum Manager von Node 2 (Nsmd2) auf, der wiederum den VPN-Gateway-Pod kontaktiert. Über die jeweiligen Forwarder in den Nodes (künftig soll es mehrere Forwarder geben) bauen Nsmd1 und Nsmd2 dann einen Tunnel zwischen Client-Pod und VPNGateway- Pod auf.
Solche Verbindungen planen die NSMEntwickler auch über Cluster-Grenzen hinweg. Externe Network Service Manager (eNSM) sollen in der Lage sein, mit VIMs (Virtual Infrastructure Manager) Kontakt aufzunehmen. Das ist insbesondere in Umgebungen mit Telekommunikations- Hardware interessant. VIMs kontrollieren und verwalten in NFVIs (Network Functions Virtualization Infrastructures), den Netzwerken für den Betrieb der VNFs, die Prozessoren-, Speicher- und Netzwerkressourcen. Hier schlägt das Network Service Mesh also eine Brücke in andere Netzwerke, in denen zum Beispiel virtuelle Maschinen auf Open-Stack-Basis laufen. Aber auch externe Netzwerkgeräte sollen sich so in NSMs einbinden lassen.
Will ein Entwickler neue Network Service Endpoints ergänzen oder sich einen Überblick der im Cluster vorhandenen Network Services, Endpoints und Manager verschaffen, springt die Network Service Registry (NSR) in die Bresche. Sie kennt alle Service-Mesh-Komponenten in einem spezifischen Cluster oder physischen Netzwerk. Die Summe aller in der NSR eingetragenen Komponenten bildet dann eine Network Service Registry Domain (NSRD).

Abbildung 2: Um die Punkt-zu-Punkt-Verbindungen im Node oder über Nodes hinweg kümmern sich die Forwarder (vormals Data Planes). Sie versehen die Pods mit den passenden Interfaces.


Firewall ergänzen

Aber zurück zum Anfangsbeispiel. Will die Firma einen Firewall-Pod zwischen Client-Pod und VPN-Gateway schalten, ist auch das dank der Label kein größeres Hindernis. Der Firewall-Pod leitet alle eingehenden Anfragen automatisch an den VPN-Gateway-Pod weiter. Sein Destination Label heißt sinnvollerweise »app=firewall«. Im YAML-File steht entsprechend als Quelle »app:firewall« sowie als Ziel der Route der »destinationSelector « (oder das Destination Label) »app:vpn‑gateway« (Listing 2, Zeile 3 bis 9). Kommt die Anfrage hingegen vom Pod, fehlt das Source Label (Zeile 10). Die Route führt dann automatisch zur Firewall (Zeile 12 bis 14).
Das Network Service Mesh umzusetzen, verlange keine großen Anpassungen an Kubernetes, argumentiert das Projekt. Dafür würden NSM-Nutzer verschiedene Vorteile mitnehmen. So sollen Tunnel und Netzwerkkontexte „Bürger erster Klasse” werden. NSM erlaubt heterogene Netzwerkkonfigurationen und kommt auch mit exotischen Protokollen zurecht. Zu den unterstützten Interfaces gehören die von Linux, Shared Memory Packet Interfaces (Memif) oder vHost-user. Als Payloads kommen unter anderem Ethernet- Frames, IP, Multiprotocol Label Switching (MPLS) oder L2TP zum Einsatz.
Verbindungen organisiert NSM dynamisch und nach Bedarf. Neue Verbindungen handeln ihre Eigenschaften selbstständig untereinander aus. Zudem lässt sich das aus dem SDN-Umfeld bekannte Service Function Chaining (SFC) auch mit NSM umsetzen: Wie das Beispiel aus Firewall und VPN-Gateway zeigt, verknüpft der Admin dabei mehrere Netzwerkfunktionen miteinander.

Fazit

Noch befindet sich das NSM-Projekt in einem frühen Stadium. Insofern müssen Interessierte abwarten, wie schnell es in der Lage sein wird, die eigenen Pläne in Software umzusetzen. Interessenten gibt es durchaus. Vor allem Cloud-Native- Entwicklern dürfte NSM gefallen, weil es den oft komplizierten Aufbau von spezielleren Netzwerkfunktionen vereinfacht. YAML-Dateien und die Struktur eines Service Mesh kennen sie von Kubernetes, daher passt das Network Service Mesh gut in den Kubernetes-Kontext.
Zugleich lässt es sich aber dank der externen Network Service Manager auch in Netzwerken einsetzen, die auf Open Stack basieren und virtuelle Maschinen einsetzen. Das ist zum Beispiel in der Telekommunikation häufig der Fall. Wie auf dem Open Networking Summit zu erfahren war[5] , ist gerade dort der Wunsch nach Container-basierten Netzwerkfunktionen groß: VNFs durch CNFs zu ersetzen, steht auf der Roadmap recht weit oben. Insofern kommt NSM für die Telcos nicht ungelegen.

Infos
[1] CNI-Einführung: [https://kubernetes.academy/lessons/an‑introduction‑to‑cni]
[2] NSM auf Github: [https://github.com/networkservicemesh/networkservicemesh]
[3] Network Service Mesh: [https://networkservicemesh.io]
[4] NFV: [https://en.wikipedia.org/wiki/Network_function_virtualization]
[5] ONS Europe 2019: Kristian Kißling, „Randphänomen”, LM 12/ 2019, S. 6, [https://www.linux‑magazin.de/43522]
[6] Projektpräsentation: [https://networkservicemesh.io/docs/concepts/narrative/]
[7] gRPC-Protokoll: [https://www.grpc.io]
[8] Weiteres Material zu NSM: [https://docs.google.com/document/d/1113nzdL‑DcDAWT3963IsS9LeekgXLTgGebxPO7ZnJaA/edit#]


© pixpack, 123RF

© Networkservicemesh.io

Networkservicemesh.io