Hallo Habr! Ich präsentiere Ihnen die Übersetzung des Artikels "Service Mesh Data Plane vs Control Plane" von Matt Klein .



Dieses Mal wollte und übersetzte ich die Beschreibung beider Komponenten des Service-Netzes, der Datenebene und der Steuerebene. Diese Beschreibung erschien mir am verständlichsten und interessantesten und führte vor allem zum Verständnis von "Ist es überhaupt notwendig?"

Da die Idee eines „Service-Netzes“ in den letzten zwei Jahren immer beliebter wurde (Originalartikel vom 10. Oktober 2017) und die Anzahl der Teilnehmer im Weltraum zugenommen hat, habe ich in der gesamten technischen Community eine entsprechende Zunahme der Verwirrung hinsichtlich des Vergleichs festgestellt und kontrastieren verschiedene Lösungen.

Die Situation lässt sich am besten in der folgenden Reihe von Tweets beschreiben, die ich im Juli geschrieben habe:

Verwechslung mit dem Service-Mesh (Service-Mesh) Nr. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Gesandter. Keiner von ihnen ist Istio gleich. Istio ist etwas ganz anderes. 1 /

Die ersten sind nur Datenebenen. Sie selbst tun nichts. Sie müssen auf etwas mehr abgestimmt sein. 2 /

Istio ist ein Beispiel für eine Steuerebene, die Teile miteinander verbindet. Dies ist eine andere Schicht. / Ende

In früheren Tweets wurden verschiedene Projekte erwähnt (Linkerd, NGINX, HAProxy, Envoy und Istio), aber was noch wichtiger ist, die allgemeinen Konzepte einer Datenebene, eines Dienstnetzes und einer Steuerebene werden vorgestellt. In diesem Beitrag werde ich einen Schritt zurücktreten und auf sehr hoher Ebene erklären, was ich unter den Begriffen „Datenebene“ und „Steuerebene“ verstehe, und dann erläutern, wie sich die Begriffe auf die genannten Projekte beziehen in Tweets.

Was ist ein Service-Mesh (wirklich)?

Abbildung 1: Übersicht über das Service-Netz

Abbildung 1 zeigt das Konzept eines Service-Meshs auf der 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 Proxyserver an die entsprechenden externen Dienstcluster übertragen. Daher kennt die Anwendungsinstanz das Netzwerk als Ganzes nicht und nur den lokalen Proxy. Tatsächlich war das Netzwerk des verteilten Systems vom Dienst entfernt.

Datenebene

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

• Serviceerkennung Welche Dienste / Dienste / Anwendungen stehen für Ihre Anwendung zur Verfügung?
• Gesundheitsprüfung Sind von der Serviceerkennung zurückgegebene Dienstinstanzen betriebsbereit und bereit, Netzwerkverkehr zu akzeptieren? Dies kann entweder eine aktive (z. B. Überprüfung der / healthcheck-Antwort) oder eine passive (z. B. Verwendung von 3 aufeinanderfolgenden 5xx-Fehlern als Hinweis auf den ungesunden Zustand des Dienstes) Gesundheitsprüfung umfassen.
• Routing Nachdem Sie vom REST-Service eine Anfrage an "/ foo" erhalten haben, an welchen Service-Cluster soll die Anfrage gesendet werden?
• Lastausgleich An welche Instanz des Dienstes soll die Anforderung gesendet werden, nachdem während des Routings ein Dienstcluster ausgewählt wurde? Welche Auszeit? Welche Einstellungen für Leistungsschalter? Wenn die Anfrage fehlschlägt, sollte sie wiederholt werden?
• Authentifizierung und Autorisierung Kann der anrufende Dienst bei eingehenden Anfragen mithilfe von mTLS oder einem anderen Mechanismus kryptografisch identifiziert / autorisiert werden? Wenn es identifiziert / autorisiert ist, darf es die angeforderte Operation (Endpunkt) im Dienst aufrufen oder sollte eine nicht authentifizierte Antwort zurückgegeben werden?
• Beobachtbarkeit Für jede Anforderung sollten detaillierte Statistiken, Protokolle / Protokolle und verteilte Ablaufverfolgungsdaten generiert werden, damit die Bediener den verteilten Verkehrsfluss und die auftretenden Debugging-Probleme verstehen können.

Für alle vorherigen Punkte im Servicenetz (Service Mesh) ist die Datenebene verantwortlich. Tatsächlich ist der für den Dienst lokale Proxy (Beiwagen) eine Datenebene. Mit anderen Worten, die Datenebene ist für das bedingte Senden, Weiterleiten und Überwachen jedes Netzwerkpakets verantwortlich, das an den Dienst gesendet oder von diesem gesendet wird.

Die Steuerebene

Die Netzwerkabstraktion, die der lokale Proxy in der Datenebene bereitstellt, ist magisch (?). Woher weiß der Proxy jedoch tatsächlich über die "/ foo" -Route zu Dienst B? Wie können Service-Discovery-Daten verwendet werden, die mit Proxy-Anforderungen gefüllt sind? Wie werden die Einstellungen für Lastausgleich, Zeitüberschreitung, Unterbrechung usw. konfiguriert? Wie kann die Anwendung mithilfe der blau / grünen (blau / grün) Methode oder der Methode der schrittweisen Übertragung des Datenverkehrs bereitgestellt werden? Wer richtet systemweite Authentifizierungs- und Autorisierungseinstellungen ein?

Alle oben genannten Elemente werden von der Steuerebene des Servicegitters verwaltet. Die Steuerebene akzeptiert eine Reihe zustandsloser isolierter Proxyserver und verwandelt sie in ein verteiltes System .

Ich denke, der Grund, warum viele Technologen die getrennten Konzepte der Datenebene und der Steuerebene verwirrt finden, ist, dass für die meisten Menschen die Datenebene vertraut ist, während die Steuerebene fremd / unverständlich ist. Wir arbeiten seit langer Zeit mit physischen Netzwerkroutern und Switches. Wir verstehen, dass Pakete / Anfragen von Punkt A nach Punkt B gehen müssen und dass wir dafür Hardware und Software verwenden können. Die neue Generation von Software-Proxys ist einfach die trendige Version der Tools, die wir seit langem verwenden.


Abbildung 2: Menschliche Kontrollebene

Wir haben die Steuerebene jedoch schon lange verwendet, obwohl die meisten Netzbetreiber diesen Teil des Systems möglicherweise keiner technologischen Komponente zuordnen. Der Grund dafür ist einfach:
Die meisten der heute verwendeten Steuerebenen sind ... wir .

Abbildung 2 zeigt, was ich als "menschliche Kontrollebene" bezeichne. Bei dieser Art von Bereitstellung, die immer noch sehr verbreitet ist, erstellt der wahrscheinlich mürrische menschliche Bediener statische Konfigurationen - möglicherweise mithilfe von Skripten - und stellt sie mithilfe eines speziellen Prozesses auf allen Proxys bereit. Dann beginnen die Proxys, diese Konfiguration zu verwenden und beginnen mit der Verarbeitung der Datenebene unter Verwendung der aktualisierten Einstellungen.


Abbildung 3: Erweiterte Service-Mesh-Steuerebene

Abbildung 3 zeigt die „erweiterte“ Steuerebene des Servicegitters. Es besteht aus folgenden Teilen:

• Der Mensch : Es gibt immer noch eine Person (hoffentlich weniger wütend), die Entscheidungen auf hoher Ebene in Bezug auf das gesamte System trifft.
• Benutzeroberfläche der Steuerebene : 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:
  
  • Bereitstellungsmanagement, blau / grün und / oder mit schrittweiser Verkehrsübertragung
  • Authentifizierungs- und Autorisierungseinstellungen
  • Routing-Tabellenspezifikationen, z. B. wenn Anwendung A Informationen zu "/ foo" anfordert, was passiert
  • Load-Balancer-Einstellungen wie Zeitüberschreitungen, Wiederholungsversuche, Parameter für Stromkreisunterbrechungen usw.
• Workload-Scheduler : Services werden in der Infrastruktur über ein bestimmtes Planungs- / Orchestrierungssystem wie Kubernetes oder Nomad gestartet. Der Scheduler ist für das Laden des Dienstes zusammen mit seinem lokalen Proxyserver verantwortlich.
• Serviceerkennung Wenn der Scheduler Dienstinstanzen startet und stoppt, meldet er den Integritätsstatus an das Diensterkennungssystem.
• Sidecar-Proxy-Konfigurations-APIs : Lokale Proxys extrahieren den Status dynamisch aus verschiedenen Komponenten des Systems gemäß dem „letztendlich konsistenten“ Modell ohne Eingreifen des Bedieners. Das gesamte System, bestehend aus allen derzeit ausgeführten Instanzen von Diensten und lokalen Proxyservern, konvergiert letztendlich zu einem Ökosystem. Die Envoy-Datenebenen-API ist ein Beispiel dafür, wie dies in der Praxis funktioniert.

Im Wesentlichen besteht das Ziel der Steuerebene darin, eine Richtlinie festzulegen, die letztendlich von der Datenebene übernommen wird. Fortgeschrittenere Steuerebenen entfernen mehr Teile einiger Systeme vom Bediener und erfordern weniger manuelle Steuerung, vorausgesetzt, sie funktionieren ordnungsgemäß!

Datenebene und Steuerebene. Zusammenfassung von Datenebene und Steuerebene

• Service-Mesh-Datenebene : Betrifft jedes Paket / jede Anforderung im System. Verantwortlich für die Erkennung von Anwendungen / Diensten, Integritätsprüfungen, Routing, Lastausgleich, Authentifizierung / Autorisierung und Beobachtbarkeit.
• Service-Mesh-Steuerebene : Bietet Richtlinien und Konfigurationen für alle Arbeitsdatenebenen innerhalb des Service-Netzwerks. Berührt keine Pakete / Anforderungen im System. Die Steuerebene verwandelt alle Datenebenen in ein verteiltes System.

Aktuelle Projektlandschaft

Nachdem wir die obige Erklärung herausgefunden haben, schauen wir uns den aktuellen Status des Projekts „Service Mesh“ an.

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

Anstatt eine eingehende Analyse jeder der oben genannten Lösungen durchzuführen, werde ich mich kurz auf einige Punkte konzentrieren, die meiner Meinung nach derzeit die größte Verwirrung im Ökosystem verursachen.

Zu Beginn des Jahres 2016 war Linkerd einer der ersten Proxy-Server für die Datenebene für das Service-Mesh und hat auf fantastische Weise das Bewusstsein und die Aufmerksamkeit für das Service-Mesh-Designmodell geschärft. Ungefähr 6 Monate später kam Envoy zu Linkerd (obwohl er seit Ende 2015 bei Lyft ist). Linkerd und Envoy sind zwei der Projekte, die am häufigsten bei der Diskussion von Servicenetzwerken erwähnt werden.

Istio wurde im Mai 2017 angekündigt. Die Ziele des Istio-Projekts sind der in Abbildung 3 gezeigten erweiterten Steuerebene sehr ähnlich. Envoy for Istio ist der Standard-Proxyserver. Somit ist Istio die Steuerebene und Envoy die Datenebene. In kurzer Zeit verursachte Istio viele Unruhen, und andere Datenebenen wurden als Ersatz für Envoy integriert (sowohl Linkerd als auch NGINX demonstrierten die Integration mit Istio). Die Tatsache, dass Sie verschiedene Datenebenen in derselben Steuerebene verwenden können, bedeutet, dass die Steuerebene und die Datenebene nicht unbedingt eng miteinander verbunden sind. Eine API wie die universelle Datenebenen-API von Envoy kann eine Brücke zwischen zwei Teilen des Systems bilden.

Nelson und SmartStack veranschaulichen die Trennung von Steuerebene und Datenebene weiter. Nelson verwendet Envoy als Proxy und erstellt eine zuverlässige Steuerebene des Service-Netzes basierend auf dem HashiCorp-Stack, d. H. Nomad etc. SmartStack ist möglicherweise der erste einer neuen Welle von Servicenetzwerken. SmartStack bildet eine Steuerebene um einen HAProxy oder NGINX und demonstriert die Fähigkeit, eine Steuerebene von einem Service-Mesh und einer Datenebene zu entkoppeln.

Eine Microservice-Architektur mit einem Service-Mesh zieht mehr Aufmerksamkeit auf sich (richtig!), Und immer mehr Projekte und Anbieter beginnen, in diese Richtung zu arbeiten. In den nächsten Jahren werden wir viele Innovationen sowohl in der Datenebene als auch in der Steuerebene sowie eine weitere Vermischung der verschiedenen Komponenten sehen. Letztendlich sollte die Microservice-Architektur für den Bediener transparenter und magischer werden (?).
Hoffe immer weniger genervt.

Wichtige Punkte (Key Takeaways)

• Ein Servicegitter (Servicegitter) besteht aus zwei verschiedenen Teilen: einer Datenebene und einer Steuerebene. Beide Komponenten sind erforderlich, und ohne sie funktioniert das System nicht.
• Jeder ist mit der Steuerebene vertraut, und jetzt können Sie die Steuerebene sein!
• Alle Datenebenen konkurrieren in Funktionen, Leistung, Konfigurierbarkeit und Erweiterbarkeit miteinander.
• Alle Steuerebenen konkurrieren in Funktion, Konfigurierbarkeit, Erweiterbarkeit und Benutzerfreundlichkeit.
• Eine einzelne Steuerebene kann die richtigen Abstraktionen und APIs enthalten, sodass mehrere Datenebenen verwendet werden können.