Shënim: Ky material rreth përmbledhjes nga Weaveworks njihet me strategjitë më të njohura të shpërndarjes së aplikacioneve dhe përshkruan mundësinë e implementimit të disa prej tyre më të avancuara me ndihmën e operatorit Kubernetes Flagger. Ai është shkruar në një gjuhë të thjeshtë dhe përmban skema visive që e lejojnë të kuptohet edhe nga inxhinierët fillestarë.
Schema është marrë nga e strategjive të shpërndarjes, e bërë në Container Solutions
Një nga problemet më të mëdha në zhvillimin e aplikacioneve cloud native sot është përshpejtimi i deploy-it. Me qasjen mikroshërbimesh, zhvilluesit tashmë punojnë me aplikacione krejtësisht modulare dhe i projektuan ato, duke lejuar që ekipe të ndryshme të shkruajnë kod dhe të bëjnë ndryshime në aplikacion njëkohësisht.
Deploy-et 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.
- Reagimet e përdoruesve arrijnë më shpejt te ekipi i zhvilluesve. Kjo do të thotë se ekipi mund të shtojë funksione dhe të rregullojë problemet më shpejt.
- Moralitë e zhvilluesve rriten: me më shumë funksionalitete, është më interesante të punosh në zhvillim.
Por me rritjen e frekuencës së lëshimeve, rriten gjithashtu shanset që të ndikojë negativisht në besueshmërinë e aplikacionit ose në përvojën e përdoruesit. Pikërisht për këtë arsye, ekipet e operacioneve dhe DevOps ë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ë CI/CD pipeline) .)
Në këtë publikim ne do të diskutojmë strategjitë e ndryshme të shpërndarjes në Kubernetes, duke përfshirë shpërndarjet e rolling dhe metoda më të avancuara siç janë lëshimet canary dhe variacionet e tyre.
Strategjitë e shpërndarjes
Ka disa lloje të ndryshme strategjish të shpërndarjes që mund të përdoren në varësi të qëllimit. Për shembull, mund të keni nevojë të bëni ndryshime në një ambient për testim të mëtejshëm, ose për një nënmbledhje përdoruesish/klientësh, ose mund të ketë nevojë për të kryer një testim të kufizuar në përdorues para se të bëni një veçori publike.
Rolling (derdhënës, "në rritje")
Kjo është strategjia standarde e implementimit në Kubernetes. Ajo zëvendëson gradualisht, njërën pas tjetrës, podët me versionin e vjetër të aplikacionit me podët me versionin e ri — pa ndërprerje të grumbullit.
Kubernetes prit përgatitjen e podëve të rinj për funksionim (duke i kontrolluar me ), para se të fillojë të heqë të vjetrat. Nëse ndodhin probleme, një përditësim i tillë mund të ndërpritet pa ndaluar të gjithë grumbullin. Në skedarin YAML që përshkruan llojin e implementimit, 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: 8080Parametrat e përditësimit të rritjes mund të saktësohen në skedarin e manifestës:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (rikrijim)
Në këtë lloj më të thjeshtë të implementimit, podët e vjetër eliminohen të gjithë njëherësh dhe zëvendësohen me të rinjtë:
Manifesti përkatës duket kështu:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (implementime blu/jeshile)
Strategjia e shpërndarjes blu-jeshile (e njohur ndonjëherë si e kuqe/e zezë) parashikon shpërndarjen e përbashkët të versioneve të vjetra (jeshile) dhe të reja (blu) të aplikacionit. Pasi të dy versionet të jenë vendosur, përdoruesit e zakonshëm kanë qasje në versionin jeshil, ndërsa versioni blu është në dispozicion për ekipin e QA për automatizimin e testeve përmes një shërbimi të veçantë ose një kalimi të drejtpërdrejtë të porteve:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Pasi versioni blu (i ri) të jetë testuar dhe të jetë miratuar për publikim, shërbimi kalon në të, ndërsa versioni jeshil (i vjetër) ndërpritet:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (shpërndarjet kanarie)
Shpërndarjet kanarie janë të ngjashme me ato blu-jeshile, por menaxhohen më mirë dhe përdorin me faza. Ky tip përfshin disa strategji të ndryshme, përfshirë lansimet "e fshehta" dhe testimin A/B.
Kjo strategji aplikohet kur është e nevojshme të provoni ndonjë funksionalitet të ri, zakonisht në backend-in e aplikacionit. Thelbi i qasjes është të krijoni dy serverë praktikisht identikë: njëri shërben për pothuajse të gjithë përdoruesit, ndërsa tjetri, me funksionalitete të reja, shërben vetëm një nën-grup të vogël përdoruesish, pas së cilës rezultatet e punësit krahasohen. Nëse gjithçka shkon pa probleme, versioni i ri ngadalë lancohet në të gjithë infrastrukturën.
Megjithatë, ndonëse kjo strategji mund të realizohet ekskluzivisht me anë të Kubernetes, zëvendësimi i pod-ve të vjetra me të reja, është shumë më e përshtatshme dhe më e lehtë të përdorni një service mesh si Istio.
Për shembull, mund të keni dy manifesto të ndryshme në Git: një të zakonshme me etiketë 0.1.0 dhe një "kanar" me etiketë 0.2.0. Duke ndryshuar peshat në manifestin e portit virtual të Istio, mund të menaxhoni shpërndarjen e trafikut mes këtyre dy deploymenteve:
Një udhëzues hap pas hapi për realizimin e kanarëve me anë të Istio mund të gjendet në materialin . (Shën. përk.: Ne gjithashtu kemi përkthyer materialin në lidhje me lancimet kanar në Istio .)
Kanarë të lancimeve me Weaveworks Flagger
lejon që lejon menaxhimin e lehtë dhe efikas të lançimeve kanariesh.
Flagger automatizon punën me këto. Ai përdor Istio ose AWS App Mesh për të dirigjuar dhe anashkaluar trafikun, si dhe metrikat Prometheus për të analizuar rezultatet. Për më tepër, analiza e lançimeve kanariet mund të plotësohet me webhooks për të kryer testet e pranimit, teste ngarkese dhe çdo lloj kontrolli tjetër.
Bazuar në deployment’in Kubernetes dhe, nëse është e nevojshme, shkalzimin horizontal të pod’ave (HPA), Flagger krijon grupe objesh (deployment’it Kubernetes, shërbime ClusterIP dhe shërbime virtuale Istio ose App Mesh) për të kryer analizën dhe për realizimin e lançimeve kanariet:
Duke realizuar konturin e menaxhimit (grupi i kontrollit), Flagger gradualisht ndalon trafikun në serverin kanarie, duke matur për njëkohësisht treguesit kyç të performancës, siç janë përqindja e kërkesave HTTP të suksesshme, koha mesatare e kërkesës dhe shëndeti i pod’ave. Në bazë të analizës së KPI (tregues të performancës), pjesa kanarie 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ë material. .
Erë (të fshehta) ose A/B-distribuime
Distribuimi i fshehtë është një variacion tjetër i strategjisë kanarin. Ndryshimi midis një distribucimi të fshehtë dhe një kanarine është se distribuitet e fshehta merret me frontend-in dhe jo me backend-in, siç janë ato kanarin.
Një emër tjetër për këto distribucione është testimi A/B. Në vend që të ofrohet një veçori e re për të gjithë përdoruesit, ajo ofrohet vetëm për një grup të kufizuar. Zakonisht, këta përdorues nuk e dinë se janë testues të hershëm (prandaj termi 'distribuim i fshehtë').
Me anë të ndërruesve të funksionalitetit (feature toggles) dhe mjeteve të tjera mund të ndjekim se si përdoruesit ndërveprojnë me veçorinë e re, nëse ajo i angazhon ata apo nëse ata e konsiderojnë ndërfaqen e re të përdoruesit si të komplikuar, dhe metrika të tjera.
Flagger dhe A/B-distribuime
Përveç rutes së peshorave, Flagger mund të drejtojë gjithashtu trafik në serverin kanarinë në varësi të parametrave HTTP. Gjatë testimit A/B, mund të përdoren headers HTTP ose cookie për të redirigjuar një segment të caktuar të përdoruesve. Kjo është veçanërisht efektive në rastet e aplikacioneve frontend që kërkojnë afinitet seance me serverin (afiniteti me seancën). Informacione të mëtejshme mund të gjenden në dokumentacionin e Flagger.
Autori shpreh falënderim , inxhinier i Weaveworks (dhe krijuesi i Flagger), për të gjitha këto skema të mrekullueshme të implementimit.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
