Moderný vývoj aplikácií v cloudu, minimálne v Azure, sa stal takmer závislým od Kubernetes. Technológie ako Virtual Kubelets, AKS (Azure Kubernetes Service) a Azure Service Fabric Mesh sú kľúčom k vytváraniu škálovateľných distribuovaných aplikácií v Azure pomocou kontajnerov na nasadenie a správu mikroslužieb.
Pri pohľade na nástroje Kubernetes spoločnosti Azure je zrejmé, že spoločnosť Microsoft robí veľa práce v prostredí Cloud Native Computing Foundation a okolo neho, pričom pracuje na všetkých aspektoch rámca otvoreného zdroja. Nemali by sme byť prekvapení; Spoločnosť Microsoft najala jedného zo zakladateľov projektu Kubernetes a potom získala významného dodávateľa spoločnosti Deis. Tím Deis stojí za jedným z najnovších príspevkov Azure do ekosystému Kubernetes, Service Mesh Interface (SMI).
Predstavujeme služobné oká
Možno je najlepšie najskôr vysvetliť, čo je to sieť služieb a prečo je to dôležité pre každú aplikáciu založenú na Kubernetes.
Moderné architektúry IT sú predovšetkým o abstrakcii. Vďaka cloudovým službám už nemusíme myslieť na základný hardvér. Ak používame IaaS, definujeme virtuálne stroje na hosťovanie nášho kódu. Vďaka PaaS sme od hardvéru ešte ďalej, využívame služby a API, ktoré sme si vybrali, a vyberáme vhodnú úroveň výkonu pre naše aplikácie a rozpočty. S architektúrami založenými na kontajneroch, ako je Kubernetes, sme na mieste niekde medzi nimi: pomocou služieb ako AKS môžeme definovať základné virtuálne stroje, ktoré potom hostia naše kontajnerové pody a škálovajú sa zmenami vo výpočtoch a pamäti (a teraz s KEDA (automatické škálovanie založené na udalostiach založené na Kubernetes), po prijatí udalostí).
To je len jeden aspekt abstrakcie. Mikroslužby Kubernetes sú v jadre bez štátnej príslušnosti; využívajú externé úložisko a sedia na vrchole fyzických alebo virtuálnych sietí. Je to asi najsložitejší aspekt siete Kubernetes: Keď sa služby zmenšujú a zmenšujú, musíte upraviť svoju sieť tak, aby zodpovedala zmenám vašej aplikácie. Ako však zaistiť, aby boli služby pripojené, keď môže mať klientske rozhranie a zadné rozhranie škálovanie rôznou rýchlosťou?
To je miesto, kde prichádzajú sieťové siete. Sú to nová vrstva abstrakcie, ktorá zdvihne váš kód preč od základnej siete využitím výhod modernej softvérovo definovanej siete. Tým, že funguje ako sada sieťových proxy, ktoré sú nasadené s vaším kódom, sieť služieb riadi komunikáciu medzi službami bez toho, aby váš kód potreboval akékoľvek vedomosti o základnej sieti. Služobnú sieť si môžete predstaviť ako automatizovanú riadiacu rovinu pre sieťovanie vašej aplikácie, ktorá spravuje základnú riadiacu rovinu, pretože Kubernetes upravuje váš kód hore a dole.
Softvérová sieť pre mikroslužby
Sieť služieb je v zásade distribuovaný smerovač s pravidlami dynamického smerovania, ktorý sa spravuje ako súčasť nasadenia Kubernetes, a možno sa bude najlepšie považovať za spôsob implementácie inteligentného, latentného a škálovateľného vyvažovania záťaže popri zisťovaní služieb. Môžete definovať ďalšie pravidlá; napríklad oddelenie produkčných a testovacích systémov alebo zvládnutie nasadenia nového vydania a zmeny medzi verziami kontajnerov. Každý pod v aplikácii má inštanciu siete služieb bežiacu ako postranný vozík a zisťovanie služieb a ďalšie stavové prvky bežiace mimo vašich služieb.
Vďaka sieti služieb posúvate inteligenciu do novej sieťovej vrstvy, takže ju nemusíte vkladať do svojich mikroslužieb. Potrebujete šifrovať pripojenie? To je práca pre vašu sieť služieb. Potrebujete splnomocniť klientov? Ďalšia úloha pre servisnú sieť.
Príliš veľa ôk
Kombinácia nasadenia Kubernetes so sieťou služieb má veľký zmysel. Existuje však ešte jeden veľký problém: Ktorý z nich používate? Vyslanec? Istio? Linkerd? Aspen Mesh? Ak ste si vybrali jednu, čo zabráni vývojovému tímu v inej časti vašej firmy, aby si vybral inú? Čo sa potom stane, ak sa vaša spoločnosť rozhodne štandardizovať na konkrétnej platforme?
To je problém, ktorý sa spoločnosť Microsoft chystá vyriešiť pomocou rozhrania Service Mesh. Namiesto toho, aby každá sieť služieb mala svoju vlastnú sadu rozhraní API, je SMI spôsob, ako implementovať spoločné API, ktoré fungujú v rôznych sieťach sietí a spravujú túto novú inteligentnú sieť. Namiesto blokovania kódu do konkrétnej siete služieb a jej rozhraní API môžete napísať kód, ktorý rieši najbežnejšie prípady použitia, prostredníctvom spoločného rozhrania API. Ak potrebujete vymeniť sieť služieb - ak zmeníte poskytovateľa alebo nájdete lepšie fungujúceho - nie je potrebné meniť váš kód, pokiaľ sieť služieb implementuje SMI. Všetko, čo musíte urobiť, je zmeniť prívesné vozíky so služobnou sieťou a znova nasadiť kód.
SMI: spoločné API služby Service Mesh
V spolupráci s ekosystémovými spoločnosťami Kubernetes, ako sú Hashicorp a Buoyant, Microsoft definoval kľúčové vlastnosti pre SMI, ktoré podporujú bežné požiadavky zákazníkov. V počiatočnom vydaní sa zameral na tri oblasti: dopravná politika, telemetria dopravy a správa dopravy. Tieto tri oblasti sú riadené väčšinou servisných sietí a zámerom je vytvoriť z nich špecifikáciu, ktorá sa dá ľahko implementovať bez zmeny základnej aplikácie.
Tým, že sa zo spoločnosti SMI stane sada štandardných rozhraní API, nič nebráni tomu, aby dodávatelia sietí služieb naďalej ponúkali svoje vlastné API alebo ďalšie funkcie mimo uvedených. Prípadne nemusia robiť žiadne zmeny; tretie strany môžu vytvárať prekladové vrstvy, ktoré sú umiestnené medzi rozhraniami SMI API a proprietárnymi API služieb. Tiež nebudete potrebovať novú verziu Kubernetes, pretože rozhrania SMI API sú implementované ako servery rozšírenia API a vlastné definície zdrojov. Môžete ich nainštalovať do ľubovoľného klastra pomocou existujúcich nástrojov na správu. To by malo uľahčiť SMI pre Azure a ďalšie cloudové služby Kubernetes, aby ich mohli zabudovať do svojich existujúcich spravovaných služieb Kubernetes.
Či už chcete používať Linkerd alebo Aspen Mesh alebo NSX Service Mesh spoločnosti VMware, u SMI si budete môcť zvoliť ten, ktorý uprednostňujete, vylepšiť prenosnosť kódu a vyhnúť sa blokovaniu konkrétnych cloudových služieb. Potom je tu príležitosť zmeniť sieť služieb bez ovplyvnenia vášho kódu. Ak nová sieť služieb ponúka lepší výkon, musíte iba zmeniť kanál zostavenia tak, aby používal novú sieť, a potom nasadiť aktualizovanú aplikáciu.
Je zaujímavé vidieť, ako sa Microsoft ujíma vedenia v takomto projekte, ktorý pracuje so širokým prierezom komunity Kubernetes. Prijatím prístupu, ktorý sa výslovne nezameriava na vytváranie siete služieb, môže Azure v rámci konfigurácie AKS ponúknuť rôzne siete služieb, vďaka čomu si môžete zvoliť požadovaný nástroj bez potreby zmeny kódu.
