Programování

Na Istio a dále: Azure Service Mesh Interface

Moderní vývoj aplikací založených na cloudu, alespoň v Azure, se stal téměř závislým na Kubernetes. Technologie jako Virtual Kubelets, AKS (Azure Kubernetes Service) a Azure Service Fabric Mesh jsou klíčem k vytváření škálovatelných distribuovaných aplikací v Azure pomocí kontejnerů k nasazení a správě mikroslužeb.

Při pohledu na nástroje Kubernetes v Azure je jasné, že Microsoft dělá v Cloud Native Computing Foundation a kolem něj hodně práce a pracuje na všech aspektech rámce open source. Neměli bychom být překvapeni; Microsoft najal jednoho ze zakladatelů projektu Kubernetes a poté získal významného dodavatele Deis. Tým Deis stojí za jedním z nejnovějších příspěvků Azure do ekosystému Kubernetes, Service Mesh Interface (SMI).

Představujeme servisní sítě

Možná je nejlepší nejprve vysvětlit, co je síť služeb a proč je to důležité pro jakoukoli aplikaci založenou na Kubernetes.

Moderní IT architektury jsou o abstrakci. S cloudovými službami již nemusíme přemýšlet o základním hardwaru. Pokud používáme IaaS, definujeme virtuální stroje pro hostování našeho kódu. S PaaS jsme ještě dále od hardwaru, využíváme služby a rozhraní API, která jsme si vybrali, a volíme vhodnou úroveň výkonu pro naše aplikace a rozpočty. S architekturami založenými na kontejnerech, jako je Kubernetes, jsme v bodě někde mezi těmito dvěma: pomocí služeb, jako je AKS, můžeme definovat podkladové virtuální stroje, které pak hostují naše kontejnerové lusky a škálovat se změnami ve výpočetních a paměťových (a nyní s KEDA (automatické škálování založené na událostech založené na Kubernetes), po přijetí událostí).

To je jen jeden aspekt abstrakce. Mikroslužby Kubernetes jsou srdcem bez státní příslušnosti; využívají externí úložiště a sedí na vrcholu fyzické nebo virtuální sítě. Je to pravděpodobně nejsložitější síťový aspekt běhu Kubernetes: Jak se služby škálovají a zmenšují, musíte upravit svou síť tak, aby odpovídala změnám vaší aplikace. Jak ale zajistit, aby byly služby propojeny, když může mít front-end a back-end aplikace škálování různými rychlostmi?

To je místo, kde přicházejí servisní sítě. Jedná se o novou vrstvu abstrakce, která zvedne váš kód pryč od základní sítě tím, že využije možnosti moderní softwarově definované sítě. Tím, že funguje jako sada síťových proxy serverů, které jsou nasazeny s vaším kódem, síť služeb spravuje komunikaci mezi službami, aniž by váš kód potřeboval jakékoli povědomí o základní síti. Síť služeb si můžete představit jako automatickou rovinu řízení pro síť vaší aplikace, která spravuje základní rovinu řízení, protože Kubernetes mění váš kód nahoru a dolů.

Softwarově definovaná síť pro mikroslužby

Snad nejlépe představený jako způsob implementace inteligentního, latenčního a škálovatelného vyvažování zátěže vedle zjišťování služeb, síť služeb je v podstatě distribuovaný směrovač s pravidly dynamického směrování, které jsou spravovány jako součást nasazení Kubernetes. Můžete definovat další pravidla; například vedení produkčních a testovacích systémů odděleně nebo manipulace s nasazením nového vydání a změna mezi verzemi kontejnerů. Každý pod v aplikaci má instanci sítě služby spuštěnou jako postranní vozík, přičemž zjišťování služeb a další stavové prvky běží mimo vaše služby.

Díky síti služeb posíláte inteligenci do nové síťové vrstvy, takže ji nemusíte vkládat do svých mikroslužeb. Potřebujete zašifrovat připojení? To je práce pro vaši síť služeb. Potřebujete autorizovat klienty? Další úkol pro servisní síť.

Příliš mnoho sítí

Kombinace nasazení Kubernetes se sítí služeb má velký smysl. Existuje však ještě jeden velký problém: Který používáte? Vyslanec? Istio? Linkerd? Aspen Mesh? Pokud jste si vybrali jednu, co má zabránit vývojovému týmu v jiné části vašeho podnikání, aby si vybral jinou? Co se stane, když se vaše společnost rozhodne standardizovat na konkrétní platformě?

To je problém, který se společnost Microsoft chystá vyřešit pomocí rozhraní Service Mesh. Místo toho, aby každá síť služeb měla svou vlastní sadu rozhraní API, je SMI způsob, jak implementovat běžná rozhraní API, která fungují napříč různými sítěmi služeb a spravují tuto novou inteligentní síť. Místo zamykání kódu do konkrétní sítě služeb a jejích rozhraní API můžete napsat kód, který řeší nejběžnější případy použití prostřednictvím společného rozhraní API. Pokud potřebujete vyměnit síť služeb - pokud změníte poskytovatele nebo zjistíte, že funguje lépe - není třeba měnit váš kód, pokud síť služeb implementuje SMI. Vše, co musíte udělat, je změnit postranní vozy servisní sítě a znovu nasadit kód.

SMI: Common API služby API

Ve spolupráci s ekosystémovými společnostmi Kubernetes, jako jsou Hashicorp a Buoyant, Microsoft definuje klíčové funkce pro SMI, které podporují běžné požadavky svých zákazníků. V počátečním vydání se zaměřil na tři oblasti: dopravní politika, telemetrie provozu a správa provozu. Tyto tři oblasti jsou řízeny většinou sítí služeb a záměrem je, aby z toho byla specifikace, kterou lze snadno implementovat beze změny podkladové aplikace.

Díky tomu, že se SMI stane sadou standardních API, nic nebrání tomu, aby dodavatelé služeb sítě pokračovali v nabídce svých vlastních API nebo dalších funkcí mimo uvedené. Alternativně nemusí provádět žádné změny; třetí strany mohou vytvářet překladové vrstvy, které jsou umístěny mezi SMI API a proprietárními API služeb. Také nebudete potřebovat novou verzi Kubernetes, protože rozhraní SMI API jsou implementována jako servery rozšíření API a vlastní definice prostředků. Můžete pokračovat a nainstalovat je do libovolného klastru pomocí stávajících nástrojů pro správu. To by mělo usnadnit SMI pro Azure a další cloudové služby Kubernetes, aby je mohly integrovat do svých stávajících spravovaných služeb Kubernetes.

Ať už chcete používat Linkerd nebo Aspen Mesh nebo VMware NSX Service Mesh, u SMI si budete moci vybrat ten, který vám vyhovuje, zlepšit přenositelnost kódu a vyhnout se uzamčení konkrétních cloudových služeb. Pak je tu možnost přepnout servisní sítě bez ovlivnění kódu. Pokud nová síť služeb nabízí lepší výkon, vše, co musíte udělat, je změnit potrubí sestavení tak, aby používalo novou síť, a poté nasadit aktualizovanou aplikaci.

Je zajímavé vidět, že se společnost Microsoft ujala vedení v takovém projektu, který pracuje se širokým průřezem komunity Kubernetes. Přijetím přístupu, který se výslovně nezaměřuje na vytváření sítě služeb, může Azure nabídnout různé sítě služeb jako součást konfigurace AKS, což vám umožní vybrat si požadovaný nástroj, aniž byste museli měnit jakýkoli kód.

$config[zx-auto] not found$config[zx-overlay] not found