Service Mesh

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

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

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

Automatyczne zbieranie traces przez Envoy bez zmian w kodzie aplikacji.

Automatyczne retry nieudanych requestów z konfigurowalnymi politykami.

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

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.

Wyślij zapytanie