Poznámka preklad: Tento prehľad od Weaveworks predstavuje najobľúbenejšie stratégie zavádzania aplikácií a ukazuje, ako je možné implementovať tie najpokročilejšie pomocou operátora Kubernetes Flagger. Je napísaná jednoduchým jazykom a obsahuje vizuálne diagramy, ktoré umožnia porozumieť problematike aj začínajúcim inžinierom.
Diagram je prevzatý z stratégie zavádzania vytvorené v rámci riešení kontajnerov
Jednou z najväčších výziev pri vývoji cloudových natívnych aplikácií je dnes urýchlenie nasadenia. V prístupe mikroslužieb vývojári už pracujú a navrhujú úplne modulárne aplikácie, čo umožňuje rôznym tímom súčasne písať kód a vykonávať zmeny v aplikácii.
Kratšie a častejšie nasadenia majú tieto výhody:
- Čas uvedenia na trh je skrátený.
- Nové funkcie sa k používateľom dostanú rýchlejšie.
- Spätná väzba používateľov sa dostane k vývojovému tímu rýchlejšie. To znamená, že tím môže rýchlejšie pridávať funkcie a riešiť problémy.
- Morálka vývojára sa zvyšuje: s viacerými funkciami vo vývoji je zábavnejšie pracovať.
Ale so zvyšujúcou sa frekvenciou vydaní sa zvyšuje aj pravdepodobnosť negatívneho ovplyvnenia spoľahlivosti aplikácie alebo používateľskej skúsenosti. Preto je dôležité, aby operácie a tímy DevOps budovali procesy a spravovali stratégie nasadenia spôsobom, ktorý minimalizuje riziko pre produkt a používateľov. (Môžete sa dozvedieť viac o automatizácii potrubia CI/CD .)
V tomto príspevku budeme diskutovať o rôznych stratégiách nasadenia v Kubernetes vrátane postupných nasadení a pokročilejších metód, ako je napríklad zavedenie kanárikov a ich variácie.
Stratégie nasadenia
Existuje niekoľko rôznych typov stratégií nasadenia, ktoré môžete použiť v závislosti od vášho cieľa. Napríklad možno budete musieť vykonať zmeny v určitom prostredí na ďalšie testovanie alebo v podskupine používateľov/klientov, alebo možno budete musieť pred vytvorením funkcie vykonať obmedzené používateľské testovanie. verejnosti.
Rolling (postupné, „rolling“ nasadenie)
Toto je štandardná stratégia nasadenia v Kubernetes. Postupne, jeden po druhom, nahrádza pody so starou verziou aplikácie podmi s novou verziou – bez výpadku klastra.
Kubernetes čaká, kým budú nové moduly pripravené na prácu (skontroluje ich pomocou ), než začnete zrolovať staré. Ak sa vyskytne problém, túto priebežnú aktualizáciu možno prerušiť bez zastavenia celého klastra. V súbore YAML popisujúcom typ nasadenia nový obrázok nahradí starý obrázok:
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: 8080Parametre aktualizácie prechodu možno zadať v súbore manifestu:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Znovu vytvoriť
V tomto najjednoduchšom type nasadenia sú staré moduly zabité naraz a nahradené novými:
Zodpovedajúci manifest vyzerá asi takto:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Modrá/zelená (modro-zelené nasadenie)
Modro-zelená stratégia nasadenia (niekedy nazývaná aj červená/čierna) zahŕňa súčasné nasadenie starej (zelenej) a novej (modrej) verzie aplikácie. Po odoslaní oboch verzií majú bežní používatelia prístup k zelenej verzii, zatiaľ čo modrá je k dispozícii tímu QA na automatizáciu testov prostredníctvom samostatnej služby alebo priameho presmerovania portov:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Po otestovaní modrej (novej) verzie a schválení jej vydania sa na ňu služba prepne a zelená (stará) verzia sa zloží:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (nasadenie kanárikov)
Zavedenia Canary sú podobné ako modrozelené, ale majú lepšie ovládanie a používanie postupný prístup. Tento typ zahŕňa niekoľko rôznych stratégií vrátane „skrytých“ spustení a testovania A/B.
Táto stratégia sa používa, keď je potrebné vyskúšať nejakú novú funkcionalitu, zvyčajne v backende aplikácie. Podstatou prístupu je vytvorenie dvoch takmer identických serverov: jeden slúži takmer všetkým používateľom a druhý s novými funkciami slúži len malej podskupine používateľov, po ktorých sa porovnávajú výsledky ich práce. Ak všetko prebehne bez chýb, nová verzia je postupne nasadená na celú infraštruktúru.
Aj keď je možné túto stratégiu implementovať výlučne pomocou Kubernetes a nahradiť staré moduly novými, je oveľa pohodlnejšie a jednoduchšie použiť sieť služieb, ako je Istio.
V Gite môžete mať napríklad dva rôzne manifesty: bežný manifest so značkou 0.1.0 a kanársky manifest so značkou 0.2.0. Zmenou váh v manifeste virtuálnej brány Istio môžete ovládať rozdelenie návštevnosti medzi tieto dve nasadenia:
Podrobný návod na implementáciu nasadenia canary pomocou Istio nájdete na . (Poznámka. preklad.: Materiál o zavedení kanárikov sme preložili aj do Istio .)
Canary Deployments with Weaveworks Flagger
vám umožňuje jednoducho a efektívne riadiť zavádzanie kanárikov.
Flagger prácu s nimi automatizuje. Používa Istio alebo AWS App Mesh na smerovanie a prepínanie prevádzky a metriky Prometheus na analýzu výsledkov. Okrem toho môže byť analýza nasadení kanárikov doplnená o webhooky na vykonávanie akceptačných testov, záťažových testov a akýchkoľvek iných typov kontrol.
Na základe nasadenia Kubernetes a v prípade potreby horizontálneho škálovania podov (HPA) vytvára Flagger sady objektov (nasadenia Kubernetes, služby ClusterIP a virtuálne služby Istio alebo App Mesh) na analýzu a implementáciu nasadení canary:
Implementácia regulačnej slučky (riadiaca slučka),Fagger postupne prepína návštevnosť na server Canary a súčasne meria kľúčové metriky výkonu, ako je percento úspešných požiadaviek HTTP, priemerné trvanie požiadavky a stav pod. Na základe analýzy KPI (Key Performance Indicators) kanárik buď rastie, alebo skolabuje a výsledky analýzy sú publikované v Slacku. Popis a demonštráciu tohto procesu nájdete v materiáli .
Tmavé (skryté) alebo nasadenia A/B
Stealth nasadenie je ďalšou variáciou kanárikovej stratégie (s ktorou mimochodom dokáže pracovať aj Flagger). Rozdiel medzi stealth a canary nasadeniami je v tom, že stealth nasadenia sa zaoberajú skôr frontendom než backendom ako canary nasadeniami.
Ďalším názvom pre tieto nasadenia je A/B testovanie. Namiesto toho, aby bola nová funkcia dostupná pre všetkých používateľov, je ponúkaná len obmedzenej časti z nich. Títo používatelia si zvyčajne neuvedomujú, že sú priekopníckymi testermi (odtiaľ pojem „skryté nasadenie“).
Použitie funkčných prepínačov (prepínanie funkcií) a ďalších nástrojov, môžete sledovať, ako používatelia interagujú s novou funkciou, či ich zaujala, alebo či im nové používateľské rozhranie pripadá mätúce, a ďalšie typy metrík.
Flagger a A/B nasadenia
Okrem smerovania na základe hmotnosti môže Flagger smerovať aj prenos na server Canary na základe parametrov HTTP. V A/B testovaní môžete použiť hlavičky HTTP alebo súbory cookie na zacielenie na konkrétny segment používateľov. Toto je obzvlášť účinné v prípade frontendových aplikácií, ktoré vyžadujú väzbu relácie na server (príbuznosť relácie). Viac informácií nájdete v dokumentácii Flagger.
Autor vyjadruje vďačnosť , Weaveworks inžinier (a tvorca Flagger), pre všetky tieto úžasné vzory nasadenia.
PS od prekladateľa
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «»;
- «".
Zdroj: hab.com
