Cloud Native / Kubernetes

Service Mesh

Zamiast implementować mTLS, circuit breakers i tracing w każdej mikrousłudze osobno, Service Mesh wyciąga tę logikę do dedykowanej warstwy infrastruktury — transparentnej dla kodu aplikacji.

Istio / Linkerd

Popularne

Envoy / Rust

Proxy

mTLS + SPIFFE

Security

Sidecar Proxy

Pattern

6 kluczowych funkcji Service Mesh

Service Mesh dostarcza funkcje sieciowe które normalnie wymagają implementacji w każdej mikrousłudze — raz, na poziomie infrastruktury.

mTLS (Mutual TLS)

Security

Wzajemna autentykacja między serwisami. Szyfrowanie całego ruchu wewnętrznego.

Circuit Breaking

Reliability

Automatyczne wyłączanie usług które zwracają błędy. Zapobiega kaskadowym awariom.

Canary Deployments

Traffic Mgmt

Routing % ruchu do nowej wersji serwisu. Bezpieczne rollout bez downtime.

Distributed Tracing

Observability

Automatyczne zbieranie traces przez Envoy bez zmian w kodzie aplikacji.

Retry Logic

Reliability

Automatyczne retry nieudanych requestów z konfigurowalnymi politykami.

Rate Limiting

Traffic Mgmt

Ograniczanie liczby requestów per serwis lub per klient (global + local).

Istio vs. Linkerd

Dwa najpopularniejsze Service Mesh — Istio z bogatym feature setem vs. Linkerd z prostotą i minimalnym overhead.

Aspekt	Istio	Linkerd
Proxy	Envoy (C++)	Linkerd2-proxy (Rust)
Overhead	Wyższy (Envoy)	Niższy (ultra-lightweight)
Feature set	Bardzo bogaty	Podstawowy + mTLS
Złożoność	Wysoka	Niska
mTLS	Tak (SPIFFE)	Tak (SPIFFE)
Adopcja	Dominująca	Niszowa ale lojalna

Często zadawane pytania

Co to jest Service Mesh i dlaczego powstał?

Service Mesh to warstwa infrastruktury która zarządza komunikacją między mikrousługami w sposób transparentny dla aplikacji. Zamiast implementować logikę sieciową (retries, timeouty, circuit breakers, mTLS, observability) w każdej usłudze osobno, Service Mesh wyciąga ją do dedykowanej warstwy. Problem który rozwiązuje: w architekturze mikrousług każdy serwis musi radzić sobie z: load balancing, service discovery, circuit breaking, timeouts, retries, mTLS (wzajemna autentykacja), distributed tracing, rate limiting. Implementowanie tego w każdej usłudze to duplikacja kodu, różne języki programowania = różne implementacje, trudne zarządzanie. Service Mesh rozwiązuje przez: Sidecar proxy (Envoy) wstrzyknięty obok każdego poda. Proxy przechwytuje cały ruch sieciowy. Control plane zarządza konfiguracją wszystkich proxy. Data plane — Envoy proxy na poziomie per-pod. Control plane — Istiod (Istio), Linkerd control plane. Alternatywy: Istio (najpopularniejszy, oparty na Envoy), Linkerd (lekki, Rust-based proxy), Consul Connect (HashiCorp), Kuma (Kong), AWS App Mesh.

Jak działa Istio — architektura i komponenty?

Istio — architektura: Data Plane: Envoy proxy jako sidecar container w każdym podzie. Automatycznie wstrzykiwany przez Istio admission controller (MutatingWebhookConfiguration). Przechwytuje CAŁY ruch IN i OUT z poda przez iptables rules. Control Plane (Istiod): Pilot — service discovery, routing rules dla Envoy. Citadel — certificate authority (mTLS certificates). Galley — konfiguracja validation. W Istio 1.5+ wszystkie zintegrowane w jeden proces Istiod. Kluczowe zasoby Kubernetes (CRDs): VirtualService — definiuje routing rules (np. 20% ruchu do v2). DestinationRule — policy per destination (load balancing algo, circuit breaker thresholds, TLS). Gateway — ingress/egress dla Service Mesh. ServiceEntry — rejestracja zewnętrznych serwisów. AuthorizationPolicy — RBAC na poziomie serwisów. PeerAuthentication — wymóg mTLS między serwisami. Traffic Management: canary deployments — 5% ruchu do nowej wersji. A/B testing — routing po nagłówkach HTTP. Fault injection — dodaj opóźnienie lub błąd do konkretnego serwisu (chaos engineering built-in). Mirror traffic — duplikuj ruch do shadow service. Kiali — UI dashboard dla Istio (service graph, traffic flow).

mTLS w Service Mesh — jak działa i dlaczego ważne?

mTLS (mutual TLS) w Service Mesh: TLS (standardowe HTTPS): klient weryfikuje certyfikat serwera. Serwer nie weryfikuje klienta. mTLS: obie strony wzajemnie weryfikują swoje certyfikaty. Serwer wie z którym serwisem rozmawia. Dlaczego ważne w mikrousługach: bez mTLS — kompromitacja jednego poda pozwala atakować wszystkie inne serwisy w sieci wewnętrznej. Z mTLS — każdy serwis ma tożsamość (SPIFFE ID). Komunikacja między serwisami jest szyfrowana i autentykowana. Nawet jeśli atakujący jest w sieci — nie może podszywać się pod serwis. Zero Trust Network: mTLS jest fundamentem Zero Trust w Kubernetes. Nie ufaj sieci wewnętrznej — weryfikuj każdą komunikację. Jak Istio zarządza mTLS: Istiod działa jako Certificate Authority. Automatycznie rotuje certyfikaty (krótkotrwałe, SPIFFE). Sidecar Envoy obsługuje handshake TLS transparentnie dla aplikacji. Tryby: STRICT (wymaga mTLS), PERMISSIVE (akceptuje i TLS i plain). Workload Identity: SPIFFE/SPIRE standard — serwis ma tożsamość (URI: spiffe://cluster.local/ns/default/sa/frontend). AuthorizationPolicy może kontrolować komunikację: serwis A może rozmawiać tylko z serwisem B.

Service Mesh vs. API Gateway — różnice i kiedy używać?

Service Mesh vs. API Gateway: API Gateway: zarządza ruchem ZEWNĘTRZNYM (North-South). Klient zewnętrzny → API Gateway → backend. Funkcje: autentykacja zewnętrzna, rate limiting, SSL termination, routing, transformacja requestów. Narzędzia: Kong, AWS API Gateway, Nginx, Traefik. Service Mesh: zarządza ruchem WEWNĘTRZNYM (East-West). Mikrousługa A → Serwis Mesh Proxy → Mikrousługa B. Funkcje: mTLS, circuit breaking, retry, distributed tracing, canary inside cluster. Narzędzia: Istio, Linkerd, Consul. Kiedy używać obu razem: API Gateway na granicy klastra (ingress). Service Mesh wewnątrz klastra między serwisami. To jest popularny pattern w enterprise K8s. Kiedy Service Mesh może być za dużo: małe projekty z 3-5 serwisami — overhead Service Mesh nie jest wart. Dodaje latency (sidecar proxy + iptables rules). Złożoność operacyjna. Linkernd vs. Istio: Linkerd — prostszy, lżejszy (Rust proxy zamiast Envoy), mniej features ale też mniej złożony w operacji. Istio — pełen feature set, większa adopcja, ale wymaga doświadczonego SRE/Platform Engineer do zarządzania.

Jak wdrożyć Service Mesh — krok po kroku i pułapki?

Wdrożenie Service Mesh: Krok 1 — Ocena gotowości: czy masz wystarczającą liczbę serwisów? Czy masz problemy które Service Mesh rozwiązuje (mTLS, observability, traffic management)? Krok 2 — Wybór narzędzia: Istio (pełen feature set, duża społeczność) vs. Linkerd (prostszy, lżejszy). Krok 3 — Instalacja: Istio — istioctl install --set profile=default. Linkerd — linkerd install | kubectl apply. Krok 4 — Wstrzykiwanie sidecar: per namespace: kubectl label namespace default istio-injection=enabled. Per deployment (adnotacja). Krok 5 — Migracja do mTLS: zacznij od PERMISSIVE mode (akceptuje plain i mTLS). Sprawdź który ruch jest plain. Przełącz na STRICT mode per namespace stopniowo. Krok 6 — Traffic Management: wdróż pierwsze VirtualService i DestinationRule dla canary deployment. Krok 7 — Observability: skonfiguruj Kiali + Jaeger + Prometheus przez Istio addons. Pułapki: Resource overhead: każdy Envoy sidecar = 50-100MB RAM + CPU. W dużych klastrach adduje się. Debugging: istioctl analyze i istioctl proxy-config do debuggingu mesh config. mTLS STRICT too early: zablokuje health checks i zewnętrzne połączenia jeśli nie skonfigurowane. Sidecar injection failure: aplikacja nie startuje jeśli sidecar injection webhook nie działa.

Czytaj dalej