Envoy Proxy

Envoy Proxy ist ein quelloffener, hochleistungsfähiger Edge- und Service-Proxy, der für Cloud-native-Anwendungen entwickelt wurde und als universelle Datenebene für Microservices-Architekturen fungiert. Er abstrahiert Netzwerkkomplexitäten und bietet fortschrittliches Traffic-Management, Observability und Sicherheitsfunktionen, die für verteilte Systeme unerlässlich sind.

Envoy fungiert als transparenter Proxy für den gesamten Netzwerkverkehr zwischen Diensten, wodurch Entwickler und Betreiber sich auf die Anwendungslogik statt auf Netzwerkbelange konzentrieren können. Seine Architektur ist für moderne Microservices-Bereitstellungen konzipiert und bietet Funktionen, die traditionelle Proxys oft nicht haben oder weniger effizient implementieren.

Kernarchitekturprinzipien

Envoy's Design priorisiert Leistung, Erweiterbarkeit und dynamische Konfiguration. Er arbeitet als ein einzelner Prozess, Multi-Thread-Server, der ereignisgesteuerte I/O nutzt, um ein hohes Volumen gleichzeitiger Verbindungen und Anfragen effizient zu verarbeiten.

L3/L4 Filterarchitektur

Envoy verwendet eine steckbare Filterkettenarchitektur sowohl auf der Netzwerk- (L3/L4) als auch auf der Anwendungsebene (L7). Dies ermöglicht eine hochgradig anpassbare Verarbeitung des Netzwerkverkehrs.
* Netzwerkfilter: Arbeiten auf rohen Byte-Streams. Beispiele sind TCP-Proxy, TLS-Terminierung und Ratenbegrenzung auf Verbindungsebene.
* HTTP-Filter: Arbeiten auf HTTP-Anfragen und -Antworten. Beispiele sind Gzip-Komprimierung, Injektion von Anfrage-IDs, JWT-Authentifizierung und erweitertes Routing.

Diese Modularität ermöglicht eine ausgeklügelte Richtliniendurchsetzung und Traffic-Manipulation in verschiedenen Phasen des Anfragelife-Cycles.

Hauptmerkmale für Microservices

HTTP/2 und gRPC-Unterstützung

Envoy bietet erstklassige Unterstützung für HTTP/2 und gRPC, essentielle Protokolle in modernen Microservices. Er kann HTTP/1.1-Clients mit HTTP/2-Diensten verbinden, HTTP/2-Verbindungen terminieren und gRPC-Proxying erleichtern, einschließlich erweiterter Funktionen wie gRPC-aware Load Balancing und Routing.

Erweitertes Load Balancing

Envoy bietet eine Reihe ausgeklügelter Load-Balancing-Algorithmen jenseits des einfachen Round-Robin:
* Least Request: Leitet an das Backend mit den wenigsten aktiven Anfragen weiter.
* Ring Hash: Konsistentes Hashing für bessere Cache-Auslastung und Sticky Sessions.
* Maglev (Power of Two Choices): Wählt zwei zufällige Hosts aus und selektiert denjenigen mit weniger aktiven Anfragen, wodurch Einfachheit mit nahezu optimaler Verteilung kombiniert wird.
* Random: Für eine einfache, unvoreingenommene Verteilung.
* Original Destination: Leitet an die beabsichtigte Ziel-IP ohne Service Discovery weiter.

Es unterstützt auch automatische Wiederholungsversuche, Circuit Breaking, Outlier Detection und Health Checking, um sicherzustellen, dass der Traffic nur an gesunde Instanzen gesendet wird, was die Ausfallsicherheit verbessert.

Dynamische Konfiguration (xDS API)

Ein Eckpfeiler von Envys Cloud-native-Design sind seine dynamischen Konfigurationsmöglichkeiten über die xDS (Discovery Service) API. Anstelle statischer Konfigurationsdateien kann Envoy Updates für verschiedene Ressourcen dynamisch empfangen:
* Listener Discovery Service (LDS): Listener (Ports, an die Envoy bindet).
* Route Discovery Service (RDS): HTTP-Routing-Regeln.
* Cluster Discovery Service (CDS): Upstream-Cluster (Gruppen von Backend-Diensten).
* Endpoint Discovery Service (EDS): Endpunkte (einzelne Instanzen) innerhalb von Clustern.
* Secret Discovery Service (SDS): TLS-Zertifikate und private Schlüssel.
* Runtime Discovery Service (RTDS): Dynamische Laufzeitkonfigurationswerte.

Dies ermöglicht Konfigurationsänderungen ohne Ausfallzeiten, was Continuous Deployment und die Integration mit Service-Mesh-Control-Planes (z.B. Istio, App Mesh) ermöglicht, die diese Konfigurationen verwalten.

Observability

Envoy ist mit Observability als erstklassigem Bürger konzipiert und bietet tiefe Einblicke in den Netzwerkverkehr:
* Detaillierte Statistiken: Gibt eine große Anzahl von Statistiken (über 100 pro Upstream-Cluster) aus, die Verbindungen, Anfragen, Fehler, Latenz und mehr abdecken, die von Prometheus oder ähnlichen Systemen gesammelt werden können.
* Distributed Tracing: Unterstützt beliebte Tracing-Systeme wie Jaeger, Zipkin und AWS X-Ray, propagiert Trace-Kontexte (z.B. B3, W3C Trace Context) und generiert Spans für jeden Hop.
* Access Logging: Umfassende, anpassbare Zugriffs-Logs, die jede Anfrage detailliert beschreiben, einschließlich Header, Antwortcodes und Zeitinformationen.

Diese Funktionen sind entscheidend für Debugging, Performance-Analyse und Monitoring verteilter Microservices.

Sicherheitsfunktionen

Envoy bietet robuste Sicherheitsfunktionen, die diese Bedenken oft von der Anwendungslogik entlasten:
* TLS-Terminierung und -Originierung: Handhabt TLS-Verschlüsselung/-Entschlüsselung, wodurch Dienste intern über Klartext kommunizieren können, während eine sichere externe Kommunikation aufrechterhalten wird.
* Mutual TLS (mTLS): Ermöglicht sichere, authentifizierte Kommunikation zwischen Diensten innerhalb eines Meshes durch Validierung von Client-Zertifikaten.
* Rate Limiting: Erzwingt Anfrageratenbegrenzungen, um Dienste vor Überlastung oder Missbrauch zu schützen.
* Authentifizierung und Autorisierung: Integriert sich über seinen External Authorization Filter mit externen Autorisierungsdiensten (z.B. OPA), wodurch eine feingranulare Zugriffskontrolle ermöglicht wird.

Envys Rolle in Microservices-Architekturen

Sidecar Proxy

Das gängigste Bereitstellungsmuster für Envoy in einer Microservices-Umgebung ist als Sidecar-Proxy. In diesem Modell läuft jede Dienstinstanz einen Envoy-Proxy daneben, typischerweise innerhalb desselben Pods in Kubernetes. Der gesamte eingehende und ausgehende Netzwerkverkehr für den Dienst wird transparent vom Sidecar abgefangen und verwaltet.

Dieser Ansatz bietet mehrere Vorteile:
* Netzwerkabstraktion: Anwendungsentwickler schreiben Dienste, die mit localhost kommunizieren, und der Envoy-Sidecar kümmert sich um Routing, Wiederholungsversuche und andere Netzwerkbelange.
* Polyglot-Unterstützung: Ermöglicht konsistente Netzwerkrichtlinien und -funktionen über Dienste hinweg, die in verschiedenen Sprachen und Frameworks geschrieben sind.
* Isolation: Netzwerkbelange sind von der Geschäftslogik isoliert, was Entwicklung und Bereitstellung vereinfacht.

Service Mesh Datenebene

Envoy dient als de facto Datenebene für viele populäre Service-Mesh-Implementierungen (z.B. Istio, Linkerd, AWS App Mesh). In einem Service Mesh verwaltet und konfiguriert eine Control Plane eine Flotte von Envoy-Proxys (die Datenebene). Die Control Plane verwendet die xDS API, um die Konfiguration aller Envoys im Mesh dynamisch zu aktualisieren und Traffic-Richtlinien, Sicherheit und Observability im gesamten Microservices-Ökosystem durchzusetzen.

Edge Proxy / API Gateway

Envoy kann auch am Rand eines Netzwerks als API-Gateway oder Reverse-Proxy bereitgestellt werden. In dieser Rolle handhabt er den Ingress-Traffic, führt Authentifizierung, Ratenbegrenzung, TLS-Terminierung durch und leitet Anfragen an entsprechende Backend-Dienste innerhalb der Microservices-Architektur weiter. Seine erweiterten L7-Routing-Fähigkeiten machen ihn für komplexe Edge-Routing-Anforderungen geeignet.

Konfigurationsbeispiel

Eine grundlegende Envoy-Konfiguration definiert Listener, Filterketten und Cluster. Dieses Beispiel zeigt einen Listener auf Port 10000, der HTTP-Anfragen an einen Upstream-Dienstcluster namens web_service proxyt.

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          codec_type: AUTO
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: web_service
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
  - name: web_service
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    # Comment out the following line to test on v6.
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: web_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: webserver.example.com # Replace with your actual service hostname/IP
                port_value: 80

Vergleich mit anderen Proxys

Praktische Überlegungen

Performance-Tuning

Envoy ist von Haus aus hochperformant, aber spezifische Bereitstellungen können von Tuning profitieren. Schlüsselbereiche umfassen:
* Thread-Konfiguration: Anpassen der Anzahl der Worker-Threads an die CPU-Kerne.
* Pufferverwaltung: Optimierung der Lese-/Schreibpuffergrößen.
* Verbindungspool-Größe: Konfigurieren der maximalen Verbindungen und Anfragen pro Verbindung zu Upstream-Clustern.

Ressourcenverbrauch

Obwohl effizient, erhöht das Ausführen eines Envoy-Sidecars für jede Dienstinstanz den gesamten Ressourcenverbrauch (CPU, Speicher). Dieser Kompromiss ist oft akzeptabel für die betrieblichen Vorteile, die ein Service Mesh bietet. Eine sorgfältige Überwachung der Ressourcennutzung ist bei großen Bereitstellungen entscheidend.

Debugging

Envoy bietet eine Admin-Oberfläche (typischerweise auf Port 15000), die wertvolle Debugging-Endpunkte bereitstellt:
* /stats: Aktuelle Statistiken.
* /config_dump: Gibt die aktuell aktive Konfiguration aus.
* /clusters: Status der Upstream-Cluster.
* /hot_restart: Initiiert einen graceful Hot Restart.

Diese Endpunkte sind entscheidend für die Fehlerbehebung bei Konfigurationsproblemen, die Überwachung der Gesundheit und das Verständnis des Traffic-Flusses.