Athugið þýðing: Þetta yfirlit frá Weaveworks kynnir vinsælustu útsetningaraðferðirnar og sýnir hvernig hægt er að útfæra þær fullkomnustu með Kubernetes Flagger símafyrirtækinu. Það er skrifað á einföldu máli og inniheldur sjónrænar skýringarmyndir sem gera jafnvel byrjendum kleift að skilja málið.
Skýringarmyndin er tekin úr útfærsluaðferðir gerðar í Container Solutions
Ein stærsta áskorunin við þróun skýjaforrita í dag er að flýta fyrir uppsetningu. Í örþjónustunálgun vinna verktaki nú þegar með og hanna algjörlega mát forrit, sem gerir mismunandi teymum kleift að skrifa kóða samtímis og gera breytingar á forritinu.
Styttri og tíðari dreifing hefur eftirfarandi kosti:
- Tími á markað styttist.
- Nýir eiginleikar ná til notenda hraðar.
- Viðbrögð notenda ná hraðar til þróunarteymisins. Þetta þýðir að teymið getur bætt við eiginleikum og lagað vandamál hraðar.
- Siðferði þróunaraðila eykst: Fleiri eiginleikar í þróun eru skemmtilegri að vinna með.
En eftir því sem útgáfutíðni eykst aukast líkurnar á að hafa neikvæð áhrif á áreiðanleika forritsins eða notendaupplifun líka. Þess vegna er mikilvægt fyrir rekstrar- og DevOps teymi að byggja upp ferla og stjórna dreifingaraðferðum á þann hátt sem lágmarkar áhættu fyrir vöruna og notendur. (Þú getur lært meira um CI/CD leiðslusjálfvirkni .)
Í þessari færslu munum við ræða ýmsar dreifingaraðferðir í Kubernetes, þar á meðal rúllandi dreifingar og fullkomnari aðferðir eins og útfærslur á kanarífuglum og afbrigði þeirra.
Dreifingaraðferðir
Það eru nokkrar mismunandi gerðir af dreifingaraðferðum sem þú getur notað eftir markmiðum þínum. Til dæmis gætir þú þurft að gera breytingar á ákveðnu umhverfi til frekari prófana, eða á undirmengi notenda/viðskiptavina, eða þú gætir þurft að gera takmarkaðar notendaprófanir áður en þú gerir eiginleika almennings.
Rúlla (smám saman, „veltandi“ dreifing)
Þetta er staðlaða dreifingarstefnan í Kubernetes. Það kemur smám saman, einn af öðrum, í stað belgs fyrir gömlu útgáfuna af forritinu fyrir belg með nýju útgáfunni - án þyrpingar í miðbæ.
Kubernetes bíður þar til nýir belg eru tilbúnir til að vinna (athugar þá með því að nota ), áður en þú byrjar að rúlla upp þeim gömlu. Ef vandamál koma upp er hægt að hætta við þessa rúllandi uppfærslu án þess að stöðva allan klasann. Í YAML skránni sem lýsir dreifingargerðinni kemur nýja myndin í stað gömlu myndarinnar:
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: 8080Hægt er að tilgreina færibreytur veltunaruppfærslu í upplýsingaskránni:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Endurskapa
Í þessari einföldustu tegund dreifingar eru gamlar belg drepnar í einu og skipt út fyrir nýjar:
Samsvarandi upplýsingaskrá lítur einhvern veginn svona út:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blár/grænn (blágrænn uppsetning)
Blágræna dreifingaráætlunin (stundum einnig kölluð rauð/svart) felur í sér samtímis uppsetningu á gömlu (grænu) og nýju (bláu) útgáfum forritsins. Eftir að báðar útgáfurnar hafa verið birtar hafa venjulegir notendur aðgang að þeirri grænu, en sú bláa er í boði fyrir QA teymið til að gera sjálfvirkar prófanir í gegnum sérstaka þjónustu eða beina framsendingu hafna:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Eftir að bláa (nýja) útgáfan hefur verið prófuð og útgáfa hennar hefur verið samþykkt, skiptir þjónustan yfir í hana og græna (gamla) útgáfan er brotin saman:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Kanarí (kanarí-uppsetningar)
Kanaríútsetningar eru svipaðar og blágrænar útfærslur, en hafa betri stjórn og notkun skref fyrir skref nálgun. Þessi tegund inniheldur nokkrar mismunandi aðferðir, þar á meðal „laumuspil“ og A/B prófun.
Þessi aðferð er notuð þegar þörf er á að prófa nýja virkni, venjulega í bakenda forritsins. Kjarninn í nálguninni er að búa til tvo næstum eins netþjóna: annar þjónar næstum öllum notendum og hinn, með nýjum aðgerðum, þjónar aðeins litlum undirhópi notenda, eftir það eru niðurstöður vinnu þeirra bornar saman. Ef allt gengur án villna er nýja útgáfan smám saman rúllað út í alla innviði.
Þó að hægt sé að útfæra þessa stefnu eingöngu með því að nota Kubernetes og skipta út gömlum belgjum fyrir nýja, þá er miklu þægilegra og einfaldara að nota þjónustunet eins og Istio.
Til dæmis gætirðu verið með tvær mismunandi birtingarmyndir í Git: venjulega upplýsingaskrá með merkinu 0.1.0 og kanarískrá með merkinu 0.2.0. Með því að breyta þyngdinni í Istio sýndargáttarskránni geturðu stjórnað dreifingu umferðar á milli þessara tveggja uppsetninga:
Fyrir skref-fyrir-skref leiðbeiningar um útfærslu kanarífugla með Istio, sjá . (Athugið. þýð.: Við þýddum líka efni um útsetningu kanarífugla yfir á Istio .)
Canary Deployment með Weaveworks Flagger
gerir þér kleift að stjórna útsetningu kanarífugla á auðveldan og áhrifaríkan hátt.
Flagger gerir sjálfvirkan vinnu með þeim. Það notar Istio eða AWS App Mesh til að beina og skipta um umferð, og Prometheus mælingar til að greina niðurstöðurnar. Að auki er hægt að bæta við greiningu á dreifingum kanarífugla með vefkrókum til að framkvæma staðfestingarpróf, álagspróf og hvers kyns aðrar gerðir athugana.
Byggt á Kubernetes dreifingunni og, ef nauðsyn krefur, lárétta mælikvarða fræbelgja (HPA), býr Flagger til sett af hlutum (Kubernetes dreifing, ClusterIP þjónusta og Istio eða App Mesh sýndarþjónusta) til að greina og innleiða kanarídreifingar:
Innleiðing stjórnlykkju (stjórnlykja),Flagger skiptir smám saman um umferð yfir á kanaríþjóninn, á sama tíma og hann mælir lykilframmistöðumælingar eins og hlutfall heppnaðra HTTP beiðna, meðallengd beiðna og heilsu fræbelgs. Byggt á KPI (Key Performance Indicators) greiningunni vex kanarífuglinn annað hvort eða hrynur og niðurstöður greiningarinnar eru birtar í Slack. Lýsingu og sýningu á þessu ferli er að finna í efninu .
Dökk (falin) eða A/B dreifing
Stealth dreifing er önnur afbrigði af kanarístefnunni (sem Flagger getur líka unnið með). Munurinn á laumudýrauppfærslum og kanarídreifingum er að laumuspilsuppsetningar fjalla um framenda frekar en bakenda eins og kanarídreifingar.
Annað nafn fyrir þessar dreifingar er A/B prófun. Í stað þess að gera nýja eiginleikann aðgengilegan öllum notendum er hann aðeins í boði fyrir takmarkaðan hluta þeirra. Venjulega eru þessir notendur ekki meðvitaðir um að þeir eru brautryðjandi prófunaraðilar (þess vegna hugtakið "laumumiðlun").
Notkun virknirofa (eiginleikaskipti) og önnur tól, þú getur fylgst með hvernig notendur hafa samskipti við nýja eiginleikann, hvort þeir séu virkir í honum eða hvort þeim finnist nýja notendaviðmótið ruglingslegt og aðrar gerðir mælikvarða.
Flagger og A/B dreifing
Til viðbótar við þyngdartengda leið getur Flagger einnig beint umferð á kanaríþjóninn byggt á HTTP breytum. Í A/B prófunum geturðu notað HTTP hausa eða smákökur til að miða á ákveðinn hluta notenda. Þetta er sérstaklega áhrifaríkt þegar um er að ræða framendaforrit sem krefjast lotubindingar við netþjóninn (Sengjasækni). Frekari upplýsingar er að finna í Flagger skjölunum.
Höfundur lýsir þakklæti , Weaveworks verkfræðingur (og skapari Flagger), fyrir öll þessi ótrúlegu dreifingarmynstur.
PS frá þýðanda
Lestu líka á blogginu okkar:
- «»;
- «»;
- «»;
- «'.
Heimild: www.habr.com