Noat oersetting: Dit oersjoch fan Weaveworks yntroduseart de populêrste strategyen foar útrol fan applikaasjes en lit sjen hoe't de meast avansearre kinne wurde ymplementearre mei de Kubernetes Flagger-operator. It is skreaun yn ienfâldige taal en befettet fisuele diagrammen wêrtroch sels begjinnende yngenieurs it probleem kinne begripe.
It diagram is nommen út útrolstrategyen makke yn Container Solutions
Ien fan 'e grutste útdagings by it ûntwikkeljen fan cloud native applikaasjes hjoed is it rapperjen fan ynset. Yn in oanpak fan mikrotsjinsten wurkje ûntwikkelders al mei en ûntwerpe folslein modulêre applikaasjes, wêrtroch ferskate teams tagelyk koade kinne skriuwe en feroaringen oanmeitsje oan 'e applikaasje.
Koarte en faker ynset hawwe de folgjende foardielen:
- Tiid nei merk wurdt fermindere.
- Nije funksjes berikke brûkers rapper.
- Feedback fan brûkers berikt it ûntwikkelingsteam rapper. Dit betsjut dat it team funksjes kin tafoegje en problemen rapper reparearje.
- Untwikkeldersmoraal nimt ta: mear funksjes yn ûntwikkeling binne leuker om mei te wurkjen.
Mar as de frekwinsje fan releases tanimt, ferheegje de kânsen om de betrouberens of brûkersûnderfining fan 'e applikaasje negatyf te beynfloedzjen. Dêrom is it wichtich foar operaasjes en DevOps-teams om prosessen te bouwen en ynsetstrategyen te behearjen op in manier dy't it risiko foar it produkt en brûkers minimalisearret. (Jo kinne mear leare oer automatisearring fan CI/CD-pipeline .)
Yn dizze post sille wy ferskate ynsetstrategyen yn Kubernetes beprate, ynklusyf rôljende ynset en mear avansearre metoaden lykas kanaryske rollouts en har fariaasjes.
Ynset strategyen
D'r binne ferskate ferskillende soarten ynsetstrategyen dy't jo kinne brûke ôfhinklik fan jo doel. Bygelyks, jo moatte miskien wizigingen meitsje oan in bepaalde omjouwing foar fierdere testen, of oan in subset fan brûkers/kliïnten, of jo moatte miskien beheinde brûkerstests dwaan foardat jo in funksje meitsje iepenbier.
Rolling (stadichoan, "rollende" ynset)
Dit is de standert ynsetstrategy yn Kubernetes. It ferfangt stadichoan, ien foar ien, pods mei de âlde ferzje fan 'e applikaasje troch pods mei de nije ferzje - sûnder klusterdowntime.
Kubernetes wachtet oant nije pods klear binne om te wurkjen (kontrolearje se mei ), foardat jo de âlde begjinne oprolje. As der in probleem optreedt, kin dizze rôljende fernijing ôfbrutsen wurde sûnder it heule kluster te stopjen. Yn it YAML-bestân dat it ynsettype beskriuwt, ferfangt de nije ôfbylding de âlde ôfbylding:
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: 8080De parameters foar fernijing fan rollover kinne wurde opjûn yn it manifestbestân:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate
Yn dit ienfâldichste type ynset wurde âlde pods yn ien kear fermoarde en ferfongen troch nije:
It oerienkommende manifest sjocht der sa út:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blau/grien (blau-grien ynset)
De blau-griene ynsetstrategy (soms ek wol read/swart neamd) omfettet de simultane ynset fan 'e âlde (griene) en nije (blau) ferzjes fan 'e applikaasje. Nei it pleatsen fan beide ferzjes hawwe reguliere brûkers tagong ta de griene, wylst de blauwe beskikber is foar it QA-team om tests te automatisearjen fia in aparte tsjinst of direkte poarte trochstjoere:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Nei't de blauwe (nije) ferzje is hifke en de frijlitting is goedkard, skeakelt de tsjinst nei, en wurdt de griene (âlde) ferzje fold:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Kanaryske (kanaryske ynset)
Kanaryske rollouts binne fergelykber mei blau-griene rollouts, mar hawwe bettere kontrôle en gebrûk stap-foar-stap oanpak. Dit type omfettet ferskate ferskillende strategyen, ynklusyf "stealth" lansearringen en A / B-testen.
Dizze strategy wurdt brûkt as it nedich is om wat nije funksjonaliteit út te probearjen, meastentiids yn 'e efterkant fan' e applikaasje. De essinsje fan 'e oanpak is om twa hast identike servers te meitsjen: ien tsjinnet hast alle brûkers, en de oare, mei nije funksjes, tsjinnet mar in lytse subgroep fan brûkers, wêrnei't de resultaten fan har wurk wurde fergelike. As alles sûnder flaters ferrint, wurdt de nije ferzje stadichoan útrôle nei de hiele ynfrastruktuer.
Hoewol dizze strategy kin wurde ymplementearre eksklusyf mei help fan Kubernetes, ferfangende âlde pods mei nije, it is folle handiger en ienfâldiger te brûken in tsjinst mesh lykas Istio.
Jo kinne bygelyks twa ferskillende manifesten hawwe yn Git: in reguliere manifest mei de tag 0.1.0 en in kanaryske manifest mei de tag 0.2.0. Troch de gewichten te feroarjen yn it Istio-virtuele gateway-manifest, kinne jo de ferdieling fan ferkear tusken dizze twa ynset kontrolearje:
Foar in stap-foar-stapke hantlieding foar it útfieren fan kanaryske ynset mei Istio, sjoch . (Noat. transl.: Wy hawwe ek oerset materiaal oer kanaryske rollouts yn Istio .)
Kanaryske ynset mei Weaveworks Flagger
kinne jo maklik en effektyf beheare kanaryske rollouts.
Flagger automates wurkje mei harren. It brûkt Istio of AWS App Mesh om ferkear te routeren en te wikseljen, en Prometheus-metriken om de resultaten te analysearjen. Derneist kin de analyze fan kanaryske ynset wurde oanfolle mei webhooks om akseptaasjetests, loadtests en alle oare soarten kontrôles út te fieren.
Op grûn fan de Kubernetes-ynset en, as nedich, horizontale skaalfergrutting fan pods (HPA), makket Flagger sets fan objekten (Kubernetes-ynset, ClusterIP-tsjinsten en Istio of App Mesh firtuele tsjinsten) om kanaryske ynset te analysearjen en te ymplementearjen:
It útfieren fan de kontrôle loop (kontrôle loop), Flagger skeakelt stadichoan ferkear oer nei de kanaryske tsjinner, wylst se tagelyk wichtige prestaasjemetriken mjitten lykas it persintaazje suksesfolle HTTP-oanfragen, gemiddelde fersykdoer, en podsûnens. Op grûn fan 'e KPI-analyse (Key Performance Indicators) groeit de kanaryske of ynstoart en de resultaten fan' e analyse wurde publisearre yn Slack. In beskriuwing en demonstraasje fan dit proses is te finen yn it materiaal .
Dark (ferburgen) as A / B ynset
Stealth-ynset is in oare fariaasje fan 'e kanaryske strategy (dêr't Flagger trouwens ek mei kin wurkje). It ferskil tusken stealth- en kanaryske ynset is dat stealth-ynsettingen omgean mei de frontend ynstee fan 'e backend lykas kanaryske ynset.
In oare namme foar dizze ynset is A/B-testen. Ynstee fan it beskikber stellen fan de nije funksje foar alle brûkers, wurdt it oanbean oan mar in beheind diel fan har. Typysk binne dizze brûkers net bewust dat se baanbrekkende testers binne (dêrfandinne de term "stealth-ynset").
It brûken fan funksjonaliteit switches (funksje wikselje) en oare ark, kinne jo kontrolearje hoe't brûkers ynteraksje mei de nije funksje, oft se binne dwaande mei it, of oft se fine de nije brûkersynterface betiizjend, en oare soarten metriken.
Flagger en A/B ynset
Neist gewicht-basearre routing, kin Flagger ek rûte ferkear nei de kanaryske tsjinner basearre op HTTP parameters. Yn A/B-testen kinne jo HTTP-headers of cookies brûke om in spesifyk segmint fan brûkers te rjochtsjen. Dit is benammen effektyf yn it gefal fan frontend-applikaasjes dy't sesje-bining oan de tsjinner fereaskje (sesje affiniteit). Mear ynformaasje is te finen yn de Flagger dokumintaasje.
De skriuwer sprekt tankberens út , Weaveworks-yngenieur (en makker fan Flagger), foar al dizze geweldige ynsetpatroanen.
PS fan oersetter
Lês ek op ús blog:
- «";
- «";
- «";
- «".
Boarne: www.habr.com