Hey Habr! Ich präsentiere Ihnen die Übersetzung des Artikels „Service-Mesh-Datenebene vs. Kontrollebene“ Autor Matthias Klein.

Dieses Mal „wollte und übersetzte“ ich die Beschreibung beider Service-Mesh-Komponenten, der Datenebene und der Kontrollebene. Diese Beschreibung erschien mir am verständlichsten und interessantesten und führte vor allem zu der Frage: „Ist es überhaupt notwendig?“

Da die Idee eines „Service Mesh“ in den letzten zwei Jahren immer beliebter wurde (Originalartikel vom 10. Oktober 2017) und die Anzahl der Teilnehmer im Raum zunahm, habe ich eine entsprechende Zunahme der Verwirrung im Gesamten beobachtet Tech-Community darüber, wie man verschiedene Lösungen vergleicht und gegenüberstellt.

Die Situation lässt sich am besten durch die folgende Reihe von Tweets zusammenfassen, die ich im Juli geschrieben habe:

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

Die ersten sind einfach Datenebenen. Allein machen sie nichts. Sie müssen Lust auf mehr haben. 2/

Istio ist ein Beispiel für eine Steuerungsebene, die die Teile miteinander verbindet. Das ist eine weitere Ebene. /Ende

Die vorherigen Tweets erwähnen mehrere verschiedene Projekte (Linkerd, NGINX, HAProxy, Envoy und Istio), stellen aber vor allem die allgemeinen Konzepte von Datenebene, Service Mesh und Kontrollebene vor. In diesem Beitrag werde ich einen Schritt zurücktreten und auf einer sehr hohen Ebene darüber sprechen, was ich unter den Begriffen „Datenebene“ und „Kontrollebene“ verstehe, und dann darüber sprechen, wie die Begriffe auf die in Tweets erwähnten Projekte anwendbar sind.

Was ist eigentlich ein Service Mesh?

Abbildung 1: Service-Mesh-Übersicht

Abbildung 1 veranschaulicht das Konzept eines Service Mesh auf seiner grundlegendsten Ebene. Es gibt vier Service-Cluster (AD). Jede Dienstinstanz ist einem lokalen Proxyserver zugeordnet. Der gesamte Netzwerkverkehr (HTTP, REST, gRPC, Redis usw.) von einer einzelnen Anwendungsinstanz wird über einen lokalen Proxy an die entsprechenden externen Service-Cluster weitergeleitet. Auf diese Weise kennt die Anwendungsinstanz das Netzwerk als Ganzes nicht, sondern nur ihren lokalen Proxy. Tatsächlich wurde das verteilte Systemnetzwerk aus dem Dienst entfernt.

Datenebene

In einem Service Mesh führt ein lokal für die Anwendung befindlicher Proxyserver folgende Aufgaben aus:

• Diensterkennung. Welche Dienste/Anwendungen stehen für Ihre Anwendung zur Verfügung?
• Gesundheitsprüfung. Sind die von Service Discovery zurückgegebenen Dienstinstanzen fehlerfrei und bereit, Netzwerkverkehr zu akzeptieren? Dies kann sowohl aktive (z. B. Antwort/Gesundheitsprüfung) als auch passive (z. B. Verwendung von drei aufeinanderfolgenden 3xx-Fehlern als Hinweis auf einen fehlerhaften Dienstzustand) Gesundheitsprüfungen umfassen.
• Routing. An welchen Service-Cluster soll die Anfrage gesendet werden, wenn Sie eine Anfrage an „/foo“ von einem REST-Dienst erhalten?
• Lastverteilung. An welche Dienstinstanz soll die Anfrage gesendet werden, nachdem während des Routings ein Dienstcluster ausgewählt wurde? Mit welchem ​​Timeout? Mit welchen Schaltkreisunterbrechungseinstellungen? Wenn die Anfrage fehlschlägt, sollte sie erneut versucht werden?
• Authentifizierung und Autorisierung. Kann der aufrufende Dienst bei eingehenden Anfragen mithilfe von mTLS oder einem anderen Mechanismus kryptografisch identifiziert/autorisiert werden? Wenn es erkannt/autorisiert wird, darf es den angeforderten Vorgang (Endpunkt) für den Dienst aufrufen oder sollte eine nicht authentifizierte Antwort zurückgegeben werden?
• Beobachtbarkeit. Für jede Anfrage sollten detaillierte Statistiken, Protokolle/Protokolle und verteilte Ablaufverfolgungsdaten generiert werden, damit Betreiber den verteilten Datenverkehrsfluss und auftretende Debugging-Probleme nachvollziehen können.

Die Datenebene ist für alle vorherigen Punkte im Service Mesh verantwortlich. Tatsächlich ist der für den Dienst lokale Proxy (Sidecar) die Datenebene. Mit anderen Worten: Die Datenebene ist für die bedingte Übertragung, Weiterleitung und Überwachung jedes Netzwerkpakets verantwortlich, das an oder von einem Dienst gesendet wird.

Die Kontrollebene

Die Netzwerkabstraktion, die ein lokaler Proxy auf der Datenebene bietet, ist magisch(?). Doch woher weiß der Proxy eigentlich von der „/foo“-Route zu Dienst B? Wie können die durch Proxy-Anfragen gefüllten Service-Discovery-Daten verwendet werden? Wie werden die Parameter für Lastausgleich, Timeout, Stromkreisunterbrechung usw. konfiguriert? Wie stellen Sie eine Anwendung mit der Blau/Grün-Methode oder der Graceful Traffic Transition-Methode bereit? Wer konfiguriert systemweite Authentifizierungs- und Autorisierungseinstellungen?

Alle oben genannten Elemente stehen unter der Kontrolle der Steuerungsebene des Service-Mesh. Die Kontrollebene nimmt eine Reihe isolierter zustandsloser Proxys und verwandelt sie in ein verteiltes System.

Ich denke, der Grund, warum viele Technologen die getrennten Konzepte von Datenebene und Kontrollebene für verwirrend halten, liegt darin, dass den meisten Menschen die Datenebene bekannt ist, während die Kontrollebene fremd/unverstanden ist. Wir arbeiten schon lange mit physischen Netzwerk-Routern und -Switches. Wir verstehen, dass Pakete/Anfragen von Punkt A nach Punkt B gelangen müssen und dass wir hierfür Hardware und Software verwenden können. Bei der neuen Generation von Software-Proxys handelt es sich einfach um schicke Versionen der Tools, die wir schon lange verwenden.

Abbildung 2: Menschliche Kontrollebene

Allerdings nutzen wir schon seit langem Control Planes, auch wenn die meisten Netzbetreiber diesen Teil des Systems möglicherweise keiner Technologiekomponente zuordnen. Der Grund ist einfach:
Die meisten heute verwendeten Kontrollflugzeuge sind... wir.

Auf Abbildung 2 zeigt, was ich die „menschliche Kontrollebene“ nenne. Bei dieser Art der Bereitstellung, die immer noch sehr verbreitet ist, erstellt ein wahrscheinlich mürrischer menschlicher Bediener statische Konfigurationen – möglicherweise über Skripte – und stellt sie über einen speziellen Prozess auf allen Proxys bereit. Die Proxys beginnen dann mit der Verwendung dieser Konfiguration und beginnen mit der Verarbeitung der Datenebene mit den aktualisierten Einstellungen.

Abbildung 3: Erweiterte Service-Mesh-Steuerungsebene

Auf Abbildung 3 zeigt die „erweiterte“ Kontrollebene des Service Mesh. Es besteht aus folgenden Teilen:

• Der Mensch: Es gibt immer noch eine Person (hoffentlich weniger wütend), die Entscheidungen auf hoher Ebene über das gesamte System als Ganzes trifft.
• Benutzeroberfläche der Steuerungsebene: Eine Person interagiert mit einer Art Benutzeroberfläche, um das System zu steuern. Dies kann ein Webportal, eine Befehlszeilenanwendung (CLI) oder eine andere Schnittstelle sein. Über die Benutzeroberfläche hat der Bediener Zugriff auf globale Systemkonfigurationsparameter wie:
  • Bereitstellungskontrolle, Blau/Grün und/oder allmählicher Verkehrsübergang
  • Authentifizierungs- und Autorisierungsoptionen
  • Routing-Tabellenspezifikationen, beispielsweise wenn Anwendung A Informationen darüber anfordert, was mit „/foo“ passiert
  • Load-Balancer-Einstellungen, z. B. Zeitüberschreitungen, Wiederholungsversuche, Stromkreisunterbrechungseinstellungen usw.
• Workload-Planer: Dienste werden auf der Infrastruktur über eine Art Planungs-/Orchestrierungssystem wie Kubernetes oder Nomad ausgeführt. Der Scheduler ist für das Laden des Dienstes zusammen mit seinem lokalen Proxy verantwortlich.
• Diensterkennung. Wenn der Scheduler Dienstinstanzen startet und stoppt, meldet er den Integritätsstatus an das Diensterkennungssystem.
• Sidecar-Proxy-Konfigurations-APIs : Lokale Proxys extrahieren dynamisch den Status verschiedener Systemkomponenten mithilfe eines letztendlich konsistenten Modells ohne Eingriff des Bedieners. Das gesamte System, bestehend aus allen aktuell laufenden Service-Instanzen und lokalen Proxy-Servern, konvergiert letztendlich zu einem Ökosystem. Die universelle Datenebene-API von Envoy ist ein Beispiel dafür, wie dies in der Praxis funktioniert.

Der Zweck der Kontrollebene besteht im Wesentlichen darin, die Richtlinie festzulegen, die letztendlich von der Datenebene akzeptiert wird. Fortgeschrittenere Steuerungsebenen nehmen dem Bediener mehr Teile einiger Systeme ab und erfordern weniger manuelle Bedienung, vorausgesetzt, sie funktionieren richtig!...

Datenebene und Steuerebene. Zusammenfassung der Datenebene vs. Kontrollebene

• Service-Mesh-Datenebene: Betrifft jedes Paket/jede Anfrage im System. Verantwortlich für Anwendungs-/Diensterkennung, Gesundheitsprüfung, Routing, Lastausgleich, Authentifizierung/Autorisierung und Beobachtbarkeit.
• Service-Mesh-Steuerungsebene: Stellt Richtlinien und Konfiguration für alle laufenden Datenebenen innerhalb des Servicenetzwerks bereit. Berührt keine Pakete/Anfragen auf dem System. Die Kontrollebene verwandelt alle Datenebenen in ein verteiltes System.

Aktuelle Projektlandschaft

Nachdem wir die obige Erklärung verstanden haben, werfen wir einen Blick auf den aktuellen Stand des Service-Mesh-Projekts.

• Datenebenen: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Kontrollflugzeuge: Istio, Nelson, SmartStack

Anstatt auf eine eingehende Analyse jeder der oben genannten Lösungen einzugehen, werde ich kurz auf einige der Punkte eingehen, die meiner Meinung nach derzeit für einen Großteil der Verwirrung im Ökosystem sorgen.

Linkerd war Anfang 2016 einer der ersten Data-Plane-Proxyserver für das Service Mesh und hat hervorragende Arbeit geleistet, um das Bewusstsein und die Aufmerksamkeit für das Service Mesh-Designmodell zu schärfen. Ungefähr sechs Monate später kam Envoy zu Linkerd (obwohl er seit Ende 6 bei Lyft war). Linkerd und Envoy sind die beiden Projekte, die am häufigsten erwähnt werden, wenn es um Service Meshes geht.

Istio wurde im Mai 2017 angekündigt. Die Ziele des Istio-Projekts sind der in gezeigten erweiterten Steuerungsebene sehr ähnlich Abbildung 3. Envoy für Istio ist der Standard-Proxy. Somit ist Istio die Kontrollebene und Envoy die Datenebene. In kurzer Zeit sorgte Istio für großes Aufsehen und andere Datenebenen begannen mit der Integration als Ersatz für Envoy (sowohl Linkerd als auch NGINX demonstrierten die Integration mit Istio). Die Tatsache, dass unterschiedliche Datenebenen innerhalb derselben Steuerebene verwendet werden können, bedeutet, dass die Steuerebene und die Datenebene nicht unbedingt eng gekoppelt sind. Eine API wie die generische Datenebenen-API von Envoy kann eine Brücke zwischen zwei Teilen des Systems bilden.

Nelson und SmartStack helfen dabei, die Trennung der Steuerungsebene und der Datenebene weiter zu veranschaulichen. Nelson verwendet Envoy als Proxy und baut eine zuverlässige Steuerungsebene für das Service Mesh auf Basis des HashiCorp-Stacks auf, d. h. Nomade usw. SmartStack war vielleicht der erste einer neuen Welle von Service-Meshs. SmartStack baut eine Steuerungsebene um HAProxy oder NGINX auf und demonstriert damit die Fähigkeit, die Steuerungsebene vom Service-Mesh von der Datenebene zu entkoppeln.

Die Microservice-Architektur mit einem Service-Mesh gewinnt (zu Recht!) immer mehr an Aufmerksamkeit und immer mehr Projekte und Anbieter beginnen, in diese Richtung zu arbeiten. In den nächsten Jahren werden wir viele Innovationen sowohl auf der Datenebene als auch auf der Steuerungsebene sowie eine weitere Vermischung verschiedener Komponenten erleben. Letztendlich soll die Microservice-Architektur für den Betreiber transparenter und magischer (?) werden.
Hoffentlich immer weniger gereizt.

Die zentralen Thesen

• Ein Service Mesh besteht aus zwei verschiedenen Teilen: der Datenebene und der Kontrollebene. Beide Komponenten sind erforderlich und ohne sie funktioniert das System nicht.
• Jeder ist mit der Kontrollebene vertraut, und an diesem Punkt könnten Sie die Kontrollebene sein!
• Alle Datenebenen konkurrieren miteinander hinsichtlich Funktionen, Leistung, Konfigurierbarkeit und Erweiterbarkeit.
• Alle Steuerungsebenen konkurrieren miteinander hinsichtlich Funktionen, Konfigurierbarkeit, Erweiterbarkeit und Benutzerfreundlichkeit.
• Eine Steuerebene kann die richtigen Abstraktionen und APIs enthalten, sodass mehrere Datenebenen verwendet werden können.

Source: habr.com