Opomba prevod: Ta pregled podjetja Weaveworks predstavlja najbolj priljubljene strategije uvajanja aplikacij in prikazuje, kako je mogoče najbolj napredne implementirati z uporabo operaterja Kubernetes Flagger. Napisan je v preprostem jeziku in vsebuje vizualne diagrame, ki omogočajo, da celo inženirji začetniki razumejo težavo.
Diagram je vzet iz strategije uvajanja, narejene v Container Solutions
Eden največjih izzivov pri razvoju današnjih aplikacij v oblaku je pospešitev uvajanja. V pristopu mikrostoritev razvijalci že delajo in oblikujejo popolnoma modularne aplikacije, kar omogoča različnim ekipam, da hkrati pišejo kodo in spreminjajo aplikacijo.
Krajše in pogostejše uvedbe imajo naslednje prednosti:
- Čas do trga se skrajša.
- Nove funkcije hitreje dosežejo uporabnike.
- Povratne informacije uporabnikov hitreje dosežejo razvojno skupino. To pomeni, da lahko ekipa doda funkcije in hitreje odpravi težave.
- Morala razvijalcev se poveča: več funkcij v razvoju je bolj zabavno delati.
Ko pa se pogostost izdaj povečuje, se povečujejo tudi možnosti za negativen vpliv na zanesljivost aplikacije ali uporabniško izkušnjo. Zato je pomembno, da ekipe za operacije in DevOps gradijo procese in upravljajo strategije uvajanja na način, ki zmanjšuje tveganje za izdelek in uporabnike. (Lahko izveste več o avtomatizaciji cevovoda CI/CD .)
V tej objavi bomo razpravljali o različnih strategijah uvajanja v Kubernetes, vključno s tekočimi uvajanji in naprednejšimi metodami, kot so kanarčkove uvedbe in njihove različice.
Strategije uvajanja
Obstaja več različnih vrst strategij uvajanja, ki jih lahko uporabite glede na svoj cilj. Na primer, morda boste morali spremeniti določeno okolje za nadaljnje testiranje ali podmnožico uporabnikov/odjemalcev ali pa boste morda morali opraviti omejeno uporabniško testiranje, preden naredite funkcijo javnosti.
Tekoče (postopno, "tekoče" uvajanje)
To je standardna strategija uvajanja v Kubernetes. Postopoma, enega za drugim, zamenjuje pods s staro verzijo aplikacije s pods z novo verzijo - brez izpadov gruče.
Kubernetes počaka, da so novi podi pripravljeni za delo (preverjanje z uporabo ), preden začnete zvijati stare. Če pride do težave, je mogoče to tekoče posodabljanje prekiniti, ne da bi ustavili celotno gručo. V datoteki YAML, ki opisuje vrsto uvajanja, nova slika nadomesti staro sliko:
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 posodobitve prevračanja lahko podate v datoteki manifesta:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Poustvari
Pri tej najpreprostejši vrsti uvajanja se stare enote naenkrat uničijo in nadomestijo z novimi:
Ustrezni manifest je videti nekako takole:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Modra/zelena (modro-zelene uvedbe)
Modro-zelena strategija uvajanja (včasih imenovana tudi rdeča/črna) vključuje hkratno uvajanje stare (zelene) in nove (modre) različice aplikacije. Po objavi obeh različic imajo običajni uporabniki dostop do zelene, medtem ko je modra na voljo ekipi QA za avtomatizacijo testov prek ločene storitve ali neposrednega posredovanja vrat:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Ko je modra (nova) različica preizkušena in izdaja odobrena, storitev preklopi nanjo, zelena (stara) različica pa se zloži:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (razporeditve kanarčkov)
Canary rollouts so podobni modro-zelenim rollouts, vendar imajo boljši nadzor in uporabo pristop po korakih. Ta vrsta vključuje več različnih strategij, vključno s »prikritimi« zagoni in A/B testiranjem.
Ta strategija se uporablja, ko je treba preizkusiti nekaj novih funkcij, običajno v ozadju aplikacije. Bistvo pristopa je ustvariti dva skoraj enaka strežnika: eden služi skoraj vsem uporabnikom, drugi pa z novimi funkcijami služi le manjši podskupini uporabnikov, po kateri se primerjajo rezultati njihovega dela. Če vse poteka brez napak, se nova različica postopoma uvaja na celotno infrastrukturo.
Čeprav je to strategijo mogoče izvajati izključno z uporabo Kubernetesa, pri čemer stare pode zamenjamo z novimi, je veliko bolj priročno in preprosteje uporabiti storitveno mrežo, kot je Istio.
Na primer, morda imate v Gitu dva različna manifesta: običajni manifest z oznako 0.1.0 in kanarček z oznako 0.2.0. Če spremenite uteži v manifestu virtualnega prehoda Istio, lahko nadzorujete porazdelitev prometa med tema dvema uvedbama:
Za vodnik po korakih za izvajanje uvajanja canary z uporabo Istio glejte . (Opomba. prevod: V Istio smo prevedli tudi gradivo o kanarčkih .)
Razmestitve Canary z Weaveworks Flagger
vam omogoča preprosto in učinkovito upravljanje kanarčkov.
Flagger avtomatizira delo z njimi. Uporablja Istio ali AWS App Mesh za usmerjanje in preklapljanje prometa ter metrike Prometheus za analizo rezultatov. Poleg tega je mogoče analizo uvedb Canary dopolniti s spletnimi kljukicami za izvedbo sprejemnih testov, preskusov obremenitve in vseh drugih vrst preverjanj.
Na podlagi uvedbe Kubernetes in, če je potrebno, horizontalnega skaliranja podov (HPA), Flagger ustvari nabore objektov (umestitve Kubernetes, storitve ClusterIP in virtualne storitve Istio ali App Mesh) za analizo in implementacijo uvedb Canary:
Izvedba krmilne zanke (krmilna zanka),Flagger postopoma preklopi promet na strežnik Canary, hkrati pa meri ključne meritve učinkovitosti, kot so odstotek uspešnih zahtev HTTP, povprečno trajanje zahteve in zdravje podov. Na podlagi analize KPI (Key Performance Indicators) kanarček bodisi raste ali propada, rezultati analize pa so objavljeni v Slacku. Opis in predstavitev tega postopka najdete v gradivu .
Temne (skrite) ali A/B uvedbe
Prikrita uvedba je še ena različica kanarčkove strategije (s katero, mimogrede, lahko deluje tudi Flagger). Razlika med prikritimi in kanarčkovimi uvedbami je v tem, da se prikrite uvedbe ukvarjajo s sprednjim delom in ne z zaledjem, kot uvedbe kanarčkov.
Drugo ime za te uvedbe je A/B testiranje. Namesto da bi bila nova funkcija na voljo vsem uporabnikom, je na voljo le omejenemu delu njih. Običajno se ti uporabniki ne zavedajo, da so pionirski preizkuševalci (od tod izraz "prikrita uvedba").
Uporaba funkcijskih stikal (preklop funkcij) in drugimi orodji, lahko spremljate, kako uporabniki uporabljajo novo funkcijo, ali jih ta zanima ali se jim zdi nov uporabniški vmesnik zmeden, in druge vrste meritev.
Uvedbe označevalcev in A/B
Poleg usmerjanja na podlagi teže lahko Flagger tudi usmerja promet na strežnik Canary na podlagi parametrov HTTP. Pri testiranju A/B lahko uporabite glave HTTP ali piškotke za ciljanje na določen segment uporabnikov. To je še posebej učinkovito v primeru čelnih aplikacij, ki zahtevajo vezavo seje na strežnik (afiniteta seje). Več informacij najdete v dokumentaciji Flaggerja.
Avtor se zahvaljuje , inženir Weaveworks (in ustvarjalec Flaggerja), za vse te neverjetne vzorce uvajanja.
PS od prevajalca
Preberite tudi na našem blogu:
- «»;
- «»;
- «»;
- «".
Vir: www.habr.com