🥇3-viisiline liitmine werfis: Kubernetesesse kasutusele võtmine Helmi „steroididega“

Toimus see, mida me (ja mitte ainult meie) oleme kaua oodanud: werf, meie avatud lähtekoodiga tööriist rakenduste koostamiseks ja nende edastamiseks Kubernetesesse toetab nüüd muudatuste rakendamist 3-way-merge-patchide abil! Lisaks on nüüd võimalik olemasolevate K8s-resursside võtmine Helm-releasidesse ilma nende ressursside uuesti loomata.

Lühidalt öeldes, seadistame WERF_THREE_WAY_MERGE=enabled — saame „nagu kubectl apply“, mis on ühilduv olemasolevate Helm 2 installatsioonidega ja isegi veidi rohkem.

Aga alustame teooriast: mis on 3-way-merge-patchid, kuidas inimesed on jõudnud selle lähenemiseni ja miks need on olulised CI/CD-protsessides, mis põhinevad Kubernetesel? Seejärel vaatame, mis on 3-way-merge werfis, milliseid režiime kasutatakse vaikimisi ja kuidas sellega hallata.

Mis on 3-way-merge-patch?

Seega alustame ressursside väljastamise ülesandest, mis on kirjeldatud YAML-manifestides Kuberneteses.

Kubernetes API pakub ressursside haldamiseks selliseid põhitegevusi nagu create, patch, replace ja delete. Eeldatakse, et nende abil tuleb luua mugav järjepidev ressursside väljastamine klastrisse. Kuidas?

Implisiitilised kubectl käsklused

Esimene lähenemine Kubernetesese objektide haldamiseks on implitseeritud kubectl käskluste kasutamine nende objektide loomiseks, muutmiseks ja kustutamiseks. Lihtsalt öeldes:

käsklusega kubectl run saab käivitada Deploymenti või Töö:

kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE

käsklusega kubectl scale — muuta repliikide arvu:
```
kubectl scale --replicas=3 deployment/mysql
```
jne.

See lähenemine võib esialgu tunduda mugav. Kuid on probleeme:

Seda on raske automatiseerida.
Kuidas peegeldada konfiguratsioonis Git'is? Kuidas teha ülevaadet muudatustest, mis toimuvad klastris?
Kuidas tagada konfiguratsiooni korduvus taaskäivitamisel?
…

On selge, et selline lähenemine ei sobi hästi koos rakenduse koodiga ja infrastruktuurina koodina (IaC; või isegi GitOps nagu tänapäevane variant, mis saavutanud populaarsust Kubernetes-ökosüsteemis). Seetõttu ei saanud need käsklused kubectl-s edasist arengut.

Tegevused create, get, replace ja delete

Esialgse loomisega on kõik lihtne: saadame manifesti kube API operatsiooni ja ressurss on loodud. YAML-esitus manifestist saab hoida Git'is ning loomise jaoks kasutada käsku create kubectl create -f manifest.yaml kustutamine.

A on samuti lihtne: asendame sama manifest.yaml Git'ist käsus kubectl delete -f manifest.yaml kubectl delete -f manifest.yaml.

Tehe replace võimaldab täielikult asendada ressursi konfiguratsiooni uuega, ilma et oleks vaja ressursi uuesti luua. See tähendab, et enne muudatuste tegemist ressursil on mõistlik küsida praegust versiooni operatsiooniga get, muuta see ja uuendada operatsiooniga replace. Kube API serverisse on sisse ehitatud optimistlik lukustus ja, kui objekti pärast operatsiooni get olek muutub, siis operatsioon replace ei õnnestu.

Kuna konfiguratsiooni tuleb salvestada Git'i ja uuendada kasutades replace'i, tuleb teha operatsioon get, sulandada konfigureerimine Git'ist saadud andmetega ning teostada replace. Kubectl võimaldab vaid kasutada käsku kubectl replace -f manifest.yaml, kus Git'ist käsus — juba täielikult ette valmistatud (meie puhul — sulandatud) manifest, mille tuleb installida. Tulemuseks on see, et kasutajal tuleb implementeerida manifestide sulandumine, mis pole sugugi triviaalne…

Samuti on oluline märkida, et kuigi Git'ist käsus see on salvestatud Git'i, ei saa me ette teada, kas objekt tuleb luua või uuendada — seda peab tegema kasutaja tarkvara.

Kokkuvõtteks: Kas saame ehitada pideva väljalaset ainult create, replace ja delete abil, tagades infrastruktuuri konfiguratsiooni salvestamise Git'isse koos koodiga ning mugava CI/CD?

Põhimõtteliselt saame… Selleks on vaja teostada manifestide sulandumise operatsioon ja mingi ümberprojekteerimine, mis:

kontrollib objekti olemasolu klastris,
teostab objekti esialgse loomise,
uuendab või kustutab selle.

Uuendamisel tuleb arvesse võtta, et ressurss on võinud muutuda alates viimast get ja automaatselt käituda optimistliku lukustuse olukorras — teha uuendamise katseid.

Kuid miks leiutada jalgratast, kui kube-apiserver pakub teistsugust viisi ressursside uuendamiseks: operatsiooni patch, mis vabastab kasutajat mõnedest eespool kirjeldatud probleemidest?

Patch

Nüüd oleme jõudnud patšide juurde.

Patšid on peamine viis rakenduste muudatuste tegemiseks olemasolevatele objektidele Kuberneteses. Operatsioon patch töötleb nii, et:

kube-apiserveri kasutajal on vaja saata patš JSON-vormingus ja näidata objekti,
ja api server mõistab ise objekti praegust seisu ning viib selle nõutud olekusse.

Optimistlik lukustus ei ole sel juhul vajalik. See operatsioon on dekreetiivsem võrreldes replace'iga, kuigi alguses võib see tunduda vastupidine.

Seega:

kasutades operatsiooni create loome objekti Git’i manifestist,
kasutades delete — eemaldame, kui objekt ei ole enam vajalik,
kasutades patch — muudame objekti, viies selle Git'is kirjeldatud olekusse.

Kuid selleks, et seda teha, on vajalik luua õige patch!

Kuidas Helm 2 patchid töötavad: 2-way-merge

Helmi välja esmakordsel installimisel toimub create chart'i ressursside jaoks.

Helmi välja värskendamisel iga ressursi jaoks:

loob patchi eelneva chart'i ressursi versiooni ja praeguse chart'i versiooni vahel,
rakendab selle patchi.

Seda patchi nimetatakse 2-way-merge patch, kuna selle loomisel osaleb 2 manifesti:

eelneva välja ressursi manifest,
praeguse ressursi manifest.

Kustutamise korral toimub operatsioon delete kube apiserveris, mis kutsub esile ressursid, mis olid kuulutatud eelnevas versioonis, kuid ei ole kuulutatud praeguses.

2-way-merge patch lähenemine omab probleemi: see viib ressursi tegeliku oleku ja Git'i manifesti desünkroniseerimiseni..

Probleemi illustreerimine näite abil

Git'is, chart'is on manifest, mille väli image Deployment'il on väärtus ubuntu:18.04.
Kasutaja on kubectl edit muutnud selle välja väärtust ubuntu:19.04.
Helmi chart'i uuesti väljalaskmisel ei genereeri patchi, kuna väli image eelneva versiooni vabanemises ja praeguses chart'is on identsed.
Pärast uuesti väljalaset jääb image , kuigi chart'is on kirjas ubuntu:19.04Oleme saanud desünkroniseerimise ja kaotanud deklaratiivsuse. ubuntu:18.04.

Mis on sünkroniseeritud ressurs?

täielik

Üldiselt vastavus töötava klastri ressursi manifesti ja Git'ist saadud manifesti vahel on võimatu. Kuna tegelikus manifestis võivad olla teenuse annotatsioonid/kleebised, täiendavad konteinerid ja muud andmed, mida mõni kontrollija dünaamiliselt ressurssi lisab ja eemaldab. Me ei saa ja ei soovi neid andmeid Git'is hoida. Siiski tahame, et väljalaske korral väärtustavad need välja, mida me selgelt Git'is määratlesime, vastavaid väärtusi. Tekib selline üldine

sünkroniseeritud ressursi reegel : ressursi väljalaskmisel võib muutuda või kustuda ainult need väljad, mis on selgelt määratletud Git'i manifestis (või olid määratletud eelnevas versioonis ja nüüd eemaldatud).3-way-merge patch

: genereerib patchi viimase rakendatud manifesti versiooni ja sihitud manifesti versiooni vahel, arvestades praegust töötava klastri manifesti versiooni. Lõpptulemus peab vastama sünkroniseeritud ressursi reeglile:

Põhimõte : genereerib patchi viimase rakendatud manifesti versiooni ja sihitud manifesti versiooni vahel, arvestades praegust töötava klastri manifesti versiooni. Lõpptulemus peab vastama sünkroniseeritud ressursi reeglile:uusid välju, mis on lisatud sihitud versioonile, lisatakse patchi abil;

Uued väljaanded, mis on lisatud sihtversiooni, lisatakse patch'i kaudu;
Eelmised väljaandmed, mis ei ole olemas sihtversioonis, nullitakse viimase rakendatud versiooni abil patchi kaudu;
Praeguseid objekti välju, mis erinevad sihtversioonist, uuendatakse patchi kaudu.

Just selle põhimõtte kohaselt genereeritakse patše. kubectl apply:

Viimane rakendatud versioon säilitatakse objekti enda annotatsioonis,
sihtversioon võetakse määratud YAML-failist,
praegune versioon on töötavast klastrist.

Nüüd, kui oleme teooria selgeks teinud, on aeg rääkida, mida me werf-is tegime.

Muudatuste rakendamine werf-is

Varem kasutas werf, nagu ka Helm 2, 2-way-merge patše.

Repair patch

Et liikuda uue patši tüübi — 3-way-merge — juurde, on esimene samm sisse viia nn repair-patchid..

Deployimise ajal kasutatakse standardset 2-way-merge patši, kuid werf genereerib lisaks sellise patši, mis sünkroniseerib ressursi reaalse seisundi sellega, mis on kirjutatud Git-i (see patš luuakse ülesande sünkroniseeritud ressursi reeglite järgi, nagu eespool kirjeldatud).

Sünkroonimise probleemi korral saab kasutaja deployimise lõpuks WARNING-i koos vastava sõnumi ja patšiga, mida tuleb rakendada, et tuua ressurss sünkroniseeritud seisu. Samuti salvestatakse see patš spetsiaalsesse annotatsiooni werf.io/repair-patch. Eeldatakse, et kasutaja rakendab selle patši käsitsi: kasutaja rakendab selle patši: werf ei rakenda seda põhimõtteliselt.

Repair-patchide genereerimine on ajutine meetod, mis võimaldab proovida 3-way-merge põhimõttel patšide loomist, kuid neid patše ei rakendata automaatselt. Praegu on see töörežiim vaikimisi sisse lülitatud.

3-way-merge patch ainult uutele väljaannetele

Alates 1. detsembrist 2019 hakkavad werf-i beetaversioonid ja alpha-versioonid vaikimisi käsitlema täielikult 3-way-merge patše muudatuste rakendamiseks ainult uute Helm-i väljaannetega, mis väljastatakse läbi werf. Juba olemasolevad väljaanded jätkavad 2-way-merge + repair-patšide lähenemise kasutamist.

Seda töörežiimi saab selgesõnaliselt lubada seadistusega WERF_THREE_WAY_MERGE_MODE=onlyNewReleases juba praegu.

Märkus: see funktsioon ilmus werf-is mitme väljaande jooksul: alpha-kanalis oli see valmis versiooniga v1.0.5-alpha.19, ja beetakanalis — versiooniga v1.0.4-beta.20.

3-way-merge patch kõikide väljaannete jaoks

Alates 15. detsembrist 2019 hakkavad werf'i beetaversioonid ja alphasid vaikimisi kasutama täielikke 3-way-merge-patch'e muudatuste rakendamiseks kõigis väljaannetes.

Seda töörežiimi saab selgesõnaliselt lubada seadistusega WERF_THREE_WAY_MERGE_MODE=enabled juba praegu.

Kuidas on lood ressursside automaatse skaleerimisega?

Kuberneteses on kaks tüüpi automaatset skaleerimist: HPA (horisontaalne) ja VPA (vertikaalne).

Horisontaalne skaleerimine valib automaatselt koopiate arvu, vertikaalne – ressursside arvu. Nii koopiate arv kui ka ressursside nõudmised on määratud ressursi manifestis (vt. spec.replicas või spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory ja muud).

Probleem: kui kasutaja konfigureerib ressursi chart'is nii, et seal on määratud kindlad ressursi või koopiate väärtused ja sellele ressursile on lubatud automaatne skaleerimine, siis iga werf'i juurutamisega taastatakse need väärtused selliseks, nagu need on määratud chart'i manifestis.

Probleemi lahendamiseks on kaks võimalust. Esiteks on parem loobuda automaatsete väärtuste selgesõnalisest määratlemisest chart'i manifestis. Kui see valik mingil põhjusel ei sobi (näiteks seetõttu, et chart'is on mugav seada algseid ressursi piiranguid ja koopiate arvu), pakub werf järgmisi annotatsioone:

werf.io/set-replicas-only-on-creation=true
werf.io/set-resources-only-on-creation=true

Kui selline annotatsioon on olemas, ei lähtestata werf vastavaid väärtusi iga juurutamise ajal, vaid seadistatakse need ainult ressursi esmakordsel loomisel.

Lisateabe jaoks vt projekti dokumentatsioonist HPA ja VPA.

Keelata 3-way-merge patch'i kasutamine

Kasutaja saab praegu keelata uusimate patch'ide kasutamise werf'is keskkonnamuutuja abil WERF_THREE_WAY_MERGE_MODE=disabled. Kuid alates 1. märtsist 2020 kaotab see keeld kehtivuse ja võimalik on kasutada ainult 3-way-merge-patch'e.

Ressursside vastuvõtmine werf'is

3-way-merge-patch'ide muutmisviisi omaksvõtmine võimaldas meil kohe rakendada sellist funktsiooni nagu klastris olemasolevate ressursside vastuvõtmine Helm'i väljaande.

Helm 2-l on probleem: ei saa lisada chart'i manifestidesse ressurssi, mis juba eksisteerib klastris, ilma seda ressurssi täiesti uuesti loomata (vt. #6031, #3275). Oleme õpetanud werf'i aktsepteerima olemasolevaid ressursse väljaandes. Selleks tuleb seadistada klastris töötava ressursi praegusele versioonile annotatsioon (näiteks koos kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

Nüüd tuleb ressurss kirjeldada chart'is ja järgmisel korral, kui werf'iga versioon juurutatakse, võetakse olemasolev ressurss sellesse versiooni vastu ning jääb selle haldusse. Veelgi enam, ressurssi versiooni vastuvõtmise protsessis viib werf tööklastri praeguse oleku chart'is kirjeldatud olekusse, kasutades samu 3-way-merge-patch'e ja sünkroniseeritud ressursi reeglit.

Märkus: seadistus WERF_THREE_WAY_MERGE_MODE ei mõjuta ressursside vastuvõttu — vastuvõtu korral kasutatakse alati 3-way-merge-patch'i.

Detailid — dokumentatsioon.

Järeldused ja tulevikuplaanid

Loodan, et pärast seda artiklit on selgem, mis on 3-way-merge-patch'id ja miks nendeni jõuti. Praktikas werf projekti arendamise mõttes on nende rakendamine veel üks samm Helm'i sarnase juurutuse täiustamise teel. Nüüd saab unustada konfigureerimise sünkroonimise probleemid, mis sageli tekkisid Helm 2 kasutamise ajal. Samuti on lisatud uus kasulik funktsioon juba saadud Kubernetes-resursside vastuvõtu (adoption) jaoks Helm versioonis.

Helm'i sarnases juurutuses on siiski alles mõned probleemid ja raskused, nagu Go-mallide kasutamine, ning me jätkame nende lahendamist.

Teavet ressursside uuendamise meetodite ja vastuvõtu kohta leiab samuti sellelt dokumentatsiooni lehelt.

Helm 3

Erilist tähelepanu väärib hiljuti ilmunud sel nädalal uus peamine versioon Helm — v3, — mis kasutab samuti 3-way-merge-patch'e ja vabaneb Tiller'ist. Uus versioon Helm nõuab migreerimise juba olemasolevate paigalduste konverteerimist uue versiooni salvestusformaadi jaoks.

Werf on oma osa pealt juba loobunud Tiller'i kasutamisest, lülitunud 3-way-merge peale ja lisanud palju muud, olles samal ajal ühilduv juba olemasolevate Helm 2 paigaldustega (migratsiooniskeeme ei ole vaja käivitada). Seega, kuni werf ei ole lülitatud Helm 3 peale, ei kaota werf kasutajad olulisi eeliseid, mida Helm 3 pakub võrreldes Helm 2-ga (samuti on need werf'is olemas).

Kuid werf'i üleminek Helm 3 koodibaasile on vältimatu ja toimub lähitulevikus. Eeldatavasti on see werf 1.1 või werf 1.2 (praegu on werf'i peamine versioon — 1.0; lisainfot werf'i versioonihaldusest leiate siin). Selle aja jooksul jõuab Helm 3 stabiliseeruda.