🥇Kubernetes-en hedapen-estrategiak: errodatzea, birsortzea, urdina/berdea, kanariarra, iluna (A/B probak)

Ohar itzulpena: Weaveworks-en ikuspegi orokor honek aplikazioak zabaltzeko estrategia ezagunenak aurkezten ditu eta aurreratuenak nola inplementa daitezkeen erakusten du Kubernetes Flagger operadorea erabiliz. Hizkuntza sinplean idatzita dago eta ingeniari hasiberriei ere arazoa ulertzeko aukera ematen dieten diagrama bisualak ditu.

Diagramatik aterata dago beste berrikuspen bat Container Solutions-en egindako zabaltze-estrategiak

Hodeiko aplikazio natiboak garatzeko gaur egun erronka handienetako bat inplementazioa bizkortzea da. Mikrozerbitzuen ikuspegian, garatzaileek dagoeneko aplikazio guztiz modularekin lan egiten dute eta diseinatzen dute, talde ezberdinek aldi berean kodea idazteko eta aplikazioan aldaketak egiteko aukera emanez.

Inplementazio laburragoek eta maizagoek abantaila hauek dituzte:

Merkaturatzeko denbora murrizten da.
Eginbide berriak azkarrago iristen dira erabiltzaileei.
Erabiltzaileen iritzia azkarrago iristen da garapen-taldera. Horrek esan nahi du taldeak funtzioak gehitu eta arazoak azkarrago konpondu ditzakeela.
Garatzaileen morala handitzen da: garapenean eginbide gehiagorekin lan egitea dibertigarriagoa da.

Baina kaleratzeen maiztasuna handitzen den heinean, aplikazioaren fidagarritasunean edo erabiltzailearen esperientzian negatiboki eragiteko aukerak ere handitzen dira. Horregatik, garrantzitsua da eragiketa eta DevOps taldeek prozesuak eraikitzea eta inplementazio-estrategiak kudeatzea produktuaren eta erabiltzaileentzako arriskuak minimizatzeko moduan. (CI/CD kanalizazioen automatizazioari buruz gehiago ikas dezakezu Hemen.)

Argitalpen honetan, Kubernetes-en inplementazio-estrategia ezberdinak eztabaidatuko ditugu, inplementazio iraunkorrak eta metodo aurreratuagoak, hala nola, canary inplementazioak eta haien aldaerak.

Inplementazio-estrategiak

Zure helburuaren arabera erabil ditzakezun hainbat inplementazio estrategia mota daude. Adibidez, baliteke ingurune jakin batean aldaketak egin behar izatea proba gehiago egiteko, edo erabiltzaile/bezeroen azpimultzo batean, edo baliteke erabiltzaileen proba mugatuak egin behar izatea eginbide bat egin aurretik. publiko.

Iraultzea (pixkanaka, hedapen "iraulkorra")

Hau da Kubernetesen inplementazio estrategia estandarra. Pixkanaka-pixkanaka, banan-banan, aplikazioaren bertsio zaharra duten podak ordezkatzen ditu bertsio berriarekin, kluster geldialdirik gabe.

Kubernetes-ek pods berriak lan egiteko prest dauden arte itxarongo du (hauek erabiliz egiaztatuz presttasun probak), zaharrak biribiltzen hasi baino lehen. Arazoren bat gertatzen bada, etengabeko eguneraketa hau bertan behera utzi daiteke kluster osoa gelditu gabe. Inplementazio mota deskribatzen duen YAML fitxategian, irudi berriak irudi zaharra ordezkatzen du:

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

Rollover eguneratzeko parametroak manifestu fitxategian zehaztu daitezke:

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

Birsortu

Inplementazio-mota errazen honetan, leka zaharrak aldi berean hiltzen dira eta berriekin ordezkatzen dira:

Dagokion manifestuak honelako itxura du:

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

Urdina/Berdea (inplementazio urdin-berdeak)

Urdin-berdea hedatzeko estrategiak (batzuetan gorri/beltza ere deitzen zaio) aplikazioaren bertsio zaharra (berdea) eta berria (urdina) aldi berean zabaltzea dakar. Bi bertsioak argitaratu ondoren, ohiko erabiltzaileek berderako sarbidea dute, eta urdina, berriz, QA taldeak probak automatizatzeko erabilgarri dago aparteko zerbitzu baten bidez edo zuzeneko portuaren birbidalketaren bidez:

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

Bertsio urdina (berria) probatu eta kaleratzea onartu ondoren, zerbitzua horretara aldatzen da eta bertsio berdea (zaharra) tolesten da:

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

Kanariar (kanariar hedapenak)

Kanariar inplementazioak urdin-berdearen antzekoak dira, baina kontrol eta erabilera hobea dute progresiboa pausoz pauso planteamendua. Mota honek hainbat estrategia barne hartzen ditu, besteak beste, "stealth" abiarazteak eta A/B probak.

Estrategia hau funtzionalitate berriren bat probatu beharra dagoenean erabiltzen da, normalean aplikazioaren backend-ean. Planteamenduaren funtsa bi zerbitzari ia berdinak sortzea da: batek ia erabiltzaile guztiei zerbitzatzen die, eta bestea, funtzio berriekin, erabiltzaileen azpitalde txiki bat baino ez du balio, eta, ondoren, haien lanaren emaitzak alderatzen dira. Dena akatsik gabe joaten bada, bertsio berria pixkanaka azpiegitura osora zabaltzen da.

Estrategia hau Kubernetes erabiliz soilik inplementa daitekeen arren, pod zaharrak berriekin ordezkatuz, Istio bezalako zerbitzu-sare bat erabiltzea askoz erosoagoa eta errazagoa da.

Adibidez, Git-en bi manifestu ezberdin izan ditzakezu: 0.1.0 etiketa duen manifest arrunt bat eta 0.2.0 etiketa duen kanariar manifestua. Istio atebide birtualeko manifestuko pisuak aldatuz, bi inplementazio hauen arteko trafikoaren banaketa kontrola dezakezu:

Istio erabiliz canary inplementazioak ezartzeko urratsez urrats gida bat ikusteko, ikus GitOps lan-fluxuak Istio-rekin. (Ohar. itzul.: Kanariar inplementari buruzko materiala ere itzuli dugu Istiora Hemen.)

Weaveworks Flagger-ekin Canary inplementazioa

Weaveworks Flagger Kanariar inplementazioak erraz eta eraginkortasunez kudeatzeko aukera ematen du.

Flaggerrek haiekin lana automatizatzen du. Istio edo AWS App Mesh erabiltzen du trafikoa bideratzeko eta aldatzeko, eta Prometheus-en neurketak emaitzak aztertzeko. Horrez gain, kanariar inplementazioen azterketa webhookekin osa daiteke, onarpen-probak, karga-probak eta beste edozein motatako egiaztapenak egiteko.

Kubernetes-en inplementazioan eta, behar izanez gero, pods-en eskala horizontalean (HPA), Flaggerrek objektu multzoak sortzen ditu (Kubernetes inplementazioak, ClusterIP zerbitzuak eta Istio edo App Mesh zerbitzu birtualak) inplementazioak aztertzeko eta ezartzeko:

Kontrol-begizta ezartzea (kontrol-begizta),Flagger-ek trafikoa kanariar zerbitzarira aldatzen du pixkanaka, eta, aldi berean, funtsezko errendimendu-neurriak neurtzen ditu, hala nola HTTP eskaera arrakastatsuen ehunekoa, eskaeraren batez besteko iraupena eta podaren osasuna. KPI (Key Performance Indicators) analisian oinarrituta, kanaria hazten edo kolapsatzen da eta analisiaren emaitzak Slack-en argitaratzen dira. Prozesu honen deskribapena eta froga materiala aurki daiteke Aplikazioen sarerako bidalketa progresiboa.

Inplementazio ilunak (ezkutuan) edo A/B

Stealth inplementazioa kanariar estrategiaren beste aldaera bat da (bide batez, Flaggerrek ere lan egin dezakeen). Stealth eta canary inplementazioen arteko aldea da stealth inplementazioek frontend-a lantzen dutela eta ez backend-a canary inplementazioak bezala.

Inplementazio hauen beste izen bat A/B testing da. Ezaugarri berria erabiltzaile guztientzat eskuragarri jarri beharrean, horien zati mugatu bati bakarrik eskaintzen zaio. Normalean, erabiltzaile hauek ez dakite probatzaile aitzindariak direla (hortik "inplementazio ezkutua" terminoa).

Funtzionalitate etengailuak erabiltzea (eginbide txandakatu) eta beste tresna batzuekin, erabiltzaileek funtzio berriarekin nola elkarreragiten duten kontrolatu dezakezu, horrekin arduratzen diren ala ez, edo erabiltzaile-interfaze berria nahasgarria iruditzen zaien ala ez eta beste neurketa mota batzuk.

Flagger eta A/B inplementazioak

Pisuan oinarritutako bideratzeaz gain, Flaggerrek trafikoa canary zerbitzarira bideratu dezake HTTP parametroetan oinarrituta. A/B probetan, HTTP goiburuak edo cookieak erabil ditzakezu erabiltzaileen segmentu jakin batera bideratzeko. Hau bereziki eraginkorra da zerbitzariarekin saioa lotzea eskatzen duten frontend aplikazioen kasuan (saioko kidetasuna). Informazio gehiago Flagger dokumentazioan aurki daiteke.

Egileak esker ona adierazten du Stefan Prodan, Weaveworks ingeniaria (eta Flaggerren sortzailea), hedapen eredu harrigarri horiengatik.

PS itzultzailetik

Irakurri ere gure blogean:

Iturria: www.habr.com

Kubernetes-en hedatzeko estrategiak: biribiltzea, birsortzea, urdina/berdea, kanariarra, iluna (A/B probak)