Hallo, Habr! Ich präsentiere Ihnen die Übersetzung des Artikels «Service Mesh Datenebene vs. Steuerungsebene» Autor Matt Klein.

Diesmal habe ich eine Beschreibung beider Komponenten des Service Mesh, der Datenebene und der Steuerungsebene, übersetzt. Diese Beschreibung schien mir am verständlichsten und interessantesten zu sein und führt außerdem zur Frage: „Brauchen wir das eigentlich?“

Da die Idee des «Service Mesh» in den letzten zwei Jahren zunehmend populär geworden ist (ursprünglicher Artikel vom 10. Oktober 2017) und die Anzahl der Akteure in diesem Bereich gestiegen ist, habe ich ein entsprechendes Wachstum der Verwirrung innerhalb der technischen Community festgestellt, wie man verschiedene Lösungen vergleichen und gegenüberstellen kann.

Die Situation lässt sich am besten durch die folgenden Tweet-Reihen beschreiben, die ich im Juli verfasst habe:

Verwirrung über Service Mesh Nr. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Keiner von ihnen ist Istio gleich. Istio ist etwas ganz anderes. 1 /

Die ersten sind einfach Datenebenen. Sie tun für sich genommen nichts. Sie müssen für etwas Größeres konfiguriert werden. 2 /

Istio ist ein Beispiel für eine Steuerungsebene, die die Teile zusammenführt. Das ist eine andere Schicht. / Ende

In früheren Tweets werden mehrere verschiedene Projekte erwähnt (Linkerd, NGINX, HAProxy, Envoy und Istio), aber wichtiger ist, dass grundlegende Konzepte wie die Datenebene (data plane), das Service Mesh und die Steuerungsebene (control plane) eingeführt werden. In diesem Beitrag werde ich einen Schritt zurückgehen und erklären, was ich unter den Begriffen „Datenebene (data plane)“ und „Steuerungsebene (control plane)“ auf einem sehr hohen Niveau verstehe und wie diese Begriffe mit den in den Tweets erwähnten Projekten zusammenhängen.

Was ist ein Service Mesh (What is a service mesh, really)?

Abbildung 1: Übersicht über das Service Mesh (Service mesh overview)

Abbildung 1 veranschaulicht das Konzept des Service Mesh auf der grundlegendsten Ebene. Es gibt vier Service-Clustern (A-D). Jede Instanz des Services ist mit einem lokalen Proxy-Server verbunden. Der gesamte Netzwerkverkehr (HTTP, REST, gRPC, Redis usw.) von einer einzelnen Instanz der Anwendung wird über den lokalen Proxy-Server zu den entsprechenden externen Service-Clustern geleitet. Dadurch weiß die Instanz der Anwendung nichts über das Netzwerk als Ganzes und kennt nur ihren lokalen Proxy. Tatsächlich wurde das Netzwerk des verteilten Systems vom Service entfernt.

Datenebene (Data plane)

In einem Service-Mesh übernimmt ein lokal für die Anwendung eingesetzter Proxy-Server folgende Aufgaben:

• Service-Erkennung (Service discovery). Welche Dienste/Services/Anwendungen stehen Ihrer Anwendung zur Verfügung?
• Prüfung der Verfügbarkeit (Health checking). Sind die von der Service-Erkennung zurückgegebenen Instanzen der Dienste verfügbar und bereit, Netzwerkverkehr zu empfangen? Dies kann sowohl aktive (z. B. Antwortüberprüfung / Healthcheck) als auch passive (z. B. durch die Verwendung von 3 aufeinanderfolgenden 5xx-Fehlern als Indikator für einen ungesunden Zustand des Dienstes) Überprüfungen umfassen.
• Routing. Bei einer REST-Anforderung an den Dienst "/foo", an welchen Service-Cluster sollte die Anfrage gesendet werden?
• Lastverteilung (Load balancing). Nachdem während des Routings der Service-Cluster ausgewählt wurde, an welche Instanz des Dienstes soll die Anfrage gesendet werden? Mit welchem Timeout? Mit welchen Einstellungen für Circuit-Breaking? Soll die Anfrage wiederholt werden, wenn sie fehlschlägt?
• Authentifizierung und Autorisierung (Authentication and authorization). Kann der aufrufende Dienst für eingehende Anfragen kryptografisch identifiziert/autorisiert werden, beispielsweise mit mTLS oder einem anderen Mechanismus? Wenn er identifiziert/autorisiert ist, darf er dann den angeforderten Vorgang (Endpoint) im Dienst aufrufen, oder muss eine nicht authentifizierte Antwort zurückgegeben werden?
• Beobachtbarkeit (Observability). Für jede Anfrage müssen detaillierte Statistiken, Protokolle (Logs) und Daten zur verteilten Trace-Analyse generiert werden, damit die Betreiber den verteilten Datenverkehr und aufkommende Debugging-Probleme verstehen können.

Für alle vorangegangenen Punkte in der Dienstnetzwerk (Service Mesh) ist die Datenebene (Data Plane) verantwortlich. Im Wesentlichen ist der lokale Proxy für den Dienst (Sidecar) die Datenebene (Data Plane). Mit anderen Worten, die Datenebene (Data Plane) ist dafür zuständig, jedes Netzwerkpaket, das an den Dienst gesendet wird oder von ihm gesendet wird, bedingt zu translatieren, weiterzuleiten und zu überwachen.

Die Steuerungsebene (Control Plane)

Die Netzwerkabstraktion, die durch einen lokalen Proxy im Datenbereich (data plane) bereitgestellt wird, ist bemerkenswert. Wie erfährt der Proxy jedoch tatsächlich vom Pfad „/foo“ zum Dienst B? Wie können die Service-Discovery-Daten, die durch Proxy-Anfragen gefüllt werden, genutzt werden? Wie sind die Parameter für Lastverteilung, Timeouts, Circuit Breaking usw. konfiguriert? Wie wird die Anwendung unter Verwendung der blauen/grünen (blue/green) Methode oder der schrittweisen Traffic-Umleitung bereitgestellt? Wer konfiguriert die Parameter der allgemeinen Systemauthentifizierung und -autorisierung?

All diese Punkte liegen in der Verantwortung der Steuerungsebene (control plane) des Servicenetzwerks (service mesh). Die Steuerungsebene (control plane) nimmt eine Reihe von isolierten ProxysServer ohne Zustand und verwandelt sie in ein verteiltes System..

Ich denke, der Grund, warum viele Technologen die Konzepte der Datenebene und der Steuerungsebene oft als verwirrend empfinden, liegt darin, dass die Datenebene den meisten vertraut ist, während die Steuerungsebene fremd oder unverständlich wirkt. Wir arbeiten schon lange mit physischen Netzwerkroutern und Switches. Wir wissen, dass Pakete und Anfragen von Punkt A nach Punkt B gelangen müssen und dass wir dafür Hardware und Software einsetzen können. Die neue Generation von Software-Proxys sind einfach moderne Versionen der Tools, die wir schon seit langer Zeit nutzen.

Abbildung 2: Menschliche Steuerungsebene (Human control plane)

Wir haben jedoch schon seit langem Steuerungsebenen genutzt, obwohl die meisten Netzwerkbetreiber diesen Teil des Systems möglicherweise nicht mit einem technologischen Element verknüpfen. Der Grund ist einfach:
Die meisten heute verwendeten Steuerungsebenen sind… wir.

Auf in Abbildung 2 Hier sehen Sie, was ich als «Human Control Plane» bezeichne. In dieser Art der Implementierung, die nach wie vor sehr häufig vorkommt, erstellt ein menschlicher Operator, der möglicherweise etwas grimmig ist, statische Konfigurationen — möglicherweise mit Hilfe von Skripten — und implementiert sie mithilfe eines speziellen Prozesses auf allen Proxy-Servern. Diese Proxys beginnen dann, diese Konfiguration zu verwenden und verarbeiten die Datenebene (Data Plane) mit den aktualisierten Einstellungen.

Abbildung 3: Erweiterte Steuerungsebene des Service-Netzwerks (Advanced Service Mesh Control Plane)

Auf Abbildung 3 zeigt die «erweiterte» Steuerungsebene (Control Plane) des Service-Netzwerks (Service Mesh). Sie besteht aus folgenden Komponenten:

• Der Mensch (The Human): Es gibt immer noch einen Menschen (hoffentlich weniger verärgert), der auf hohem Niveau Entscheidungen über das gesamte System trifft.
• Benutzeroberfläche der Steuerungsebene (Control Plane UI): Eine Person interagiert mit einer Art von Benutzeroberfläche zur Verwaltung des Systems. Dies kann ein Webportal, eine Kommandozeilenanwendung (CLI) oder eine andere Schnittstelle sein. Über die Benutzeroberfläche hat der Betreiber Zugriff auf globale Systemkonfigurationsparameter wie:
  • Bereitstellungsmanagement, Blue/Green (blau/grün) und/oder schrittweise Verkehrsumschaltung
  • Authentifizierungs- und Autorisierungsoptionen
  • Routing-Tabellenspezifikationen, zum Beispiel was passiert, wenn Anwendung A Informationen über „/foo“ anfordert
  • Einstellungen des Lastenausgleichs, wie Zeitüberschreitungen (timeouts), Wiederholungsversuche (retries), Circuit-Breaking-Optionen usw.
• Lastenverteilungsplaner (Workload scheduler): Dienste werden in der Infrastruktur über ein Planungs-/Orchestrierungssystem eines bestimmten Typs gestartet, z.B. Kubernetes oder Nomad. Der Planer ist dafür verantwortlich, den Dienst zusammen mit seinem lokalen Proxy-Server zu laden.
• Serviceentdeckung (Service discovery). Wenn der Scheduler Instanzen des Dienstes startet und stoppt, meldet er den Betriebszustand an das Servicediscovery-System.
• API zur Konfiguration des lokalen Proxy-Servers (Sidecar-Proxy-Konfigurations-APIs) : Lokale Proxy-Server ziehen dynamisch den Zustand aus verschiedenen Komponenten des Systems im Rahmen eines „letztlich konsistenten“ Modells (eventually consistent) ohne das Eingreifen des Operators. Das gesamte System, bestehend aus allen aktuell laufenden Dienstinstanzen und lokalen Proxy-Servern, konvergiert letztendlich zu einem einzigen Ökosystem. Die API der universellen Datenebene (data plane) in Envoy ist ein Beispiel dafür, wie das in der Praxis funktioniert.

Im Grunde besteht das Ziel der Steuerungsebene (control plane) darin, eine Richtlinie festzulegen, die schließlich von der Datenebene (data plane) übernommen wird. Fortschrittlichere Steuerungsebenen (control plane) befreien den Operator von mehr Details bestimmter Systeme und erfordern weniger manuelle Eingriffe, vorausgesetzt, sie funktionieren ordnungsgemäß!...

Datenebene und Steuerungsebene. Zusammenfassung (Data plane vs. control plane summary)

• Datenebene des Servicenetzwerks (Service mesh data plane): betrifft jedes Paket / jede Anfrage im System. Verantwortlich für das Erkennen von Anwendungen/Diensten, die Überprüfung der Funktionsfähigkeit, die Weiterleitung, die Lastverteilung, die Authentifizierung / Autorisierung und die Überwachung.
• Steuerungsebene des Service-Netzwerks (Service Mesh Control Plane): stellt Richtlinien und Konfigurationen für alle aktiven Datenebenen innerhalb des Service-Netzwerks bereit. Berührt keine Pakete / Anfragen im System. Die Steuerungsebene verwandelt alle Datenebenen in ein verteiltes System.

Aktueller Stand des Projekts (Current Project Landscape)

Nachdem wir die obige Erklärung durchgegangen sind, werfen wir einen Blick auf den aktuellen Stand des Projekts „Service Mesh“.

• Datenebenen (Data Planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
• Steuerungsebenen (Control Planes): Istio, Nelson, SmartStack

Anstatt eine tiefgreifende Analyse jeder der oben genannten Lösungen durchzuführen, möchte ich einige Aspekte kurz ansprechen, die meiner Meinung nach zur Verwirrung in der aktuellen Ecosystem beitragen.

Anfang 2016 war Linkerd einer der ersten Proxy-Server für die Datenebene in einem Service Mesh und hat hervorragende Arbeit geleistet, um das Bewusstsein für das Designmodell "Service Mesh" zu steigern. Etwa sechs Monate später kam Envoy zu Linkerd, obwohl es bereits seit Ende 2015 bei Lyft tätig war. Linkerd und Envoy sind die beiden Projekte, die am häufigsten in Diskussionen über Service Meshes erwähnt werden.

Istio wurde im Mai 2017 angekündigt. Die Ziele des Istio-Projekts ähneln stark einer erweiterten Steuerungsebene, die auf Abbildung 3. Envoy für Istio fungiert als Standard-Proxy-Server. Somit stellt Istio die Steuerungsebene (Control Plane) dar, während Envoy die Datenebene (Data Plane) repräsentiert. In kurzer Zeit sorgte Istio für viel Aufsehen, und andere Dateneebenen (Data Plane) haben begonnen, Integrationen als Alternativen zu Envoy aufzubauen (sowohl Linkerd als auch NGINX haben Integrationen mit Istio demonstriert). Die Tatsache, dass in einer Steuerungsebene (Control Plane) verschiedene Datenebenen (Data Plane) verwendet werden können, zeigt, dass die Steuerungsebene (Control Plane) und die Datenebene (Data Plane) nicht unbedingt eng verbunden sind. Eine API wie die universelle API der Datenebene (Data Plane) von Envoy kann eine Brücke zwischen den beiden Teilen des Systems schlagen.

Nelson und SmartStack veranschaulichen zusätzlich die Trennung zwischen der Steuerungsebene (Control Plane) und der Datenebene (Data Plane). Nelson nutzt Envoy als Proxy und baut eine zuverlässige Steuerungsebene für das Service-Mesh auf, basierend auf dem HashiCorp-Stack, d.h. Nomad usw. SmartStack gilt als einer der Pioniere der neuen Generation von Service-Meshes. SmartStack formt die Steuerungsebene um HAProxy oder NGINX und demonstriert die Möglichkeit, die Steuerungsebene des Service-Mesh von der Datenebene zu entkoppeln.

Die Mikroservice-Architektur mit Service-Mesh gewinnt zunehmend an Bedeutung (zu Recht!), und immer mehr Projekte und Anbieter beginnen, in diesem Bereich aktiv zu werden. In den nächsten Jahren werden wir viele Innovationen sowohl in den Datenebenen als auch in den Steuerungsebenen sowie eine weitere Vermischung verschiedener Komponenten erleben. Letztendlich soll die Mikroservice-Architektur für den Betreiber transparenter und magischer (?) werden.
Ich hoffe, dass es immer weniger irritiert.

Wichtige Erkenntnisse

• Das Service-Mesh besteht aus zwei verschiedenen Teilen: der Datenebene (data plane) und der Steuerebene (control plane). Beide Komponenten sind erforderlich, und ohne sie wird das System nicht funktionieren.
• Alle sind mit der Steuerebene (control plane) vertraut, und im Moment können Sie die Steuerebene (control plane) sein!
• Alle Datenebenen (data plane) konkurrieren untereinander in Bezug auf Funktionen, Leistung, Konfigurierbarkeit und Erweiterbarkeit.
• Alle Steuerebenen (control plane) konkurrieren untereinander hinsichtlich Funktionen, Konfigurierbarkeit, Erweiterbarkeit und Benutzerfreundlichkeit.
• Eine Steuerebene (control plane) kann die richtigen Abstraktionen und APIs enthalten, um mehrere Datenebenen (data plane) nutzen zu können.

Quelle: habr.com