Sidecar proxy je architektonický vzor (design pattern) v moderním vývoji softwaru, při kterém je vedle hlavní aplikace (hlavního kontejneru) spuštěn pomocný síťový proxy server. Tento pomocný kontejner běží ve stejném síťovém prostoru a sdílí stejné zdroje (např. v rámci jednoho Podu v Kubernetes), ale stará se o síťovou komunikaci nezávisle na samotné aplikaci.

V mikroslužbové architektuře řeší každá aplikace řadu stejných úkolů: šifrování provozu, autentizaci, logování, sledování metrik nebo retry politiky při výpadcích. Namísto toho, aby vývojáři tuto logiku složitě programovali přímo do každé aplikace v různých jazycích (Java, Go, Python apod.), přesune se tato síťová odpovědnost do sidecar proxy.

1. Izolace odpovědnosti: Hlavní aplikace se stará pouze o svou business logiku a posílá požadavky „lokálně“. 2. Přesměrování provozu: Veškerý příchozí i odchozí síťový provoz je automaticky zachycen a přesměrován přes sidecar proxy (např. pomocí nástrojů jako Envoy). 3. Transparentní zpracování: Proxy požadavek zpracuje (např. přidá hlavičky pro trasování, zašifruje jej) a odešle jej dál do sítě nebo k jiné mikroslužbě.

* Výhody: * Univerzálnost: Funguje nezávisle na programovacím jazyku, ve kterém je napsaná hlavní aplikace. * Konzistence: Celá firma může vynucovat stejná bezpečnostní pravidla a metriky napříč všemi službami. * Snadnější údržba: Aktualizace síťových politik se provádí centrálně na úrovni proxy, nikoliv v kódu aplikací. * Nevýhody: * Zvýšená spotřeba zdrojů: Každá instance aplikace vyžaduje dodatečný kontejner s proxy, což klade vyšší nároky na paměť a CPU. * Mírná latence: Každý síťový požadavek prochází dalším síťovým hopem (skokem) uvnitř Podu.

Tip: V moderních systémech Kubernetes tvoří sidecar proxy základní stavební kámen tzv. Service Mesh platform (např. Istio nebo Linkerd), kde tyto proxy servery automaticky řídí veškerý provoz mezi desítkami či stovkami mikroslužeb.