Märkus tõlkes: See ülevaatlik materjal Weaveworksilt tutvustab kõige populaarsemaid rakenduste väljaandmise strateegiaid ja selgitab, kuidas rakendada kõige arenenumaid neist Kubernetesi operaatori Flaggeriga. See on kirjutatud lihtsas keeles ja sisaldab visuaalseid skeeme, mis aitavad mõista teemat isegi algajatel inseneridel.
Skeem on pärit väljandusstrateegiate kohta, mille on koostanud Container Solutions
Üks suurimaid probleeme tänapäeva pilvaseente rakenduste arendamisel on väljaande kiirus. Mikroteenuste lähenemisviisis töötavad arendajad juba täiesti modulaarsete rakendustega ja kavandavad neid, võimaldades erinevatele meeskondadele samal ajal koodi kirjutada ja rakenduses muudatusi teha.
Lühematel ja sagedasematel väljaannetel on järgmised eelised:
- Lühendatakse turule jõudmise aega.
- Uued funktsioonid jõuavad kiiremini kasutajateni.
- Kasutajate tagasiside jõuab kiiremini arendajate meeskonnani. See tähendab, et meeskond saab funktsioone täiendada ja probleeme kiiremini lahendada.
- Arendajate motivatsioon tõuseb: rohkemate funktsioonide arendamisel on huvitavam töötada.
Aga väljaannete sageduse suurenedes tõuseb ka risk, et see võib negatiivselt mõjutada rakenduse usaldusväärsust või kasutajakogemust. Just seetõttu on tegevus- ja DevOps-meeskondade jaoks oluline ehitada protsessid ja hallata väljaandmisstrateegiaid nii, et minimeerida riske tootele ja kasutajatele. (Lisainfot CI/CD töövoogude automatiseerimise kohta leiate .)
Selles publikatsioonis arutame erinevaid väljaandmisstrateegiaid Kubernetesis, sealhulgas järk-järgulisi väljaandeid ja arenenumaid meetodeid, nagu kanariväljaanded ja nende variatsioonid.
Juurutamisstrateegiad
On olemas mitmeid erinevaid väljaandmisstrateegiaid, mida saab kasutada sõltuvalt eesmärgist. Näiteks võite vajada muudatusi mingis keskkonnas edasiseks testimiseks, või alagrupis kasutajatest/klientidest, või võib olla vajalik teostada piiratud testimine kasutajate seas enne mõne funktsiooni avalikustamist.
Rolling (järkjärguline, „ülesehitav“ väljaanne)
See on Kubernetes'i standardne juurutamisstrateegia. See vahetab järk-järgult, üks haaval, vanade rakenduse versiooniga pod'id uute versiooniga pod'ide vastu - ilma klastris seisakut tekitamata.
Kubernetes ootab, kuni uued pod'id on tööks valmis (kontrollides neid ), enne kui alustatakse vanade sulgemist. Kui tekib probleem, saab sellise järkjärgulise uuendamise katkestada, peatamata kogu klastrit. YAML-failis, mis kirjeldab juurutamise tüüpi, asendab uus pilt vana:
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: 8080Järkjärgulise uuendamise parameetreid saab täpsustada maniifestifailis:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (uuesti loomine)
Selles kõige lihtsamas juurutamise tüübis tapetakse vanad pod'id kõik korraga ja asendatakse uutega:
Asjakohane maniifesteeritud näeb välja ligikaudu nii:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (sinine/roheline juurutamine)
Sinise-kase juurutamise strateegia (mõnikord nimetatakse seda ka punase/musta süsteemiks) hõlmab vana (rohelise) ja uue (sinise) versiooni rakenduse samaaegset juurutamist. Pärast mõlema versiooni paigutamist saavad tavakasutajad juurdepääsu rohelisele, samal ajal kui sinine on kätketud QA meeskonnale automaatsete testide läbiviimiseks läbi eraldi teenuse või otseportide suunamise:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Pärast seda, kui sinine (uus) versioon on testitud ja selle release on heaks kiidetud, lülitatakse teenus sellele üle, samal ajal kui roheline (vana) suletakse:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (kanaride juurutamine)
Kanari juurutamised on sarnased sinise-rohelise süsteemiga, kuid paremini hallatud ja kasutavad järkjärgulist lähenemist. Sellesse tüüpi kuulub mitmeid erinevaid strateegiaid, sealhulgas „varjatud” käivitamised ja A/B testimine.
Seda strateegiat rakendatakse, kui on vajalik testida uut funktsionaalsust, tavaliselt rakenduse tagapool. Lähenemise olemus seisneb kahe praktiliselt identse serveri loomises: üks teenindab peaaegu kõiki kasutajaid, samas kui teine, uute funktsioonidega, teenindab vaid väikest alagruppi kasutajatest, mille järel võrreldakse nende töö tulemusi. Kui kõik läheb ladusalt, viiakse uus versioon järk-järgult kogu infrastruktuuri.
Kuigi seda strateegiat saab teostada ainult Kubernetes'e vahenditega, asendades vanad pod'id uute vastu, on palju mugavam ja lihtsam kasutada teenuste mesh'i nagu Istio.
Näiteks võivad teil olla kaks erinevat manifesti Git'is: tavaline versioon sildiga 0.1.0 ja "kanaari" versioon sildiga 0.2.0. Muutes kaalu Istio virtuaalses väravas, saab hallata liikluse jaotust nende kahe deployment'i vahel:
Samm-sammuline juhend kanaari deployment'ide rakendamiseks Istio abil leiate materjalist . (Märkus tõlke kohta.: Oleme samuti tõlkinud materjali kanaari väljalaskmise kohta Istios .)
Kanaari deployment'id Weaveworks Flagger'iga
võimaldab hõlpsasti ja tõhusalt hallata kanaari väljalaskmisi.
Flagger automatiseerib nendega töötamise. See kasutab liikumise ja liikluse suunamise jaoks Istio või AWS App Mesh'i ning tulemuste analüüsimiseks Prometheuse mõõdikuid. Lisaks saab kanaari deployment'ide analüüsi täiendada veebiluhtidega vastuvõtu testide, koormustestide ja muude kontrollide läbiviimiseks.
Kubernetes'i deployment'i ja vajadusel pod'ide horisontaalse skalimise (HPA) alusel loob Flagger objektide kogumeid (Kubernetes'i deployment'id, ClusterIP teenused ja Istio või App Mesh'i virtuaalsed teenused) kanaari deployment'ide analüüside ja rakendamise jaoks:
Rakendades juhtimistsüklit (control loop), suunab Flagger järk-järgult liikluse kanaari serverile, samas mõõtes võtmenäitajate, näiteks edukate HTTP-päringute osakaalu, keskmise päringu kestuse ja pod'ide tervise näitajaid. KPI (võtmenäitajate) analüüsi põhjal kanaari osa kas tõuseb või langeb, ning analüüsi tulemused avaldatakse Slackis. Selle protsessi kirjelduse ja demonstrooimis saate leida materjalist .
Tume (peidetud) või A/B-juhtimised
Peidetud juurdevõtt on veel üks kanarbiku strateegia variatsioon (mille jaoks võib Flagger samuti töötada). Erinevus peidetud ja kanarbiku juurdevõtte vahel on see, et peidetud juurdevõtt tegeleb esiküljega, mitte tagaküljega, nagu kanarbiku.
Teine nimi nendele juurdevõttedele on A/B-testimine. Selle asemel, et avada uue funktsiooni juurdevõtt kõigile kasutajatele, pakutakse seda ainult piiratud osale neist. Tavaline on, et need kasutajad ei tea, et nad on esimesena testijad (seetõttu ka termin "peidetud juurdevõtt").
Funktsionaalsuse lülitite kaudu (feature toggles) ja teiste tööriistade abil saab jälgida, kuidas kasutajad uue funktsiooniga suhtlevad, kas see köidab neid või peavad nad uut kasutajaliidest segaseks, ja muid mõõdikuid.
Flagger ja A/B-juurdevõtted
Lisaks kaalu põhjal suunamisele võib Flagger samuti suunata kanarbiku serverisse liiklust sõltuvalt HTTP parameetritest. A/B-testimisel saab kasutada HTTP pealkirju või küpsiseid teatud kasutajasegmendi suunamiseks. See on eriti tõhus esiküljel rakenduste puhul, mis nõuavad seansi seotust serveriga (session affinity). Täiendavat teavet leiate Flaggeri dokumentatsioonist.
Autor tänab , Weaveworksi inseneri (ja Flaggeri looja), kõikide nende hämmastavate juurutusskeemide eest.
P.S. tõlkijalt
Lugege ka meie blogist:
- «»;
- «»;
- «»;
- «».
Allikas: habr.com
