Envoys Konfigurationsmodell ändert sich nicht danach, wo du ihn betreibst, aber wo du ihn betreibst, ändert, welches Problem er löst. Diese Anleitung behandelt die gängigen Deployment-Muster und warum eine Eigenschaft von Envoy – billig genug zu sein, um als eine Instanz pro Anwendung zu laufen – das interessanteste davon erst möglich macht.

Edge-Proxy: die Eingangstür zu deinem Netzwerk

Am Rand betrieben, sitzt Envoy zwischen der Außenwelt und deinen internen Services. Er nimmt eingehenden Traffic externer Clients an und behandelt in der anderen Richtung den ausgehenden Traffic, den deine eigenen Services nach außen senden. Das ist die klassische Position eines API-Gateways oder Load Balancers: eine (oder eine kleine, redundante Menge von) Envoy-Instanz(en), die TLS-Terminierung, Routing und Rate Limiting für alles erledigt, was die Netzwerkgrenze in beiden Richtungen überquert.

Front-Proxy: ein gemeinsamer interner Load Balancer

Ein einfacheres internes Muster: ein einzelner Envoy (oder ein kleiner Cluster davon), an den jeder interne Service Anfragen sendet und der sie dann an das richtige Backend verteilt. Das sieht aus wie ein herkömmlicher interner Load Balancer, und funktional ist es einer – nur mit Envoys Routing und Health Checking statt einer speziell gebauten LB-Appliance umgesetzt.

Sidecar: ein Envoy pro Service-Instanz

Dieses Muster hebt Envoy von den meisten anderen Proxys ab: Statt dass eine gemeinsame Instanz den Traffic vieler Services verarbeitet, läuft eine Envoy-Instanz neben jeder Instanz jedes Services – in Kubernetes-Begriffen als zweiter Container im selben Pod. Der ein- und ausgehende Traffic jedes Services fließt durch seine eigene dedizierte Proxy-Instanz statt durch eine gemeinsame.

Zwei Dinge folgen direkt aus dieser Nähe:

• Die Anwendung muss nichts mehr über Netzwerk wissen. Retries, Timeouts, TLS und Load-Balancing-Logik wandern aus dem Anwendungscode in den Proxy direkt daneben – genau die Trennung der Zuständigkeiten, die Envoys Design erreichen wollte.
• Die Fehlersuche wird schneller. Wenn Envoy eine gemeinsame Komponente irgendwo anders im Netzwerk ist, könnte ein Problem in der Anwendung, im Proxy oder im Netzwerkpfad dazwischen liegen. Wenn Envoy direkt neben der einen Anwendungsinstanz läuft, der er dient, verschwindet diese Mehrdeutigkeit größtenteils: Meldet der Sidecar eine gesunde Verbindung zur App und die Anfrage schlägt trotzdem fehl, ist der Suchraum deutlich kleiner geworden.

Eine Envoy-Instanz pro Instanz zu betreiben funktioniert nur, weil Envoy bewusst leichtgewichtig ist. Ein Proxy mit schwerem Fußabdruck pro Instanz ließe sich in dieser Dichte nicht betreiben, ohne selbst zu den Betriebskosten der Anwendung ein zweites Mal zu werden.

Service Mesh: Sidecars, koordiniert

Ein Service Mesh ist das Sidecar-Muster, konsequent über eine ganze Anwendung hinweg angewendet: Jede Service-Instanz bekommt ihren eigenen Envoy, und alle diese Proxys werden als ein koordiniertes System konfiguriert und beobachtet statt als unabhängige, einzeln verwaltete Instanzen. Hier gelten Envoys Traffic-Management-Funktionen – Retries, Circuit Breaking, Mutual TLS, feingranulares Routing – einheitlich für jeden Service im Mesh, ohne dass der Code eines einzelnen Services sie implementieren muss.

Hunderte einzelner Envoy-Instanzen von Hand zu konfigurieren ist nicht praktikabel, weshalb Service Meshes als eigene Schicht auf Envoy existieren und nicht „einfach nur Envoy, oft betrieben“ sind. Istio ist das prominenteste Beispiel: Seine Datenebene ist speziell Envoy, und Istios eigene Control Plane, istiod, erzeugt und verteilt die Konfiguration jedes Sidecars automatisch, wenn sich Services und Policies ändern. Wenn du per kubectl exec in einen Pod gehst, in den Istio einen Sidecar injiziert hat, und dir seine Logs ansiehst, läuft dort ein echter Envoy-Prozess, der von Istio statt von Hand konfiguriert wurde.

Gemischte Muster sind normal

Produktive Topologien kombinieren meist mehr als eines dieser Muster: Envoy am Rand, der Ingress und Egress für den gesamten Cluster behandelt, und Envoy-Sidecars, die den Service-zu-Service-Traffic im Inneren behandeln. Nichts an Envoy erzwingt ein einzelnes Muster. Eines oder eine Kombination zu wählen hängt davon ab, welcher Traffic welche Art von Kontrolle braucht, und ist keine Einschränkung des Proxys selbst.