TL;DR — Kurzzusammenfassung

Envoy Proxy für Service Mesh und Edge Proxy. Behandelt xDS API, Load Balancing, mTLS, Observability, Circuit Breaking und Kubernetes-Sidecar-Konfiguration.

Envoy Proxy ist die Datenebene im Herzen moderner Service Meshes. Ursprünglich bei Lyft entwickelt, um Observability und Zuverlässigkeit von Microservices in großem Maßstab zu lösen, ist Envoy heute der De-facto-Sidecar für Istio, der Edge Proxy vieler Ingress-Controller und ein universeller L3/L4/L7-Proxy, der von Google, AWS und Tausenden von Unternehmen eingesetzt wird. Dieser Leitfaden behandelt Envoys Architektur, statische und dynamische Konfiguration, Load-Balancing-Algorithmen, Observability-Pipeline, TLS-Verwaltung und erweiterte Filter.

Voraussetzungen

  • Docker (für eigenständige Tests) oder ein Kubernetes-Cluster.
  • Grundlegendes Verständnis von HTTP, TLS und Reverse-Proxy-Konzepten.
  • Vertrautheit mit YAML-Konfigurationssyntax.
  • curl und optional jq zum Testen von Endpoints.

Envoy-Architektur

Envoy arbeitet als prozessexterner Netzwerkproxy — er läuft neben Ihrer Anwendung, nicht als Bibliothek darin. Das macht den Proxy sprachunabhängig und ermöglicht unabhängige Upgrades.

Hauptkomponenten:

  • Listeners — Netzwerkports, an die Envoy gebunden ist (Downstream-Verbindungen kommen hier an).
  • Filterketten — Geordnete Liste von Netzwerk- und HTTP-Filtern, die auf jede Verbindung angewendet werden.
  • Cluster — Benannte Gruppen von Upstream-Endpoints (Ihre Backend-Services).
  • Endpoints — Individuelle IP:Port-Paare innerhalb eines Clusters, entdeckt via EDS oder statischer Konfiguration.
  • Routes — Regeln, die eingehende Anfragen basierend auf Pfad, Header oder Abfrageparametern auf Cluster abbilden.

Thread-Modell: Envoy verwendet einen Haupt-Thread für die Verwaltung plus einen Worker-Thread pro CPU-Kern. Jeder Worker-Thread verarbeitet Verbindungen unabhängig mit nicht-blockierendem I/O. Kein Lock-Contention auf dem kritischen Pfad — jeder Worker hat seinen eigenen Connection Pool.

Hot Restart: Envoy unterstützt Zero-Downtime-Binary-Upgrades über einen Shared-Memory-Handshake zwischen altem und neuem Prozess. Der neue Prozess übernimmt vorhandene Verbindungen ohne Trafik zu verlieren.

Statische Konfiguration (envoy.yaml)

Der schnellste Einstieg ist eine statische YAML-Konfiguration mit allen inline definierten Ressourcen:

admin:
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 9901

static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address:
          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
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: backend
                      domains: ["*"]
                      routes:
                        - match:
                            prefix: "/"
                          route:
                            cluster: service_backend
                            timeout: 15s
                            retry_policy:
                              retry_on: "5xx,reset,connect-failure"
                              num_retries: 3
                http_filters:
                  - name: envoy.filters.http.router
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

  clusters:
    - name: service_backend
      connect_timeout: 0.5s
      type: STRICT_DNS
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: service_backend
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: backend-service
                      port_value: 8080
      health_checks:
        - timeout: 1s
          interval: 10s
          unhealthy_threshold: 2
          healthy_threshold: 2
          http_health_check:
            path: /health

Der admin-Block stellt Envoys Management-API auf Port 9901 bereit. Verwenden Sie ihn, um /stats, /clusters, /config_dump und /healthcheck/fail für Circuit-Breaker-Tests abzufragen.

Dynamische Konfiguration: Die xDS API

Statische Konfigurationen eignen sich für einfache Deployments, werden aber bei großem Maßstab schwer handhabbar. Envoys xDS (x Discovery Service)-Protokoll erlaubt einer Control Plane, Konfigurationsänderungen zur Laufzeit zu übertragen — kein Reload, kein Neustart.

xDS-Ressourcentypen:

APIVerwaltet
LDS (Listener Discovery Service)Listener und Filterketten
RDS (Route Discovery Service)Virtual Hosts und Routentabellen
CDS (Cluster Discovery Service)Cluster-Definitionen und Richtlinien
EDS (Endpoint Discovery Service)Individuelle Endpoint-Gesundheit IP:Port
SDS (Secret Discovery Service)TLS-Zertifikate und private Schlüssel

ADS (Aggregated Discovery Service): Kombiniert alle xDS APIs in einem einzigen bidirektionalen gRPC-Stream. Das ist der empfohlene Modus, da er Reihenfolge garantiert — ein neuer Cluster wird immer vor der Route geliefert, die ihn referenziert, was temporäre 503-Fehler bei Updates verhindert.

Delta xDS: Statt bei jeder Aktualisierung den vollständigen Zustand zu senden, übermittelt Delta xDS nur hinzugefügte, geänderte oder entfernte Ressourcen. Essenziell für große Meshes mit Tausenden von Clustern.

Load-Balancing-Algorithmen

Envoy unterstützt sechs pro Cluster wählbare Load-Balancing-Richtlinien:

RichtlinieOptimal für
ROUND_ROBINGleichmäßige Backend-Kapazität, Standardwahl
LEAST_REQUESTVariable Anfragedauer, vermeidet überlastete Backends
RING_HASHKonsistentes Hashing — Cache-Affinität, zustandsbehaftete Services
RANDOMEinfach, geringer Overhead, robust gegen langsame Endpoints
MAGLEVGoogles konsistentes Hashing — gleichmäßigere Verteilung
CLUSTER_PROVIDEDDelegiert Entscheidung an Upstream-Cluster-Typ

Observability

Envoy ist eigensinnig bezüglich Observability — es wurde entwickelt, um verteilte Systeme debuggbar zu machen. Drei integrierte Säulen:

Statistiken: Envoy emittiert Tausende von Zählern, Messgrößen und Histogrammen. Stellen Sie sie Prometheus über den Admin-Endpoint bereit:

curl http://localhost:9901/stats/prometheus

Verteiltes Tracing: Envoy generiert und propagiert automatisch Trace-Kontext-Header für Jaeger, Zipkin und OpenTelemetry. Ihre Anwendung muss diese Header nur weiterleiten — Envoy übernimmt die Trace-Erstellung.

Access Logging: Strukturierte JSON-Access-Logs mit allen Anfrage-Metadaten, einschließlich Upstream-Cluster, Dauer, Response-Code und gesendeten Bytes.

TLS und mTLS mit SDS

Envoys Secret Discovery Service (SDS) löst die manuelle Zertifikatsverteilung: Zertifikate werden zur Laufzeit von einer Control Plane bezogen und ohne Prozess-Neustart rotiert.

Für gegenseitiges TLS zwischen Services erzwingt das Feld match_subject_alt_names die SPIFFE-Identität — nur Verbindungen von Services mit dem erwarteten SPIFFE-URI werden akzeptiert. So implementiert Istio Zero-Trust-Networking: Jede Pod-zu-Pod-Verbindung wird gegenseitig mit kurzlebigen, von SPIRE rotierten Zertifikaten authentifiziert.

Erweiterte Filter

Circuit Breaking: Verhindert Kaskadenausfälle durch Begrenzung ausstehender Anfragen, Wiederholungen und Verbindungen. Konfigurieren Sie max_connections, max_pending_requests, max_requests und max_retries pro Cluster.

Outlier Detection: Entfernt automatisch ungesunde Hosts aus dem Load-Balancing-Pool. Nach fünf aufeinanderfolgenden 5xx-Antworten wird der Endpoint für 30 Sekunden ausgeschlossen. max_ejection_percent verhindert die Ausgrenzung aller Hosts bei globaler Upstream-Degradierung.

Fault Injection: Injiziert Latenz oder Fehler in einen Prozentsatz der Anfragen für Chaos-Testing, pro Route konfigurierbar ohne Änderungen am Anwendungscode.

Externe Autorisierung: Delegiert Autorisierungsentscheidungen an einen externen gRPC-Service (OPA, Ory Keto). Der ext_authz-Filter sendet Anfrage-Header an den Autorisierungs-Service, bevor er upstream weiterleitet.

Wasm-Erweiterungen: Envoy unterstützt WebAssembly-Filter-Plugins für benutzerdefinierte Geschäftslogik in jeder Sprache, die zu Wasm kompiliert (Go, Rust, C++). Wasm-Filter werden ohne Binär-Upgrades hot-reloaded.

Envoy vs. Andere Proxies

MerkmalEnvoyNginxHAProxyTraefikLinkerdMOSN
Dynamische KonfigxDS API (kein Reload)nginx -s reloadRuntime APIAuto-K8s-DiscoverxDS (begrenzt)xDS API
Service MeshJa (Istio, Consul)NeinNeinNein (nur Ingress)Ja (Linkerd2)Ja
L7-ProtokolleHTTP/1.1, HTTP/2, gRPC, ThriftHTTP/1.1, HTTP/2HTTP/1.1, HTTP/2HTTP/1.1, HTTP/2HTTP/1.1, HTTP/2, gRPCHTTP/1.1, HTTP/2, Dubbo
ObservabilityStats + Tracing integriertModulbasiertStats-SocketPrometheus-PluginGoldene Signale integriertStats integriert
mTLSSDS + SPIFFEManuelle ZertsManuelle ZertsManuelle ZertsAutomatischSDS
Wasm-FilterJaNeinNeinNeinNeinJa

Praktisches Beispiel: Envoy als Front Proxy

Sie haben drei Microservices (users, orders, products) hinter Envoy als Edge Proxy, mit Traffic-Split zwischen v1 und v2 des Orders-Service für ein Canary-Deployment:

routes:
  - match:
      prefix: "/orders"
    route:
      weighted_clusters:
        clusters:
          - name: orders_v1
            weight: 90
          - name: orders_v2
            weight: 10
        total_weight: 100

Diese gewichtete Cluster-Konfiguration sendet 10% des /orders-Traffics an das v2-Canary ohne Änderungen am Anwendungscode.

Fallstricke und Randfälle

  • Header-Groß-/Kleinschreibung: HTTP/2-Header sind standardmäßig kleingeschrieben. Envoy normalisiert sie — stellen Sie sicher, dass Ihre Services content-type, authorization in Kleinbuchstaben verarbeiten.
  • Upstream- vs. Route-Timeouts: connect_timeout des Clusters (TCP) und timeout der Route (Anfrage) sind unabhängig. Der Standard-Route-Timeout beträgt 15 Sekunden — setzen Sie ihn explizit.
  • Retry-Budget: Ohne Grenzen bei retry_on können Wiederholungen unter Last Ausfälle verstärken. Kombinieren Sie Wiederholungen immer mit einem Circuit Breaker.

Fehlerbehebung

SymptomWahrscheinliche UrsacheLösung
503 upstream_reset_before_response_startedUpstream schloss Verbindung vor AntwortHealth-Check-Pfad prüfen; connect_timeout erhöhen
404 von Envoy (nicht Upstream)Keine passende Route/config_dump auf Admin-Port ausführen; Virtual-Host-Domain prüfen
Circuit Breaker in Stats offenUpstream überlastetmax_pending_requests erhöhen oder Upstream skalieren
mTLS-Handshake-FehlerSAN-Mismatch im ZertifikatPrüfen, ob match_subject_alt_names mit echtem SPIFFE-URI übereinstimmt
Hohe P99-LatenzThread-StarvationWorker-Thread-Anzahl mit concurrency im Bootstrap erhöhen

Zusammenfassung

  • Die xDS API ermöglicht vollständig dynamische Konfiguration ohne Neustarts — Cluster, Routen, Listener und Zertifikate werden live aktualisiert.
  • Load Balancing bietet sechs Algorithmen einschließlich Ring Hash für Cache-Affinität und Least Request für heterogene Workloads.
  • Integrierte Observability liefert Prometheus-Stats, verteilte Tracing-Header und strukturierte JSON-Access-Logs.
  • mTLS via SDS + SPIFFE ermöglicht Zero-Trust-Networking mit kurzlebigen, automatisch rotierten Zertifikaten.
  • Erweiterte Filter machen Envoy erweiterbar, ohne Anwendungscode anzufassen.

Verwandte Artikel