Üdvözöljük ismét! A kurzus indítása előtt még egy hasznos fordítást készítettünk.
A Service Mesh egy konfigurálható, alacsony késleltetésű infrastrukturális szint, amely szükséges a nagy mennyiségű hálózati interprozessz kommunikáció feldolgozásához az alkalmazás programozási interfészei (API) között. A Service Mesh gyors, megbízható és biztonságos kommunikációt biztosít a konténerizált és gyakran efemer alkalmazásinfrastruktúrák szolgáltatásai között. A Service Mesh olyan lehetőségeket kínál, mint a szolgáltatásmegtalálás, terheléselosztás, titkosítás, átláthatóság, nyomkövetés, hitelesítés és engedélyezés, valamint az automatikus leállítás mintázat támogatása (circuit breaker).
A Service Mesh általában úgy valósul meg, hogy minden szolgáltatási példányhoz egy proxy példányt biztosít, amelyet Sidecar-nak hívnak. A Sidecar kezeli a szolgáltatások közötti kommunikációt, figyelemmel kíséri és javítja a biztonsági problémákat, tehát mindent, ami leválasztható a különálló szolgáltatásokról. Így a fejlesztők írhatják, karbantarthatják és kezelhetik az alkalmazáskódot a szolgáltatásokban, míg a rendszergazdák a Service Mesh-sel dolgozhatnak és futtathatják az alkalmazásokat.
A Google, az IBM és a Lyft által kifejlesztett Istio a legnépszerűbb Service Mesh architektúra jelenleg. A Kubernetes, amelyet eredetileg a Google fejlesztett ki, most az egyetlen konténerorchesztráló keretrendszer, amelyet az Istio támogat. A szállítók kereskedelmi támogatott verziókat próbálnak létrehozni az Istio-ból. Érdekes, hogy mit tudnak újítással hozzáadni az open-source projekthez.
Az Istio azonban nem az egyetlen lehetőség, mivel más Service Mesh implementációk is készülnek. A sidecar proxy a legnépszerűbb implementáció, ami a Buoyant, HashiCorp, Solo.io és más projektek alapján is ítélhető. Léteznek alternatív architektúrák is: a Netflix technológiai eszközkészlete egyik megközelítése, ahol a Service Mesh funkciót a Ribbon, Hysterix, Eureka, Archaius könyvtárakkal, valamint olyan platformokkal, mint az Azure Service Fabric, valósítják meg.
A Service Mesh saját terminológiájával rendelkezik a szolgáltatási komponensekről és funkciókról:
- Konténerorchesztráló keretrendszer. Ahogy egyre több konténer kerül hozzáadásra az alkalmazás infrastruktúrájához, szükség van egy külön eszközre a konténerek megfigyelésére és kezelésére – egy konténer-orkesztráló keretrendszerre. A Kubernetes szorosan betöltötte ezt a rést, olyan mértékben, hogy a fő versenytársai, mint a Docker Swarm és a Mesosphere DC/OS alternatívaként integrációt kínálnak a Kubernetes-szel.
- Szolgáltatások és példányok (Kubernetes podok). A példány egyetlen futó másolata a mikroszolgáltatásnak. Néha egy példány egy konténert jelent. A Kubernetes esetében a példány egy kis, független konténerekből álló csoportból, amelyet podnak neveznek, áll. Az ügyfelek ritkán fordulnak közvetlenül egy példányhoz vagy podhoz, inkább egy szolgáltatáshoz fordulnak, amely az azonos, skálázható és hibamentes példányok vagy podok (replikák) készletét képviseli.
- Sidecar Proxy. A Sidecar Proxy egy példány vagy pod mellett működik. A Sidecar Proxy lényege, hogy irányítsa vagy proxizza a forgalmat, amely egy konténertől érkezik, amellyel dolgozik, és a visszaáramló forgalmat. A Sidecar más Sidecar Proxy-kkal lép kapcsolatba, és az orkestráló keretrendszer irányítja. Számos Service Mesh megvalósítás Sidecar Proxy-t használ az összes bejövő és kimenő forgalom elfogására és kezelésére egy példány vagy pod esetében.
- Szolgáltatások felfedezése. Amikor egy példánynak interakcióba kell lépnie egy másik szolgáltatással, meg kell találnia (felfedeznie) egy működő és elérhető példányt a másik szolgáltatásból. Általában a példány DNS segítségével keres. Az orkestráló keretrendszer tárolja a kérdések fogadására kész példányok listáját, és interfészt biztosít a DNS lekérdezésekhez.
- A terheléselosztás. A legtöbb konténer-orkesztráló keretrendszer a 4. réteg (szállítási) terheléselosztást biztosít. A Service Mesh bonyolultabb 7. réteg (alkalmazási) terheléselosztást valósít meg, amely gazdag algoritmusokban, és hatékonyabb a forgalom kezelésében. A terheléselosztási paraméterek változtathatók API-n keresztül, lehetővé téve a kék-zöld vagy kanári telepítést.
- Titkosítás. A Service Mesh képes titkosítani és visszafejteni a kéréseket és válaszokat, így leveszi ezt a terhet a szolgáltatásokról. A Service Mesh emellett javíthatja a teljesítményt azáltal, hogy priorizálja vagy újrahasználja a meglévő állandó kapcsolatokat, csökkentve ezzel az új kapcsolatok létrehozásához szükséges drága számítási igényeket. A legelterjedtebb forgalom titkosítási megoldás a mutual TLS (mTLS), ahol a nyilvános kulcsú infrastruktúra (PKI) tanúsítványokat és kulcsokat generál és terjeszt Sidecar Proxy használatára.
- Hitelesítés és engedélyezés. A Service Mesh képes hitelesíteni és engedélyezni a külső vagy belső alkalmazásokból érkező kéréseket, csak validált kéréseket küldve az instanciákhoz.
- Automatikus leállítási minta támogatás. A Service Mesh támogatja az , amely elszigeteli az egészségtelen instanciákat, majd szükség esetén fokozatosan visszajuttatja őket az egészséges instanciák pooljába.
A Service Mesh azon része, amely a hálózati forgalmat kezeli az instanciák között, úgynevezett Adat sík. A viselkedésüket irányító konfiguráció létrehozása és telepítése Adat síkkülön Irányító sík. Irányító sík általában API, CLI vagy GUI csatlakozására van tervezve az alkalmazás kezeléséhez.
A Control Plane a Service Mesh-ben elosztja a konfigurációt a Sidecar Proxy és a Data Plane között.
A Service Mesh architektúráját gyakran alkalmazzák bonyolult működési feladatok megoldására konténerek és mikroszolgáltatások használatával. Az iparági úttörők közé tartozik például a Lyft, a Netflix és a Twitter, akik milliónyi felhasználónak nyújtanak megbízható szolgáltatásokat világszerte. (). Kevésbé igényes alkalmazási feladatokhoz valószínűleg elegendő lesz egy egyszerűbb architektúra.
A Service Mesh architektúra valószínűleg soha nem lesz minden problémára megoldás az alkalmazások működésével és szállításával kapcsolatban. Az architektek és fejlesztők hatalmas eszközkészlettel rendelkeznek, és ebből csak egy a kalapács, amely a számos feladat közül egyetlen célra szolgál – a szögek beverésére. , például, több különböző modellt tartalmaz, amelyek folyamatos spektrumot kínálnak a feladatok megoldására mikro-szolgáltatások révén.
A Service Mesh architektúrában összekapcsolt elemek, mint például az NGINX, konténerek, Kubernetes és mikro-szolgáltatások, mint architekturális megközelítés, ugyanolyan produktívan alkalmazhatók Service Mesh nélküli megvalósításokban is. Például az Istio teljes értékű Service Mesh architektúraként lett kifejlesztve, de a moduláris felépítés azt sugallja, hogy a fejlesztők választhatják és alkalmazhatják csak a szükséges technológiai komponenseket. Ezt szem előtt tartva világos képet kell kialakítani a Service Mesh koncepciójáról, még akkor is, ha nem biztos benne, hogy valaha teljes mértékben meg tudja valósítani egy alkalmazásban.
Forrás: habr.com
