Doufáme, že čtete první díl, kde jsme stručně vysvětlili, co jsou nasazení Canary a ukázali, jak je implementovat pomocí standardních zdrojů Kubernetes.
Stejný
A předpokládáme, že přečtením tohoto článku už víte, co je Istio. Pokud ne, můžete si o tom přečíst zde.
Přihláška ke zkouškám
Každý modul obsahuje dva kontejnery: naši aplikaci a istio-proxy.
Použijeme jednoduchou testovací aplikaci s frontend-nginx a backend python pody. Pod nginx jednoduše přesměruje každý požadavek na backend pod a bude fungovat jako proxy. Podrobnosti najdete v následujících yamls:
Pokud chcete následovat můj příklad a sami tuto testovací aplikaci používat, viz projekt readme.
Počáteční nasazení
Když spustíme první nasazení, vidíme, že moduly naší aplikace mají pouze 2 kontejnery, to znamená, že postranní vozík Istio se právě implementuje:
A ve jmenném prostoru vidíme také Istio Gateway Loadbalancer istio-system:
Generování dopravy
Ke generování provozu, který bude přijímán frontendovými moduly a předáván backendovým modulům, použijeme následující IP:
while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done
Také doplníme frontend.istio-test do našeho souboru hosts.
Zobrazit Mesh přes Kiali
Nainstalovali jsme testovací aplikaci a Istio spolu s Tracing, Grafana, Prometheus a Kiali (podrobnosti viz níže). projekt readme). Proto můžeme Kiali používat prostřednictvím:
istioctl dashboard kiali # admin:admin
Kiali vizualizuje aktuální provoz prostřednictvím sítě Mesh
Jak vidíme, 100 % provozu jde do frontendové služby a poté do frontendových podů s označením v1, protože používáme jednoduchý nginx proxy, který přesměrovává požadavky na backendovou službu, která je zase přesměrovává na backendové pody. se štítkem v1.
Kiali skvěle spolupracuje s Istio a poskytuje krabicové řešení vykreslování Mesh. Prostě skvělé.
Kanárské nasazení
Náš backend již má dvě nasazení k8s, jedno pro v1 a jedno pro v2. Teď jen musíme říct Istiovi, aby přeposlal určité procento požadavků do v2.
Krok 1: 10 %
A vše, co musíme udělat, je upravit váhu VirtualService in istio.yaml:
Nyní lze nasazení Canary považovat za dokončené a veškerý provoz je přesměrován na v2:
Testování Canary ručně
Řekněme, že nyní posíláme 2 % všech požadavků na backend v10. Co když chceme ručně otestovat v2, abychom se ujistili, že vše funguje tak, jak očekáváme?
Můžeme přidat speciální pravidlo pro párování založené na HTTP hlavičkách:
Nyní pomocí curl můžeme vynutit požadavek v2 odesláním záhlaví:
Požadavky bez záhlaví budou stále řízeny poměrem 1/10:
Canary pro dvě závislé verze
Nyní zvážíme možnost, kdy máme verzi v2 pro frontend i backend. U obou jsme uvedli, že 10 % provozu by mělo jít do verze 2:
Vidíme, že frontend v1 a v2 oba dopředný provoz v poměru 1/10 k backendu v1 a v2.
Co kdybychom potřebovali přesměrovat provoz z frontend-v2 pouze na backend-v2, protože to není kompatibilní s v1? Za tímto účelem nastavíme pro frontend poměr 1/10, který řídí, jaký provoz se dostane na backend-v2 pomocí vyjednávání sourceLabels :
В první část Nasazení Canary jsme provedli ručně, také pomocí dvou nasazení k8s. Tam jsme řídili poměr požadavků změnou počtu replik. Tento přístup funguje, ale má vážné nevýhody.
Istio umožňuje určit poměr požadavků bez ohledu na počet replik. To například znamená, že můžeme používat HPA (Horizontal Pod Autoscalers) a nemusíme být konfigurováni podle aktuálního stavu nasazení Canary.
Celkový
Istio funguje skvěle a jeho použití spolu s Kiali vytváří velmi silnou kombinaci. Další na mém seznamu zájmů je kombinace Spinnaker s Istio pro automatizaci a analytiku Canary.