Service mesh Istio w architekturze mikroserwisów: role i podział odpowiedzialności w zespole

Service mesh to warstwa infrastruktury, która przejmuje komunikację między mikroserwisami: szyfruje ją, kieruje ruchem i zbiera telemetrię bez zmian w kodzie aplikacji. W Istio zespół platformowy prowadzi płaszczyznę sterowania, bramy i polityki całej siatki, zespoły aplikacyjne konfigurują routing i autoryzację we własnych przestrzeniach nazw, a bezpieczeństwo wyznacza docelowy tryb mTLS.

Na skróty

Czego dowiesz się z artykułu:

• Z czego składa się Istio i jakie mechanizmy daje mikroserwisom
• Jak wybór trybu sidecar albo ambient zmienia podział pracy
• Co należy do zespołu platformowego, zespołów aplikacyjnych i bezpieczeństwa
• Co sprawdzić przed wyborem usługi zarządzanej u dostawcy chmury

Dla kogo jest ten artykuł:

• Architekci i liderzy zespołów platformowych
• Zespoły DevOps i SRE utrzymujące klastry Kubernetes
• Liderzy zespołów aplikacyjnych i specjaliści bezpieczeństwa

Czas czytania: 7 minut

Co Istio robi w architekturze mikroserwisów

Istio składa się z płaszczyzny sterowania (istiod), która przyjmuje pożądaną konfigurację i programuje serwery proxy Envoy, oraz z płaszczyzny danych, czyli tych serwerów proxy pośredniczących w ruchu między usługami. Mechanizmy, z których korzystają zespoły, to przede wszystkim:

• wzajemne uwierzytelnianie TLS (mTLS) — każda usługa ma tożsamość zapisaną w certyfikacie, a istiod automatyzuje wydawanie i odnawianie kluczy;
• polityki ruchu — routing, podział ruchu między wersjami usług, limity czasu i ponowienia;
• polityki autoryzacji — reguły z akcjami ALLOW, DENY i CUSTOM egzekwowane w Envoy;
• telemetria — metryki, logi i ślady komunikacji między usługami.

Projekt jest dojrzały organizacyjnie: według www.cncf.io Istio przyjęto do CNCF 30 września 2022 r. na poziomie Incubating, a 12 lipca 2023 r. uzyskał status Graduated.

Tryb wdrożenia zmienia podział odpowiedzialności

Dokumentacja na istio.io opisuje dwa tryby płaszczyzny danych. W trybie sidecar przy każdym podzie działa własny Envoy. W trybie ambient ruch przechodzi przez proxy ztunnel działające na każdym węźle (warstwa 4), a funkcje warstwy 7 dodaje się opcjonalnie przez proxy waypoint. Według tej samej dokumentacji tryb ambient jest gotowy do produkcji w pojedynczym klastrze od wersji 1.22, a w porównaniu trybów opisano go jako stabilny tylko dla pojedynczego klastra.

Dla podziału ról najważniejszy jest jeden wiersz porównania na istio.io: w trybie sidecar cyklem życia proxy zarządza deweloper aplikacji, w trybie ambient administrator platformy. W sidecar dołączenie usługi do siatki wymaga restartu podów, w ambient wystarczy etykieta przestrzeni nazw. Jeżeli zespoły aplikacyjne nie chcą zajmować się proxy, ambient przesuwa tę pracę do zespołu platformowego. Ceną jest to, że autoryzacja i telemetria warstwy 7 wymagają waypointów, które ktoś musi zaplanować.

Kto za co odpowiada

Istio przechowuje polityki w hierarchii: polityka dla całej siatki leży w przestrzeni nazw root, polityka przestrzeni nazw w danej przestrzeni, a polityka dla konkretnego obciążenia ma niepusty selektor. Dla każdego obciążenia obowiązuje najwęższa pasująca polityka (istio.io). Ta hierarchia dobrze mapuje się na role:

• Zespół platformowy — instaluje i aktualizuje istiod, utrzymuje bramy wejściowe i polityki dla całej siatki w przestrzeni nazw root, na przykład PeerAuthentication z mode: STRICT. Odpowiada też za harmonogram aktualizacji.
• Zespoły aplikacyjne — konfigurują routing, podział ruchu i polityki autoryzacji swoich usług we własnych przestrzeniach nazw. Uprawnienia daje im RBAC Kubernetes: Role działa w obrębie jednej przestrzeni nazw, a ClusterRole w całym klastrze (kubernetes.io), więc zespół aplikacyjny dostaje role przestrzeni nazw, a nie klastra.
• Bezpieczeństwo — wyznacza docelowy tryb mTLS i zasady autoryzacji, przegląda polityki siatki i prowadzi migrację. Tryb PERMISSIVE pozwala usłudze przyjmować jednocześnie ruch szyfrowany i nieszyfrowany, więc nadaje się na okres przejściowy, po którym włącza się tryb STRICT.
• SRE i obserwowalność — korzystają z telemetrii siatki do celów niezawodności usług i reagowania na incydenty.

Warto zapisać jedną zasadę wprost: w siatce może być tylko jedna polityka PeerAuthentication dla całej siatki i jedna na przestrzeń nazw, a nowsze duplikaty Istio ignoruje. Zmiany na tym poziomie powinien zatwierdzać zespół platformowy razem z bezpieczeństwem.

Aktualizacje i usługi zarządzane

Według strony „Supported Releases” na istio.io nowa wersja minor wychodzi mniej więcej raz na kwartał, a jej wsparcie trwa do sześciu tygodni po wydaniu wersji N+2. Płaszczyzna sterowania może wyprzedzać płaszczyznę danych o jedną wersję, nigdy odwrotnie, a projekt zaleca aktualizacje przez rewizje. Aktualizacje to więc stały, kwartalny obowiązek zespołu platformowego, a nie jednorazowy projekt.

Usługa zarządzana nie zdejmuje tej odpowiedzialności w całości. Przed wyborem sprawdź u źródła:

• Google Cloud — Anthos Service Mesh i Traffic Director działają teraz jako Cloud Service Mesh, który obsługuje API Istio dla Kubernetes (cloud.google.com).
• Azure — dodatek Istio dla AKS według learn.microsoft.com nie obsługuje jeszcze trybu ambient i nie aktualizuje się razem z automatyczną aktualizacją klastra, więc nieaktualna rewizja siatki pozostaje zadaniem zespołu. Starszy dodatek Open Service Mesh przestaje być wspierany w AKS od 30 września 2027 r., a sam projekt OSM został wycofany; Microsoft zaleca migrację do dodatku Istio.

Czytaj także

• Migracja z Docker Swarm do Kubernetes — plan wdrożenia dla menedżera zespołu
• Bezpieczeństwo obrazów kontenerowych — skanowanie podatności przed wdrożeniem
• Autoskalowanie aplikacji w Kubernetes — HPA i VPA w praktyce

Rozwijaj kompetencje

Temat rozwijają szkolenia Tworzenie Service Mesh z Istio i Kubernetes oraz Kubernetes — wzorce projektowe i najlepsze praktyki. Pierwsze obejmuje zarządzanie ruchem i polityki bezpieczeństwa w Istio, drugie wzorce projektowania aplikacji w Kubernetes. Skontaktuj się z nami, żeby dopasować zakres do swojego zespołu.

Najczęściej zadawane pytania (FAQ)

Czym jest architektura mikroserwisów i gdzie pasuje do niej service mesh?

Architektura mikroserwisów dzieli aplikację na małe usługi, które komunikują się przez sieć i są wdrażane niezależnie. Service mesh przejmuje tę komunikację: szyfruje ją, uwierzytelnia usługi, kieruje ruchem i zbiera telemetrię. Dzięki temu zespoły nie muszą powtarzać tej logiki w kodzie każdej usługi.

Kto w organizacji powinien zarządzać Kubernetesem i siatką usług?

W ocenie autora naturalnym właścicielem jest zespół platformowy, który utrzymuje klastry, płaszczyznę sterowania Istio, bramy i polityki dla całej siatki. Zespoły aplikacyjne zarządzają konfiguracją swoich usług we własnych przestrzeniach nazw, a bezpieczeństwo wyznacza zasady mTLS i autoryzacji. Podział warto opisać w macierzy odpowiedzialności przed wdrożeniem.

Jaka jest rola zespołu platformowego i SRE przy service mesh?

Zespół platformowy traktuje siatkę jak produkt dla zespołów aplikacyjnych: instaluje ją, aktualizuje i dostarcza bezpieczne ustawienia domyślne. SRE to podejście opisane przez Google na sre.google jako to, „co się dzieje, gdy inżyniera oprogramowania poprosi się o zaprojektowanie zespołu operacyjnego”. Przy siatce usług SRE korzysta z jej telemetrii do pilnowania niezawodności.

Jak zabezpieczyć komunikację sieciową w Kubernetesie?

Na poziomie adresów IP i portów służą do tego obiekty NetworkPolicy, które działają tylko wtedy, gdy wtyczka sieciowa klastra je obsługuje (kubernetes.io). Service mesh dodaje szyfrowanie mTLS, tożsamość usług i autoryzację opartą na tej tożsamości. Oba mechanizmy się uzupełniają: NetworkPolicy ogranicza, kto może się połączyć, a siatka sprawdza, kim jest rozmówca.