© anoyo, 123RF

Der flinke Proxy-Server Envoy adressiert moderne Container-Umgebungen. Läuft er dem Konkurrenten Istio, von dem er selbst ein Teil ist, den Rang ab? Grund genug, sich die Komponente einmal genauer anzusehen.

Ein Schlagwort, das man im Container-Kontext aktuell allenthalben hört, heißt Mesh-Netzwerke für Container-Umgebungen. Von solchen Netzen behaupten Container-Apologeten gerne, mit den richtigen Werkzeugen funktioniere alles ganz automatisch und völlig problemlos, Clients fänden auf magische Art den richtigen Weg zu ihren Backend-Servern, und sobald der Admin einmal alles eingerichtet habe, gehörten Sicherheits- wie Performance-Probleme im Netz der Vergangenheit an. Leidgeprüfte Admins und Entwickler wissen freilich, dass Wunsch und Wirklichkeit oft divergieren.

Zwar hat die neuerdings so beliebte Microservices-Architektur unbestrittene Vorteile. Agile Entwicklung wird durch sie überhaupt erst möglich: Wenn sich die einzelnen Teile einer Applikation nicht länger in den Release-Zyklus eines großen Monolithen einfügen müssen, macht das das Development schon dadurch sehr viel dynamischer.

Doch jede Medaille hat zwei Seiten, und das gilt auch in diesem Fall. Als Preis für mehr Flexibilität muss man eine merklich erhöhte Komplexität in Sachen Interprozesskommunikation in Kauf nehmen. Das Thema spielt bei den konventionellen, monolithischen Apps praktisch keine Rolle, denn hier geschieht die Kommunikation innerhalb des Programms selbst.

Hat man es plötzlich jedoch mit – aus Sicht der Entwickler – vielen kleinen Komponenten zu tun, müssen diese Schnittstellen definieren, um miteinander zu sprechen. Dann spielen auf einmal Themen wie Load Balancing, Fehlertoleranz und Sicherheit eine erhebliche Rolle. Service-Mesh-Lösungen wie Istio, die auch das Linux-Magazin bereits vorgestellt hat [1], erfreuen sich aktuell großer Beliebtheit: Sie versprechen den Admins, das Thema Netzwerk automatisch abzuhandeln.

Envoy und Istio

Bei einem genaueren Blick auf die Istio-Architektur (Abbildung 1) fällt auf: Im Kern der Lösung steckt die Open-Source-Komponente Envoy. Der größte Teil der Funktionalität in Istio stammt aus Envoy; bei Istio handelt es sich im Grunde um ein dynamisches Konfigurations-Framework, das Envoy Einstellungen für die jeweilige Umgebung unterjubelt.

Abbildung 1: Envoy ist der Klassiker, wenn es darum geht, Istio zu nutzen – praktisch ist das Tool aber viel mehr als ein Istio-Anhängsel. Quelle: Mateo Burillo

Entsprechend bezeichnen die Entwickler von Istio Envoy als Sidecar, als Beiwagen. Wer Envoy aber nur als Komponente von Istio begreift, tut dem Tool unrecht. Aus diesem Grund beschäftigt sich dieser Artikel mit Envoy selbst, mit seinen Features und mit der Frage, wie sich Envoy auch fernab von Istio sinnvoll ausrollen und betreiben lässt.

Universal-Proxy

Schon der erste Satz auf der Envoy-Website verrät, dass es den Entwicklern um eine umfassende Lösung geht: Sie bezeichnen das Tool dort als Proxy, der sich sowohl für den Einsatz in Applikationen eignet als auch für den Einsatz hin zur Nutzerseite.

Faktisch haben Entwickler wie Admin es in Clouds ja gleich mit mehreren Verbindungstypen zu tun: Einerseits verbinden sich Kunden von außen mit den einzelnen Diensten einer Applikation, die auf einer Microservices-Architektur beruht, andererseits reden auch die einzelnen Komponenten miteinander. Envoy nimmt für sich in Anspruch, beide Anwendungsfälle adäquat als Proxy-Server zu bedienen: Es will also die Schaltstelle in beide Richtungen sein.

Nun ist es nicht so, als wären vergleichbare Herausforderungen in Sachen Kommunikation zwischen Diensten etwas Neues. Auch eher klassische Setups vereinen schließlich meist mehrere Dienste, und auch hier ist die Interprozesskommunikation durchaus ein Thema. Das macht schon ein kurzer Ausflug in die Desktop-Welt deutlich: Hier müssen meist diverse, von unterschiedlichen Entwicklern verfasste Dienste miteinander reden.

In der Vergangenheit löste man das Problem nicht selten über Bibliotheken, die standardisierte Funktionen boten und so den Verbindungsaufbau erleichterten. Das Konzept ist allerdings verhältnismäßig starr – und sieht man bei den Kollegen vom Desktop nach, merkt man schnell: Dort dominieren seit Jahren Kommunikationsbusse, an die alle beteiligten Tools sich anschließen. In exakt dieser Tradition sieht Envoy sich letztlich auch: Es will als Bus innerhalb von Setups fungieren. Damit das klappt, kommt Envoy mit diversen praktischen Features und Eigenschaften.

C++ soll Performance garantieren

Wer sich viel in der Welt aktueller Programme und Lösungen bewegt, der denkt meist an Go oder Rust, wenn es um neue Applikationen geht. Obgleich Envoy noch vergleichsweise wenige Lenze zählt, ist die Lösung aber weder in Go noch in Rust oder einer anderen modernen Programmiersprache verfasst. Stattdessen haben die Entwickler sich bewusst für C++ 11 entschieden, das nach ihrer Ansicht einen deutlich geringeren Performance-Overhead hat als seine modernen Kollegen.

Als Beispiel führen die Entwickler das Problem Latenz ins Feld: Die sei bei diversen aktuellen Skript- und Programmiersprachen deutlich höher, als man es sich für moderne High-Performance-Setups wünsche. C++ 11 hingegen, so schildern es die Envoy-Autoren in fast schon schwärmerischem Ton, sei ab Werk sowohl auf effiziente Entwicklung als auch auf gute Performance optimiert. Das führen sie übrigens auch als Argument gegen C ins Feld: Das sei zwar ebenfalls schnell, biete jedoch aus Entwicklersicht nicht die nötigen Werkzeuge, die man sich beim Envoy-Team für die Entwicklung eines Proxys gewünscht habe.

Vom Umgang mit Layern

Jeder Informatiker sieht sich früher oder später mit den verschiedenen Ebenen des OSI-Modells konfrontiert. Falls das dem einen oder anderen Leser bislang erspart geblieben sein sollte, ist es bei Envoy nun damit vorbei. Das Programm beschreibt sich primär als Proxy für die Ebenen L3 sowie L4. Sobald IP-Adressen im Spiel sind, möchte Envoy also dabei sein.

Weil das Programm die Layer 3 und 4 unterstützt, heißt das freilich auch: Envoy funktioniert auf Wunsch ausschließlich auf Basis von IP-Adressen – oder, wenn der Anwendungsfall es verlangt, potenziell auch als Instanz, die ein bestimmtes Protokoll spricht. Eine Lastverteilung für HTTP lässt sich etwa realisieren, indem man den Port 80 stur auf die Backends weiterleitet.

In der Praxis erweist sich dieser Ansatz allerdings als unzureichend, denn Features wie das Fortbestehen von Sessions gehören im Load-Balancer-Geschäft mittlerweile zum guten Ton. Konkret lautet eine Anforderung in heutigen Setups also, dass ein Client zuverlässig bei mehreren Requests nacheinander bei stets demselben Backend landet. Das in vielen Webapplikationen integrierte Session-Handling ist ein Beispiel für eine Funktion, die diese Persistenz benötigt.

Würde Envoy sich ausschließlich am Layer 3 orientieren, könnte es diese Funktion zwar grundsätzlich auch bieten, ohne das HTTP-Protokoll zu verstehen. Dann könnte das Programm aber den durchfließenden Traffic nicht analysieren, um etwa die Session-ID der Applikation auf der Webserver-Seite zu identifizieren und gegebenenfalls zu nutzen. Das gelingt nur, wenn Envoy den Verkehr tatsächlich versteht – und eben dazu dient die Envoy-Eigenschaft, auch Daten aus dem Layer 4 verarbeiten zu können.

Plugins für Vielfalt

Klar ist aber auch: Die Envoy-Entwickler können unmöglich Support für jede Webapplikation des Planeten in ihr Produkt einbauen, zumal für viele davon die Spezifikationen gar nicht offenliegen. Um den Nutzern dennoch so viele Features wie möglich zu bieten, haben sich die Entwickler dafür entschieden, eine Plugin-Schnittstelle zu implementieren.

Lädt der Entwickler eine Envoy-Erweiterung, leitet die Software automatisch Traffic durch dieses Plugin. Das bedeutet im weiteren Verlauf allerdings auch, dass mehrere Plugins sich hintereinander schalten lassen. Weil Envoy dabei auf eine offene Architektur und freie Standards setzt, hat jeder Applikationsentwickler die Möglichkeit, ein Envoy-Plugin für seine spezifische Anwendung zu schreiben und zusammen mit seinen Pods auch auszuliefern.

Ab Werk bringt Envoy übrigens einige grundlegende Filter schon mit. Einer davon kümmert sich um die Funktionen eines HTTP-Proxy, ein anderer ist als Terminierungsstelle für TLS-Verbindungen konzipiert. Ein simpler TCP-Proxy gehört freilich ebenfalls zum Lieferumfang.

Sonderfall HTTP

Im Kontext des Load Balancings kommt dem HTTP-Protokoll eine besondere Bedeutung zu. Einerseits war der Anwendungsfall HTTP lange vor jeder Microservices-Architektur da, Webserver-Setups fußen seit Jahrzehnten auf dem simplen Prinzip der Lastverteilung. Andererseits macht HTTP-Traffic in Zeiten von REST-APIs und modernen Webarchitekturen noch immer einen enormen Teil des Datenverkehrs aus, der bei den meisten Setups anfällt. Da verwundert es kaum, dass die Envoy-Entwickler dem HTTP-Protokoll besondere Aufmerksamkeit schenken. Das zeigt sich an zwei Stellen besonders.

So bietet Envoy die Möglichkeit, über ein eigenes Interface im HTTP-Filter zusätzliche Layer-7-Filter zwischenzuschalten. Dabei ist auch diese Schnittstelle für Filter im Filter frei zugänglich und dokumentiert, sodass Entwickler ihre eigenen Filter produzieren können. Konkret haben diese Filter Zugriff auf den gesamten HTTP-Flow und können ihn auf Basis der Tools, die der HTTP-Filter zur Verfügung stellt, überwachen oder modifizieren.

Als ein Beispiel nennen die Entwickler etwa das Routing von HTTP-Paketen, Limits für eingehende HTTP-Verbindungen unter Nutzung verschiedener Parameter (Anzahl der eingehenden HTTP-Verbindungen, übermittelte Datenmenge, etc.) sowie das Sniffen von übermittelten Inhalten. Denkbar wäre etwa, dass Envoy während der Analyse von eingehenden HTTP-Paketen feststellt, dass diese in Summe ein festgelegtes Limit für einzelne Backends überschreiten und Envoy sie deshalb dynamisch woandershin routet. Als ein Sniffing-Beispiel führen die Envoy-Entwickler Amazons Dynamo DB an, die sich per Envoy überwachen lässt.

Mittler zwischen den Welten

HTTP/2 ist zwar schon seit 2015 auf dem Markt, was aber nicht bedeutet, dass sein Vorgänger in freier Wildbahn nicht durchaus noch recht häufig anzutreffen wäre. Zum einen unterstützt Envoy HTTP/2, zum anderen wird, wer eine neue Applikation baut, im Normalfall auf HTTP/2 setzen, statt das alte HTTP zu verwenden.

Envoy bietet trotzdem eine praktische Funktion, um als Mittler zwischen den Welten zu agieren: Es beherrscht sowohl HTTP/1.1 als auch HTTP/2. Übersetzt Envoy zwischen den beiden Protokollversionen, geschieht das für den Client komplett transparent, sodass auch ältere Clients, die noch kein HTTP/2 beherrschen, durch Envoy hindurch mit HTTP/2-Diensten reden können. Für die Kommunikation zwischen mehreren Envoy-Instanzen in einem Setup empfehlen die Entwickler aber ausschließlich den Einsatz von HTTP/2.

Die Abkürzung RPC dürfte den meisten Admins schon einmal begegnet sein, konkret geht es um die Remote Procedure Calls. Unter RPC verstehen Entwickler wie Admins üblicherweise Frameworks, mit denen sich auf entfernten Systemen kontrolliert Befehle aufrufen lassen. Diese Prozesse produzieren Ergebnisse und schicken sie an die anfragende Stelle zurück. Die gängigste Art und Weise, RPC-Systeme zu entwickeln, bieten klassische Client-Server-Systeme.

Im Kontext von Mikroservice-Architekturen und Containern erlebt RPC durch Googles gRPC-Protokoll eine neue Blüte: Der Suchmaschinen-Primus hat gRPC mit dem ausdrücklichen Ziel entwickelt, innerhalb einer Applikation verschiedene Abläufe zu standardisieren und zu automatisieren. Möchte ein Entwickler also eine Schnittstelle zwischen zwei Applikationen definieren, muss er das nicht selbst tun, sondern kann stattdessen das modulare gRPC nutzen. Das tun bereits heute viele Entwickler.

Da verwundert es nicht, dass Envoy gRPC unterstützt und den fließenden gRPC-Verkehr analysieren kann. Praktisch wird Envoy in einer Umgebung, die gRPC nutzt, zum dynamischen gRPC-Transport-Layer: Es fängt die Nachrichten ab, interpretiert sie und leitet den Traffic entsprechend so, dass er das gewünschte Ziel effizient erreicht und die gewünschte RPC-Aktion auch tatsächlich ausgelöst wird.

Praktisch ergänzen gRPC und HTTP in Envoy sich also innerhalb eines solchen Gespanns. Aus Entwicklersicht ist das nützlich, weil nicht nur das Design einer eigenen API wegfällt, sondern die Verbindung zum API-Dienst durch Envoy auch automatisch bestmöglich gemanagt ist.

Envoy konfigurieren

Envoy als Sidecar eines Containers in Kubernetes auszurollen ist keine Kunst – das klappt sogar ganz leicht (Abbildung 2). Schwieriger ist schon die Antwort auf die Frage, woher Envoy seine Konfiguration bekommt. Die ist aber wichtig: Ohne Konfiguration weiß Envoy nicht einmal, welche Backends für eine Komponente einer Applikation zur Verfügung stehen. Weil Mikroapps aber qua Definition deutlich dynamischer arbeiten als konventionelle Apps, taugt der klassische Ansatz einer statischen Konfiguration nicht.

Abbildung 2: Envoy lässt sich auch unabhängig von Istio in Kubernetes nutzen, wie diese Service-Definition beweist.

Envoy trägt diesem Umstand Rechnung und bietet gleich mehrere Möglichkeiten – fast alle nach dem Prinzip, die Konfiguration so weit wie möglich selbstständig zu ermitteln. Fast alle deshalb, weil Envoy zusätzlich auch eine statische Konfiguration ermöglicht. Die Entwickler weisen ausdrücklich darauf hin, dass sie dieses Feature nicht etwa stiefmütterlich behandeln wollen.

Zwar gelingt in einer statischen Envoy-Konfiguration Host Discovery nur per DNS, ansonsten stehen aber praktisch alle Features zur Verfügung. Selbst große Setups lassen sich laut Aussage der Entwickler damit bauen, woran das Hot-Restart-Feature sicherlich einen Anteil hat: Ändern die Entwickler die Envoy-Konfiguration im laufenden Betrieb, fungiert das Hot-Restart-Feature quasi als Envoy-Variante von SIGHUP (das hier ausdrücklich nicht funktioniert – den Restart gilt es mittels interner Envoy-Funktionen auszulösen).

Wer es dynamischer mag, landet bei den verschiedenen Service-Discovery-APIs, die in Envoy ebenfalls zur Verfügung stehen und über die sich während des Betriebs die Envoy-Konfiguration modifizieren lässt. Endpoints kann man über eine eigene API ebenso dynamisch konfigurieren wie Cluster. Weitere APIs gibt es für Routen sowie für kryptografische Strings, meist also Passwörter. Auf der Envoy-Webseite [2] erklären die Entwickler die verschiedenen Service-Discovery-APIs ausführlich. Praktisch bilden sie die Basis für Lösungen wie Istio oder Contour, die über solche APIs im laufenden Betrieb neue Konfigurationsdirektiven in Envoy hinterlegen.

Wissen, was ist

Während die Verfechter moderner Mikroarchitekturanwendungen nicht selten die Mär verbreiten, solche Anwendungen bräuchten eigentlich gar kein Monitoring mehr, wissen Admins und Entwickler es meist besser. Gerade in Setups, in denen durch dynamisches Skalieren ständig Instanzen von Services verschwinden oder hinzukommen, muss der Admin wissen, was Sache ist. Da kommt es ganz gelegen, dass Envoy ab Werk mehrere Funktionen liefert, die effizentes und umfassendes Monitoring ermöglichen.

So ist das Programm einerseits in der Lage, umfangreiche Aufzeichnungen über seine Aktivitäten zu führen. Leitet es etwa einen eingehenden Request an ein Backend weiter oder stellt eine Verbindung zwischen zwei Diensten in einer Applikation her, schreibt es die Aktion immer auf und notiert auch, wie viel Traffic über diesen Kommunikationspfad verschickt wird. Hinzu kommt, dass die einzelnen in Envoy ab Werk mitgelieferten Filter viele Metriken aufzeichnen. Wer eigene Filter für Envoy schreibt, kann sich auch an dieser Stelle nochmals austoben.

Die Fähigkeit, Metriken aufzuzeichnen, ist allerdings nur die eine Seite der Medaille. Die andere Seite besteht darin, die Daten aus Envoy herauszubekommen, sie sinnvoll zu speichern und sie anschließend zu visualisieren. Hier stellt es sich als sehr praktisch heraus, dass Envoy gleich mehrere Frontends bietet, um die Daten an andere Dienste zu übergeben.

Der historische Standard ist der Export an Statsd, von wo aus sich die Metrikdaten dann weiterverarbeiten lassen. Wer es ohne Umweg haben möchte, kann die Daten aus Envoy heraus aber auch direkt zu Prometheus (Abbildung 3) exportieren. Für Grafana existieren mittlerweile eine Vielzahl vorgefertiger Dashboards, die Metrikdaten aus Envoy grafisch darstellen, wenn diese in Prometheus liegen. Für Übersicht auf Seiten des Admins ist insofern gesorgt.

Abbildung 3: Wer wissen möchte, was in Envoy los ist, exportiert die Daten in Statsd oder wie hier in Prometheus. Quelle: Envoy

Envoy sinnvoll

Wer sich als Entwickler mit den diversen Vorzügen von Envoy beschäftigt, fragt sich bald, wie er bisher eigentlich ohne es auskommen konnte. Envoy bietet riesige Vorteile – auf keine andere Art und Weise lässt sich so einfach ein Mesh-Netz zwischen den Diensten einer Microservices-Architektur spannen. Da stellt sich zwangsläufig die Frage, wie sich Envoy sinnvoll ausrollen und mit einer passenden Konfiguration versehen lässt. Hier gibt es gleich mehrere Ansätze – etwa direkt als Ressource, wie Amazon es vormacht (Abbildung 4).

Abbildung 4: Wer Envoy in AWS nutzen möchte, findet dort entsprechende Dokumentationen und vorbereitete Designs. Quelle: Amazon

Den aktuell wohl gängigsten Weg hat das Linux-Magazin erst kürzlich ganz detailliert vorgestellt: Istio. Istio verspricht dem Admin nicht weniger als das Rundum-sorglos-Paket: Es integriert Envoy als zentrale Komponente sowohl für den eingehenden Datenverkehr auf der Client-Seite (“ingress”) als auch für die Kommunikation der Komponenten einer Applikation (“east-west traffic”). Dabei erweitert es Istio um diverse Automatismen und versucht, dem Entwickler auf Basis weniger Regeln den größten Teil der Arbeit abzunehmen.

Bei Istio handelt es sich aber keineswegs um die einzige Lösung dieser Art. VMwares Contour beispielsweise versteht sich als Proxy speziell für den Ingress-Traffic in Kubernetes. Ost-West-Traffic zwischen den Teilen einer Applikation spielen bei Contour also keine Rolle, auf die Features für eingehenden Verkehr von der Client-Seite haben die Contour-Entwickler bei VMware hingegen größten Wert gelegt.

Die Control Plane für Envoy

Aus Sicht der Architektur unterscheidet Contour sich dabei gar nicht so sehr von Istio. Auch Contour funktioniert als Control Plane für Envoy und wird in Kubernetes über Custom Resource Definitions (CRDs) gesteuert. Hat der Nutzer seine Pods entsprechend eingerichtet, läuft Envoy als von Contour dynamisch gesteuerte Proxy-Instanz.

Dadurch beherrscht Contour ein umfassendes Feature-Set: Skaliert eine Komponente einer Applikation etwa wegen hoher Last automatisch in die Breite, passt Contour Envoy autonom an. Auf Wunsch konfiguriert Contour auch die TLS-Fähigkeiten von Envoy völlig automatisch; dazu muss der Nutzer lediglich beim Ausrollen seiner Pod-Definitionen die entsprechenden Zertifikate spezifizieren. All diese Funktionen stellen aus Envoy-Sicht aber nur die Pflicht dar.

Die Kür unterstützt Envoy wie beschrieben ebenfalls – Traffic lässt sich direkt aus Envoy heraus über einen virtuellen Monitor-Port überwachen, verschiedene Upstream-Server kann man in Contour dynamisch konfigurieren, und Fehlerkonditionen legt der Admin anhand setup-spezifischer Parameter fest.

Wer eine Envoy-Instanz für mehrere Namespaces in Kubernetes nutzen will, hat dazu ebenfalls die Möglichkeit: Auf diese Weise lässt sich Verkehr etwa einer gemeinsamen URL auf verschiedene Pods in Kubernetes verteilen, die dann von verschiedenen Teams betrieben werden.

Zudem im Rennen: Consul Connect

Eine weitere Möglichkeit, Envoy als Sidecar auszurollen, bietet auch der Cluster-Konsens-Algorithmus Consul: Unter dem Titel Connect ist Envoy Teil des Consul-Service-Meshs für Kubernetes. Im Wesentlichen kümmert Envoy sich in einem solchen Setup darum, einerseits die Verbindung von Clients außerhalb des Setups zu Diensten darin herzustellen. Andererseits ist es auch für die SSL-Terminierung zuständig, wenn der Admin diese Features nutzen möchte.

Quasi im Vorbeigehen konfiguriert Connect Envoy auch noch so, dass es eine elementare Sicherheitsbarriere darstellt: Zwei Dienste, die laut Connect nicht dazu autorisiert sind, miteinander zu kommunizieren, können das durch den Proxy-Server auch nicht tun. Eventuelle Verbindungsversuche würde dieser im Tandem mit Connect ablehnen.

Ohne eine ohnehin laufende Consul-Instanz ergibt die Nutzung von Connect aber nur bedingt Sinn. Wer ohnehin Consul im Einsatz hat, legt Connect darin als Service an und benutzt es ohne viel Mehraufwand. Wer Consul nicht nutzt, ist je nach Aufgabengebiet mit Istio oder Contour vermutlich besser bedient (Abbildung 5).

Abbildung 5: Bei Contour handelt es sich um eine von VMware entwickelte Control Plane für Envoy und eine mögliche Alternative zu Istio. Quelle: VMware

Fazit

Moderne App-Architekturen stellen Admins und Entwickler vor zum Teil neue Herausforderungen, was das Management vieler paralleler Verbindungen angeht. Envoy erweist sich als fantastisches Werkzeug, das sowohl zwischen den Clients und den Applikationen als auch zwischen den Teilen einer Applikation vermittelt. Sein Leistungsumfang beeindruckt: Neben einfachen Proxy-Verbindungen stellen auch komplexe Setups kein Problem dar; SSL-Terminierung gehört noch zu den eher leichten Aufgaben für Envoy. Konkurrenz erwartet das Programm im Moment nur aus einer Richtung: Linkerd ist die einzige ernst zu nehmende Alternative zu Envoy. Wer Apps für Kubernetes entwickelt, sollte sich Envoy jedenfalls gut ansehen und gegebenenfalls sorgfältig mit Linkerd vergleichen.