© pixpack, 123RF

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

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].

Das ist kein Wunder, steckt die Flexibilität von Kubernetes doch vor allem im Bereich der Applikationen. Bei Application Service Meshes wie Istio lassen sich die OSI-Schichten 4 (auf Ebene der TCP-Streams und UDP-Datagramme) und 7 (HTTP/Anwendungsprotokolle) umfassend konfigurieren. Auf das darunterliegende Layer-2- und Layer-3-Netzwerk (die Ebenen von Frames und IP-Paketen) trifft das hingegen 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 im Beispiel einer Userin namens Sarah gehört) soll Zugriff auf ein Firmen-VPN erhalten (Abbildung 1). Daher fordert der Pod einen Network Service an.

Abbildung 1: Um die grundlegende Funktionsweise eines Network Service Mesh zu erklären, hat das Projekt eine gut gemachte Präsentation entwickelt. Darin versucht Nutzerin Sarah, ihren Pod mit einem Unternehmens-VPN zu verbinden. Quelle: Networkservicemesh.io

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.

kind: NetworkService
apiVersion: V1
metadata:
  name: secure-intranet-connectivity
spec:
  payload: IP
[...]

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«). Auf diese Weise findet der Pod das Gateway.

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 Punkt-zu-Punkt-Verbindung her. Wichtig zu wissen: Alle Verbindungen im Network Service Mesh bauen auf solchen Punkt-zu-Punkt-Verbindungen auf.

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. Quelle: Networkservicemesh.io

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 VPN-Gateway-Pod auf.

Solche Verbindungen planen die NSM-Entwickler 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 oder Admin schließlich neue Network Service Endpoints ergänzen oder sich generell einen Überblick über sämtliche in einem 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).

Firewall ergänzen

Aber zurück zum anfänglichen Beispiel. Will die Firma zwischen Client-Pod und VPN-Gateway noch einen Firewall-Pod schalten, stellt auch das dank der Label kein größeres Hindernis dar. Der Firewall-Pod leitet alle eingehenden Anfragen automatisch an den VPN-Gateway-Pod weiter.

Sein Destination Label heißt dann 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).

[...]
matches:
-  match:
   sourceSelector:
     app:firewall
route:
-  destination:
   destinationSelector:
     app:vpn-gateway
match:
  route
  -  destination:
     destinationSelector:
       app:firewall

Die Anpassungen an Kubernetes, um das Network Service Mesh umzusetzen, seien nicht groß, argumentiert das Projekt. Dafür würden die 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. Ein Interesse scheint es aber zu geben. 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 sich das Network Service Mesh gut in den Kubernetes-Kontext ein.

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.