Envoy to wydajny serwer proxy napisany w C++, który siedzi między Twoimi usługami i zarządza całym ruchem sieciowym, jaki przez nie przepływa. Powstał w Lyfcie, został udostępniony jako open source w 2016 roku, a dziś jest projektem graduated w CNCF (tej samej fundacji, co Kubernetes). W praktyce to najpopularniejszy proxy, którego nie widzisz na co dzień, ale który napędza sporą część nowoczesnej infrastruktury chmurowej.
Jak to działa i do czego służy
Klasyczny wzorzec użycia Envoy to sidecar — czyli osobny kontener z proxy dostawiany obok każdej Twojej usługi. Aplikacja nie gada bezpośrednio z innymi usługami, tylko ze swoim lokalnym Envoy, a ten zajmuje się resztą: load balancingiem, ponawianiem nieudanych żądań (retry), timeoutami, circuit breakingiem czy szyfrowaniem TLS. Dzięki temu logikę sieciową wyciągasz z kodu aplikacji i przenosisz na poziom infrastruktury — programista nie musi wklejać tego do każdego serwisu od nowa.
Envoy ogarnia zarówno warstwę L4 (TCP), jak i L7 (HTTP/1.1, HTTP/2, gRPC, a także HTTP/3). Jego mocną stroną jest obserwowalność: z pudełka dostajesz metryki, tracing i szczegółowe logi dostępu, więc widzisz, co dokładnie dzieje się między usługami. Konfigurację można ładować ze statycznego pliku YAML albo dynamicznie przez xDS — zestaw API, dzięki któremu zewnętrzny control plane w locie aktualizuje trasy i listę endpointów bez restartu proxy.
Przykład z praktyki
Najczęściej spotkasz Envoy jako data plane w service meshu Istio — to właśnie Envoy ląduje jako sidecar w każdym podzie, a Istio pełni rolę control plane’a i steruje nim przez xDS. Podobnie robią Consul Connect czy Kuma. Envoy stoi też za bramą Gloo Gateway oraz projektami typu Contour (ingress dla Kubernetesa).
Chcesz pobawić się lokalnie? Odpalasz kontener i podajesz mu konfigurację:
docker run --rm -p 9901:9901 -p 10000:10000 -v $(pwd)/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoy:v1.33-latest
Port 9901 to interfejs administracyjny, gdzie pod /stats podejrzysz metryki, a pod /clusters stan upstreamów.
Częste błędy i mity
Mit pierwszy: „Envoy = service mesh”. Nie — Envoy to tylko proxy (data plane). Mesh powstaje dopiero, gdy dołożysz control plane jak Istio. Sam Envoy bez sterowania to po prostu reverse proxy.
Pułapka druga: konfiguracja YAML potrafi przytłoczyć juniora swoją gadatliwością. Nie ucz się jej na pamięć — w realnych wdrożeniach i tak generuje ją control plane, a Ty rzadko dotykasz surowego pliku. Uważaj też na interfejs admina (9901): nie wystawiaj go publicznie, bo daje wgląd w wewnętrzny stan i pozwala zmieniać poziom logowania.
Pojęcia powiązane
Warto kojarzyć: service mesh, Istio, sidecar, reverse proxy, load balancer, control plane i data plane, xDS API, gRPC oraz API gateway. Z konkurentów do tematu: NGINX, HAProxy i Linkerd (który ma własny lekki proxy zamiast Envoy).