Převod: Tento přehledový materiál od Weaveworks seznamuje s nejpopulárnějšími strategiemi nasazení aplikací a vysvětluje, jak implementovat ty nejpokročilejší z nich pomocí Kubernetes operátora Flagger. Je napsán jednoduchým jazykem a obsahuje názorné diagramy, které pomohou porozumět tématu i začínajícím inženýrům.
Diagram je převzat z strategií nasazení, který vytvořil Container Solutions
Jedním z největších problémů při vývoji cloud-native aplikací dnes je zrychlení nasazení. Při mikroslužbovém přístupu již vývojáři pracují s plně modulárními aplikacemi a navrhují je tak, aby různé týmy mohly současně psát kód a provádět změny v aplikaci.
Kratší a častější nasazení mají následující výhody:
- Zkracuje se doba uvedení na trh.
- Nové funkce se rychleji dostávají k uživatelům.
- Zpětná vazba od uživatelů se rychleji dostává k týmu vývojářů. To znamená, že tým může funkce doplňovat a opravovat problémy rychleji.
- Zvyšuje se morálka vývojářů: při větším množství funkcí v vývoji se pracuje zajímavěji.
Ale s rostoucí frekvencí vydání také roste pravděpodobnost negativního vlivu na spolehlivost aplikace nebo uživatelskou zkušenost. Proto je pro týmy provozu a DevOps důležité budovat procesy a řídit strategie nasazení tak, aby minimalizovaly riziko pro produkt a uživatele. (Zjistit více o automatizaci CI/CD pipeline můžete .)
V této publikaci budeme diskutovat o různých strategiích nasazení v Kubernetes, včetně rolling nasazení a pokročilejších metod, jako jsou kanárkové nasazení a jejich variace.
Strategie nasazení
Existuje několik různých typů strategií nasazení, které můžete využít v závislosti na cíli. Může být například potřeba provést změny v určitém prostředí pro další testování, nebo v podmnožině uživatelů/klientů, nebo může být nutné provést omezené testování na uživatelích, než bude nějaká funkce veřejně dostupná.
Rolling (postupné, "navršené" nasazení)
To je standardní strategie nasazení v Kubernetes. Postupně, jeden po druhém, nahrazuje pod'y se starou verzí aplikace pod'y s novou verzí – bez prostojů v klastru.
Kubernetes čeká, až budou nové pod'y připraveny k práci (ověřuje je pomocí ), než začne s ukončováním starých. Pokud nastane problém, lze takovou aktualizaci přerušit, aniž by se zastavil celý klastr. V YAML souboru s popisem typu nasazení nový obraz nahrazuje starý obraz:
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 aktualizace lze upřesnit v manifestovém souboru:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (znovu vytvoření)
V tomto nejjednodušším typu nasazení jsou staré pod'y zabity všechny najednou a nahrazeny novými:
Odpovídající manifest vypadá přibližně takto:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (modro-zelená nasazení)
Strategie modro-zeleného nasazení (někdy také nazývána červeno-černá) předpokládá současné nasazení staré (zelené) a nové (modré) verze aplikace. Po umístění obou verzí mají běžní uživatelé přístup k zelené, zatímco modrá je dostupná pro QA tým pro automatizaci testů přes samostatnou službu nebo přímý přístup portů:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Jakmile byla modrá (nová) verze otestována a její vydání bylo schváleno, služba se přepne na ni, zatímco zelená (starší) se ukončí:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (kanárková nasazení)
Canárková nasazení jsou podobná modro-zeleným, ale lépe řízena a využívají postupný přístup. Tento typ zahrnuje několik různých strategií, včetně "skrytých" spuštění a A/B testování.
Tato strategie se používá, když je potřeba otestovat novou funkčnost, obvykle na backendu aplikace. Podstatou přístupu je vytvořit dva téměř identické servery: jeden obsluhuje téměř všechny uživatele, zatímco druhý, se novými funkcemi, obsluhuje pouze malou skupinu uživatelů, po čemž jsou porovnány výsledky jejich činnosti. Pokud vše probíhá bez chyb, nová verze se postupně nasazuje na celou infrastrukturu.
I když tuto strategii lze realizovat výhradně pomocí Kubernetes, nahrazováním starých podů novými, je mnohem pohodlnější a jednodušší použít service mesh, jako je Istio.
Například můžete mít dva různé manifesty v Gitu: běžný s verzí 0.1.0 a 'kanárkový' s verzí 0.2.0. Úpravou váhy v manifestu virtuálního brány Istio můžete řídit rozdělení provozu mezi těmito dvěma nasazeními:
Krokový návod na realizaci kanárkových nasazení pomocí Istio naleznete v materiálu . (Pozn. přek.: Také jsme překládali materiál o kanárkových nasazeních v Istio .)
Kanárková nasazení s Weaveworks Flagger
usnadňuje a efektivně spravuje kanárková nasazení.
Flagger automatizuje práci s nimi. Používá Istio nebo AWS App Mesh pro směrování a přepínání provozu a také metriky Prometheus pro analýzu výsledků. Dále lze analýzu kanárkových nasazení doplnit webhooky pro provádění akceptačních testů, zátěžových a dalších typů kontrol.
Na základě nasazení Kubernetes a, pokud je to nutné, horizontálního škálování podů (HPA), Flagger vytváří sady objektů (nasazení Kubernetes, služby ClusterIP a virtuální služby Istio nebo App Mesh) pro provádění analýzy a realizaci kanárkových nasazení:
Realizují ovládací smyčku (control loop), Flagger postupně přepíná provoz na kanárkový server, zároveň měří klíčové výkonnostní ukazatele, jako je podíl úspěšných HTTP požadavků, průměrná doba trvání požadavku a zdraví podů. Na základě analýzy KPI (klíčových ukazatelů výkonnosti) se kanárková část buď zvětšuje, nebo zmenšuje, a výsledky analýzy se publikují na Slacku. Popis a ukázku tohoto procesu naleznete v materiálu .
Tmavé (skryté) nebo A/B nasazení
Skryté nasazení je další variace kanárkové strategie (s ní mimochodem může fungovat také Flagger). Rozdíl mezi skrytým a kanárkovým nasazením spočívá v tom, že skrytá nasazení se týkají frontendové části, nikoli backendu, jako je tomu u kanárkových.
Další název těchto nasazení je A/B testování. Místo toho, aby byla nová funkce zpřístupněna všem uživatelům, je nabízena pouze omezené části z nich. Obvykle tito uživatelé nevědí, že se podílí na testování jako prví, a proto se používá termín "skryté nasazení".
Pomocí funkčních přepínačů (feature toggles) a dalších nástrojů lze sledovat, jak uživatelé interagují s novou funkcí, zda je zaujme, nebo zda považují nové uživatelské rozhraní za zmatené, a další typy metrik.
Flagger a A/B nasazení
Kromě váhového směrování může Flagger také směrovat provoz na kanárkový server na základě HTTP parametrů. Při A/B testování lze použít HTTP hlavičky nebo cookies k přesměrování určitého segmentu uživatelů. To je zvlášť efektivní u frontendových aplikací, které vyžadují afinitu relací k serveru (session affinity). Další informace naleznete v dokumentaci Flagger.
Autor vyjadřuje vděčnost , inženýru Weaveworks (a tvůrci Flaggera), za všechny skvělé diagramy nasazení.
P.S. od překladatele
Přečtěte si také náš blog:
- «»;
- «»;
- «»;
- «».
Zdroj: habr.com
