Shënim: përkthimi: Ky material përmbledhës nga Weaveworks prezanton strategjitë më të njohura të shpërndarjes së aplikacioneve dhe tregon mundësinë e implementimit të strategjive më të avancuara me ndihmën e operatorit Kubernetes Flagger. Ai është shkruar në një gjuhë të thjeshtë dhe përmban skemat e qarta, që e lejojnë të kuptohet çështja edhe nga inxhinierët fillestarë.
Skema është marrë nga i strategjive të shpërndarjes, të bërë në Container Solutions
Një nga problemet më të mëdha në zhvillimin e aplikacioneve cloud native sot është përshpejtimi i shpërndarjes. Me qasjen mikroshërbimore, zhvilluesit tashmë punojnë me aplikacione plotësisht modulare dhe i projektojnë ato, duke lejuar ekipe të ndryshme të shkruajnë kodin dhe të bëjnë ndryshime në aplikacion njëkohësisht.
Shpërndarjet më të shkurtra dhe më të shpeshta kanë këto përparësi:
- Koha për të hyrë në treg reduktohet.
- Funksionet e reja arrijnë më shpejt te përdoruesit.
- Komentet e përdoruesve mbërrijnë më shpejt te ekipi i zhvilluesve. Kjo do të thotë se ekipi mund të shtojë funksionalitete dhe të rregullojë problemet më shpejt.
- Morali i zhvilluesve rritet: me më shumë funksione në zhvillim, është më emocionuese të punosh.
Por me rritjen e frekuencës së shpërndarjeve, rriten gjithashtu shanset për të ndikuar negativisht në besueshmërinë e aplikacionit ose përvojën e përdoruesve. Pikërisht për këtë arsye, ekipet e operacioneve dhe DevOps-it është e rëndësishme të ndërtojnë procese dhe të menaxhojnë strategjitë e shpërndarjes në mënyrë që të minimizojnë rrezikun për produktin dhe përdoruesit. (Mësoni më shumë rreth automatizimit të pipeline-ëve CI/CD) .)
Në këtë botim do të diskutojmë strategjitë e ndryshme të shpërndarjes në Kubernetes, duke përfshirë shpërndarjet rolling dhe metodat më të avancuara, siç janë shpërndarjet canary dhe llojet e tyre.
Strategjitë e shpërndarjes
Ekzistojnë disa lloje të ndryshme strategjish shpërndarjeje që mund të shfrytëzohen, në varësi të qëllimit. Për shembull, ndoshta do t'ju nevojitet të bëni ndryshime në një ambient për testim të mëtejshëm, ose në një nëngrup përdoruesish/konsumatorësh, ose ndoshta do të duhet të realizoni një testim të kufizuar te përdoruesit para se të bëni një funksion publik.
Rolling (shpërndarje ngadalësisht e realizuar)
Kjo është një strategji standarde e shpërndarjes në Kubernetes. Ajo gradualisht, një nga një, zëvendëson podët me versionin e vjetër të aplikacionit me podë me versionin e ri — pa ndërprerje të klashtës.
Kubernetes pret që podët e rinj të jenë gati për t'u përdorur (duke i kontrolluar ata me ), para se të fillojë tërheqjen e të vjetrëve. Nëse ndodhin probleme, një azhurnim i tillë mund të ndërpritet pa ndaluar tërë klashtën. Në skedarin YAML që përshkruan llojin e shpërndarjes, imazhi i ri zëvendëson imazhin e vjetër:
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: 8080Opsionet e azhurnimit të rolling mund të saktësohen në skedarin e manifestit:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (ri krijimi)
Në këtë lloj më të thjeshtë shpërndarjeje, podët e vjetra eliminohen të gjithë njëherësh dhe zëvendësohen me të rinjtë:
Manifesti përkatës duket diçka si kjo:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (shpërndarje blu/gjelbër)
Strategjia e shpërndarjes blu/gjelbër (ndonjëherë e quajtur gjithashtu red/black, dmth. e kuqe/zeshkë) parashikon shpërndarjen simultane të versioneve të vjetra (gjelbër) dhe të reja (blu) të aplikacionit. Pas vendosjes së të dy versioneve, përdoruesit normalë kanë akses në versionin gjelbër, ndërsa versione blu është në dispozicion për ekipin QA për automatizimin e testeve përmes një shërbimi të veçantë ose përmes përçimit të portave:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Pasi që versioni blu (i ri) është testuar dhe është miratuar lëshimi i tij, shërbimi kalon në të, ndërsa ai gjelbër (i vjetër) tërhiqet:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (shpërndarje kanarie)
Shpërndarjet kanarie janë të ngjashme me shpërndarjet blu/gjelbër, por menaxhohen më mirë dhe përdorin në mënyrën e saktë. Ky tip përfshin disa strategji të ndryshme, duke përfshirë lançime "të fshehta" dhe testim A/B.
Kjo strategji aplikohet kur është e nevojshme të testoni një funksionalitet të ri, zakonisht në backend të aplikacionit. Thelbi i qasjes është të krijoni dy servera praktikisht identikë: njëri shërben pothuajse të gjithë përdoruesit, ndërsa tjetri, me funksionalitete të reja, shërben vetëm një grup të vogël përdoruesish, pas së cilës rezultatet e punës së tyre krahason. Nëse gjithçka shkon pa gabime, versioni i ri gradualisht implementohet në të gjithë infrastrukturën.
Edhe pse kjo strategji mund të realizohet ekskluzivisht përmes Kubernetes, duke zëvendësuar pod-et e vjetra me të reja, është shumë më e lehtë dhe më e thjeshtë të përdorni një service mesh si Istio.
Për shembull, mund të keni dy manifestime të ndryshme në Git: një të zakonshëm me etiketën 0.1.0 dhe një "kanar" me etiketën 0.2.0. Duke ndryshuar peshat në manifestin e portës virtuale Istio, mund të menaxhoni shpërndarjen e trafikut midis këtyre dy deployment-eve:
Një udhëzues hap pas hapi për implementimin e kanareve me Istio mund të gjendet në materialin . (Shën. përkth.: Ne gjithashtu përkthyem materialin në lidhje me shpërndarjet kanar në Istio .)
Shpërndarjet kanar me Weaveworks Flagger
lejon menaxhimin e lehtë dhe efektiv të kanareve.
Flagger automatizon punën me to. Ai përdor Istio ose AWS App Mesh për të drejtuar dhe ndërruar trafikun, si dhe metrikat Prometheus për të analizuar rezultatet. Përveç kësaj, analiza e shpërndarjeve kanar mund të plotësohet me webhook për kryerjen e testeve të pranimit (acceptance), testeve nën ngarkesë dhe çdo lloj kontrolli tjetër.
Bazuar në deployment-in Kubernetes dhe, nëse është e nevojshme, shkallëzimin horizontal të pod-eve (HPA), Flagger krijon grupe objektesh (deployment-e Kubernetes, shërbime ClusterIP dhe shërbime virtuale Istio ose App Mesh) për të kryer analizën dhe implementimin e shpërndarjeve kanar:
Duke realizuar konturin e menaxhimit (control loop), Flagger gradualisht kalon trafikun në serverin kanar, duke matur paralelisht treguesit kryesorë të performancës, siç është përqindja e kërkesave HTTP të suksesshme, koha mesatare e kërkesës dhe shëndeti i pod-eve. Duke u bazuar në analizën KPI (treguesit kryesorë të performancës), pjesa kanar ose rritet ose zvogëlohet, dhe rezultatet e analizës publikohen në Slack. Përshkrimi dhe demonstrimi i këtij procesi mund të gjenden në materialin .
Dark (fshehura) ose A/B-deployments
Deployimi i fshehur është një tjetër variacion i strategjisë kanarin (me të, Flagger gjithashtu mund të punojë). Diferenca midis deployimeve të fshehura dhe atyre kanarin është që deployimet e fshehura trajtojnë frontend-in, jo backend-in, siç bëjnë deployimet kanarin.
Një emër tjetër për këto deployime është A/B-testimi. Në vend që të hapet akses për një veçori të re për të gjithë përdoruesit, ajo ofrohet vetëm për një pjesë të kufizuar të tyre. Zakonisht këta përdorues nuk e dinë se po veprojnë si testues pionierë (këtu vjen edhe termi 'deployim i fshehur').
Me ndihmën e aktivizuesve të funksionalitetit (feature toggles) dhe mjeteve të tjera është e mundur të ndiqni se si përdoruesit lidhen me veçorinë e re, a i ngacmon ata, apo e konsiderojnë ndërfaqen e re përdoruesi si të ndërlikuar, dhe lloje të tjera metrikash.
Flagger dhe A/B-deployments
Përveç ruteve të bazuara në peshë, Flagger gjithashtu mund të drejtojë trafik në serverin kanarin në varësi të parametrave HTTP. Në testimin A/B, mund të përdoren kokat HTTP ose cookie për të ridrejtuar një segment të caktuar përdoruesish. Kjo është veçanërisht efektive në rastet e aplikacioneve frontend që kërkojnë lidhjen e sesionit me serverin (session affinity). Informacione të tjera mund të gjenden në dokumentacionin Flagger.
Autori shpreh mirënjohje , inxhinierit të Weaveworks (dhe krijuesit të Flagger), për të gjithë këto skema të mahnitshme të deployimit.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
