Kas ta Istio ir kodėl apie ją visi kalba
Jei dirbate su Kubernetes ir mikroservisais, tikriausiai jau girdėjote apie service mesh koncepciją. Istio yra viena populiariausių šios kategorijos platformų, kuri pastaruosius kelerius metus sukėlė nemažai ažiotažo IT bendruomenėje. Bet kas gi tai iš tikrųjų yra ir ar tikrai jums to reikia?
Paprasčiausiai tariant, Istio – tai infrastruktūros sluoksnis, kuris sėdi tarp jūsų mikroservisų ir tvarko visą jų tarpusavio komunikaciją. Įsivaizduokite, kad turite dešimtis ar net šimtus skirtingų servisų, kurie nuolat bendrauja tarpusavyje. Kaip kontroliuoti šį chaosą? Kaip užtikrinti saugumą? Kaip stebėti, kas vyksta? Istio ateina į pagalbą būtent čia.
Platforma veikia kaip išmanus tarpininkas – ji perima visą tinklo srautą tarp jūsų konteinerių ir suteikia galimybę valdyti, stebėti bei apsaugoti komunikaciją be poreikio keisti pačių aplikacijų kodą. Tai didžiulis privalumas, nes nebereikia kiekvienoje aplikacijoje implementuoti logging, monitoring, retry logikos ar autentifikacijos mechanizmų.
Kaip Istio veikia po gaubtu
Istio architektūra gali atrodyti sudėtinga iš pirmo žvilgsnio, bet iš esmės ji paremta gana elegantišku principu. Sistema susideda iš dviejų pagrindinių dalių: data plane ir control plane.
Data plane – tai Envoy proxy instancijos, kurios automatiškai įterpiamos į kiekvieną jūsų pod’ą kaip sidecar konteineriai. Šie proxy perima visą įeinantį ir išeinantį tinklo srautą. Taip, tai reiškia, kad kiekvienas jūsų servisas gauna papildomą konteinerį, kuris veikia kaip išmanus tarpininkas. Skamba kaip overhead? Iš dalies taip, bet privalumai dažniausiai viršija trūkumus.
Control plane – tai Istio „smegenys”, kurios valdo visus tuos Envoy proxy. Čia konfigūruojate taisykles, politikas, routing logiką. Control plane komponentai (istiod) paskirsto konfigūraciją visiems sidecar’ams ir užtikrina, kad viskas veiktų sinchroniškai.
Kas įdomu – nuo Istio 1.5 versijos, visa control plane architektūra buvo supaprastinta į vieną monolitinį komponentą. Ankstesni variantai turėjo Pilot, Citadel, Galley ir kitus atskirus komponentus, bet komanda nusprendė, kad tai per daug sudėtinga. Geras sprendimas, jei manęs klaustumėte.
Diegimas ir pirmieji žingsniai
Gerai, pereikime prie praktikos. Istio diegimas nėra raketos mokslas, bet reikia žinoti, ką darote. Pirmiausia jums reikės veikiančio Kubernetes klasterio. Rekomenduočiau bent 4 CPU cores ir 8GB RAM testinei aplinkai – Istio nėra lengvasvoris.
Paprasčiausias būdas pradėti – naudoti istioctl CLI įrankį:
curl -L https://istio.io/downloadIstio | sh - cd istio-1.x.x export PATH=$PWD/bin:$PATH istioctl install --set profile=demo -y
Demo profilis puikiai tinka eksperimentams, bet production aplinkoje tikrai norėsite naudoti default arba minimal profilį. Demo profilis įjungia visas įmanomas funkcijas, įskaitant tracing, logging ir kitus dalykus, kurie suės nemažai resursų.
Po instaliacijos svarbu įjungti automatinį sidecar injection namespace’e, kuriame planuojate naudoti Istio:
kubectl label namespace default istio-injection=enabled
Nuo šiol visi nauji pod’ai šiame namespace’e automatiškai gaus Envoy sidecar konteinerį. Jau egzistuojančius pod’us reikės perkurti. Tai vienas iš momentų, kuris gali sukelti problemų production’e, todėl planuokite deployment’ą atidžiai.
Traffic management arba kaip valdyti srautą
Čia prasideda tikrasis Istio malonumas. Traffic management galimybės yra viena iš stipriausių platformos pusių. Galite daryti dalykus, kurie anksčiau reikalavo sudėtingų sprendimų aplikacijos lygyje.
Virtual Services leidžia apibrėžti, kaip užklausos turėtų būti nukreiptos. Pavyzdžiui, galite lengvai implementuoti canary deployment’us:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10
Šis pavyzdys rodo, kaip galite nukreipti 10% srauto į naują versiją, o konkretus vartotojas (jason) visada gaus naują versiją. Tai neįtikėtinai galingas įrankis testuojant naujus feature’us.
Destination Rules apibrėžia, kas nutinka po to, kai Virtual Service nusprendė, kur siųsti užklausą. Čia konfigūruojate load balancing, connection pool settings, circuit breakers ir panašius dalykus:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
http1MaxPendingRequests: 50
maxRequestsPerConnection: 2
outlierDetection:
consecutiveErrors: 5
interval: 30s
baseEjectionTime: 30s
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
Circuit breaker funkcionalumas čia yra ypač naudingas – jei servisas pradeda failinti, Istio automatiškai laikinai išjungia probleminį pod’ą iš rotation.
Saugumas be galvos skausmo
Vienas iš didžiausių Istio privalumų – automatinis mTLS (mutual TLS) tarp servisų. Tai reiškia, kad visa komunikacija tarp jūsų mikroservisų yra šifruojama ir autentifikuojama be jokio kodo keitimo.
Istio automatiškai generuoja ir rotuoja sertifikatus kiekvienam servisui. Tai vyksta visiškai skaidriai – jūsų aplikacijos net nežino, kad komunikacija yra šifruojama. Envoy sidecar’ai tvarko visą šį procesą.
Galite pradėti nuo permissive režimo, kuris leidžia ir šifruotą, ir nešifruotą srautą:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: PERMISSIVE
Kai įsitikinsite, kad viskas veikia, perjunkite į STRICT režimą, kuris privers visus servisus naudoti mTLS. Tai gerokai pakels jūsų security posture be jokių papildomų pastangų iš development komandos pusės.
Authorization politikos leidžia kontroliuoti, kurie servisai gali bendrauti tarpusavyje:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-read
namespace: default
spec:
selector:
matchLabels:
app: products
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/frontend"]
to:
- operation:
methods: ["GET"]
Tokia politika leis tik frontend servisui daryti GET užklausas į products servisą. Zero-trust security modelis praktikoje.
Observability – matykite, kas vyksta
Vienas dalykas yra turėti veikiančią sistemą, visai kitas – suprasti, kas joje vyksta. Istio suteikia puikias observability galimybes out of the box.
Kiekvienas Envoy proxy renka detalias metricas apie visą srautą, kuris pro jį praeina. Tai apima latency, error rates, throughput ir daug daugiau. Šios metrikos automatiškai eksportuojamos Prometheus formatu.
Distributed tracing su Jaeger ar Zipkin integruojasi beveik automatiškai. Vienintelis dalykas, kurį jūsų aplikacija turi daryti – propagate’inti trace headers. Istio pasirūpins visu likusiu darbu:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
enableTracing: true
defaultConfig:
tracing:
sampling: 100.0
Kiali – tai web UI, kuri vizualizuoja jūsų service mesh topologiją. Galite realiu laiku matyti, kaip servisai bendrauja, kur yra bottleneck’ai, kur kyla klaidos. Tai neįkainojamas įrankis debugging’ui ir sistemos supratimui.
Grafana dashboardai, kurie ateina su Istio, suteikia detalų vaizdą į jūsų mesh’o sveikatą. Galite matyti golden signals (latency, traffic, errors, saturation) kiekvienam servisui atskirai.
Problemos ir kaip jų išvengti
Būkime sąžiningi – Istio nėra sidabrinė kulka ir ateina su savo iššūkiais. Pirmiausia, tai resursų naudojimas. Kiekvienas sidecar konteineris suės apie 50-100MB RAM ir šiek tiek CPU. Jei turite šimtus pod’ų, tai gali susumuoti į nemažus skaičius.
Latency overhead taip pat egzistuoja. Kiekviena užklausa dabar turi praeiti per du papildomus proxy hop’us (source ir destination sidecar’us). Paprastai tai prideda 1-3ms, bet jei jūsų aplikacija labai jautri latency, tai gali būti problema.
Debugging tampa sudėtingesnis. Kai kas nors neveikia, dabar turite papildomą sluoksnį, kurį reikia investigeituoti. Ar problema aplikacijoje? Ar Istio konfigūracijoje? Ar network’e? Išmokite naudoti istioctl analyze ir istioctl proxy-status – šie įrankiai gelbsti gyvybes.
Versijų suderinamumas gali būti skausmingas. Istio vystosi greitai, ir kartais breaking changes atsiranda tarp versijų. Visada skaitykite release notes prieš upgrade’indami ir testuokite ne-production aplinkoje.
Vienas patarimas, kurį išmokau sunkiu būdu – nepradėkite nuo visko iš karto. Neįjunkite visų Istio feature’ų pirmą dieną. Pradėkite nuo paprastos traffic management, paskui pridėkite observability, paskui security. Inkrementinis approach’as leidžia geriau suprasti, kaip sistema veikia, ir lengviau debug’inti problemas.
Alternatyvos ir kada Istio galbūt nereikalingas
Istio nėra vienintelis žaidėjas service mesh rinkoje. Linkerd yra lengvesnis ir paprastesnis variantas, kuris gali būti geresnis pasirinkimas mažesnėms organizacijoms. Consul Connect iš HashiCorp taip pat turi savo gerbėjų ratą.
AWS App Mesh, jei esate AWS ekosistemoje, gali būti natūralesnis pasirinkimas su geresne integracija į kitus AWS servisus. Google’o Traffic Director panašiai veikia GCP aplinkoje.
Bet svarbiausia – ne visada jums reikia service mesh. Jei turite 5-10 mikroservisų, tikriausiai galite išsiversti be jo. Service mesh prideda kompleksiškumo, ir tas kompleksiškumas turi būti pateisinamas realiomis problemomis, kurias sprendžiate.
Klauskite savęs: ar mums tikrai reikia sudėtingo traffic routing? Ar mums reikia mTLS tarp visų servisų? Ar mums reikia distributed tracing? Jei atsakymas į daugumą šių klausimų „ne”, galbūt Istio yra overkill.
Tačiau jei auginate į dešimtis ar šimtus servisų, jei turite compliance reikalavimus dėl encryption, jei norite sophisticated deployment strategijų – tada Istio tikrai verta dėmesio.
Kelias į production ir kas toliau
Jei nusprendėte eiti su Istio, štai keletas patarimų sėkmingam production deployment’ui. Pirmiausia, investuokite laiko į mokymą. Įsitikinkite, kad jūsų komanda supranta pagrindines koncepcijas – Virtual Services, Destination Rules, Gateway’us. Dokumentacija yra gera, bet nieko nepakeičia hands-on eksperimentavimas.
Pradėkite nuo vieno namespace’o ar vieno projekto. Neįjunkite Istio visam klasteriui iš karto. Išmokite, kaip sistema elgiasi, kokios metrikos normalios, kaip debug’inti problemas. Tik tada plėskite toliau.
Monitoring ir alerting yra kritiniai. Sukonfigūruokite alertus Istio control plane sveikatai. Stebėkite sidecar injection rate – jei pod’ai kyla be sidecar’ų, tai problema. Monitorinkite Envoy proxy metricas – memory usage, connection pools, circuit breaker events.
Turite turėti rollback planą. Kaip greitai galite išjungti Istio, jei kas nors rimtai suges? Paprasčiausias būdas – pašalinti istio-injection label iš namespace’o ir perkurti pod’us. Bet tai užtrunka. Galite apsvarstyti gradual rollout strategiją, kur tik dalis pod’ų turi sidecar’us.
Performance testing prieš production yra būtinas. Išmatuokite latency overhead jūsų specifinei workload. Patikrinkite, kaip sistema elgiasi su high load. Istio prideda papildomų moving parts, ir geriau sužinoti apie problemas test aplinkoje nei 3 AM production incident metu.
Istio bendruomenė yra aktyvi ir naudinga. Jei užstrigsite, Slack kanalas paprastai atsako greitai. GitHub issues yra geras šaltinis troubleshooting’ui – didelė tikimybė, kad kažkas jau susidūrė su panašia problema.
Žvelgiant į ateitį, Istio toliau vystosi. Ambient mesh – nauja architektūra be sidecar’ų – šiuo metu yra alpha stadijoje ir žada sumažinti resource overhead. WebAssembly extensibility leidžia customizuoti Envoy elgesį be reikalo rebuild’inti proxy. Multi-cluster support gerėja su kiekviena versija.
Service mesh koncepcija niekur nedingsta. Priešingai, ji tampa standartu didelėse mikroservisų architektūrose. Istio, nepaisant savo kompleksiškumo ir trūkumų, yra brandus, production-ready sprendimas su didele bendruomene ir aktyviu vystymu. Jei jūsų organizacija auga ir mikroservisų skaičius didėja, tikrai verta ištirti, ar Istio galėtų išspręsti jūsų problemas. Tik nepamirškite – technologija yra įrankis, ne tikslas. Naudokite ją tik tada, kai ji tikrai prideda vertę.
