Huomautus käännös: Tämä Weaveworksin yleiskatsaus esittelee suosituimmat sovellusten käyttöönottostrategiat ja näyttää kuinka edistyneimmät voidaan toteuttaa Kubernetes Flagger -operaattorilla. Se on kirjoitettu yksinkertaisella kielellä ja sisältää visuaalisia kaavioita, joiden avulla jopa aloittelevat insinöörit voivat ymmärtää ongelman.
Kaavio on otettu Container Solutionsissa tehdyt käyttöönottostrategiat
Yksi suurimmista haasteista pilvipohjaisten sovellusten kehittämisessä nykyään on käyttöönoton nopeuttaminen. Mikropalvelulähestymistavassa kehittäjät työskentelevät jo täysin modulaaristen sovellusten kanssa ja suunnittelevat niitä, jolloin eri tiimit voivat samanaikaisesti kirjoittaa koodia ja tehdä muutoksia sovellukseen.
Lyhyemmillä ja tiheämmillä käyttöönotoilla on seuraavat edut:
- Markkinoille tuloaika lyhenee.
- Uudet ominaisuudet tavoittavat käyttäjät nopeammin.
- Käyttäjäpalaute saavuttaa kehitystiimin nopeammin. Tämä tarkoittaa, että tiimi voi lisätä ominaisuuksia ja korjata ongelmia nopeammin.
- Kehittäjien moraali kasvaa: enemmän kehitysvaiheessa olevia ominaisuuksia on hauskempaa työskennellä.
Mutta kun julkaisujen tiheys kasvaa, myös mahdollisuudet vaikuttaa negatiivisesti sovelluksen luotettavuuteen tai käyttökokemukseen kasvavat. Siksi toimintojen ja DevOps-tiimien on tärkeää rakentaa prosesseja ja hallita käyttöönottostrategioita tavalla, joka minimoi tuotteelle ja käyttäjille aiheutuvat riskit. (Saat lisätietoja CI/CD-putkien automatisoinnista .)
Tässä viestissä keskustelemme erilaisista Kubernetesin käyttöönottostrategioista, mukaan lukien jatkuvat käyttöönotot ja edistyneemmät menetelmät, kuten Canary-versiot ja niiden muunnelmat.
Käyttöönottostrategiat
On olemassa useita erilaisia käyttöönottostrategioita, joita voit käyttää tavoitteesi mukaan. Saatat esimerkiksi joutua tekemään muutoksia tiettyyn ympäristöön lisätestausta varten tai osaan käyttäjiä/asiakkaita, tai sinun on ehkä suoritettava rajoitettu käyttäjätestaus ennen ominaisuuden tekemistä. julkinen.
Rullaava (asteittainen, "rullaava" käyttöönotto)
Tämä on Kubernetesin vakiokäyttöönottostrategia. Se korvaa vähitellen yksitellen sovelluksen vanhan version podit uudella versiolla - ilman klusterin seisokkeja.
Kubernetes odottaa, kunnes uudet podit ovat valmiita toimimaan (tarkistaa ne käyttämällä ), ennen kuin alat rullata vanhoja. Jos ongelma ilmenee, tämä jatkuva päivitys voidaan keskeyttää pysäyttämättä koko klusteria. Käyttöönottotyyppiä kuvaavassa YAML-tiedostossa uusi näköistiedosto korvaa vanhan kuvan:
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: 8080Kierrätyspäivitysparametrit voidaan määrittää luettelotiedostossa:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Luo uudelleen
Tässä yksinkertaisimmassa käyttöönotossa vanhat kotelot tuhotaan kerralla ja korvataan uusilla:
Vastaava manifesti näyttää suunnilleen tältä:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Sininen/vihreä (sini-vihreät asennukset)
Sinivihreä käyttöönottostrategia (joskus kutsutaan myös punaiseksi/mustaksi) sisältää sovelluksen vanhan (vihreän) ja uuden (sinisen) version samanaikaisen käyttöönoton. Molempien versioiden julkaisemisen jälkeen tavallisilla käyttäjillä on pääsy vihreään, kun taas sininen on QA-tiimin käytettävissä testien automatisoimiseksi erillisen palvelun tai suoran porttiohjauksen kautta:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Kun sininen (uusi) versio on testattu ja sen julkaisu on hyväksytty, palvelu vaihtaa siihen ja vihreä (vanha) versio taitetaan:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Kanaria (kanarialintujen käyttöönotot)
Canary-versiot ovat samanlaisia kuin sinivihreät, mutta niillä on parempi hallinta ja käyttö askel askeleelta lähestymistapa. Tämä tyyppi sisältää useita erilaisia strategioita, mukaan lukien "stealth"-laukaisut ja A/B-testaus.
Tätä strategiaa käytetään, kun on tarvetta kokeilla uusia toimintoja, yleensä sovelluksen taustalla. Lähestymistavan ydin on luoda kaksi lähes identtistä palvelinta: toinen palvelee lähes kaikkia käyttäjiä, ja toinen uusilla toiminnoilla palvelee vain pientä käyttäjien alaryhmää, minkä jälkeen heidän työnsä tuloksia verrataan. Jos kaikki sujuu ilman virheitä, uusi versio otetaan vähitellen käyttöön koko infrastruktuurissa.
Vaikka tämä strategia voidaan toteuttaa yksinomaan Kubernetesilla, korvaamalla vanhat podit uusilla, on paljon kätevämpää ja yksinkertaisempaa käyttää Istion kaltaista palveluverkkoa.
Sinulla voi esimerkiksi olla kaksi erilaista luetteloa Gitissä: tavallinen luettelo tunnisteella 0.1.0 ja kanarian luettelo tunnisteella 0.2.0. Muutamalla Istion virtuaalisen yhdyskäytävän luettelon painotuksia voit hallita liikenteen jakautumista näiden kahden käyttöönoton välillä:
Katso vaiheittaiset ohjeet kanarialinjojen käyttöönottoon Istion avulla . (Huomautus. käännös: Käänsimme myös kanarianrullasta materiaalia Istioon .)
Canary Deployments Weaveworks Flaggerin kanssa
avulla voit helposti ja tehokkaasti hallita kanarialintujen käyttöönottoa.
Flagger automatisoi työskentelyn heidän kanssaan. Se käyttää Istio- tai AWS App Meshiä liikenteen reitittämiseen ja vaihtamiseen ja Prometheus-mittareita tulosten analysointiin. Lisäksi kanarialinjojen käyttöönottojen analyysiä voidaan täydentää webhookeilla hyväksymistestien, kuormitustestien ja minkä tahansa muun tyyppisten tarkastusten suorittamiseksi.
Perustuen Kubernetes-asennukseen ja tarvittaessa horisontaaliseen podd-skaalaukseen (HPA), Flagger luo objektijoukkoja (Kubernetes-asennukset, ClusterIP-palvelut ja Istio- tai App Mesh -virtuaalipalvelut) analysoimaan ja toteuttamaan Canary-käyttöönoksia:
Ohjaussilmukan toteuttaminen (ohjaussilmukka),Flagger siirtää liikennettä vähitellen Canary-palvelimelle ja mittaa samanaikaisesti keskeisiä suorituskykymittareita, kuten onnistuneiden HTTP-pyyntöjen prosenttiosuutta, pyynnön keskimääräistä kestoa ja kotelon kuntoa. KPI (Key Performance Indicators) -analyysin perusteella kanarialintu joko kasvaa tai romahtaa ja analyysin tulokset julkaistaan Slackissa. Tämän prosessin kuvaus ja esittely löytyy materiaalista .
Tummat (piilotetut) tai A/B-käytöt
Stealth-käyttöönotto on toinen muunnelma kanarian strategiasta (jonka kanssa muuten myös Flagger voi toimia). Ero stealth- ja Canary-asetuksien välillä on se, että varkain käyttöönotot käsittelevät etuosaa eikä taustajärjestelmää, kuten Canary-asennukset.
Toinen nimi näille käyttöönottoille on A/B-testaus. Sen sijaan, että uusi ominaisuus olisi kaikkien käyttäjien saatavilla, sitä tarjotaan vain rajoitetulle osalle heistä. Tyypillisesti nämä käyttäjät eivät tiedä olevansa uraauurtavia testaajia (tästä syystä termi "varkain käyttöönotto").
Toimintokytkimien käyttö (ominaisuuden vaihto) ja muiden työkalujen avulla voit seurata, miten käyttäjät ovat vuorovaikutuksessa uuden ominaisuuden kanssa, ovatko he kiinnostuneita siitä vai kokevatko he uuden käyttöliittymän hämmentävän, ja muun tyyppisiä mittareita.
Ilmoittaja- ja A/B-käytöt
Painoperusteisen reitityksen lisäksi Flagger voi reitittää liikennettä myös kanarian palvelimelle HTTP-parametrien perusteella. A/B-testauksessa voit käyttää HTTP-otsikoita tai evästeitä kohdistaaksesi tiettyyn käyttäjäsegmenttiin. Tämä on erityisen tehokasta käyttöliittymäsovelluksissa, jotka vaativat istunnon sitomisen palvelimeen (istunnon affiniteetti). Lisätietoja löytyy Flaggerin dokumentaatiosta.
Kirjoittaja on kiitollinen , Weaveworks-insinööri (ja Flaggerin luoja) kaikille näille uskomattomille käyttöönottomalleille.
PS kääntäjältä
Lue myös blogistamme:
- «";
- «";
- «";
- «'.
Lähde: will.com