Pastaba vertimas: Šioje „Weaveworks“ apžvalgoje pristatomos populiariausios programų diegimo strategijos ir parodoma, kaip pažangiausias galima įdiegti naudojant „Kubernetes Flagger“ operatorių. Jis parašytas paprasta kalba ir jame yra vaizdinių diagramų, leidžiančių net pradedantiesiems inžinieriams suprasti problemą.
Diagrama paimta iš išleidimo strategijos, sukurtos naudojant konteinerių sprendimus
Vienas didžiausių iššūkių kuriant vietines debesų programas šiandien yra paspartinti diegimą. Taikydami mikropaslaugų metodą, kūrėjai jau dirba su visiškai modulinėmis programomis ir kuria jas, leidžiančias skirtingoms komandoms vienu metu rašyti kodą ir keisti programą.
Trumpesnis ir dažnesnis diegimas turi šiuos privalumus:
- Sumažėja laikas patekti į rinką.
- Naujos funkcijos vartotojus pasiekia greičiau.
- Vartotojų atsiliepimai greičiau pasiekia kūrėjų komandą. Tai reiškia, kad komanda gali pridėti funkcijų ir greičiau išspręsti problemas.
- Padidėja kūrėjų moralė: su daugiau kuriamų funkcijų dirbti smagiau.
Tačiau didėjant leidimų dažniui, didėja ir tikimybė, kad bus neigiamai paveiktas programos patikimumas ar vartotojo patirtis. Štai kodėl operacijoms ir „DevOps“ komandoms svarbu kurti procesus ir valdyti diegimo strategijas taip, kad būtų sumažinta rizika produktui ir vartotojams. (Galite sužinoti daugiau apie CI / CD dujotiekio automatizavimą .)
Šiame įraše aptarsime įvairias „Kubernetes“ diegimo strategijas, įskaitant nuolatinį diegimą ir pažangesnius metodus, tokius kaip „Canary“ diegimas ir jų variantai.
Diegimo strategijos
Atsižvelgdami į savo tikslą, galite naudoti keletą skirtingų diegimo strategijų tipų. Pavyzdžiui, gali tekti atlikti tam tikros aplinkos arba vartotojų/klientų pogrupio pakeitimus, arba prieš naudojant funkciją gali reikėti atlikti ribotą naudotojo testavimą. viešas.
Slenkantis (laipsniškas, „slenkantis“ diegimas)
Tai yra standartinė Kubernetes diegimo strategija. Palaipsniui, po vieną, senos programos versijos ankštys pakeičiamos nauja versija – be klasterio prastovų.
„Kubernetes“ laukia, kol nauji ankštys bus paruoštos darbui (tikrinkite jas naudodami ), prieš pradėdami vynioti senuosius. Jei iškyla problema, šį nuolatinį naujinimą galima nutraukti nesustabdžius visos grupės. YAML faile, kuriame aprašomas diegimo tipas, naujas vaizdas pakeičia senąjį vaizdą:
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: 8080Perkėlimo atnaujinimo parametrus galima nurodyti manifesto faile:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Atkurti
Taikant šį paprasčiausią diegimo būdą, senos ankštys sunaikinamos iš karto ir pakeičiamos naujais:
Atitinkamas manifestas atrodo maždaug taip:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Mėlyna / žalia (mėlyna-žalia dislokacija)
Mėlynai žalios spalvos diegimo strategija (kartais dar vadinama raudona / juoda) apima senosios (žalios) ir naujos (mėlynos) programos versijų diegimą vienu metu. Paskelbus abi versijas, paprasti vartotojai turi prieigą prie žaliosios, o mėlynąją – QA komanda, kuri gali automatizuoti testus per atskirą paslaugą arba tiesioginį prievado persiuntimą:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Išbandžius mėlyną (naują) versiją ir patvirtinus jos leidimą, paslauga persijungia į ją, o žalia (senoji) versija sulankstoma:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Kanarų (kanarėlių dislokacijos)
„Canary“ išleidimai yra panašūs į mėlynai žalius išleidimus, tačiau geriau valdomi ir naudojami žingsnis po žingsnio metodas. Šis tipas apima keletą skirtingų strategijų, įskaitant „slaptąjį“ paleidimą ir A/B testavimą.
Ši strategija naudojama tada, kai reikia išbandyti naujas funkcijas, dažniausiai programos užpakalinėje dalyje. Požiūrio esmė – sukurti du beveik identiškus serverius: vienas aptarnauja beveik visus vartotojus, o kitas su naujomis funkcijomis aptarnauja tik nedidelį vartotojų pogrupį, po kurio lyginami jų darbo rezultatai. Jei viskas vyksta be klaidų, naujoji versija palaipsniui iškeliama į visą infrastruktūrą.
Nors šią strategiją galima įgyvendinti tik naudojant Kubernetes, pakeičiant senus podius naujais, daug patogiau ir paprasčiau naudoti tokį paslaugų tinklelį kaip Istio.
Pavyzdžiui, „Git“ gali turėti du skirtingus aprašus: įprastą aprašą su žyma 0.1.0 ir kanarėlių aprašą su žyma 0.2.0. Pakeitę svorius Istio virtualiojo šliuzo apraše, galite valdyti srauto paskirstymą tarp šių dviejų diegimų:
Žingsnis po žingsnio vadovą, kaip įgyvendinti kanarėlių diegimą naudojant Istio, žr . (Pastaba. vert.: Į Istio taip pat išvertėme medžiagą apie kanarėlių iškočiojimą .)
Kanarų diegimas naudojant „Weaveworks Flagger“.
leidžia lengvai ir efektyviai valdyti kanarėlių išleidimą.
Žymėjas automatizuoja darbą su jais. Jis naudoja Istio arba AWS App Mesh srautui nukreipti ir perjungti, o Prometheus metriką rezultatams analizuoti. Be to, kanarėlių diegimo analizė gali būti papildyta žiniatinklio kabliukais, kad būtų galima atlikti priėmimo testus, apkrovos bandymus ir bet kokius kitus patikrinimus.
Remdamasis „Kubernetes“ diegimu ir, jei reikia, horizontaliu „podų“ masteliu (HPA), „Flagger“ sukuria objektų rinkinius („Kubernetes“ diegimas, „ClusterIP“ paslaugos ir „Istio“ arba „App Mesh“ virtualios paslaugos), kad galėtų analizuoti ir įgyvendinti „Canary“ diegimus:
Valdymo kontūro įgyvendinimas (valdymo kilpa),Flagger palaipsniui perjungia srautą į Canary serverį, tuo pat metu matuodamas pagrindinius našumo rodiklius, pvz., sėkmingų HTTP užklausų procentą, vidutinę užklausos trukmę ir podelio būklę. Remiantis KPI (Key Performance Indicators) analize, kanarėlė arba auga, arba žlunga, o analizės rezultatai skelbiami Slack. Šio proceso aprašymą ir demonstravimą galima rasti medžiagoje .
Tamsi (paslėpta) arba A/B dislokacija
Slaptas diegimas yra dar vienas kanarėlių strategijos variantas (su kuriuo, beje, „Flagger“ taip pat gali dirbti). Skirtumas tarp slapto ir „Canary“ diegimo yra tas, kad slaptas diegimas yra susijęs su priekine sistema, o ne su užpakaline sistema, kaip „canary“ diegimas.
Kitas šių diegimų pavadinimas yra A/B testavimas. Užuot padarius naująją funkciją prieinamą visiems vartotojams, ji siūloma tik ribotai jų daliai. Paprastai šie vartotojai nežino, kad yra novatoriški bandytojai (iš čia ir kilęs terminas „slaptas diegimas“).
Naudojant funkcinius jungiklius (funkcijų perjungimas) ir kitus įrankius, galite stebėti, kaip vartotojai sąveikauja su nauja funkcija, ar ji juos sudomino, ar naujoji vartotojo sąsaja jiems atrodo paini, ir kitų tipų metriką.
Žymėjimo ir A/B diegimas
Be pagal svorį pagrįsto maršruto parinkimo, „Flagger“ taip pat gali nukreipti srautą į Canary serverį pagal HTTP parametrus. Atliekant A/B testavimą, galite naudoti HTTP antraštes arba slapukus, kad nukreiptumėte į konkretų vartotojų segmentą. Tai ypač efektyvu, kai priekinės programos reikalauja seanso susiejimo su serveriu (seanso giminingumas). Daugiau informacijos galite rasti žymėtojo dokumentacijoje.
Autorius reiškia dėkingumą , „Weaveworks“ inžinierius (ir „Flagger“ kūrėjas) už visus šiuos nuostabius diegimo modelius.
PS iš vertėjo
Taip pat skaitykite mūsų tinklaraštyje:
- «»;
- «»;
- «»;
- «".
Šaltinis: www.habr.com