Märge tõlge: See Weaveworksi ülevaade tutvustab kõige populaarsemaid rakenduste levitamisstrateegiaid ja näitab, kuidas kõige arenenumaid saab Kubernetes Flaggeri operaatori abil rakendada. See on kirjutatud lihtsas keeles ja sisaldab visuaalseid diagramme, mis võimaldavad isegi algajatel inseneridel probleemist aru saada.
Diagramm on võetud kohast Container Solutionsis tehtud levitamisstrateegiad
Üks suurimaid väljakutseid pilvepõhiste rakenduste arendamisel tänapäeval on juurutamise kiirendamine. Mikroteenuste lähenemisviisi puhul töötavad arendajad juba täiesti modulaarsete rakendustega ja kujundavad neid, võimaldades erinevatel meeskondadel üheaegselt koodi kirjutada ja rakenduses muudatusi teha.
Lühemal ja sagedasemal kasutuselevõtul on järgmised eelised:
- Turule jõudmise aeg väheneb.
- Uued funktsioonid jõuavad kasutajateni kiiremini.
- Kasutajate tagasiside jõuab arendusmeeskonnani kiiremini. See tähendab, et meeskond saab funktsioone kiiremini lisada ja probleeme lahendada.
- Arendaja moraal tõuseb: rohkemate arendusfunktsioonidega on lõbusam töötada.
Kuid kui väljalasete sagedus suureneb, suureneb ka tõenäosus, et see mõjutab negatiivselt rakenduse töökindlust või kasutuskogemust. Seetõttu on oluline, et operatsioonid ja DevOpsi meeskonnad ehitaksid protsesse ja haldaksid juurutusstrateegiaid viisil, mis minimeerib toote ja kasutajate riski. (Lisateavet CI/CD torujuhtme automatiseerimise kohta saate .)
Selles postituses käsitleme erinevaid Kubernetese juurutamisstrateegiaid, sealhulgas jooksvaid juurutusi ja täiustatud meetodeid, nagu Canary juurutamine ja nende variatsioonid.
Kasutusstrateegiad
Sõltuvalt eesmärgist saate kasutada mitut erinevat tüüpi juurutusstrateegiaid. Näiteks peate võib-olla tegema muudatusi teatud keskkonnas edasiseks testimiseks või kasutajate/klientide alarühmas või enne funktsiooni loomist piiratud kasutajateste. avalik.
Rullimine (järkjärguline, veerev kasutuselevõtt)
See on Kubernetese tavaline juurutamisstrateegia. See asendab järk-järgult ükshaaval rakenduse vana versiooniga kaustad uue versiooniga kaustadega – ilma klastri seisakuta.
Kubernetes ootab, kuni uued kaustad on tööks valmis (kontrollides neid kasutades ), enne kui hakkate vanu kokku rullima. Probleemi ilmnemisel saab selle jooksva värskenduse katkestada ilma kogu klastrit peatamata. Juurutustüüpi kirjeldavas YAML-failis asendab uus pilt vana pildi:
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: 8080Ülemineku värskendamise parameetrid saab määrata manifestifailis:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Loo uuesti
Selle lihtsaima kasutuselevõtutüübi korral hävitatakse vanad kaunad korraga ja asendatakse uutega:
Vastav manifest näeb välja umbes selline:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Sinine/roheline (sini-rohelised juurutused)
Sini-roheline juurutamisstrateegia (mõnikord nimetatakse seda ka punaseks/mustaks) hõlmab rakenduse vana (rohelise) ja uue (sinise) versiooni samaaegset juurutamist. Pärast mõlema versiooni postitamist on tavakasutajatel juurdepääs rohelisele, samas kui sinine on saadaval kvaliteedikontrolli meeskonnale, et automatiseerida teste eraldi teenuse või pordi otsesuunamise kaudu:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Pärast sinise (uue) versiooni testimist ja selle väljalaske kinnitamist lülitub teenus sellele ja roheline (vana) versioon volditakse kokku:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Kanaari (kanaari saarte kasutuselevõtt)
Canary väljalasked on sarnased sinakasroheliste väljalaskmistega, kuid neil on parem juhtimine ja kasutamine samm-sammult lähenemine. See tüüp hõlmab mitut erinevat strateegiat, sealhulgas varjatud käivitamist ja A/B testimist.
Seda strateegiat kasutatakse siis, kui on vaja proovida mõnda uut funktsiooni, tavaliselt rakenduse taustaprogrammis. Lähenemisviisi põhiolemus on luua kaks peaaegu identset serverit: üks teenindab peaaegu kõiki kasutajaid ja teine uute funktsioonidega teenindab ainult väikest kasutajate alamrühma, mille järel võrreldakse nende töö tulemusi. Kui kõik läheb vigadeta, levitatakse uus versioon järk-järgult kogu infrastruktuurile.
Kuigi seda strateegiat saab rakendada ainult Kubernetese abil, asendades vanad kaustad uutega, on palju mugavam ja lihtsam kasutada sellist teenindusvõrku nagu Istio.
Näiteks võib teil Gitis olla kaks erinevat manifesti: tavaline manifest sildiga 0.1.0 ja kanaari manifest sildiga 0.2.0. Muutes Istio virtuaalse lüüsi manifestis kaalu, saate juhtida liikluse jaotust nende kahe juurutuse vahel.
Üksikasjaliku juhendi Istio abil kanaari juurutamise rakendamiseks vt . (Märge. tõlge: Tõlkisime istiosse ka materjali kanaarirullide kohta .)
Kanaari juurutamine Weaveworks Flaggeriga
võimaldab teil hõlpsalt ja tõhusalt hallata kanaari levitamist.
Liputaja automatiseerib nendega töötamist. See kasutab liikluse suunamiseks ja vahetamiseks Istio või AWS App Meshi ning tulemuste analüüsimiseks Prometheuse mõõdikuid. Lisaks saab kanaari juurutamise analüüsi täiendada veebihaagidega, et viia läbi vastuvõtuteste, koormusteste ja mis tahes muud tüüpi kontrolle.
Tuginedes Kubernetese juurutamisele ja vajadusel kaadrite horisontaalsele skaleerimisele (HPA), loob Flagger objektide komplektid (Kubernetese juurutused, ClusterIP teenused ja Istio või App Meshi virtuaalteenused), et analüüsida ja rakendada kanaari juurutusi:
Juhtkontuuri rakendamine (juhtsilmus),Flagger lülitab liikluse järk-järgult Canary serverisse, mõõtes samal ajal peamisi jõudlusmõõdikuid, nagu edukate HTTP-päringute protsent, päringu keskmine kestus ja kausta olek. KPI (Key Performance Indicators) analüüsi põhjal kanaarilind kas kasvab või vajub kokku ning analüüsi tulemused avaldatakse Slackis. Selle protsessi kirjelduse ja demonstratsiooni leiate materjalist .
Tumedad (varjatud) või A/B juurutused
Stealth juurutamine on kanaari strateegia teine variant (millega, muide, ka Flagger töötada saab). Erinevus varjatud ja kanaari juurutamise vahel seisneb selles, et varjatud juurutused tegelevad pigem esiservaga kui taustaprogrammiga nagu kanaari juurutused.
Nende juurutuste teine nimi on A/B testimine. Selle asemel, et teha uus funktsioon kättesaadavaks kõigile kasutajatele, pakutakse seda vaid piiratud osale neist. Tavaliselt ei tea need kasutajad, et nad on teedrajavad testijad (sellest ka mõiste "varjakasutamine").
Funktsionaalsuse lülitite kasutamine (funktsiooni lüliti) ja muud tööriistad, saate jälgida, kuidas kasutajad uue funktsiooniga suhtlevad, kas see on neile kaasatud või kas uus kasutajaliides on neile segane, ja muud tüüpi mõõdikuid.
Liputaja ja A/B juurutamine
Lisaks kaalupõhisele marsruutimisele saab Flagger suunata liiklust kanaari serverisse ka HTTP parameetrite alusel. A/B-testimisel saate kasutada HTTP-päiseid või küpsiseid, et sihtida konkreetset kasutajasegmenti. See on eriti efektiivne esiserveri rakenduste puhul, mis nõuavad seansi sidumist serveriga (seansi afiinsus). Lisateavet leiate märgistaja dokumentatsioonist.
Autor avaldab tänu , Weaveworksi insener (ja Flaggeri looja) kõigi nende hämmastavate juurutusmustrite jaoks.
PS tõlkijalt
Loe ka meie blogist:
- «";
- «";
- «";
- «'.
Allikas: www.habr.com