Sidecar

Dodatkowy kontener działający obok głównego kontenera aplikacji w tym samym podzie, rozszerzający jego funkcje. Często używany w service mesh do obsługi sieci czy logów.

Sidecar (sidecar container) to dodatkowy kontener, który uruchamiasz obok głównego kontenera aplikacji w tym samym podzie (Kubernetes), żeby rozszerzyć jego możliwości bez dotykania kodu samej aplikacji. Nazwa wzięła się z motocyklowej przyczepki bocznej: jedzie obok, dokłada funkcję, ale to nie ona prowadzi. W praktyce sidecar przejmuje zadania poboczne — logowanie, proxy sieciowe, szyfrowanie ruchu, synchronizację plików — a Twoja aplikacja zajmuje się tylko swoją robotą.

Jak to działa

Kluczowe jest słowo pod. W Kubernetesie pod to najmniejsza jednostka, w której może żyć kilka kontenerów. Wszystkie dzielą tę samą przestrzeń sieciową (ten sam localhost i adres IP) oraz mogą współdzielić wolumeny. Dzięki temu sidecar i kontener główny gadają ze sobą po localhost, jakby siedziały na jednej maszynie, a pliki wymieniają przez wspólny emptyDir.

Sidecar realizuje wzorzec separation of concerns: kod aplikacji nie musi wiedzieć, jak zbierać metryki czy szyfrować połączenia. Tę odpowiedzialność wynosisz do osobnego kontenera, który możesz wdrażać, aktualizować i reużywać niezależnie. Jeden obraz sidecara obsługuje wtedy dziesiątki różnych aplikacji.

Przykład z praktyki

Najgłośniejsze zastosowanie to service mesh, np. Istio. Do każdego poda wstrzykiwany jest sidecar z proxy Envoy, które przechwytuje cały ruch wchodzący i wychodzący. Dzięki temu dostajesz mTLS, retry, timeouty, load balancing i metryki — bez jednej linijki w kodzie aplikacji. W manifeście poda zobaczysz wtedy dwa kontenery: Twój i istio-proxy.

Inny klasyk: kontener z Fluent Bit, który czyta logi aplikacji ze wspólnego wolumenu i wysyła je do Elasticsearcha. Od Kubernetesa 1.29 masz też natywne sidecary — deklarujesz je w initContainers z restartPolicy: Always, dzięki czemu startują przed aplikacją i nie blokują zakończenia poda.

Na co uważać

Sidecar to nie magia za darmo. Każdy dokłada zużycie CPU i RAM — przy setkach podów rachunek rośnie szybko. Częsty błąd to klasyczny sidecar bez natywnego wsparcia: w Jobie kontener główny kończy pracę, a sidecar dalej działa i pod nigdy się nie domyka. Drugi grzech to brak limitów zasobów — wtedy proxy potrafi zagłodzić aplikację. Pamiętaj też, że sidecar i aplikacja dzielą cykl życia poda: restart poda restartuje oba.

Pojęcia powiązane: pod, init container, service mesh, Istio, Envoy, ambassador pattern, adapter pattern, DaemonSet (alternatywa, gdy funkcja ma być per-węzeł, a nie per-pod).