Istio

Otwartoźródłowa platforma typu service mesh do zarządzania i zabezpieczania mikrousług. Zapewnia kontrolę ruchu, równoważenie obciążenia i monitorowanie.

Istio to otwartoźródłowa platforma typu service mesh, czyli warstwa, która siada pomiędzy Twoimi mikrousługami i przejmuje całą komunikację sieciową między nimi. Zamiast wpisywać logikę ponawiania zapytań, szyfrowania czy zbierania metryk do kodu każdej usługi z osobna, oddajesz to Istio. Twoja aplikacja po prostu wysyła żądanie HTTP/gRPC, a Istio ogarnia resztę: routing, równoważenie obciążenia, szyfrowanie ruchu (mTLS), retry, timeouty i obserwowalność.

Jak to działa

Istio dzieli się na dwie części. Data plane to zestaw proxy opartych na Envoy, które przechwytują ruch wchodzący i wychodzący z każdej usługi. Klasycznie wstrzykuje się je jako kontener sidecar do każdego poda w Kubernetes, więc kod aplikacji nawet nie wie, że ktoś nim steruje. Control plane, czyli komponent istiod, zarządza tymi proxy: rozsyła konfigurację, certyfikaty i reguły routingu.

Konfigurujesz to deklaratywnie przez zasoby Kubernetes (CRD). Najważniejsze to VirtualService (gdzie i jak kierować ruch) oraz DestinationRule (polityki dla docelowej usługi, np. load balancing czy circuit breaking). Od jakiegoś czasu Istio ma też tryb ambient, który rezygnuje z sidecarów na rzecz lekkiego węzłowego komponentu ztunnel — mniej narzutu na pamięć.

Przykład z praktyki

Masz dwie wersje usługi reviews i chcesz puścić canary deployment: 90% ruchu na v1, 10% na v2. W VirtualService ustawiasz weight: 90 i weight: 10 na odpowiednich subset, aplikujesz przez kubectl apply -f reviews-vs.yaml i obserwujesz metryki w Kiali albo Grafanie. Bez dotykania kodu, bez redeploya aplikacji. Jak v2 sypie błędami, przesuwasz wagę z powrotem na 100/0.

Na co uważać

Pierwszy mit: „Istio jest darmowe, więc tanie”. Software owszem, ale sidecary zżerają CPU i RAM, a do tego dochodzi narzut latencji na każdym hopie. Drugi: ludzie wrzucają Istio do projektu z trzema usługami, bo brzmi profesjonalnie — i topią się w YAML-u. Service mesh zaczyna się opłacać przy kilkunastu+ usługach. Klasyczna pułapka to też mTLS w trybie STRICT włączony zanim wszystkie usługi mają proxy — wtedy ruch z legacy poda nagle ginie z błędem połączenia.

Pojęcia powiązane

Warto znać: Envoy, Kubernetes, sidecar, mTLS, Linkerd i Consul Connect (konkurencyjne service mesh), API Gateway, observability oraz canary deployment.