Poznámka. překlad: Tento návod od Weaveworks představuje nejoblíbenější strategie zavádění aplikací a jak můžete implementovat ty nejpokročilejší s operátorem Flagger Kubernetes. Je napsána jednoduchým jazykem a obsahuje vizuální diagramy, které umožňují pochopit problematiku i začínajícím inženýrům.
Diagram převzat z strategie zavádění vytvořené v Container Solutions
Jednou z největších výzev při vývoji cloudových nativních aplikací je dnes rychlost nasazení. Díky přístupu mikroslužeb vývojáři již pracují a navrhují plně modulární aplikace, což umožňuje různým týmům psát kód a provádět změny v aplikaci současně.
Kratší a častější nasazení má následující výhody:
- Zkrácený čas uvedení na trh.
- Nové funkce se k uživatelům dostanou rychleji.
- Zpětná vazba uživatelů se rychleji dostane k vývojovému týmu. To znamená, že tým může rychleji přidávat funkce a řešit problémy.
- Zlepšuje morálku vývojářů: Práce s více funkcemi ve vývoji je zábavnější.
Ale jak se frekvence vydávání zvyšuje, zvyšuje se také šance na negativní dopad na spolehlivost aplikace nebo uživatelský dojem. Proto je důležité, aby provozní a DevOps týmy budovaly procesy a řídily strategie nasazení způsobem, který minimalizuje riziko pro produkt a uživatele. (Další informace o automatizaci potrubí CI/CD naleznete v části .)
V tomto příspěvku budeme diskutovat o různých strategiích nasazení Kubernetes, včetně postupných nasazení a pokročilejších metod, jako je zavádění canary a jejich variace.
Strategie nasazení
Existuje několik různých typů strategií nasazení, které lze použít v závislosti na účelu. Například možná budete muset provést změny v některém prostředí pro další testování nebo v podmnožině uživatelů/klientů, nebo možná budete muset provést omezené testování na uživatelích před vytvořením funkce. veřejnost.
Rolling (postupné, postupné nasazení)
Toto je standardní strategie nasazení pro Kubernetes. Postupně, jeden po druhém, nahrazuje pody se starou verzí aplikace pody s novou verzí - bez prostojů clusteru.
Kubernetes čeká, až budou připraveny nové moduly (kontroluje je pomocí ), než začnete srolovat ty staré. Pokud dojde k problému, lze tuto průběžnou aktualizaci přerušit bez zastavení celého clusteru. V souboru YAML popisujícím typ nasazení nový obrázek nahradí starý obrázek:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080Parametry průběžné aktualizace lze zadat v souboru manifestu:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Znovu vytvořit (znovu vytvořit)
V tomto nejjednodušším typu nasazení jsou staré moduly zabity všechny najednou a nahrazeny novými:
Odpovídající manifest vypadá asi takto:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Modrá/zelená (modro-zelená nasazení)
Strategie nasazení modro-zelená (někdy také označovaná jako červená / černá, tedy červeno-černá) zahrnuje současné nasazení staré (zelené) a nové (modré) verze aplikace. Jakmile jsou obě verze hostovány, zelená je k dispozici obecnému uživateli, zatímco modrá je k dispozici týmu QA pro automatizaci testů prostřednictvím samostatné služby nebo přímého přesměrování portů:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Poté, co byla otestována a schválena modrá (nová) verze, služba se na ni přepne a zelená (stará) se minimalizuje:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (kanárská nasazení)
Canary rollouty jsou podobné modrozeleným, ale lépe se ovládají a používají postupný přístup. Tento typ zahrnuje několik různých strategií, včetně „stealth“ spouštění a A/B testování.
Tato strategie se používá, když je potřeba otestovat nějakou novou funkcionalitu, obvykle v backendu aplikace. Podstatou přístupu je vytvoření dvou téměř identických serverů: jeden obsluhuje téměř všechny uživatele a druhý s novými funkcemi obsluhuje pouze malou podskupinu uživatelů, načež se výsledky jejich práce porovnávají. Pokud vše proběhne bez chyb, je nová verze postupně nasazena na celou infrastrukturu.
I když lze tuto strategii implementovat výhradně pomocí Kubernetes, nahrazování starých modulů novými, je mnohem pohodlnější a jednodušší použít servisní síť, jako je Istio.
Můžete mít například dva různé manifesty Git: běžný s tagem 0.1.0 a kanárský s tagem 0.2.0. Změnou vah v manifestu Istio Virtual Gateway můžete řídit rozložení provozu mezi tato dvě nasazení:
Podrobný průvodce implementací kanárských nasazení s Istio lze nalézt v . (Poznámka. přel.: Také jsme překládali materiál o kanárských závitcích v Istiu .)
Nasazení Canary s Weaveworks Flagger
umožňuje snadné a efektivní ovládání kanárských závitků.
Flagger práci s nimi automatizuje. Ke směrování a přepínání provozu využívá Istio nebo AWS App Mesh a k analýze výsledků metriky Prometheus. Kromě toho lze analýzu nasazení kanárků doplnit o webhooky pro provádění akceptačních testů, zátěžových testů a jakýchkoli dalších typů kontrol.
Na základě nasazení Kubernetes a v případě potřeby scale-out podů (HPA) vytváří Flagger sady objektů (nasazení Kubernetes, služby ClusterIP a virtuální služby Istio nebo App Mesh) pro analýzu a implementaci kanárkových nasazení:
Zavedení regulační smyčky (kontrolní smyčka)Flagger postupně přepíná provoz na server Canary a zároveň měří klíčové metriky výkonu, jako je úspěšnost požadavků HTTP, průměrná doba trvání požadavku a stav podu. Na základě analýzy KPI (Key Performance Indicators) kanárská část buď roste, nebo se zmenšuje a výsledky analýzy jsou publikovány do Slacku. Popis a ukázku tohoto procesu naleznete v materiálu .
Tmavé (skryté) nebo nasazení A/B
Stealth nasazení je další variací kanárské strategie (se kterou mimochodem umí pracovat i Flagger). Rozdíl mezi stealth a canary nasazením je v tom, že stealth nasazení se zabývá frontendem a ne backendem, jako to dělají canary nasazení.
Dalším názvem pro tato nasazení je A/B testování. Místo otevření přístupu k nové funkci všem uživatelům je nabízena pouze omezené části z nich. Tito uživatelé si obvykle neuvědomují, že jsou průkopnickými testery (odtud termín „tiché nasazení“).
S přepínači funkcí (přepínání funkcí) a dalších nástrojů můžete sledovat, jak uživatelé interagují s novou funkcí, zda jsou na ní závislí nebo zda je nové uživatelské rozhraní matoucí, a další typy metrik.
Flagger a A/B nasazení
Kromě váženého směrování může Flagger také směrovat provoz na server Canary na základě parametrů HTTP. A/B testování může používat HTTP hlavičky nebo cookies k přesměrování konkrétního segmentu uživatelů. To je zvláště účinné v případě frontendových aplikací, které vyžadují spojení relace se serverem. (příbuznost relace). Více informací naleznete v dokumentaci Flagger.
Autor je vděčný , inženýr Weaveworks (a tvůrce Flagger), za všechna tato úžasná schémata nasazení.
PS od překladatele
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «".
Zdroj: www.habr.com