🥇Strategjitë e vendosjes në Kubernetes: rrotullim, rikrijim, blu/jeshile, kanarinë, errësirë (testimi A/B)

shënim përkthimi: Kjo përmbledhje nga Weaveworks prezanton strategjitë më të njohura të paraqitjes së aplikacioneve dhe tregon se si ato më të avancuara mund të zbatohen duke përdorur operatorin Kubernetes Flagger. Është shkruar në gjuhë të thjeshtë dhe përmban diagrame vizuale që lejojnë edhe inxhinierët fillestarë të kuptojnë çështjen.

Diagrami është marrë nga një përmbledhje tjetër Strategjitë e shpërndarjes të bëra në Container Solutions

Një nga sfidat më të mëdha në zhvillimin e aplikacioneve vendase të cloud sot është përshpejtimi i vendosjes. Në një qasje të mikroshërbimeve, zhvilluesit tashmë punojnë dhe dizajnojnë aplikacione plotësisht modulare, duke lejuar ekipe të ndryshme të shkruajnë kodin dhe të bëjnë ndryshime në të njëjtën kohë në aplikacion.

Vendosjet më të shkurtra dhe më të shpeshta kanë përfitimet e mëposhtme:

Koha për në treg është zvogëluar.
Funksionet e reja arrijnë përdoruesit më shpejt.
Reagimet e përdoruesve arrijnë më shpejt në ekipin e zhvillimit. Kjo do të thotë se ekipi mund të shtojë veçori dhe të rregullojë problemet më shpejt.
Morali i zhvilluesit rritet: më shumë veçori në zhvillim janë më argëtuese për të punuar.

Por me rritjen e frekuencës së publikimeve, rriten edhe shanset për të ndikuar negativisht në besueshmërinë e aplikacionit ose përvojën e përdoruesit. Kjo është arsyeja pse është e rëndësishme që operacionet dhe ekipet e DevOps të ndërtojnë procese dhe të menaxhojnë strategjitë e vendosjes në një mënyrë që minimizon rrezikun për produktin dhe përdoruesit. (Mund të mësoni më shumë rreth automatizimit të tubacionit CI/CD këtu.)

Në këtë postim, ne do të diskutojmë strategjitë e ndryshme të vendosjes në Kubernetes, duke përfshirë vendosjet e rrotullimit dhe metodat më të avancuara siç janë nxjerrja e kanarinave dhe variacionet e tyre.

Strategjitë e vendosjes

Ekzistojnë disa lloje të ndryshme të strategjive të vendosjes që mund t'i përdorni në varësi të qëllimit tuaj. Për shembull, mund t'ju duhet të bëni ndryshime në një mjedis të caktuar për testime të mëtejshme, ose në një grup përdoruesish/klientësh, ose mund t'ju duhet të bëni testime të kufizuara të përdoruesit përpara se të bëni një veçori publike.

Rrotullim (vendosje graduale, "rrotulluese")

Kjo është strategjia standarde e vendosjes në Kubernetes. Ai gradualisht, një nga një, zëvendëson podet me versionin e vjetër të aplikacionit me pods me versionin e ri - pa ndërprerje të grupeve.

Kubernetes pret derisa podet e reja të jenë gati për të punuar (duke i kontrolluar ato duke përdorur testet e gatishmërisë), përpara se të filloni të rrotulloni të vjetrat. Nëse shfaqet një problem, ky përditësim i vazhdueshëm mund të ndërpritet pa ndalur të gjithë grupin. Në skedarin YAML që përshkruan llojin e vendosjes, 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: 8080

Parametrat e përditësimit të përmbysjes mund të specifikohen në skedarin e manifestit:

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

Rikrijo

Në këtë lloj më të thjeshtë vendosjeje, bishtajat e vjetra vriten menjëherë dhe zëvendësohen me të reja:

Manifesti përkatës duket diçka si kjo:

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

Blu/jeshile (vendosjet blu-jeshile)

Strategjia e vendosjes blu-jeshile (nganjëherë quhet edhe e kuqe/e zezë) përfshin vendosjen e njëkohshme të versioneve të vjetra (jeshile) dhe të reja (blu) të aplikacionit. Pas postimit të të dy versioneve, përdoruesit e rregullt kanë akses në atë të gjelbër, ndërsa ai blu është i disponueshëm për ekipin e QA për të automatizuar testet përmes një shërbimi të veçantë ose përcjelljes direkte të portit:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

Pasi versioni blu (i ri) është testuar dhe lëshimi i tij është miratuar, shërbimi kalon në të dhe versioni i gjelbër (i vjetër) paloset:

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

Kanarie (vendosjet e kanarinave)

Lëshimet e kanarisë janë të ngjashme me ato blu-jeshile, por kanë kontroll dhe përdorim më të mirë progresiv qasje hap pas hapi. Ky lloj përfshin disa strategji të ndryshme, duke përfshirë lëshimet "stealth" dhe testimin A/B.

Kjo strategji përdoret kur ka nevojë për të provuar disa funksione të reja, zakonisht në pjesën e pasme të aplikacionit. Thelbi i qasjes është krijimi i dy serverëve pothuajse identikë: njëri u shërben pothuajse të gjithë përdoruesve, dhe tjetri, me funksione të reja, i shërben vetëm një nëngrupi të vogël përdoruesish, pas së cilës krahasohen rezultatet e punës së tyre. Nëse gjithçka shkon pa gabime, versioni i ri shpërndahet gradualisht në të gjithë infrastrukturën.

Edhe pse kjo strategji mund të zbatohet ekskluzivisht duke përdorur Kubernetes, duke zëvendësuar podat e vjetra me të reja, është shumë më i përshtatshëm dhe më i thjeshtë të përdorësh një rrjetë shërbimi si Istio.

Për shembull, mund të keni dy manifeste të ndryshme në Git: një manifest të rregullt me etiketën 0.1.0 dhe një manifest kanarin me etiketën 0.2.0. Duke ndryshuar peshat në manifestin e portës virtuale Istio, mund të kontrolloni shpërndarjen e trafikut midis këtyre dy vendosjeve:

Për një udhëzues hap pas hapi për zbatimin e vendosjeve të kanarinave duke përdorur Istio, shih Rrjedhat e punës GitOps me Istio. (Shënim. përkth.: Ne gjithashtu kemi përkthyer në Istio materialin për nxjerrjen e kanarinave këtu.)

Zbatimet e Kanarit me Weaveworks Flagger

Weaveworks Flagger ju lejon të menaxhoni me lehtësi dhe efektivitet nxjerrjen e kanarinëve.

Flagger automatizon punën me ta. Ai përdor Istio ose AWS App Mesh për të drejtuar dhe ndërruar trafikun, dhe matjet e Prometheus për të analizuar rezultatet. Përveç kësaj, analiza e vendosjeve të kanarinave mund të plotësohet me grepa për të kryer teste pranimi, teste ngarkese dhe çdo lloj kontrolli tjetër.

Bazuar në vendosjen e Kubernetes dhe, nëse është e nevojshme, shkallëzimin horizontal të pods (HPA), Flagger krijon grupe objektesh (vendosjet e Kubernetes, shërbimet ClusterIP dhe shërbimet virtuale Istio ose App Mesh) për të analizuar dhe zbatuar vendosjet e kanarinave:

Zbatimi i qarkut të kontrollit (laku i kontrollit),Flagger gradualisht kalon trafikun te serveri i kanarisë, ndërsa mat njëkohësisht metrikat kryesore të performancës si përqindja e kërkesave të suksesshme HTTP, kohëzgjatja mesatare e kërkesës dhe shëndeti i pod. Bazuar në analizën e KPI (Key Performance Indicators), kanarina ose rritet ose shembet dhe rezultatet e analizës publikohen në Slack. Një përshkrim dhe demonstrim i këtij procesi mund të gjendet në material Dorëzimi progresiv për rrjetën e aplikacionit.

Vendosjet e errëta (të fshehura) ose A/B

Vendosja e fshehtë është një tjetër variant i strategjisë së kanarisë (me të cilën, meqë ra fjala, Flagger gjithashtu mund të punojë). Dallimi midis vendosjeve të fshehta dhe kanarinave është se vendosjet e fshehta kanë të bëjnë me pjesën e përparme dhe jo me pjesën e pasme si vendosjet e kanarinave.

Një emër tjetër për këto vendosje është testimi A/B. Në vend që funksioni i ri të jetë i disponueshëm për të gjithë përdoruesit, ai u ofrohet vetëm një pjese të kufizuar të tyre. Në mënyrë tipike, këta përdorues nuk janë të vetëdijshëm se janë testues pionierë (prandaj edhe termi "shpërndarje e fshehtë").

Përdorimi i çelsave të funksionalitetit (ndërrimi i veçorive) dhe mjete të tjera, ju mund të monitoroni se si përdoruesit ndërveprojnë me veçorinë e re, nëse janë të angazhuar prej tij, ose nëse e shohin ndërfaqen e re të përdoruesit konfuze dhe lloje të tjera metrike.

Vendosjet e Flagger dhe A/B

Përveç rrugëtimit të bazuar në peshë, Flagger gjithashtu mund të drejtojë trafikun në serverin e kanarisë bazuar në parametrat HTTP. Në testimin A/B, mund të përdorni titujt ose kukit HTTP për të synuar një segment të caktuar përdoruesish. Kjo është veçanërisht efektive në rastin e aplikacioneve frontend që kërkojnë lidhjen e sesionit me serverin (afiniteti i seancës). Më shumë informacion mund të gjenden në dokumentacionin e Flagger.

Autori shpreh mirënjohje Stefan Prodan, inxhinier i Weaveworks (dhe krijues i Flagger), për të gjitha këto modele të mahnitshme të vendosjes.

PS nga përkthyesi

Lexoni edhe në blogun tonë:

Burimi: www.habr.com

Strategjitë e vendosjes në Kubernetes: rrotullim, rikrijim, blu/jeshile, kanarinë, errësirë ​​(testimi A/B)