Hallo, Habr! Ich präsentiere Ihnen eine Übersetzung des Artikels. „Service Mesh Datenebene vs. Steuerungsebene“ Autor Matt Klein.

In dieser Ausgabe habe ich das Bedürfnis verspürt, die Beschreibung beider Komponenten des Service Mesh – Datenebene und Steuerungsebene – zu übersetzen. Diese Beschreibung erschien mir am verständlichsten und interessantesten und führt vor allem zur Frage: „Ist es überhaupt notwendig?“.

Da die Idee des „Service Mesh“ in den letzten zwei Jahren zunehmend populär wird (der ursprüngliche Artikel stammt vom 10. Oktober 2017) und die Anzahl der Akteure in diesem Bereich gestiegen ist, habe ich ein entsprechendes Wachstum der Verwirrung innerhalb der gesamten technischen Gemeinschaft hinsichtlich des Vergleichs und der Gegenüberstellung verschiedener Lösungen beobachtet.

Die Situation lässt sich am besten mit den folgenden Tweets beschreiben, die ich im Juli geschrieben habe:

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

Die ersten sind einfach Datenebenen. An sich tun sie nichts. Sie müssen auf etwas Größeres konfiguriert werden. 2 /

Istio ist ein Beispiel für eine Steuerungsebene, die die Teile zusammenbindet. Es ist eine andere Schicht. / Ende

In den vorherigen Tweets werden mehrere verschiedene Projekte (Linkerd, NGINX, HAProxy, Envoy und Istio) erwähnt, aber was noch wichtiger ist, es werden grundlegende Konzepte der Datenebene, des Service Mesh und der Steuerungsebene eingeführt. In diesem Beitrag werde ich einen Schritt zurückgehen und erläutern, was ich unter den Begriffen „Datenebene“ und „Steuerungsebene“ auf sehr hohem Niveau verstehe, und dann erläutern, wie diese Begriffe sich auf die in den Tweets erwähnten Projekte beziehen.

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

Abb. 1: Überblick über das Service Mesh (Service mesh overview)

Abb. 1 veranschaulicht das Konzept des Service Mesh auf der grundlegendsten Ebene. Es gibt vier Servicecluster (A-D). Jede Instanz des Dienstes ist mit einem lokalen Proxy-Server verbunden. Der gesamte Netzwerkverkehr (HTTP, REST, gRPC, Redis usw.) einer einzelnen Anwendungsinstanz wird über den lokalen Proxy-Server zu den entsprechenden externen Serviceclustern geleitet. Somit kennt die Anwendungsinstanz nur ihren lokalen Proxy und nicht das gesamte Netzwerk. Tatsächlich wurde das Netzwerk des verteilten Systems von dem Dienst entfernt.

Datenebene (Data plane)

Im Service Mesh führt der lokal für die Anwendung eingestellte Proxy-Server folgende Aufgaben aus:

• Service Discovery. Welche Dienste/Services/Anwendungen stehen für Ihre Anwendung zur Verfügung?
• Health Checking. Sind die von der Service Discovery zurückgegebenen Service-Instanzen funktionsfähig und bereit, Netzwerktraffic zu empfangen? Dies kann sowohl aktive (z.B. Antwortprüfung/Healthcheck) als auch passive (z.B. durch Verwendung von 3 aufeinanderfolgenden 5xx-Fehlern als Indikator für einen ungesunden Zustand des Dienstes) Prüfungen der Funktionsfähigkeit umfassen.
• Routing. Nach dem Erhalt einer REST-Anfrage an "/foo", an welchen Service-Cluster sollte die Anfrage gesendet werden?
• Load Balancing. Nachdem während des Routings ein Service-Cluster ausgewählt wurde, an welche Service-Instanz sollte die Anfrage gesendet werden? Mit welcher Timeout-Dauer? Mit welchen Circuit-Breaking-Einstellungen? Sollte die Anfrage wiederholt werden, wenn sie fehlschlägt?
• Authentication and Authorization. Kann der aufrufende Dienst für eingehende Anfragen kryptografisch identifiziert/autorisiert werden, z.B. mit mTLS oder einem anderen Mechanismus? Wenn er identifiziert/autorisiert ist, darf er die angeforderte Operation (Endpoint) im Dienst aufrufen, oder sollte eine nicht authentifizierte Antwort zurückgegeben werden?
• Observability. Für jede Anfrage sollten detaillierte Statistiken, Protokolle und Daten zur verteilten Nachverfolgung generiert werden, damit die Betreiber den verteilten Datenfluss und die Debugging-Probleme im Falle ihrer Entstehung verstehen können.

Für alle oben genannten Punkte ist die Datenebene (data plane) im Servicenetzwerk (service mesh) verantwortlich. Im Wesentlichen ist der lokale Service-Proxy (Sidecar) die Datenebene (data plane). Mit anderen Worten, die Datenebene (data plane) ist verantwortlich für die bedingte Übertragung, das Routing und die Überwachung jedes Netzwerkpakets, das an den Dienst gesendet oder von diesem gesendet wird.

Die Steuerungsebene (The Control Plane)

Die Netzwerbabstraktion, die der lokale Proxy in der Datendre Ebene bereitstellt, ist faszinierend. Wie erfährt der Proxy jedoch tatsächlich vom Pfad „/foo“ zu Dienst B? Wie können die von Proxy-Anfragen gespeicherten Dienstentdeckungsdaten verwendet werden? Wie sind die Einstellungen für Lastverteilung, Zeitüberschreitungen, Circuit Breaking usw. konfiguriert? Wie wird eine Anwendung mit der Blue/Green-Methode oder dem schrittweisen Traffic-Shift-Ansatz bereitgestellt? Wer konfiguriert die Einstellungen für die systemweite Authentifizierung und Autorisierung?

All diese Punkte fallen in den Verantwortungsbereich der Steuerungsebene (control plane) des Service Mesh. Die Steuerungsebene (control plane) nimmt eine Reihe isolierter Proxies ohne Zustand und verwandelt sie in ein verteiltes System.Server Ich denke, der Grund, warum viele Technologen die Konzepte von Datenebene (data plane) und Steuerungsebene (control plane) verwirrend finden, liegt darin, dass die Datenebene vielen vertraut ist, während die Steuerungsebene fremd/unverständlich ist. Wir arbeiten schon lange mit physischen Netzwerkrouten und Switches. Wir verstehen, dass Pakete/Anfragen von Punkt A nach Punkt B gelangen müssen und welches Hardware- und Softwaremittel wir dafür verwenden können. Die neue Generation der Software-Proxies sind einfach moderne Versionen von Werkzeugen, die wir schon lange verwenden..

Abbildung 2: Die menschliche Steuerungsebene (Human control plane).

Allerdings verwenden wir schon lange Steuerungsebenen (control planes), auch wenn die meisten Netzwerkadministratoren diese Systemkomponente möglicherweise nicht mit einem technologischen Element in Verbindung bringen. Der Grund dafür ist einfach:

Die meisten der heutigen verwendeten Steuerungsebenen (control planes) sind… wir
in Abbildung 2..

Auf Abbildung 2 Hier wird das gezeigt, was ich die „Menschliche Steuerungsebene (Human control plane)“ nenne. In dieser Art der Bereitstellung, die immer noch sehr häufig vorkommt, erstellt der menschliche Operator, wahrscheinlich mürrisch, statische Konfigurationen – möglicherweise mit Hilfe von Skripten – und implementiert sie über einen speziellen Prozess auf allen Proxy-Servern. Dann beginnen die Proxys, diese Konfiguration zu verwenden und verarbeiten die Datenplane (data plane) mit den aktualisierten Einstellungen.

Abbildung 3: Erweiterte Steuerungsebene des Servicenetzes (Advanced service mesh control plane)

Auf Abbildung 3 zeigt die ‚erweiterte‘ Steuerungsebene (control plane) des Servicenetzes (service mesh). Sie besteht aus den folgenden Teilen:

• Der Mensch (The human): Es gibt immer noch einen Menschen (hoffentlich weniger verärgert), der hochrangige Entscheidungen über das Gesamtsystem trifft.
• Benutzeroberfläche der Steuerungsebene (Control plane UI): Der Mensch interagiert mit einer Art von Benutzeroberfläche zur Verwaltung des Systems. Dies kann ein Webportal, eine Befehlszeilenanwendung (CLI) oder eine andere Schnittstelle sein. Über die Benutzeroberfläche hat der Operator Zugriff auf globale Systemkonfigurationsparameter wie:
  • Bereitstellungsmanagement, blau/grün (blue/green) und/oder schrittweise Übertragung des Datenverkehrs
  • Authentifizierungs- und Autorisierungsparameter
  • Routing-Tabellenspezifikationen, z.B. was passiert, wenn Anwendung A Informationen zu „/foo“ anfordert
  • Einstellungen des Lastenausgleichs, z.B. Zeitüberschreitungen (timeouts), Wiederholungsversuche (retries), circuit breaking Parameter usw.
• Arbeitslastplaner (Workload scheduler): Dienste werden über ein Planung/Orchestrierungssystem eines bestimmten Typs, z.B. Kubernetes oder Nomad, in der Infrastruktur gestartet. Der Planer ist verantwortlich für die Bereitstellung des Dienstes zusammen mit seinem lokalen Proxy-Server.
• Dienstentdeckung (Service discovery). Wenn der Planer Instanzen des Dienstes startet und stoppt, reportiert er den Betriebsstatus an das Dienstentdeckungssystem.
• APIs zur Konfiguration des lokalen Proxy-Servers (Sidecar proxy configuration APIs) : Lokale Proxy-Server ziehen dynamisch den Status aus verschiedenen Komponenten des Systems nach dem Modell der „eventuell konsistenten“ (eventually consistent) Architektur ohne das Eingreifen eines Operators. Das gesamte System, das aus allen derzeit laufenden Instanzen von Diensten und lokalen Proxy-Servern besteht, konvergiert letztendlich zu einem Ecosystem. Die API der universellen Datenebene (data plane) in Envoy ist ein Beispiel dafür, wie dies in der Praxis funktioniert.

Im Wesentlichen besteht das Ziel der Steuerungsebene (control plane) darin, eine Richtlinie festzulegen, die letztendlich von der Datenebene (data plane) übernommen wird. Fortgeschrittenere Steuerungsebenen (control planes) entziehen dem Operator mehr Details bestimmter Systeme und erfordern weniger manuelle Eingriffe, vorausgesetzt, sie funktionieren korrekt!.

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

• Datenebene des Service Mesh (Service mesh data plane): betrifft jedes Paket / jede Anfrage im System. Verantwortlich für die Entdeckung von Anwendungen / Diensten, die Überprüfung der Verfügbarkeit, das Routing, die Lastverteilung, die Authentifizierung / Autorisierung und die Beobachtbarkeit.
• Steuerungsebene des Service Mesh (Service mesh control plane): stellt Richtlinien und Konfigurationen für alle aktiven Datenebenen innerhalb des Service Mesh bereit. Beeinflusst 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 verstanden haben, lassen Sie uns einen Blick auf den aktuellen Stand des Projekts „Service Mesh“ werfen.

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

Anstatt eine tiefgehende Analyse jeder der oben genannten Lösungen durchzuführen, möchte ich kurz auf einige Punkte eingehen, die meiner Meinung nach den Großteil der Verwirrung im Ökosystem gerade jetzt auslösen.

Zu Beginn des Jahres 2016 war Linkerd einer der ersten Proxy-Server für die Datenebene (data plane) in einem Service-Mesh und hat hervorragende Arbeit geleistet, um das Bewusstsein und das Interesse an dem Designmodell „Service-Mesh“ zu steigern. Etwa sechs Monate später schloss sich Envoy Linkerd an (obwohl es bereits seit Ende 2015 bei Lyft tätig war). Linkerd und Envoy sind zwei Projekte, die oft in Gesprächen über Service-Meshs erwähnt werden.

Istio wurde im Mai 2017 angekündigt. Die Ziele des Istio-Projekts ähneln stark der erweiterten Steuerungsebene (control plane), die angezeigt wird. Abbildung 3Envoy ist der standardmäßige Proxy für Istio. So stellt Istio die Steuerungsebene (control plane) dar, während Envoy die Datenebene (data plane) bildet. In kurzer Zeit hat Istio für großes Aufsehen gesorgt, und andere Datenebenen (data plane) begannen ihre Integration als Ersatz für Envoy (sowohl Linkerd als auch NGINX haben die Integration mit Istio demonstriert). Die Tatsache, dass in einer Steuerungsebene (control plane) verschiedene Datenebenen (data plane) verwendet werden können, bedeutet, dass Steuerungsebene (control plane) und Datenebene (data plane) nicht unbedingt eng miteinander verbunden sind. Eine API, wie die universelle API der Datenebene (data plane), kann eine Brücke zwischen den beiden Teilen des Systems bilden.

Nelson und SmartStack helfen, die Trennung zwischen Steuerungsebene (control plane) und Datenebene (data plane) weiter zu veranschaulichen. Nelson verwendet Envoy als seinen Proxy und baut eine zuverlässige Steuerungsebene (control plane) für das Service-Mesh auf der Basis des HashiCorp-Stacks auf, d.h. Nomad usw. SmartStack war vielleicht das erste aus der neuen Welle von Service-Meshs. SmartStack bildet eine Steuerungsebene (control plane) rund um HAProxy oder NGINX und zeigt die Möglichkeit der Entkopplung der Steuerungsebene (control plane) vom Service-Mesh und der Datenebene (data plane) auf.

Mikroservice-Architekturen mit Service Mesh ziehen immer mehr Aufmerksamkeit auf sich (zu Recht!), und immer mehr Projekte und Anbieter beginnen, in diesem Bereich zu arbeiten. In den nächsten Jahren werden wir viele Innovationen sowohl im Daten- (data plane) als auch im Steuerungsbereich (control plane) sehen, sowie eine weitere Vermischung verschiedener Komponenten. Letztendlich sollte die Mikroservice-Architektur transparenter und magischer (?) für den Operator werden.
Ich hoffe, immer weniger irritiert zu sein.

Wichtige Punkte (Key takeaways)

• Ein Service Mesh besteht aus zwei verschiedenen Teilen: der Datenebene (data plane) und der Steuerungsebene (control plane). Beide Komponenten sind unerlässlich, ohne sie wird das System nicht funktionieren.
• Alle sind mit der Steuerungsebene (control plane) vertraut, und im Moment könnte es auch Ihre Steuerungsebene (control plane) sein!
• Alle Datenebenen (data plane) konkurrieren in Bezug auf Funktionen, Leistung, Konfigurierbarkeit und Erweiterbarkeit.
• Alle Steuerungsebenen (control plane) konkurrieren in Bezug auf Funktionen, Konfigurierbarkeit, Erweiterbarkeit und Benutzerfreundlichkeit.
• Eine Steuerungsebene (control plane) kann die richtigen Abstraktionen und APIs enthalten, um mehrere Datenebenen (data plane) nutzen zu können.

Quelle: habr.com