Wprowadzenie do service mesh: po co Istio i Linkerd - Blog

Problem nie zaczyna się od mesha.

Zaczyna się od tego, że jedna aplikacja przestaje być jedną aplikacją.

text

frontend
  -> api
     -> payments
     -> inventory
     -> notifications

Na początku wystarcza HTTP client w kodzie.

Potem pojawiają się pytania:

text

czy ten request jest szyfrowany?
kto naprawdę woła tę usługę?
ile trwa call do payments?
czy retry pogorszy awarię?
czy timeout jest taki sam w każdej usłudze?
gdzie zobaczyć graf zależności?

Można odpowiedzieć biblioteką w każdej aplikacji.

Tylko wtedy każda aplikacja musi umieć to samo.

Co było przed service meshem

W prostszym systemie dużo logiki siedziało na brzegu.

text

client
  |
  v
load balancer / ingress / API gateway
  |
  v
application

Brzeg mógł kończyć TLS, routować requesty i zbierać część metryk.

To działa, dopóki najważniejszy ruch idzie z zewnątrz do środka.

W mikroserwisach duża część problemu przenosi się do środka klastra:

text

service A -> service B
service B -> service C
service C -> service D

Ingress nie widzi całej tej rozmowy.

API gateway też zwykle nie widzi każdego połączenia service-to-service.

Jeżeli każda usługa sama implementuje retry, timeouty, TLS, metryki i polityki dostępu, to po kilku latach platforma ma tyle modeli komunikacji, ile zespołów.

Service mesh powstał jako próba wyjęcia tej powtarzalnej logiki z aplikacji.

Czym jest service mesh

Service mesh to warstwa infrastruktury dla ruchu między usługami.

Najczęściej dodaje:

text

mTLS między usługami
tożsamość workloadów
metryki requestów
tracing
retry i timeouty
routing między wersjami
polityki dostępu

Kluczowe jest miejsce, w którym ta logika działa.

Aplikacja nadal wysyła zwykły request:

await fetch("http://payments/charge");

Obok aplikacji albo przed nią działa proxy.

text

app container
  |
  v
local proxy
  |
  v
network
  |
  v
local proxy
  |
  v
other app container

Proxy może dodać TLS, zebrać metryki, zastosować policy albo zmienić routing bez dopisywania tego w kodzie usługi.

Najprostszy model w Kubernetes

W klasycznym modelu sidecar mesh dokłada proxy do Poda.

Przed meshem Pod wygląda tak:

text

Pod
  api

Po wstrzyknięciu sidecara:

text

Pod
  api
  proxy

Aplikacja nie musi wiedzieć, że obok działa proxy.

To platforma kieruje ruch przez ten proxy.

Najprostszy przykład operacyjny wygląda jak włączenie mesha dla namespace:

bash

kubectl label namespace apps istio-injection=enabled
kubectl rollout restart deployment/api -n apps

albo w Linkerd:

bash

kubectl annotate namespace apps linkerd.io/inject=enabled
kubectl rollout restart deployment/api -n apps

To nie jest cała konfiguracja produkcyjna.

To tylko moment, w którym workload zaczyna być częścią mesha.

Po co Istio

Istio jest cięższym i bardziej rozbudowanym meshem.

Ma sens, gdy potrzebujemy dużo kontroli nad ruchem, bezpieczeństwem i politykami.

Typowe powody:

text

mTLS jako domyślny model komunikacji
policy per workload
zaawansowany routing
canary i traffic shifting
telemetria ruchu service-to-service
integracja z Envoy
multi-cluster albo hybrydowe środowiska

Istio historycznie kojarzy się z sidecarami opartymi o Envoy, ale dziś ma też ambient mode, który próbuje zmniejszyć koszt operacyjny sidecarów.

To nadal jest narzędzie dla sytuacji, w których platforma chce mocno programować sieć aplikacyjną.

Po co Linkerd

Linkerd idzie w inną stronę.

Jego główny argument to prostszy, lżejszy mesh dla Kubernetes.

Typowe powody:

text

automatyczne mTLS
metryki per service
retries i timeouts
load balancing
prostszy model operacyjny
mniejszy proxy

Jeżeli zespół chce głównie szyfrowania, podstawowej obserwowalności i bezpieczniejszego service-to-service bez budowania dużej platformy polityk, Linkerd bywa bardziej naturalnym wyborem.

To nie znaczy, że Linkerd jest "tylko prosty".

Raczej: wybiera mniejszą powierzchnię operacyjną.

Czego service mesh nie rozwiązuje

Service mesh nie naprawia złych granic między usługami.

Jeżeli usługi wołają się zbyt często, mesh pokaże ten problem wyraźniej, ale nie usunie zależności.

Service mesh nie zastępuje dobrego API.

Nie zastępuje też decyzji, które timeouty, retry i polityki są poprawne biznesowo.

Może wymusić mTLS, ale nie powie sam, która usługa powinna mieć dostęp do której operacji.

Może dać świetne metryki, ale nadal trzeba wiedzieć, które z nich oznaczają problem.

Kiedy to ma sens

Service mesh ma sens, gdy problem service-to-service jest już realny:

text

dużo usług
wiele zespołów
brak spójnych timeoutów
brak wspólnego mTLS
trudne debugowanie zależności
potrzeba polityk między workloadami
rollouty zależne od routingu wewnątrz klastra

Nie ma sensu wdrażać mesha tylko dlatego, że klaster ma Kubernetes.

Jeżeli system ma kilka usług i proste zależności, mesh może dodać więcej warstw niż problemów rozwiąże.

Najprostsze pytanie brzmi:

text

czy problem jest w aplikacji, czy w powtarzalnym ruchu między aplikacjami?

Jeżeli problem powtarza się w każdej usłudze, service mesh zaczyna być narzędziem platformowym, a nie ozdobą architektury.