Kubernetesi väljundistrateegiad: rolling, recreate, blue/green, canary, dark (A/B testimine)

Märkus: See ülevaatlik materjal Weaveworksilt tutvustab kõige populaarsemaid rakenduste väljundistrateegiaid ning räägib, kuidas nende rakendamine on võimalik Kubernetes'i operaatori Flagger abil. Tekst on kirjutatud arusaadavas keeles ja sisaldab visuaalseid skeeme, mis aitavad küsimust mõista isegi algajatele inseneridele.

Skeem on võetud teisest ülevaatest rakenduste väljundistrateegiatest, mille tegi Container Solutions

Üks suurimaid probleeme cloud native rakenduste arendamisel täna on väljaande kiirus. Mikroteenuste lähenemise korral töötavad arendajad juba täielikult moodulaarsete rakendustega ja projekteerivad neid, võimaldades erinevatel meeskondadel samal ajal koodi kirjutada ja rakenduses muudatusi teha.

Lühemate ja sagedamate väljundite eelised on järgmised:

• Turule pääsemise aeg on lühem.
• 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 moraal tõuseb: rohkem funktsioone arendusprotsessis muudab töö huvitavamaks.

Kuid koos väljaande sageduse suurenemisega kasvab ka tõenäosus, et see mõjutab negatiivselt rakenduse usaldusväärsust või kasutajakogemust. Seepärast on operatsioonimeeskondade ja DevOpsi jaoks oluline üles ehitada protsessid ja hallata juurutusstrateegiaid viisil, mis vähendab riski tootele ja kasutajatele. (Rohkem teavet CI/CD torujuhtme automatiseerimise kohta leiate siit.)

Selles publikatsioonis arutame erinevaid juurutusstrateegiaid Kuberneteses, sealhulgas järkjärgulisi juurutusi ja täiustatud meetodeid, nagu kanarüüde (canary) kasutuselevõtt ja nende variandid.

Juurutamise strateegiad

On mitmeid erinevaid juurutusstrateegiaid, millest saad valida sõltuvalt eesmärgist. Näiteks võib sul tekkida vajadus teha muudatusi mingis keskkonnas edasiseks katsetamiseks, või alamhulgale kasutajatele/klientidele, või võib tekkida vajadus viia läbi piiratud testimine kasutajatega, enne kui teha mingi funktsioon avalikuks.

Järkjärguline (rolling) juurutamine

See on Kubernetes'i standardne juurutusstrateegia. See asendab järk-järgult vana versiooni rakenduse pod'id uute versioonidega - ilma klastri seiskamiseta.

Kubernetes ootab, kuni uued pod'id on tööks valmis (kontrollides neid valmiduskatsete), enne kui vanade kokkupakkumist alustatakse. Kui tekivad probleemid, saab sellise järkjärgulise uuendamise peatada, peatamata kogu klastri tööd. YAML-failis, mis kirjeldab juurutustüü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: 8080

Järk-järgult uuendamise parameetreid saab täpsustada manifestifailis:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%
  template:
  ...

Recreate (uuesti loomine)

Selles kõige lihtsamas juurutustüübis tapetakse vanad pod'id kõik korraga ja asendatakse uutega:

Asjakohane manifest näeb välja umbes nii:

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

Blue/Green (sinine/roheline juurdamine)

Sinine-roheline juurutamisstrateegia (mida nimetatakse ka punaseks/mustaks) hõlmab vana (roheline) ja uue (sinine) versiooni rakenduse samaaegset juurutamist. Pärast mõlema versiooni paigaldamist saavad tavalised kasutajad juurdepääsu rohelisele, samas kui sinine versioon on QA meeskonnale automaatsete testide tegemiseks saadaval läbi eraldi teenuse või otsese portide edastamise:

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 väljalaskmine on heaks kiidetud, lülitutakse teenuse kasutamisele ning roheline (vana) sulgedakse:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Kanareejad (kanareepide juurutamised)

Kanareepide juurutamised sarnanevad sinine-roheline lähenemisega, kuid neid juhitakse paremini ja nad kasutavad progressiivset etapilist lähenemist. Sellesse tüüpi kuuluvad mitmed erinevad strateegiad, sealhulgas "peidetud" käivitused ja A/B-testimine.

Seda strateegiat kasutatakse, kui on vaja testida uut funktsionaalsust, reeglina rakenduse tagaplaanil. Lähenemise olemus on luua kaks praktiliselt identset serverit: üks teenindab enamiku kasutajatest, teine, uutega, teenindab vaid väikest kasutajate rühma, mille järel võrreldakse nende tulemusi. Kui kõik läheb probleemideta, tutvustatakse uut versiooni järk-järgult kogu infrastruktuuri.

Kuigi seda strateegiat saab rakendada ainult Kubernetes'e tööriistadega, asendades vanad pod'id uutega, on palju mugavam ja lihtsam kasutada teenuste võrgustikku nagu Istio.

Näiteks võib teil olla kaks erinevat manifesti Git'is: tavapärane versioon sildiga 0.1.0 ja "kananäidise" versioon sildiga 0.2.0. Muutes Istio virtuaalse värava manifestis kaalu, saab hallata liikluse jaotust nende kahe kasutuselevõtu vahel:

Käesolevas dokumendis on samm-sammuline juhend kanaaride kasutuselevõttude rakendamiseks Istio abil GitOps Workflow'id koos Istio'ga. (Märk. tõlge.: Samuti tõlkisime materjali kanaaride kasutuselevõttude kohta Istio's siit.)

Kanaaride kasutuselevõtud Weaveworks Flagger'iga

Weaveworks Flagger võimaldab hõlpsasti ja tõhusalt hallata kanarooli väljaandeid.

Flagger automatiseerib nende töötluse. See kasutab Istio või AWS App Mesh'i liikluse suunamiseks ja vahetamiseks ning Prometheuse statistikat tulemuste analüüsimiseks. Lisaks saab kanarooli väljaannete analüüsi täiendada veebihook'idega, et läbi viia aktsepteerimisteste, koormusteste ja muid kontrolle.

Kubernetes'i väljade põhjal ja vajadusel konteinerite (pod'ide) horisontaalse skaleerimisega (HPA) loob Flagger Kubernetes'e objektide komplektid (Kubernetes'i väljad, ClusterIP teenused ja virtuaalsed teenused Istio või App Mesh) analüüsiks ja kanarooli väljaannete rakendamiseks.

Rakendades juhtimiskontuuri (kontrolli silmus), Flagger suunab järk-järgult liikluse kanarooli serverisse, samal ajal mõõtes võtme jõudlusnäitajaid nagu edukaid HTTP-päringute osakaal, keskmine päringu kestus ja pod'ide seisund. KPI (võtme jõudlusnäitajate) analüüsi põhjal kas kanarooli osa kasvab või väheneb ning analüüsi tulemused avaldatakse Slackis. Selle protsessi kirjelduse ja demonstreerimise leiate materjalist. Progressiivne kohaletoimetamine App Mesh'i jaoks.

Tumedad (salajased) või A/B-deploy'd

Salajane deploy on veel üks kanaristrateegia variatsioon (mille puhul suudab Flagger samuti toimida). Erinevus salajase ja kanarise deploy vahel seisneb selles, et salajased deploy'd tegelevad esiplaaniga, mitte tagaplaaniga, nagu kanarisüsteem.

Need deploy'd on tuntud ka kui A/B-testimine. Selle asemel, et avada uus funktsioon kõigile kasutajatele, pakutakse seda vaid piiratud osale. Tüüpiliselt ei tea need kasutajad, et nad on pioneeritestidest (seetõttu ka termin 'salajane deploy').

Funktsionaalsuse lülitite abil (feature toggles) ja teiste tööriistade abil saab jälgida, kuidas kasutajad suhtlevad uue funktsiooniga, kas see köidab neid või peavad nad uut kasutajaliidest segaseks, ning muid tüüpe metrikat.

Flagger ja A/B-deploy'd

Lisaks kaalu arvestavale suunamisele saab Flagger suunata kanarieserverile ka HTTP parameetrite põhjal. A/B-testimise korral saab kasutada HTTP päiseid või küpsiseid, et suunata kindlat kasutajasegmenti. See on eriti tõhus frontend-rakenduste puhul, mis nõuavad sessiooni kinnitamist serveriga. (sessiooni kinnitamine). Täiendavat teavet leiate Flaggeri dokumentatsioonist.

Autor tänab Stefan Prodanit, Weaveworksi inseneri (ja Flaggeri looja), kõigi nende hämmastavate juurutusdiagrammide eest.

P.S. tõlkija märkused

Lugege ka meie blogist:

• «Kubernetes'e Ingress kontrollerite ülevaade ja võrdlus»;
• «werf — meie CI/CD tööriist Kubernetesis (ülevaade ja videoettekanne)»;
• «Ühesuguste mikroteenuste kogumine ja juurutamine werfi ja GitLab CI-ga.»;
• «Mis on GitOps?».

Allikas: habr.com