Série příspěvků o Istio Service Mesh

Začínáme sérii příspěvků, ve které představíme některé z mnoha funkcí servisní sítě Istio Service Mesh v kombinaci s Red Hat OpenShift a Kubernetes.

Série příspěvků o Istio Service Mesh

Díl první, dnešní:

  • Vysvětlíme pojem sidecar kontejnerů Kubernetes a formulujeme leitmotiv této série příspěvků: „Nemusíte nic měnit ve svém kódu“.
  • Představíme základní věc Istio – pravidla směrování. Na těchto pravidlech jsou založeny všechny ostatní možnosti Istio, protože právě pravidla umožňují směrovat provoz k mikroservisům s využitím externích souborů YAML. Také se podíváme na schéma nasazení Canary Deployment. Novoroční bonus – 10 interaktivních lekcí o Istio.


Díl druhý, který brzy vyjde, vám poví:

  • Jak Istio implementuje Pool Ejection v kombinaci s Circuit Breaker a ukáže, jak Istio umožňuje odstranit z rovnice nefungující nebo špatně fungující pod.
  • Dále se zaměříme na téma Circuit Breaker z prvního příspěvku, abychom zjistili, jak lze Istio zapojit. Ukážeme, jak směrovat provoz a zpracovávat síťové chyby pomocí konfiguračních souborů YAML a příkazů terminálu, aniž bychom museli měnit kód služeb.

Díl třetí:

  • Příběh o trasování a monitorování, které jsou již integrovány nebo snadno přidány do Istio. Ukážeme, jak používat nástroje jako Prometheus, Jaeger a Grafana v kombinaci se škálováním OpenShift, abychom mohli bez větší námahy řídit mikroservisní architekturu.
  • Přecházíme od monitorování a zpracování chyb k tomu, abychom je do systému záměrně zadávali. Jinými slovy, učíme se provádět fault injection bez změny zdrojového kódu, což je velmi důležité z hlediska testování – protože pokud se kvůli tomu změní samotný kód, hrozí přidání dalších chyb.

Nakonec, ve finálním příspěvku o Istio Service Mesh:

  • Přejdeme na Temnou Stranu. Přesněji řečeno, budeme se učit používat schéma Dark Launch, když je kód nasazen a testován přímo na produkčních datech, ale nijak nezapadá do práce systému. Zde se skvěle hodí umění Istio rozdělovat provoz. A možnost provádět testování na živých produkčních datech, aniž bychom ovlivnili činnost produkčního systému, je nejpřesvědčivější způsob ověření.
  • Vycházeje z Dark Launch, ukážeme, jak použít model Canary Deployment k minimalizaci rizik a usnadnění zavádění nového kódu. Sama o sobě není Canary Deployment nic nového, ale Istio umožňuje implementaci tohoto schématu pouze pomocí jednoduchých YAML souborů.
  • Na závěr ukážeme, jak pomocí Istio Egress poskytnout přístup k službám těm, kteří se nacházejí mimo vaše klastry, aby využili možnosti Istio při práci s internetem.

Tak jdeme na to...

Nástroje pro monitorování a správu Istio – vše potřebné pro koordinaci mikroslužeb v servisní síti service mesh.

Co je servisní síť Istio

Servisní síť realizuje pro skupinu služeb funkce jako monitoring provozu, řízení přístupu, objevování, bezpečnost, odolnost vůči selhání a další užitečné věci. Istio umožňuje to vše bez jakýchkoliv změn v kódu samotných služeb. Jaké je tajemství tohoto kouzla? Istio přidává k každé službě svůj proxy ve formě sidecar kontejneru (sidecar – motocyklový vozík), a poté veškerý provoz k této službě jde přes proxy, který, řízený zadanými politikami, rozhoduje, jak, kdy a zda vůbec má tento provoz dosáhnout služby. Istio také umožňuje implementaci pokročilých technik DevOps, jako jsou canary deployments, circuit breakers, fault injection a mnoho dalších.

Jak Istio pracuje s kontejnery a Kubernetes

Servisní síť Istio je sidecarová implementace všeho, co je třeba pro vytváření a správu mikroslužeb: monitoring, trasování, circuit breakers, směrování, vyrovnávání zátěže, fault injection, opakování, časové limity, zrcadlení, řízení přístupu, omezení rychlosti a mnohem více. Ačkoli dnes existuje spousta knihoven pro implementaci těchto funkcí přímo v kódu, s Istio můžete získat totéž, aniž byste museli měnit svůj kód.

Podle sidecarového modelu se Istio provádí v Linuxovém kontejneru, který se nachází ve stejném Kubernetes-podu jako řízená služba a vkládá (inject) a extrahuje (extract) funkcionalitu a informace podle zadané konfigurace. Podtrháváme, že to je vaše vlastní konfigurace, a ta žije mimo váš kód. Proto je kód mnohem jednodušší a kratší.

Co je důležité, je to, že operační složka mikroslužeb není nijak spjata s kódem, což znamená, že její provozování může bez obav převzít IT specialisté. Opravdu, proč by měl vývojář odpovídat za circuit breakery a fault injection? Reagovat – ano, ale zpracovávat je a vytvářet? Pokud to všechno odstraníte z kódu, programátoři se mohou plně soustředit na aplikační funkce. A kód bude také kratší a jednodušší.

Služební síť

Istio, implementující funkce správy mikroslužeb mimo jejich kód – to je koncept služební sítě Service Mesh. Jinými slovy, je to koordinovaná skupina jednoho nebo více binárních souborů, které tvoří síťové funkce.

Jak Istio pracuje s mikroslužbami

Takto vypadá práce sidecar kontejnerů ve spojení s Kubernetes a Minishift z výšky ptáka: spustíte instanci Minishiftu, vytvoříte projekt pro Istio (nazvěme ho 'istio-system'), nainstalujete a spustíte všechny související komponenty Istio. Poté, jakmile vytvoříte projekty a pod, přidáte konfigurační informace do svých nasazení a vaše pod začnou používat Istio. Zjednodušeně diagram vypadá takto:

Série příspěvků o Istio Service Mesh

Nyní můžete měnit nastavení Istio, abyste například organizovali fault injection, podporu Canary Deployment nebo další možnosti Istio – a to vše bez jakéhokoli zásahu do samotného kódu aplikací. Představte si, že chcete přesměrovat veškerý webový provoz od uživatelů svého největšího klienta (Foo Corporation) na novou verzi webu. K tomu stačí vytvořit pravidlo přesměrování Istio, které bude hledat @foocorporation.com v identifikátoru uživatele a provede odpovídající přesměrování. Pro všechny ostatní uživatele se nic nezmění. A mezitím budete v klidu testovat novou verzi webu. A pamatujte, že k tomu vůbec není třeba zapojovat vývojáře.

A za to bude nutné zaplatit hodně?

Vůbec ne. Istio pracuje dost rychle, je napsáno na Go a vytváří velmi malou režii. Kromě toho možné ztráty v online výkonnosti jsou kompenzovány zvýšenou produktivitou vývojářů. Minimálně v teorii: nezapomínejte, že čas vývojářů je drahý. Co se týče nákladů na software, Istio je software s otevřeným zdrojovým kódem, takže jej lze získat a používat zdarma.

Osvojte si to sami

Tým Red Hat Developer Experience vyvinul podrobný praktický průvodce o Istio (v angličtině). Funguje na Linuxu, MacOS a Windows a kód je dostupný ve variantách na Java a Node.js.

10 interaktivních lekcí o Istio

Blok 1 — Pro začátečníky

Úvod do Istio
30 minut
Seznamujeme se se Service Mesh, učíme se, jak nainstalovat Istio v Kubernetes clusteru OpenShift.
Začít

Nasazení mikroslužeb v Istio
30 minut
Používáme Istio k nasazení tří mikroslužeb pomocí Spring Boot a Vert.x.
Začít

Blok 2 – střední úroveň

Monitorování a trasování v Istio
60 minut
Studujeme vestavěné monitorovací nástroje Istio, konfigurovatelné metriky a také OpenTracing přes Prometheus a Grafana.
Začít

Jednoduché směrování v Istio
60 minut
Učíme se řídit směrování v Istio pomocí jednoduchých pravidel.
Začít

Pokročilá směrovací pravidla
60 minut
Seznamujeme se s inteligentním směrováním v Istio, řízením přístupu, vyvažováním zátěže a omezením toku.
Začít

Blok 3 – pokročilý uživatel

Fault Injection v Istio
60 minut
Studujeme scénáře zpracování chyb v distribuovaných aplikacích tím, že vytváříme HTTP chyby a síťové zpoždění, učíme se používat chaos engineering k obnovení prostředí.
Začít

Circuit Breaker v Istio
30 minut
Instalujeme Siege pro zátěžové testování webových stránek a učíme se zajistit odolnost backendu pomocí opakování, circuit breaker a pool ejection.
Začít

Egress a Istio
10 minut
Používáme Egress trasy k vytváření pravidel pro interakci interních služeb s externími API a službami.
Začít

Istio a Kiali
15 minut
Učíme se používat Kiali k získání celkového přehledu o síti služeb a zkoumání toků požadavků a dat.
Začít

Mutual TLS v Istio
15 minut
Vytváříme Istio Gateway a VirtualService, poté podrobně zkoumáme mutual TLS (mTLS) a jeho nastavení.
Začít

Blok 3.1 — Hluboké ponoření: Istio Service Mesh pro mikroslužby

Série příspěvků o Istio Service Mesh
O čem kniha je:

  • Co je to služební síť service mesh.
  • Systém Istio a jeho úloha v architektuře mikroslužeb.
  • Použití Istio při řešení následujících úkolů:
    • Odolnost proti chybám;
    • Směrování;
    • Chaos testing;
    • Bezpečnost;
    • Sběr telemetrie pomocí trasování, metrik a Grafany.

Stáhněte knihu

Série článků o servisních sítích a Istio

Vyzkoušejte sami

Tato série příspěvků nemá za cíl poskytnout hluboký ponor do světa Istio. Chceme vás jen seznámit s touto koncepcí a možná vás inspirovat k tomu, abyste si Istio vyzkoušeli sami. To lze provést zcela zdarma a Red Hat poskytuje všechny potřebné nástroje k tomu, abyste začali ovládat OpenShift, Kubernetes, Linuxové kontejnery a Istio, a to konkrétně: Red Hat Developer OpenShift Container Platform, našeho průvodce Istio a další zdroje na našem mikrostránce o Service Mesh. Neotálejte, začněte ihned dnes!

Pravidla směrování Istio: směřujeme servisní požadavky tam, kam je potřeba

OpenShift a Kubernetes dobře zvládají, aby žádosti na mikroslužby byly směrovány k potřebným podům. Tímto se dosahuje jednoho z cílů existence Kubernetes – směrování a vyvažování zatížení. A co když potřebujete jemnější a sofistikovanější směrování? Například abyste mohli současně používat dvě verze mikroslužby. Jak zde mohou pomoci pravidla směrování Istio Route Rules?

Pravidla směrování jsou pravidla, která určují výběr trasy. Při jakékoli úrovni složitosti systému zůstává celkový princip fungování těchto pravidel jednoduchý: požadavky jsou směrovány na základě stanovených parametrů a hodnot HTTP hlaviček.
Podívejme se na příklady:

Kubernetes ve výchozím nastavení: triviální "50 na 50"

V našem příkladu ukážeme, jak současně používat v OpenShift dvě verze mikroslužby, nazveme je v1 a v2. Každá verze běží ve vlastním podu Kubernetes a ve výchozím nastavení zde funguje rovnoměrně vyvážené cyklické směrování. Každý pod dostává svůj podíl požadavků podle počtu svých instancí mikroslužby, jinými slovy, replik. Istio však umožňuje tento balanc ručně změnit.

Předpokládejme, že jsme na OpenShiftu nasadili dvě verze našeho doporučovacího servisu, recommendation-v1 a recommendation-v2.
Na obrázku 1 je vidět, že když je každý služba představena v jednom exempláři, dotazy se rovnoměrně střídají mezi nimi: 1-2-1-2-… Takto funguje směrování Kubernetes ve výchozím nastavení:

Série příspěvků o Istio Service Mesh

Vážené rozdělení mezi verzemi

Na obrázku 2 je ukázáno, co se stane, pokud zvýšíme počet replik služby v2 z jedné na dvě (to se provádí příkazem oc scale —replicas=2 deployment/recommendation-v2). Jak vidíme, dotazy mezi v1 a v2 se nyní dělí v poměru „jeden k třem“: 1-2-2-1-2-2-…:

Série příspěvků o Istio Service Mesh

Ignorování verze pomocí Istio

Istio umožňuje snadno změnit rozdělení dotazů požadovaným způsobem. Například, odesílat celý provoz pouze na recommendation-v1 pomocí následujícího yaml souboru Istio:

Série příspěvků o Istio Service Mesh

Zde je třeba věnovat pozornost jedné věci: pod’ům jsou vybírány podle značek. V našem příkladu je použita značka v1. Parametr „weight: 100“ znamená, že 100% provozu bude směrováno na všechny pod’y služby, které mají značku v1.

Direktivní rozdělení mezi verzemi (Canary Deployment)

Dále, pomocí parametru weight, můžeme směrovat provoz na obě pod’y, bez ohledu na počet exemplářů mikroservisů spuštěných v každém z nich. Například zde směrujeme 90% provozu na v1 a 10% – na v2:

Série příspěvků o Istio Service Mesh

Oddělené směrování mobilních uživatelů

Na závěr ukážeme, jak donutit směrovat provoz mobilních uživatelů na službu v2, zatímco všichni ostatní půjdou na v1. K tomu analyzujeme hodnotu user-agent v hlavičce dotazu pomocí regulárních výrazů:

Série příspěvků o Istio Service Mesh

Teď je to na vás

Příklad s regulárními výrazy pro analýzu hlaviček by vás měl motivovat k hledání vlastních možností aplikace pravidel směrování Istio. Obzvlášť, když se zde otevírá celá řada možností, protože hodnoty hlaviček lze tvořit v původním kódu aplikací.

A pamatujte, že Ops, nikoli Dev

Vše, co jsme ukázali v příkladech výše, se provádí bez jakýchkoli změn v původním kódu, kromě případů, kdy je potřeba tvořit zvláštní hlavičky dotazů. Istio bude užitečné jak pro vývojáře, kteří ho například mohou použít během testování, tak pro specialisty na provoz IT systémů, které mu výrazně pomohou v produkci.

Takže zopakujme leitmotiv této série příspěvků: nemusíte na svém kódu nic měnitNení potřeba vytvářet nové obrazy nebo spouštět nové kontejnery. Vše se realizuje mimo kód.

Zapněte svou představivost

Jen si představte, jaké perspektivy otevírá analýza hlaviček pomocí regulárních výrazů. Chcete přesměrovat svého největšího klienta na speciální verzi vašich mikroslužby? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.

Vyzkoušejte sami

Číst o Istio, Kubernetes a OpenShift je jedna věc, ale proč si to nevyzkoušet na vlastní kůži? Tým Red Hat Developer Program připravila podrobného průvodce (v angličtině), který vám pomůže co nejrychleji se seznámit s těmito technologiemi. Průvodce je také 100% open source, takže je dostupný veřejnosti. Soubor funguje na macOS, Linux a Windows, a zdrojový kód je k dispozici ve variantách v Java a node.js (verze v jiných jazycích přijdou brzy). Stačí otevřít v prohlížeči příslušný git repozitář. Red Hat Developer Demo.

V dalším příspěvku: řešíme problémy elegantně

Dnes jste viděli, na co mají pravidla směrování Istio. A teď si představte totéž, ale se zaměřením na zpracování chyb. O tom bude náš další příspěvek.

Zdroj: habr.com

Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery 🔥 Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery | ProHoster