Envoy Proxy

Dynamic Config

Warstwa: Control Plane

xDS API — zmiana konfiguracji bez restartu

Integracje: Istio, Consul, własny control plane

Load Balancing

Warstwa: L7

Round Robin, Least Request, Ring Hash, Maglev, Random

Integracje: Wbudowany

Circuit Breaking

Warstwa: L7

Outlier Detection (passive) + Active Health Check

Integracje: Wbudowany

mTLS

Warstwa: L4/L7

Mutual TLS między serwisami, cert rotation przez SDS

Integracje: Istio Citadel, SPIRE

Distributed Tracing

Warstwa: L7

Zipkin, Jaeger, OpenTelemetry — per-request trace headers

Integracje: Wbudowany + backends

Rate Limiting

Warstwa: L7

Local (token bucket) + Global (ratelimit service + Redis)

Integracje: lyft/ratelimit, Envoy + Redis

Co to jest Envoy Proxy i czym różni się od Nginx?

Envoy Proxy: high-performance, cloud-native L4/L7 proxy napisany w C++ (Lyft, 2016, CNCF graduated). Projektowany dla mikrousług i service mesh. Główne różnice Envoy vs Nginx: Envoy — dynamiczna konfiguracja przez API (xDS). Nginx — statyczna konfiguracja (wymaga reload). Envoy — L7 aware (HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket). Nginx — L4 + L7 ale mniej rozbudowane. Envoy — observability first (per-request metrics, distributed tracing). Nginx — podstawowe metryki bez per-request granularity. Envoy — extensible filters pipeline. Nginx — modules system (mniej elastyczny). Envoy xDS (Extensible Discovery Service) API: Listener Discovery Service (LDS). Route Discovery Service (RDS). Cluster Discovery Service (CDS). Endpoint Discovery Service (EDS). Secret Discovery Service (SDS) — TLS certs. Aggregated Discovery Service (ADS) — wszystko razem. Control plane (Istio, Consul Connect) aktualizuje konfigurację Envoy dynamicznie przez xDS bez restartu. Data plane: Envoy proxy per-pod (sidecar) lub standalone. Admin API: localhost:9901 dla metrics, config dump, health check.

Envoy jako sidecar proxy w service mesh — jak działa?

Service Mesh data plane: Envoy sidecar wstrzykiwany do każdego poda jako dodatkowy kontener. Ruch aplikacji przechodzi przez Envoy (iptables intercept). Envoy obsługuje: mTLS (Mutual TLS) między serwisami. Load balancing (Round Robin, Least Request, Ring Hash, Maglev). Circuit Breaking (Outlier Detection). Retries i timeouts (per route, per cluster). Rate limiting (local i global przez ext-authz). Distributed Tracing (Zipkin, Jaeger, OpenTelemetry). Istio + Envoy: Istio jako control plane (Pilot, Citadel, Galley). Envoy jako data plane. VirtualService (routing rules) -> Envoy Route Config. DestinationRule (traffic policy) -> Envoy Cluster config. PeerAuthentication -> mTLS policy. AuthorizationPolicy -> Envoy ext-authz filter. Consul Connect: HashiCorp Consul jako control plane. Envoy jako data plane. Service intentions zamiast K8s CRDs. Traffic analysis: kiali.io — wizualizacja service mesh (Istio). Traffic flow, error rates, latency per service. Zipkin/Jaeger traces przez Envoy. Envoy performance: sub-millisecond overhead. Benchmarki: 1% CPU, 10MB RAM per sidecar dla typowego serwisu.

Envoy xDS API — jak kontrolować Envoy programatycznie?

xDS (Extensible Discovery Service): gRPC API do dynamicznej konfiguracji Envoy. Control plane (twój serwis lub Istio/Consul) implementuje xDS server. Envoy łączy się jako klient i pobiera konfigurację. xDS resources: Listener: port, protokół (HTTP/TCP/UDP), filter chain. Route: matching (prefix, header, regex) -> action (route, redirect, direct response). Cluster: backend upstream (IP list lub DNS). Load balancing policy. Circuit breaker config. Health check config. Endpoint: konkretne IP:port dla klastra. Weighted routing dla A/B testing i canary. Secret: TLS certyfikaty i klucze. State of the World (SotW) vs Delta xDS: SotW — wysyłaj kompletny stan przy każdej zmianie. Delta — wysyłaj tylko zmiany. Bardziej efektywny dla dużych deploymentów. go-control-plane (Google): Go biblioteka do implementacji xDS server. java-control-plane: Java biblioteka. Przykład użycia: własny control plane dla custom routing logic. Feature flag -> zmiana routing rules przez xDS. Canary: 5% ruchu na new-service-v2 przez Endpoint weight. Fault injection: Envoy fault filter — inject errors/delays dla testów. Chaos engineering bez modyfikacji kodu.

Envoy rate limiting, circuit breaking i outlier detection?

Rate Limiting w Envoy: Local Rate Limiting: per-Envoy instancja, nie wymaga zewnętrznego serwisu. Konfiguracja przez token bucket filter. Globalne Rate Limiting: ratelimit service (gRPC) — centralne rate limiting. Envoy wysyła request do ratelimit service przed forwarding. Redis backend dla współdzielonego state. Descriptors: per user, per IP, per API key, per endpoint. Circuit Breaking: Outlier Detection (passive) — Envoy obserwuje błędy upstream. 5xx errors lub latencja -> eject endpoint. Konfiguracja: consecutive_5xx — ile błędów przed eject. interval, base_ejection_time, max_ejection_percent. Pendinig Requests Limit — max requests w kolejce. Max Connections — max TCP connections do upstream. Max Retries — max retry requests. Active health checking: HTTP health check (periodic /health). TCP health check. gRPC health check (grpc.health.v1.Health). Retries: retry_on — 5xx, gateway-error, connect-failure, retriable-4xx. num_retries — maksymalna liczba prób. retry_back_off — Jitter dla exponential backoff. Hedging: wyślij request do wielu backends równolegle, użyj pierwszej odpowiedzi. Zmniejsza tail latency.

Envoy Filter chain i rozszerzenia — Lua, WASM, ext-proc?

Envoy Network Filters: HTTP Connection Manager (HCM) — parsowanie HTTP, routing, header manipulation. TCP Proxy — transparent proxy dla TCP. Thrift Proxy, MongoDB Proxy, Redis Proxy — application-aware proxying. HTTP Filters (na HCM): Router — końcowy filter, forward do upstream. CORS — obsługa preflight i CORS headers. CSRF — ochrona przed CSRF. gzip — kompresja odpowiedzi. Fault Injection — losowe błędy/delays (chaos engineering). Health Check — odpowiedz na health checks bez forwarding. JWT Authentication — weryfikacja JWT. OAuth2 — OAuth flow. Rate Limit — integracja z ratelimit service. External Processing (ext-proc): gRPC call do zewnętrznego serwisu per-request. Umożliwia custom request/response processing. Używane przez: advanced auth (OPA), request transformation, custom logging. WASM (WebAssembly) filters: extend Envoy przez WASM. C++, Rust, Go, AssemblyScript -> WASM. proxy-wasm spec. Bezpieczny sandbox. Solo.io Gloo, Tetrate — commercial products nad Envoy. Ambassador: Envoy + Kubernetes ingress controller. Open source, CRD-based config. Emissary-ingress (fork Ambassador). Contour: VMware, Envoy + HTTPProxy CRD. GitOps friendly.

Wyślij zapytanie