Az utóbbi évek fejlesztési trendjei alapvetően változtatták meg az alkalmazások felépítését: hatalmas monolitikus kódbázisok helyett a microservice alapelv vette át a főszerepet, ahol a lazán összefüggő kis komponenseket konténerekbe csomagolva futtatják. A konténerizált alkalmazások hatékony futtatására és menedzsmentjére pedig ott a Kubernetes. A stack bővülésével azonban az alkalmazások közötti kommunikáció szinte átláthatatlanná vált. Hogy ezt a problémát feloldjuk, egy új infrastruktúra réteg került bevezetésre: ez a service mesh!

Egy kis történelem

A service mesh "feltalálásához" azonban kanyargós út vezetett, a kezdetekben ugyanis a különálló alkalmazások többségébe rengeteg olyan funkciót kellett beépíteni, melyek igazából függetlenek az adott komponens üzleti logikájától. Tipikus példák ezekre a funkciókra: service discovery, load balancing, health checks, timeouts, retries, circuit breaking, mTLS, rate limiting, header rewrites, redirects, monitoring metrics, access logs, distributed tracing, fault injection.

Ez már kis alkalmazásszám mellett sem volt hatékony, de nagyobb méretben hatalmas terhet jelentett a rendszer egészére nézve. Erre válaszul születtek meg kezdetben különböző nyelvi könyvtárak (pl.: Stubby - Google, Finagle - Twitter), melyek összegyűjtötték ezeket a funkciókat egy közös projektben, és minden egyes megépült szolgáltatás függőségként kezelve használhatta az általuk kínált funkciókat. Pár év után azonban ez az elképzelés is hasonló problémába futott bele: ezen projektek mindegyike egy hatalmas monolitikus kódbázissá nőtte ki magát, melyet nehéz volt megérteni és használni. Ráadásul ezek a könyvtárak megkötötték a fejlesztők kezét, mert magát az alkalmazást is ugyanazon a nyelven kellett implementálni, elvesztve ezzel a microservice architektúrák által biztosított nyelvi szabadságot.

Ezt felismerve a Twitter Finagle könyvtárának a fejlesztői kitalálták, hogyan is lehetne feloldani ezeket a problémákat: átvezetve minden forgalmat lokális szerveren futó proxykon, így a fent említett funkciókat nem kell többé a szolgáltatásba kódolni, hanem külsőleg megoldható infrastrukturális szinten.

A projekt fejlesztői kiválva a Twitterből megalapították az első igazi service mesh projektet, ez lett a Linkerd, ami tulajdonképpen egy HTTP proxy (nagyrészt a Finagle kódjára építve) és hozzá egy okos vezérlő, ami képes megfelelően felprogramozni az egyes node-okon futó proxy szervereket. Ezzel párhuzamosan terjedt el a konténerizáció és a hozzá tartozó orkesztrációs környezetek, és lett a Kubernetes egyeduralkodó ezen a területen.

Így hamarosan a mérnökök elkezdtek service mesh működést implementálni Kubernetes környezetekbe és rájöttek, hogy van egy még hatékonyabb módja egy ilyen infrastruktúra felépítésének: ahelyett, hogy minden node-on egy közös proxy futna, akár minden alkalmazás konténer mellé el lehet helyezni egy saját proxyt úgynevezett side-car modellben. A Google és az IBM elkezdett dolgozni egy saját service mesh implementáción, ez lett az Istio: itt a side-car proxy feladatát az Envoy oldja meg, és az Istio vezérlése ezeket programozza fel az infrastrukturális szabályok mentén.

Mivel az Istio nagyon hamar nagy népszerűségre tett szert a Kubernetes felhasználók körében, a Linkerd csapata is elhatározta, hogy teljesen átalakítják a projektet, és csak és kizárólag Kubernetesre fogják optimalizálni a projektjüket: egy teljesen új proxy implementációt készítettek Rust nyelven (hogy a side-car proxyk a lehető legjobb teljesítményt nyújtsák a lehető legkisebb erőforrás szükséglet mellett), és kiadták hozzá a Kubernetes erőforrásokra épülő vezérlőjüket is.

Ezen felül elindult némi konszolidáció is, hogy ne legyen minden egyes eszköznek teljesen különböző a használata: az SMI (Service Mesh Interface) megjelenésével most már lehetőségünk van egy közös "nyelven" kialakítani a service mesh logikánkat, amit a legtöbb eszköz támogat.

A lényeg

A service mesh lényege, hogy a konténerizált szolgáltatásokat sosem engedik közvetlen kommunikálni egymással, helyette a forgalmat mindig proxy szervereken keresztül terelik. Így az alkalmazások közötti hívások proxy szervereken haladnak keresztül, melyeket egy egységes környezetben tudunk együttesen menedzselni. Ezzel nagyon sok folyamatot be tudunk hozni az infrastrukturális szintre, mint például a konzisztens monitoring és forgalom menedzsment, security ellenőrzések, mTLS, automatikus hibakezelés.

A konténerizáció és a Kubernetes hazai terjedésével eljött az idő, hogy a hazai szakemberek is megismerjék a service mesh megoldásokat, hiszen ezek immár az ökoszisztéma szerves részei. Erre az igényre válaszul a HWSW 6 alkalmas, 18 órás gyakorlatorientált online képzést indít., mely most akár akciós csomagban is elérhető a tavalyi, Kubernetes alapjai képzésünk videóanyagával együtt. Oktatóik kiváló szakemberek és előadók, ezt magad is ellenőrizheted, ha megnézed “A Service Mesh fejlődésének újabb irányai” című rövid és szuper előadásuk felvételét.

A tanfolyam során először bemutatják a service mesh témakör rövid történetét, architekturális felépítését, valamit az elérhető eszközöket. Ezek után a két legnépszerűbb megoldást (Istio és Linkerd) részletesen is átnézik a résztvevőkkel: hogyan lehet őket használni egy Kubernetes klaszter fölött, milyen absztrakciókra épülnek, és milyen use-case-eket lehet velük egyszerűen megvalósítani. Bemutatják mikor és hogyan érdemes ezeket az eszközöket használni, valamit rengeteg demo segítségével megmutatják, milyen funkciókat lehet velük nagyon egyszerűen megvalósítani.