Service Mesh

Warstwa infrastruktury zarządzająca komunikacją między mikrousługami: ruchem, bezpieczeństwem i monitorowaniem. Popularne implementacje to Istio i Linkerd.

Service mesh to dedykowana warstwa infrastruktury, która przejmuje całą komunikację sieciową między mikrousługami i zarządza nią w jednym miejscu: routingiem ruchu, bezpieczeństwem połączeń, ponawianiem nieudanych żądań oraz monitoringiem. Zamiast wpychać tę logikę do kodu każdej usługi, mesh wynosi ją na zewnątrz, do osobnego komponentu, który siedzi obok Twojej aplikacji i obsługuje ruch za nią.

W klasycznym wariancie service mesh działa w modelu sidecar: obok każdej instancji usługi (zwykle w tym samym podzie Kubernetesa) uruchamiany jest mały proxy, najczęściej Envoy. Cały ruch wchodzący i wychodzący przechodzi przez ten proxy. Dzięki temu Twoja aplikacja „myśli”, że gada zwyczajnie po HTTP z sąsiadem, a w tle proxy szyfruje połączenie, sprawdza polityki dostępu i zlicza metryki.

Mesh dzieli się na dwie części. Data plane to zbiór tych proxy, które realnie przepychają pakiety. Control plane to mózg, który konfiguruje proxy, rozdaje certyfikaty i pilnuje reguł. Najpopularniejsze implementacje to Istio (control plane istiod + proxy Envoy) oraz Linkerd, ceniony za lekkość i własny szybki micro-proxy w Ruście. Coraz głośniej jest też o trybie bez sidecarów — Istio ma model ambient, który zdejmuje proxy z każdego poda na rzecz wspólnego węzła.

Przykład z praktyki

Masz w Kubernetesie usługę payments i chcesz wdrożyć nową wersję bez ryzyka. Z Istio definiujesz VirtualService, który kieruje 90% ruchu na wersję v1, a 10% na v2 (canary release). Sprawdzasz dashboard, widzisz, że v2 nie sypie błędami 5xx, i płynnie przesuwasz ruch do 100% — bez zmiany jednej linijki w kodzie usługi. Przy okazji włączasz mTLS, więc payments i orders rozmawiają po szyfrowanym kanale z wzajemną weryfikacją tożsamości. Stan siatki podejrzysz np. komendą istioctl proxy-status.

Częste błędy i mity

  • „Mesh to za darmo” — nie jest. Każdy sidecar zjada trochę CPU, RAM i dokłada milisekundy opóźnienia. Przy paru usługach to przerost formy nad treścią.
  • Wrzucanie mesha na starcie projektu — jeśli masz trzy usługi, prawdopodobnie wystarczy biblioteka do retry i zwykły load balancer.
  • Mylenie z API Gateway — gateway pilnuje ruchu wchodzącego z zewnątrz (north-south), a mesh ogarnia ruch między usługami wewnątrz klastra (east-west).

Pojęcia powiązane: mikrousługi, Kubernetes, sidecar proxy, Envoy, mTLS, observability (metryki, tracing, logi), API Gateway, canary release, circuit breaker.