Ein Kubernetes-Service-Mesh-Vergleich

Bei der Diskussion über Microservices-Architektur und Containerisierung hat in den letzten Jahren ein Satz produktionserprobter Tools die meiste Aufmerksamkeit auf sich gezogen: das Service Mesh.

Tatsächlich sind Microservices-Architektur und Kubernetes (oft stilisierte „K8s“) schnell zur Norm für skalierbare Apps geworden, was das Problem der Verwaltung der Kommunikation zwischen Diensten zu einem heißen Thema macht – und Service Meshes zu einer attraktiven Lösung. Ich selbst habe Service-Meshes in der Produktion verwendet, insbesondere Linkerd, Istio und eine frühere Form von Ambassador. Aber was genau machen Service Meshes? Welche ist die beste zu verwenden? Woher wissen Sie, ob Sie überhaupt eine verwenden sollten?

Um diese Fragen zu beantworten, hilft es zu verstehen, warum Service Meshes entwickelt wurden. In der Vergangenheit liefen Anwendungen in der traditionellen IT-Infrastruktur als Monolithen. Ein Dienst lief auf einem Server; Wenn mehr Kapazität benötigt wurde, bestand die Lösung darin, es vertikal zu skalieren, indem eine größere Maschine bereitgestellt wurde.

Als die großen Technologieunternehmen an die Grenzen dieses Ansatzes stießen, übernahmen sie schnell eine Drei-Ebenen-Architektur, die einen Load Balancer von Anwendungsservern und einer Datenbankebene trennt. Obwohl diese Architektur einigermaßen skalierbar blieb, entschieden sie sich, die Anwendungsebene in Microservices aufzuteilen. Die Kommunikation zwischen diesen Diensten muss überwacht und gesichert werden, damit Anwendungen skaliert werden können.

Um die Kommunikation zwischen Diensten zu ermöglichen, haben diese Unternehmen interne Bibliotheken entwickelt: Finagle bei Twitter, Hystrix bei Netflix und Stubby bei Google (das 2016 zu gRPC wurde). Diese Bibliotheken zielten darauf ab, Probleme zu beheben, die durch die Microservices-Architektur aufgeworfen wurden: Sicherheit zwischen Diensten, Latenz, Überwachung und Lastausgleich. Aber die Verwaltung einer großen Bibliothek als Abhängigkeit – in mehreren Sprachen – ist komplex und zeitaufwändig.

Am Ende wurde diese Art von Bibliothek durch einen einfacher zu verwendenden, schlanken Proxy ersetzt. Solche Proxys waren extern unabhängig von der Anwendungsschicht – potenziell transparent für die Anwendung – und einfacher zu aktualisieren, zu warten und bereitzustellen. Damit war das Service Mesh geboren.

Was ist ein Service-Mesh?

Ein Service Mesh ist eine Software-Infrastrukturschicht zur Steuerung der Kommunikation zwischen Diensten; Es besteht im Allgemeinen aus zwei Komponenten:

1. Die Datenebene , die die Kommunikation in der Nähe der Anwendung abwickelt. Typischerweise wird dies mit der Anwendung als eine Reihe von Netzwerk-Proxys bereitgestellt, wie zuvor dargestellt.
2. Die Steuerungsebene, das „Gehirn“ des Service Mesh. Die Steuerungsebene interagiert mit Proxys, um Konfigurationen zu pushen, die Erkennung von Diensten sicherzustellen und die Beobachtbarkeit zu zentralisieren.

Service Meshes haben drei Hauptziele in Bezug auf die Kommunikation zwischen Diensten:

1. Konnektivität
2. Sicherheit
3. Beobachtbarkeit

Konnektivität

Dieser Aspekt der Service-Mesh-Architektur ermöglicht die Erkennung von Diensten und dynamisches Routing. Es deckt auch die Ausfallsicherheit der Kommunikation ab, wie z. B. Wiederholungen, Zeitüberschreitungen, Leitungsunterbrechung und Ratenbegrenzung.

Ein Hauptmerkmal von Service Meshes ist der Lastenausgleich . Alle Dienste, die durch Proxys vernetzt sind, ermöglichen die Implementierung von Lastausgleichsrichtlinien zwischen Diensten, wie z. B. Round-Robin-, Zufalls- und geringste Anforderungen. Diese Richtlinien sind die Strategie, die vom Service Mesh verwendet wird, um zu entscheiden, welches Replikat die ursprüngliche Anfrage erhält, genau so, als ob Sie kleine Load Balancer vor jedem Dienst hätten.

Schließlich bieten Service-Meshes Routing-Kontrolle in Form von Traffic-Shifting und -Mirroring.

Sicherheit

In der traditionellen Microservices-Architektur kommunizieren Dienste untereinander mit unverschlüsseltem Datenverkehr. Unverschlüsselter interner Datenverkehr gilt heutzutage in Bezug auf die Sicherheit als schlechte Praxis, insbesondere für öffentliche Cloud-Infrastrukturen und Zero-Trust-Netzwerke.

Zusätzlich zum Schutz der Privatsphäre von Kundendaten, wenn keine direkte Kontrolle über die Hardware besteht, fügt die Verschlüsselung des internen Datenverkehrs im Falle einer Systemverletzung eine willkommene Ebene zusätzlicher Komplexität hinzu. Daher verwenden alle Service-Meshes gegenseitige TLS-Verschlüsselung (mTLS) für die Kommunikation zwischen Diensten, dh die gesamte Kommunikation zwischen Proxys.

Service-Meshes können sogar komplexe Matrizen von Autorisierungsrichtlinien durchsetzen und Datenverkehr basierend auf Richtlinien zulassen oder ablehnen, die auf bestimmte Umgebungen und Dienste abzielen.

Beobachtbarkeit

Das Ziel von Service Meshes ist es, die Kommunikation zwischen den Diensten sichtbar zu machen. Durch die Steuerung des Netzwerks erzwingt ein Service-Mesh die Beobachtbarkeit und stellt Schicht-Sieben-Metriken bereit , die wiederum automatische Warnungen ermöglichen, wenn der Datenverkehr einen anpassbaren Schwellenwert erreicht.

Eine solche Steuerung wird normalerweise von Tools oder Plug-Ins von Drittanbietern wie Jaeger oder Zipkin unterstützt und ermöglicht auch das Tracing durch Einfügen von HTTP-Tracing-Headern .

Service-Mesh-Vorteile

Das Service Mesh wurde entwickelt, um einen Teil der Betriebslast auszugleichen, die durch eine Microservices-Architektur entsteht. Diejenigen, die Erfahrung mit Microservices-Architekturen haben, wissen, dass ihr täglicher Betrieb einen erheblichen Arbeitsaufwand erfordert. Um das Potenzial von Microservices voll auszuschöpfen, sind normalerweise externe Tools erforderlich, um unter anderem zentralisierte Protokollierung, Konfigurationsverwaltung und Skalierbarkeitsmechanismen zu handhaben. Die Verwendung eines Service Mesh standardisiert diese Funktionen sowie deren Einrichtung und Integration .

Insbesondere die Service-Mesh-Beobachtbarkeit bietet äußerst vielseitige Debugging- und Optimierungsmethoden. Dank der granularen und vollständigen Sichtbarkeit des Austauschs zwischen Diensten können Ingenieure – insbesondere SREs – mögliche Fehler und Fehlkonfigurationen des Systems schneller beheben. Mit Service-Mesh-Tracing können sie eine Anfrage von ihrem Eingang in das System (bei einem Load Balancer oder externen Proxy) bis hin zu privaten Diensten im Stack verfolgen. Sie können die Protokollierung verwenden, um eine Anfrage abzubilden und die Latenz aufzuzeichnen, auf die sie in jedem Dienst stößt. Das Endergebnis: detaillierte Einblicke in die Systemleistung .

Das Datenverkehrsmanagement bietet leistungsstarke Möglichkeiten, bevor eine vollständige Version einer neuen Version eines Dienstes hochgefahren wird:

1. Leiten Sie kleine Prozentsätze von Anfragen um.
2. Noch besser ist es, Produktionsanfragen in eine neue Version zu spiegeln , um ihr Verhalten mit Echtzeitverkehr zu testen.
3. A/B-Tests für jeden Dienst oder jede Kombination von Diensten.

Service Meshes rationalisieren alle oben genannten Szenarien und machen es einfacher, Überraschungen in der Produktion zu vermeiden und/oder abzumildern.

Kubernetes-Service-Mesh-Vergleich

In vielerlei Hinsicht sind Service Meshes die ultimativen Tools für die Microservices-Architektur; Viele von ihnen laufen auf einem der besten Container-Orchestrierungstools, Kubernetes. Wir haben drei der wichtigsten Service-Meshes ausgewählt, die heute auf Kubernetes ausgeführt werden: Linkerd (v2), Istio und Consul Connect. Wir werden auch einige andere Service Meshes besprechen: Kuma, Traefik Mesh und AWS App Mesh. Obwohl sie derzeit in Bezug auf Nutzung und Community weniger prominent sind, sind sie vielversprechend genug, um sie hier zu überprüfen und allgemein im Auge zu behalten.

Eine kurze Anmerkung zu Sidecar-Proxys

Nicht alle Kubernetes-Service-Meshes verfolgen denselben architektonischen Ansatz, aber ein gängiger Ansatz ist die Nutzung des Sidecar-Musters. Dazu gehört das Anhängen eines Proxys (Sidecar) an die Hauptanwendung, um den ein- und ausgehenden Netzwerkverkehr der Anwendung abzufangen und zu regulieren. In der Praxis erfolgt dies in Kubernetes über einen sekundären Container in jedem Anwendungs-Pod, der dem Lebenszyklus des Anwendungscontainers folgt.

Der Sidecar-Ansatz für Service Meshes hat zwei Hauptvorteile:

• Sidecar-Proxys sind unabhängig von der Laufzeit und sogar der Programmiersprache der Anwendung.
  • Dies bedeutet, dass es einfach ist, alle Funktionen eines Service Mesh überall dort zu aktivieren, wo es verwendet werden soll, im gesamten Stack.
• Ein Sidecar hat dieselbe Berechtigungsstufe und denselben Zugriff auf Ressourcen wie die Anwendung.
  • Der Sidecar kann dabei helfen, die von der Hauptanwendung verwendeten Ressourcen zu überwachen, ohne dass die Überwachung in die Codebasis der Hauptanwendung integriert werden muss.

Aber Sidecars sind ein gemischter Segen, weil sie sich direkt auf eine Anwendung auswirken:

• Die Sidecar-Initialisierung kann den Startmechanismus einer Anwendung blockieren.
• Sidecar-Proxys fügen Ihrer Anwendung eine potenzielle Latenz hinzu.
• Sidecar-Proxys fügen auch einen Ressourcen-Fußabdruck hinzu, der bei Skalierung eine erhebliche Menge Geld kosten kann.

Angesichts dieser Vor- und Nachteile ist der Sidecar-Ansatz häufig Gegenstand von Diskussionen in der Service-Mesh-Community. Allerdings verwenden vier der sechs hier verglichenen Service-Meshes den Envoy-Sidecar-Proxy, und Linkerd verwendet seine eigene Sidecar-Implementierung; Traefik Mesh verwendet in seinem Design keine Beiwagen.

Linkerd-Rezension

Linkerd, das 2017 debütierte, ist das älteste Service Mesh auf dem Markt. Linkerd v1 wurde von Buoyant (einem Unternehmen, das von zwei ehemaligen Twitter-Ingenieuren gegründet wurde) entwickelt und basierte auf Finagle und Netty.

Linkerd v1 wurde als seiner Zeit voraus beschrieben, da es sich um ein vollständiges, produktionsbereites Service Mesh handelte. Gleichzeitig war es ein bisschen schwer in Bezug auf den Ressourcenverbrauch. Außerdem erschwerten erhebliche Lücken in der Dokumentation die Einrichtung und den Betrieb in der Produktion.

Damit hatte Buoyant die Möglichkeit, mit einem vollständigen Produktionsmodell zu arbeiten, Erfahrungen daraus zu sammeln und dieses Wissen anzuwenden. Das Ergebnis war Conduit, die komplette Linkerd-Neufassung des Unternehmens, die 2018 veröffentlicht und später in diesem Jahr in Linkerd v2 umbenannt wurde. Linkerd v2 brachte mehrere überzeugende Verbesserungen mit sich; Da Buoyants aktive Entwicklung von Linkerd v1 vor langer Zeit eingestellt wurde, beziehen sich unsere Erwähnungen von „Linkerd“ im Rest dieses Artikels auf v2.

Linkerd ist vollständig Open Source und verlässt sich auf einen hausgemachten Proxy, der für die Datenebene in Rust geschrieben wurde, und auf Quellcode, der in Go für die Steuerungsebene geschrieben wurde.

Konnektivität

Linkerd-Proxys haben Wiederholungs- und Timeout-Funktionen, aber zum jetzigen Zeitpunkt keine Schaltungsunterbrechung oder Verzögerungsinjektion. Die Ingress-Unterstützung ist umfangreich; Linkerd bietet die Integration mit den folgenden Ingress-Controllern:

• Traefik
• Nginx
• GCE
• Botschafter
• Gloo
• Kontur
• Kong

Dienstprofile in Linkerd bieten erweiterte Routing-Funktionen, die dem Benutzer Metriken, Wiederholungseinstellungen und Zeitüberschreitungseinstellungen geben, alles auf einer pro-Route-Basis. Für den Lastausgleich bietet Linkerd eine automatische Proxy-Injektion, ein eigenes Dashboard und native Unterstützung für Grafana.

Sicherheit

Die mTLS-Unterstützung in Linkerd ist insofern praktisch, als die anfängliche Einrichtung automatisch erfolgt, ebenso wie die automatische tägliche Schlüsselrotation.

Beobachtbarkeit

Standardmäßig sind Linkerd-Statistiken und -Routen über eine CLI beobachtbar. Auf der GUI-Seite umfassen die Optionen vorgefertigte Grafana-Dashboards und ein natives Linkerd-Dashboard.

Linkerd kann sich in eine Instanz von Prometheus einklinken.

Die Ablaufverfolgung kann über ein Add-on aktiviert werden, wobei OpenTelemetry (ehemals OpenCensus) als Kollektor fungiert und Jaeger die Ablaufverfolgung selbst durchführt.

Installation

Die Linkerd-Installation erfolgt durch Einfügen eines Sidecar-Proxys, was durch Hinzufügen einer Anmerkung zu Ihren Ressourcen in Kubernetes erfolgt. Dazu gibt es zwei Möglichkeiten:

1. Verwenden eines Helm-Diagramms. (Für viele ist Helm der bevorzugte Konfigurations- und Vorlagenmanager für Kubernetes-Ressourcen.)
2. Installieren Sie die Linkerd-CLI und verwenden Sie diese dann, um Linkerd in einem Cluster zu installieren.

Die zweite Methode beginnt mit dem Herunterladen und Ausführen eines Installationsskripts:

 curl -sL https://run.linkerd.io/install | sh

Von dort aus stellt das Linkerd-CLI-Tool linkerd ein nützliches Toolkit bereit, mit dem der Rest von Linkerd installiert und mit dem App-Cluster und der Steuerungsebene interagiert werden kann.

linkerd check --pre führt alle Vorabprüfungen durch, die für Ihre Linkerd-Installation erforderlich sind, und liefert klare und präzise Protokolle darüber, warum eine potenzielle Linkerd-Installation möglicherweise noch nicht funktioniert. Ohne --pre kann dieser Befehl zum Debuggen nach der Installation verwendet werden.

Der nächste Schritt besteht darin, Linkerd im Cluster zu installieren, indem Sie Folgendes ausführen:

 linkerd install | kubectl apply -f -

Linkerd installiert dann viele verschiedene Komponenten mit einem sehr geringen Ressourcenverbrauch; Daher haben sie selbst einen Microservices-Ansatz:

• linkerd-controller , der die öffentliche API bereitstellt, mit der die CLI und das Dashboard interagieren
• linkerd-identity , die die Zertifizierungsstelle zum Implementieren von mTLS bereitstellt
• linkerd-proxy-injector , der die Injektion des Proxys übernimmt, indem er die Konfiguration eines Pods verändert
• linkerd-web , das ein Dashboard bereitstellt, das die Überwachung von Bereitstellungen und Pods sowie internen Linkerd-Komponenten ermöglicht

Linkerd basiert den größten Teil seiner Konfiguration auf CustomResourceDefinitions (CRDs). Dies gilt als Best Practice bei der Entwicklung von Kubernetes-Add-on-Software – es ist wie die dauerhafte Installation eines Plug-ins in einem Kubernetes-Cluster.

Das Hinzufügen von verteiltem Tracing – was Linkerd-Benutzer aufgrund einiger verbreiteter Mythen möglicherweise tatsächlich wollen oder nicht – erfordert einen weiteren Schritt mit linkerd-collector und linkerd-jaeger. Dazu erstellen wir zunächst eine Konfigurationsdatei:

 cat >> config.yaml << EOF tracing: enabled: true EOF

Um die Ablaufverfolgung zu aktivieren, würden wir Folgendes ausführen:

 linkerd upgrade --config config.yaml | kubectl apply -f -

Wie bei jedem Service Mesh, das auf Sidecar-Proxys basiert, müssen Sie Ihren Anwendungscode ändern, um die Ablaufverfolgung zu aktivieren. Der Großteil davon besteht einfach darin, eine Client-Bibliothek hinzuzufügen, um Tracing-Header zu verbreiten; es muss dann in jedem Dienst enthalten sein.

Die Traffic-Split-Funktion von Linkerd, die über die SMI-konforme API (Service Mesh Interface) bereitgestellt wird, ermöglicht bereits Canary-Releases. Aber um sie und das Traffic-Management zu automatisieren, benötigen Sie auch externe Tools wie Flagger.

Flagger ist ein progressives Bereitstellungstool, das bewertet, was Linkerd die „goldenen“ Metriken nennt: „Anfragevolumen, Erfolgsrate und Latenzverteilungen“. (Ursprünglich verwendeten Google SREs den Begriff goldene Signale und enthielten ein viertes – Sättigung –, aber Linkerd deckt es nicht ab, da dies Metriken erfordern würde, auf die nicht direkt zugegriffen werden kann, wie z. B. CPU- und Speicherauslastung.) Flagger verfolgt diese, während es den Datenverkehr aufteilt Verwenden einer Rückkopplungsschleife; Daher können Sie automatisierte Canary-Releases implementieren, die Metriken berücksichtigen.

Nachdem Sie sich mit dem Installationsprozess befasst haben, wird klar, dass es leicht ist, mindestens ein Dutzend Dienste auszuführen, wenn ein Linkerd-Service-Mesh betriebsbereit ist und häufig gewünschte Funktionen ausschöpft. Allerdings werden bei der Installation mehr davon von Linkerd geliefert als bei anderen Service Meshes.

Linkerd-Service-Mesh-Zusammenfassung

Vorteile:

Linkerd profitiert von der Erfahrung seiner Entwickler, zwei Ex-Twitter-Ingenieure, die an dem internen Tool Finagle gearbeitet und später von Linkerd v1 gelernt haben. Als eines der ersten Service-Meshes verfügt Linkerd über eine blühende Community (Slack hat mehr als 5.000 Benutzer, außerdem verfügt es über eine aktive Mailingliste und einen Discord-Server) und eine umfangreiche Reihe von Dokumentationen und Tutorials. Linkerd ist mit der Veröffentlichung von Version 2.9 ausgereift, wie die Übernahme durch große Unternehmen wie Nordstrom, eBay, Strava, Expedia und Subspace zeigt. Bezahlter Support der Enterprise-Klasse von Buoyant ist für Linkerd verfügbar.

Nachteile:

Es gibt eine ziemlich starke Lernkurve, um das volle Potenzial von Linkerd-Service-Meshes auszuschöpfen. Linkerd wird nur innerhalb von Kubernetes-Containern unterstützt (d. h. es gibt keinen VM-basierten „universellen“ Modus). Der Sidecar-Proxy von Linkerd ist nicht Envoy. Dies ermöglicht es Buoyant zwar, es nach eigenem Ermessen abzustimmen, entfernt jedoch die inhärente Erweiterbarkeit, die Envoy bietet. Es bedeutet auch, dass Linkerd die Unterstützung für Circuit Breaking, Delay Injection und Rate Limiting fehlt. Keine bestimmte API ist verfügbar, um die Linkerd-Steuerungsebene einfach zu steuern. (Sie können jedoch die gRPC-API-Bindung finden.)

Linkerd hat seit v1 große Fortschritte in seiner Benutzerfreundlichkeit und einfachen Installation gemacht. Das Fehlen einer offiziell offengelegten API ist eine bemerkenswerte Auslassung. Aber dank einer ansonsten gut durchdachten Dokumentation ist die Out-of-the-Box-Funktionalität in Linkerd einfach zu testen.

Consul Connect Bewertung

Unser nächster Service-Mesh-Anwärter, Consul Connect, ist ein einzigartiger Hybrid. Consul von HashiCorp ist besser bekannt für seine Schlüsselwertspeicherung für verteilte Architekturen, die es seit vielen Jahren gibt. Nach der Entwicklung von Consul zu einer vollständigen Suite von Service-Tools beschloss HashiCorp, darauf ein Service-Mesh aufzubauen: Consul Connect.

Um genau zu seiner hybriden Natur zu sein:

Die Datenebene von Consul Connect basiert auf Envoy, das in C++ geschrieben ist. Die Steuerungsebene von Consul Connect ist in Go geschrieben. Dies ist der Teil, der von Consul KV, einem Schlüsselwertspeicher, unterstützt wird.

Wie die meisten anderen Service-Meshes funktioniert Consul Connect, indem es einen Sidecar-Proxy in Ihren Anwendungs-Pod einfügt. Architekturtechnisch basiert Consul Connect auf Agenten und Servern . Standardmäßig soll Consul Connect eine hohe Verfügbarkeit (HA) haben, indem es drei oder fünf Server als StatefulSet verwendet, das die Pod-Anti-Affinität angibt. Pod-Anti-Affinität ist die Praxis, sicherzustellen, dass Pods eines verteilten Softwaresystems nicht auf demselben Knoten (Server) landen, wodurch die Verfügbarkeit garantiert wird, falls ein einzelner Knoten ausfällt.

Konnektivität

Es gibt nicht viel, was Consul Connect in diesem Bereich auszeichnet; Es bietet das, was jedes Service-Mesh tut ( was ziemlich viel ist), plus Layer-7-Funktionen für pfadbasiertes Routing, Traffic-Shifting und Load-Balancing.

Sicherheit

Wie bei den anderen Service-Meshes bietet Consul Connect grundlegende mTLS-Funktionen. Es bietet auch eine native Integration zwischen Consul und Vault (ebenfalls von HashiCorp), die als CA-Anbieter verwendet werden kann, um Zertifikate in einem Cluster zu verwalten und zu signieren.

Beobachtbarkeit

Consul Connect verfolgt den gebräuchlichsten Observability-Ansatz, indem es Envoy als Sidecar-Proxy integriert, um Layer-7-Funktionen bereitzustellen. Das Konfigurieren der Benutzeroberfläche von Consul Connect zum Abrufen von Metriken umfasst das Ändern einer integrierten Konfigurationsdatei und das Aktivieren eines Metrikanbieters wie Prometheus. Es ist auch möglich, einige Grafana-Dashboards so zu konfigurieren, dass relevante dienstspezifische Metriken angezeigt werden.

Installation

Consul Connect wird mithilfe eines Helm-Diagramms in einem Kubernetes-Cluster installiert:

 helm repo add hashicorp https://helm.releases.hashicorp.com

Sie müssen die default values.yaml ändern, wenn Sie die Benutzeroberfläche aktivieren oder das Consul Connect-Modul dazu bringen möchten, seinen Sidecar-Proxy einzufügen:

 helm install -f consul-values.yml hashicorp hashicorp/consul

Um Mitglieder zu konsultieren und die verschiedenen Knoten zu überprüfen, empfiehlt exec , in einen der Container auszuführen und dann das CLI-Tool consul zu verwenden.

Führen kubectl port-forward service/hashicorp-consul-ui 18500:80 aus, um die von Consul bereitgestellte sofort einsatzbereite Web-Benutzeroberfläche bereitzustellen.

Consul Connect Service-Mesh-Zusammenfassung

Vorteile:

• Consul wird von HashiCorp unterstützt; Als Freemium-Produkt gibt es auch eine Unternehmensversion mit zusätzlichen Funktionen, die Unterstützung auf Unternehmensebene bietet. In Bezug auf die Erfahrung von Entwicklungsteams ist Consul eines der ältesten Tools auf dem Markt.
• Consul verfügt über eine solide Unternehmensgemeinschaft und ist dafür bekannt, auf einer Infrastruktur mit 50.000 Knoten ausgeführt zu werden. Außerdem gibt es es seit 2014, was es zu einem ausgereiften Produkt im Vergleich zum Markt macht.
• Consul Connect läuft dank nativer Unterstützung gut in einer VM.
• Mit Consul Connect ist es möglich, App-Integrationen zu erreichen, die so tief sind wie die Pre-Service-Mesh-Implementierungen bei erstklassigen Technologieunternehmen. Dies ist der Offenlegung einer vollständig dokumentierten API auf Bibliotheksebene zu verdanken.

Nachteile:

• Consul Connect hat eine steilere Lernkurve als die anderen Service Meshes und erfordert mehr Feinabstimmung, um visuelle Dashboards und Metriken auszuführen.
• Die Dokumentation von HashiCorp ist nicht einfach, sodass Benutzer graben und experimentieren müssen, um sie richtig zu konfigurieren.
• Die Dokumentation zum Verkehrsmanagement ist schwer zu finden und besteht hauptsächlich aus Links zur Dokumentation von Envoy, die insbesondere keine Details zum Verkehrsmanagement von Consul Connect enthält.
• Die SMI-Schnittstelle von Consul Connect ist noch experimentell.

Consul Connect kann eine sehr gute Wahl für diejenigen sein, die ein Produkt der Unternehmensklasse suchen. HashiCorp ist bekannt für die Qualität seiner Produkte und Consul Connect ist da keine Ausnahme. Im Vergleich zu anderen Service Meshes sehe ich hier zwei starke Vorteile: starke Unterstützung durch das Unternehmen mit der Enterprise-Version und ein Tool, das für alle Arten von Architekturen (nicht nur Kubernetes) bereit ist.

Istio-Überprüfung

Im Mai 2017 kündigten Google, IBM und Lyft Istio an. Als Istio in das Rennen der Service-Mesh-Tools einstieg, erlangte es eine sehr gute Präsenz im Technologiebereich. Die Autoren haben bis zur Version 1.9 Funktionen basierend auf dem Feedback der Benutzer hinzugefügt.

Gegenüber seinen damaligen Konkurrenten versprach Istio wichtige Neuerungen: automatisches Load Balancing, Fault Injection und viele mehr. Dies brachte der Community viel Aufmerksamkeit ein, aber wie wir weiter unten im Detail erläutern werden, ist die Verwendung von Istio alles andere als trivial: Istio wurde als besonders komplex in der Produktion erkannt.

In der Vergangenheit ist das Istio-Projekt in Bezug auf Quellcodeänderungen häufig herumgesprungen. Nachdem Istio eine Microservice-Architektur für die Steuerungsebene eingeführt hatte, ist es nun (seit Version 1.5) wieder zu einer monolithischen Architektur übergegangen. Istios Begründung für die Rückkehr zur Zentralisierung war, dass Microservices für Betreiber schwer zu überwachen waren, die Codebasis zu redundant war und das Projekt organisatorisch ausgereift war – es musste nicht mehr viele kleine Teams in Silos arbeiten.

Im Laufe der Zeit erlangte Istio jedoch den Ruf, eines der höchsten Volumen an offenen GitHub-Problemen zu haben. Zum jetzigen Zeitpunkt liegt die Zählung bei etwa 800 offenen und etwa 12.000 geschlossenen Ausgaben. Während die Anzahl der Probleme täuschen kann, stellen sie in diesem Fall eine bedeutende Verbesserung in Bezug auf zuvor fehlerhafte Funktionen und außer Kontrolle geratene Ressourcennutzung dar.

Konnektivität

Istio ist im Traffic-Management im Vergleich zu Consul Connect und Linkerd ziemlich stark. Dies ist einem umfangreichen Angebot an Unterfunktionen zu verdanken: Request-Routing, Fehlerinjektion, Traffic-Shifting, Request-Timeouts, Circuit-Breaking und Kontrolle des eingehenden und ausgehenden Datenverkehrs zum Service-Mesh. Das Konzept der virtuellen Dienste und Zielregeln macht es in Bezug auf das Verkehrsmanagement sehr vollständig.

All diese Möglichkeiten sind jedoch mit einer Lernkurve verbunden, zuzüglich der Verwaltung dieser neuen Ressourcen in Ihrem Kubernetes-Cluster.

Sicherheit

Istio verfügt über ein umfassendes Set an sicherheitsbezogenen Tools mit zwei Hauptachsen: Authentifizierung und Autorisierung. Istio kann verschiedene Ebenen von Richtlinien in verschiedenen Bereichen erzwingen: arbeitslastspezifisch, Namespace-weit oder Mesh-weit. Alle diese Sicherheitsressourcen werden über Istio-CRDs wie AuthorizationPolicy oder PeerAuthentication .

Neben der standardmäßigen mTLS-Unterstützung kann Istio auch so konfiguriert werden, dass unverschlüsselter Datenverkehr akzeptiert oder abgelehnt wird.

Beobachtbarkeit

Hier ist Istio von Haus aus ziemlich weit fortgeschritten, mit mehreren Arten von Telemetrie, die solide Einblicke in das Service Mesh bieten. Metriken basieren auf den vier goldenen Signalen (Latenz, Verkehr, Fehler und teilweise Sättigung).

Insbesondere stellt Istio Metriken für die Steuerungsebene selbst bereit. Es dient auch verteilten Ablaufverfolgungen und Zugriffsprotokollen und bietet eine explizite Kompatibilität mit Jaeger, Lightstep und Zipkin, um die Ablaufverfolgung zu ermöglichen.

Es gibt kein natives Dashboard, aber es gibt offizielle Unterstützung für die Kiali-Verwaltungskonsole.

Installation

Die Installation ist so einfach wie das Befolgen der offiziellen Schritte. Istio ist auch nativ als Beta-Funktion in GKE integriert, aber dort verwendet GKE Istio 1.4.X, die ältere Microservices-Version im Gegensatz zur neuesten Monolith-Version.

Eine native Installation beginnt mit dem Herunterladen der neuesten Version:

 curl -L https://istio.io/downloadIstio | sh -

Nachdem Sie in den neu erstellten cd istio-* -Ordner gecdingt haben, können Sie ihn Ihrem Pfad hinzufügen, damit Sie das Dienstprogramm istioctl verwenden können:

 export PATH=$PWD/bin:$PATH

Von dort aus können Sie Istio über istioctl in Ihrem Kubernetes-Cluster installieren:

 istioctl install

Dadurch wird Istio mit einem default installiert. istioctl Profilen können Sie verschiedene Installationskonfigurationen erstellen und bei Bedarf zwischen ihnen wechseln. Aber selbst in einem Szenario mit einem einzigen Profil können Sie die Installation von Istio umfassend anpassen, indem Sie einige CRDs ändern.

Istio-Ressourcen sind schwieriger zu verwalten, da Sie mehrere Arten von CRDs verwalten müssen – mindestens VirtualService , DestinationRule und Gateway –, um sicherzustellen, dass die Datenverkehrsverwaltung vorhanden ist.

• Eine VirtualService -Ressource ist eine Konfiguration, die einen Dienst und die verschiedenen Routingregeln deklariert, die auf Anforderungen angewendet werden.
• Eine DestinationRule -Ressource wird verwendet, um zielspezifische Datenverkehrsrichtlinien zu gruppieren und durchzusetzen.
• Eine Gateway -Ressource wird erstellt, um den eingehenden und ausgehenden Service-Mesh-Datenverkehr zu verwalten (d. h. zusätzliche Envoy-Proxys, die jedoch am Edge und nicht als Sidecars ausgeführt werden).

Die semantischen Details sprengen den Rahmen dieser Übersicht, aber schauen wir uns ein kurzes Beispiel an, das zeigt, wie alle diese zusammenarbeiten. Angenommen, wir haben eine E-Commerce-Website mit einem Service namens products . Unser VirtualService könnte so aussehen:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

Die entsprechende DestinationRule könnte dann lauten:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

Zu guter Letzt unser Gateway :

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

Mit diesen drei Dateien wäre eine Istio-Installation bereit, den grundlegenden Datenverkehr zu verarbeiten.

Istio Service Mesh-Zusammenfassung

Vorteile:

• Unter den verschiedenen Service-Meshes ist Istio zum jetzigen Zeitpunkt dasjenige mit der größten Online-Community. Mit mehr als dem 10-fachen der Stack Overflow-Ergebnisse als einer seiner Hauptkonkurrenten ist es das am meisten diskutierte Service-Mesh im Internet. seine GitHub-Mitwirkenden sind ebenfalls eine Größenordnung über denen von Linkerd.
• Istio unterstützt sowohl Kubernetes- als auch VM-Modi; Letzteres ist ab Version 1.9 in der Beta-Phase.

Nachteile:

• Istio ist in zweierlei Hinsicht nicht kostenlos:
  • Die Anforderungen sind hoch in Bezug auf den Zeitaufwand, der zum Lesen der Dokumentation, zum Einrichten, zum ordnungsgemäßen Funktionieren und zum Pflegen der Dokumentation erforderlich ist. Abhängig von der Größe der Infrastruktur und der Anzahl der Dienste wird Istio mehrere Wochen bis mehrere Monate Vollzeitarbeit benötigen, um voll funktionsfähig und in die Produktion integriert zu sein.
  • Es fügt auch einen erheblichen Ressourcen-Overhead hinzu: Es werden 350 Millikerne (mCPU) für den Envoy-Container pro 1.000 Anforderungen pro Sekunde (RPS) benötigt. Sogar die Steuerungsebene selbst kann Ressourcen verbrauchen. (Früher war die Ressourcennutzung schwer vorherzusagen, aber nach einiger Anstrengung hat sich istiod bei der Verwendung von 1 vCPU und 1,5 GB Arbeitsspeicher stabilisiert.)
• Im Gegensatz zu Linkerd hat es kein natives Admin-Dashboard.
• Istio erfordert die Verwendung eines eigenen Ingress-Gateways.
• Die Istio-Steuerungsebene wird nur innerhalb von Kubernetes-Containern unterstützt (dh es gibt keinen VM-Modus, anders als bei der Datenebene von Istio).

Istio ist ein großartiges Beispiel dafür, wie Technologiegiganten zusammenkommen, um ein Open-Source-Projekt zu erstellen, um eine Herausforderung anzugehen, vor der sie alle stehen. Das Istio-Projekt als Ganzes brauchte einige Zeit, um sich zu strukturieren (unter Hinweis auf den architektonischen Wechsel von Microservices zu Monolithen) und seine vielen anfänglichen Probleme zu lösen. Heute leistet Istio absolut alles, was man von einem Service-Mesh erwartet, und ist stark erweiterbar. All diese Möglichkeiten sind jedoch mit hohen Anforderungen in Bezug auf Wissen, Arbeitsstunden und Rechenressourcen verbunden, um die Verwendung in einer Produktionsumgebung zu unterstützen.

Kuma-Schnellüberprüfung

Kuma wurde von Kong entwickelt und dann Open-Source. Ende 2020 erreichte Kuma 1.0. In gewissem Maße wurde es als Reaktion darauf entwickelt, dass die ersten Service-Meshes ziemlich schwer und schwierig zu bedienen waren.

Seine Feature-Liste deutet darauf hin, dass es sehr modular ist; Die Idee hinter Kuma ist es, es auf die Integration mit Anwendungen auszurichten, die bereits auf Kubernetes oder einer anderen Infrastruktur laufen.

• Im Bereich des Verkehrsmanagements bietet Kuma gängige Service-Mesh-Funktionen wie Fault Injection und Circuit Breaking.
• Über die dienstübergreifende mTLS-Verschlüsselung hinaus wird der Austausch zwischen der Datenebene und der Steuerungsebene in Kuma über ein Datenebenen-Proxy-Token gesichert.
• Die Beobachtbarkeit wird in Kuma über verschiedene Verkehrsrichtlinien in Bezug auf Metriken, Ablaufverfolgung und Protokollierung definiert.
• Die Diensterkennung ist über Kuma dank seines eigenen DNS-Resolvers verfügbar, der auf Port 5653 der Steuerungsebene ausgeführt wird.
• Kuma legt großen Wert auf Multimesh-Funktionalität : Sie können problemlos mehrere Kubernetes-Cluster oder VM-Umgebungen zu einem gemeinsamen Kuma-Cluster mit seinem Multizonen-Bereitstellungstyp kombinieren.
• Kuma lässt sich für bestehende Kong-Benutzer problemlos in Kong Gateway integrieren .

Die universelle (Nicht-Kubernetes-)Version von Kuma erfordert PostgreSQL als Abhängigkeit, und Kongs CTO war insbesondere gegen die Unterstützung von SMI. Aber Kuma wurde von Anfang an mit der Idee von Multicloud- und Multicluster-Bereitstellungen entwickelt, und sein Dashboard spiegelt dies wider.

Während Kuma im Bereich der Service-Meshs noch jung ist und bisher nur wenige Fälle von Produktionsanwendungen hatte, ist es ein interessanter und vielversprechender Anwärter.

Traefik Mesh Schnellüberprüfung

Ursprünglich Maesh genannt, ist Traefik Mesh (von Traefik Labs) ein weiterer Newcomer im Rennen um Service-Mesh-Werkzeuge. Die Projektaufgabe besteht darin, das Service Mesh zu demokratisieren, indem es einfach zu verwenden und zu konfigurieren ist; Die Erfahrung der Entwickler mit dem durchdachten Traefik Proxy versetzte sie in eine erstklassige Position, um dies zu erreichen.

• Zu den Verkehrsmanagementfunktionen in Traefik Mesh gehören Leitungsunterbrechung und Ratenbegrenzung.
• In Bezug auf die Beobachtbarkeit bietet Traefik Mesh native OpenTracing-Unterstützung und sofort einsatzbereite Metriken (die Standardinstallation enthält automatisch Prometheus und Grafana), was die Einrichtungszeit spart.
• Aus Sicherheitsgründen sind die Spezifikationen – abgesehen von mTLS – SMI-konform und Traefik Mesh ermöglicht die Feinabstimmung der Verkehrsberechtigungen durch Zugriffskontrolle.

Traefik Mesh benötigt die Installation von CoreDNS auf dem Cluster. (Während Azure seit 1.12 standardmäßig CoreDNS verwendet, verwendet GKE zum jetzigen Zeitpunkt standardmäßig kube-dns, was bedeutet, dass in diesem Fall ein erheblicher zusätzlicher Schritt erforderlich ist.) Es fehlen auch Multicluster-Funktionen.

Allerdings ist Traefik Mesh in unserem Service-Mesh-Vergleich insofern einzigartig, als es keine Sidecar-Injektion verwendet. Stattdessen wird es als DaemonSet auf allen Knoten bereitgestellt, um als Proxy zwischen Diensten zu fungieren, wodurch es nicht invasiv wird. Insgesamt ist Traefik Mesh einfach zu installieren und zu verwenden.

AWS App Mesh-Schnellüberprüfung

In der Welt der Cloud-Anbieter ist AWS der erste, der ein natives Service-Mesh implementiert hat, das mit Kubernetes (oder insbesondere EKS), aber auch mit seinen anderen Diensten kompatibel ist. AWS App Mesh wurde im November 2018 veröffentlicht und AWS hat es seitdem wiederholt. Der Hauptvorteil von AWS App Mesh ist das bereits bestehende AWS-Ökosystem und die Marktposition; Die große Community hinter AWS insgesamt wird die Nutzung und Benutzerfreundlichkeit weiter vorantreiben.

• Das Datenverkehrsmanagement in AWS App Mesh umfasst zusätzlich zu den allgemeinen Funktionen auch das Breaking Breaking.
• Since AWS App Mesh is hosted by AWS, it's a fully managed service , which means not having to worry about resource usage or control plane availability.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

Infrastruktur

Traffic Management

Observability

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

Einsatz

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.