3-kordne liitumine werf-ga: Kubernetes'is kasutamine Helm-iga "steroidide peal"

Juhtus see, mida me (ja mitte ainult meie) pikalt ootasime: werf, meie Open Source-i tööriist rakenduste ehitamiseks ja nende toimetamiseks Kubernetesesse toetab nüüd muudatuste rakendamist 3-way-merge-patchide abil! Lisaks on tekkinud võimalus olemasolevate K8s-resursside edastamise viimine Helm-release'idesse ilma nende ressursside uuesti loomata.

Lühidalt öeldes, paneme WERF_THREE_WAY_MERGE=enabled — saame deploida "nagu kubectl apply", mis on ühilduv olemasolevate Helm 2 installatsioonidega ja isegi natuke rohkem.

Aga alustame teooriast: mis on 3-way-merge-patchid, kuidas inimesed jõudsid nende genereerimise lähenemiseni ja miks need on olulised CI/CD protsessides, mille infrastruktuuri baasiks on Kubernetes? Pärast seda vaatame, mis 3-way-merge werf'is endast kujutab, milliseid režiime vaikimisi kasutatakse ja kuidas sellega juhtida.

Mis on 3-way-merge-patch?

Alustame Kubernetesesse YAML-manifestide kaudu ressurside juurutamise ülesandega.

Kubernetes API abil on sellised põhitoimingud nagu create, patch, replace ja delete. Eeldatakse, et nende abil tuleb luua mugav pidev ressursside juurutamine klastrisse. Kuidas?

Imperatiivsed kommandod kubectl

Esimene lähenemine Kubernetes'e objektide haldamisele on imperatiivsete kubectl käskude kasutamine nende objektide loomiseks, muutmiseks ja kustutamiseks. Lihtsalt öeldes:

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

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

• käsku kubectl scale — muuda replikate arvu:

  kubectl scale --replicas=3 deployment/mysql

• Kui kaua aega kulub väljastamiseks?

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

1. Sellel on raske saab automatiseerida.
2. Kuidas peegeldada konfiguratsiooni Git'is? Kuidas teha muudatuste ülevaatamist, mis toimuvad klastris?
3. Kuidas tagada uuendatavus konfiguratsioonide järjepidevus taaskäivitamisel?
4. …

On selge, et see lähenemine ei sobi hästi koos rakenduse koodi ja infrastruktuuri koodina salvestamisega (IaC; või isegi GitOps nagu kaasaegsem variant, mis saab populaarsust Kubernetes'i ökosüsteemis). Seetõttu ei saanud need käsklused kubectl-s edasist arengut.

Toimingud create, get, replace ja delete

Esmaste loomise juhul on kõik lihtne: saadame manifesti create kube API-sse ja ressurss on loodud. YAML-esitus manifestist saab salvestada Git'i ja loomise jaoks kasutada käsku kubectl create -f manifest.yaml.

C kustutamine on samuti lihtne: sisestame sama manifest.yaml Git'ist käsku kubectl delete -f manifest.yaml.

Operatsioon asenda võimaldab täielikult asendada ressursi konfiguratsiooni uuega, ilma et ressursi uuesti looma peaks. See tähendab, et enne ressursi muutmist on loogiline küsida praegust versiooni toimingu get, muuta see ja uuendada toiminguga asenda. Kube apiserveris on sisse ehitatud optimistlik lukustus ja kui pärast toimingut get objekt on muutunud, siis toiming asenda ei toimi.

Et salvestada konfiguratsioon Git'is ja uuendada seda replace kaudu, tuleb teha toiming get, liita Git'i konfiig sellega, mida me saime, ja teha asenda. Vaikimisi võimaldab kubectl kasutada ainult käsku kubectl replace -f manifest.yaml, kus manifest.yaml — juba täielikult ettevalmistatud (meie puhul — ühendatud) manifest, mille nõutakse paigaldus. Seega peab kasutaja rakendama manifestide ühinemist, mis on keeruline ülesanne ...

Samuti tasub märkida, et kuigi manifest.yaml salvestatakse Git'is, ei saa me ette teada, kas on vajalik objekti loomine või uuendamine — selle peab tegema kasutaja tarkvara.

Kokku: Kas saame ehitada pideva juurutamise ainult create, replace ja delete kaudu, tagades infrastruktuuri konfiguratsiooni salvestamise Git'is koos koodiga ja mugava CI/CD-ga?

Põhimõtteliselt saame… Selleks peab olema rakendatud manifestide ühendamise operatsioon ja mingi ümbrus, mis:

• kontrollib objekti olemasolu klastris,
• teeb esialgse ressursi loomise,
• uuendab või kustutab selle.

Uuendamisel tuleb arvestada, et ressurss võis olla muutunud viimase get ja automaatselt käsitleda optimistliku lukustuse juhtumit — teha korduvad uuendamise katsetused.

Kuid miks leiutada ratast, kui kube-apiserver pakub teisi vahendeid ressursside uuendamiseks: toimingu patch, mis vabastab kasutaja osadest kirjeldatud probleemidest?

Patch

Nüüd olemegi jõudnud patšideni.

Patšid on peamine viis muudatuste rakendamiseks olemasolevatele objektidele Kuberneteses. Toiming patch töötavad nii, et:

• kasutaja kube-apiserver peab saatma patši JSON-vormingus ja näitama objekti,
• samuti apiserver mõistab objekti praegust seisundit ja viib selle soovitud kujule.

Sellisel juhul ei ole optimistlik lukustus vajalik. See operatsioon on deklaratiivsem võrreldes replace'iga, kuigi alguses võidakse tunduda vastupidi.

Seega:

• toimingu abil create loome objekti Git'i manifesti põhjal,
• kasutades kustuta — kustutame, kui objekti enam ei vajata,
• kasutades patch — muudame objekti, viies selle kujule, mis on kirja pandud Git'is.

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

Kuidas töötavad Helm 2 patch'id: 2-way-merge

Helmi versiooni esmakordsel installimisel teeb Helm toimingu create chart'i ressurside jaoks.

Versiooni uuendamise puhul teeb Helm iga ressursi jaoks:

• võrdleb eelmise chart'i ressursi versiooni ja praeguse chart'i versiooni vahel olevat patch'i,
• rakendab selle patch'i.

Seda patch'i nimetame 2-way-merge patch, kuna selle loomises osalevad 2 manifesti:

• eelneva versiooni ressursi manifest,
• praeguse ressursi manifest.

Kustutamisel toimub toiming kustuta kube apiserveris ressurside jaoks, mis olid eelmises versioonis deklareeritud, kuid ei ole praeguses.

2-way merge patch lähenemisviisil on probleem: see toob kaasa ressursi tegeliku seisundi ja manifesti vahelise mittesünkroonimise Git'is.

Probleemi illustreerimine näite abil

• Git'is, chart'is on manifest, mille väli pilt Deployment'il on väärtus ubuntu:18.04.
• Kasutaja on läbi kubectl edit muutanud selle välja väärtuseks ubuntu:19.04.
• Helm'i chart'i kordusel ei genereerita patch'i , sest välieelmises versioonis ja praeguses chart'is on samad. pilt Pärast korduvat deploimentimist
• Pärast korduvat juurutamist pilt jääb alles ubuntu:19.04, kuigi chart'is on kirjutatud ubuntu:18.04.

Oleme saanud mittesünkroonimise ja kaotanud deklaratiivsuse.

Mis on sünkroonitud ressurss?

Üldiselt peab täielik vastavus toimiva klastriga ressurssi manifesti ja Git'ist saadud manifesti vahel on võimatu saavutada. Sest tegelikus manifestis võivad olla teenuse annotatsioonid / sildid, lisakonteinerid ja muud andmed, mille dünaamiliselt lisavad ja eemaldavad mõned kontrollijad. Need andmed ei saa ja me ei soovi neid hoida Git'is. Siiski soovime, et nende väljade väärtused, mille oleme selgelt Git'is määranud, vastaksid.

Saades seejärel selline üldine sünkroonitud ressursi reegel: ressursi välja käimisel võib muuta või eemaldada ainult need väljad, mis on selgelt määratud Git'i manifestis (või kirjutati eelnevas versioonis, kuid nüüd on eemaldatud).

3-way-merge patch

Peamine idee 3-way-merge patch: genereeritakse patch viimase rakendatud versiooni manifestist Git'ist ja sihtversiooni manifestist Git'ist, arvestades praegust versiooni toimivas klastris. Lõpppatch peab vastama sünkroonitud ressursi reeglile:

• uusid välju, mis on lisatud sihtversioonile, lisatakse patch'i kaudu;
• varasemad väljad viimases rakendatud versioonis ja sihtversioonis, mis ei eksisteeri — nullitakse patch'i kaudu;
• praeguse objekti versioonis olevad väljad, mis erinevad sihtversiooni manifestist, — uuendatakse patch'i kaudu.

Just selle põhimõtte järgi genereeritakse patch'id kubectl apply:

• viimane rakendatud versioon manifestist säilitatakse objekti enda annotatsioonis,
• siht — võetakse määratud YAML-failist,
• praegune — toimivast klastrist.

Nüüd, kui me oleme teooriat selgitanud, on aeg rääkida, mida me werf'is tegime.

Muudatuste kohaldamine werf'is

Varem kasutas werf, nagu ka Helm 2, 2-way-merge-patch'e.

Repair patch

Uue patch'i tüübi, 3-way-merge, juurutamiseks, esimeseks sammuks tutvustasime nn repair-patch'e.

Käivitamisel kasutatakse standardset 2-way-merge-patch'i, kuid werf genereerib täiendavalt sellise patch'i, mis sünkroniseerib ressursi tegeliku seisundi sellekohasega Git'is (loodud patch sünkroonitud ressursi reegli järgi, nagu eespool kirjeldatud).

Kui tekib mittesünkroonimine, saab kasutaja deploimentimise lõpus WARNING'i vastava sõnumiga ja patch'i, mida tuleb rakendada, et tuua ressurss sünkroniseeritud välimusele. Samuti salvestatakse see patch spetsiaalsesse annotatsiooni werf.io/repair-patch.Eeldatakse, et kasutaja rakendab selle patch'i käsitsi: werf ei rakenda seda põhimõtteliselt. Repair-patch'ide genereerimine on ajutine lahendus, mis võimaldab proovida 3-way-merge põhimõtte alusel patch'ide loomist, kuid neid patch'e automaatselt ei rakendata. Praegu on see töörežiim vaikimisi sisse lülitatud. rakendab selle plaastri: werf ei rakenda seda põhimõtteliselt.

Repair-plaastrite genereerimine on ajutine meede, mis võimaldab praktikas katsetada plaastrite loomist 3-way-merge põhimõttel, kuid neid plaastreid ei rakendata automaatselt. Praegu on see töörežiim vaikimisi sisse lülitatud.

3-way-merge patch ainult uutele väljaandele

Alates 1. detsembrist 2019 alustavad werf'i beta- ja alpha-versioonid vaikimisi rakendada täieõiguslikke 3-way-merge-patsh'e muutuste rakendamiseks ainult uutele Helm'i väljaannetele, mis on werf'i kaudu välja antud. Juba olemasolevad väljaanded jätkavad 2-way-merge ja repair-patch'ide lähenemist.

Seda töörežiimi saab selgelt lubada seadistusega WERF_THREE_WAY_MERGE_MODE=onlyNewReleases Seda võib juba praegu kasutada.

Märkus: funktsiooni arendamine toimus werf'is mitme väljaande jooksul: alpha-kanalis sai see valmis versiooniga v1.0.5-alpha.19,beta-kanalis — alates v1.0.4-beta.20.

3-way-merge patch kõigile väljaannetele

Alates 15. detsembrist 2019 alustavad werf'i beta- ja alpha-versioonid vaikimisi rakendada täieõiguslikke 3-way-merge-patsh'e muutuste rakendamiseks kõigile väljaannetele.

Seda töörežiimi saab selgelt lubada seadistusega WERF_THREE_WAY_MERGE_MODE=enabled Seda võib juba praegu kasutada.

Kuidas on automaatse ressursside skaleerimisega?

Kuberneteses on 2 tüüpi automaatmõõtmisel: HPA (horisontaalne) ja VPA (vertikaalne).

Horisontaalne valib automaatselt koopiate arvu, vertikaalne määrab ressursse. Nii koopiate arv kui ka ressursinõuded on märgitud ressursi manifestis (vt. spec.replicas või spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory ja teised).

Probleem: kui kasutaja konfigureerib ressursi chartis nii, et seal on määratud kindlad ressursid või koopiad, ja selle ressursi jaoks on lubatud automaatmõõtjad, siis igal deploy'il kätkeb werf neid väärtusi tagasi manifestis loetletud väärtustele.

Probleemi lahendamiseks on kaks võimalust. Esiteks on parem loobuda automaatmõõtmisväärtuste selgesõnalisest määramisest charti manifestis. Kui see variant mingil põhjusel ei sobi (näiteks kuna chartis on mugav määrata algseid ressursipiiranguid ja koopiate arvu), siis pakub werf järgmisi annotatsioone:

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

Kuna selline annotatsioon on olemas, ei reseti werf vastavaid väärtusi igal deploy'il, vaid need määratakse ainult ressursi esmakordsel loomisel.

Täpsemalt vt projekti dokumentatsioonis HPA ja VPA.

Keela 3-way-merge patch'i kasutamine

Kasutaja saab hetkel keelduda uute patchide kasutamisest werfis keskkonnamuutuja abil WERF_THREE_WAY_MERGE_MODE=disabled. Kuid alates 1. märtsist 2020 kaotab see keeld kehtivuse ja võimalikuks jääb vaid 3-way-merge patch'ide kasutamine.

Ressursside adopteerimine werfis

3-way-merge patch'ide kasutuselevõtt võimaldas kohe rakendada sellise funktsiooni nagu klastris olemasolevate ressursside adopteerimine Helm'i väljaande sisse.

Helm 2-l on probleem: juba klastris olemasolevat ressursi ei saa chartide manifestidesse lisada ilma ressursi nulli täiendamiseta (vt. #6031, #3275). Oleme õpetanud werfi aktsepteerima olemasolevaid ressursse väljaandes. Selleks tuleb praeguse ressursi versiooni annotatsioon asetada töötavas klastris (näiteks kasutades kubectl edit):

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

Nüüd tuleb ressurss chartis kirjeldada ja järgmise werf'iga selle nimega väljaande deploy'imisel võetakse olemasolev ressurss sellesse väljaandesse ja jääb selle juhtimise alla. Veelgi enam, ressursi vastuvõtmise protsessis toob werf ressursi praeguse oleku töötavast klastrist vastavaks chartis kirjeldatud olekule, kasutades samu 3-way-merge patch'e ja ressurssi sünkroniseerimise reeglit.

Märkus: seade WERF_THREE_WAY_MERGE_MODE ei mõjuta ressurside adopteerimist — adopteerimisel kasutatakse alati 3-way-merge patch'i.

Täpsemalt vt dokumentatsioonis.

Kokkuvõtted ja edasised plaanid

Loodan, et pärast seda artiklit sai selgemaks, mis on 3-way-merge patch'id ja miks need sisse viidi. Projekti werf arendamise praktilises vaates on nende rakendamine veel üks samm Helm'i sarnaste deploy'ide parandamiseks. Nüüd võib unustada konfigureerimise sünkroniseerimisega seotud probleemid, millega tihti seoses Helm 2 kasutamisel kokku puututi. Samuti on lisatud uus kasulik funktsioon juba kasutusele võetud Kubernetes'i ressursside adopteerimiseks Helm'i väljaandesse.

Helm'i sarnases deploy's on endiselt mõned probleemid ja raskused, nagu Go-mallide kasutamine, ja me jätkame nende lahendamist.

Teavet ressursside uuendamise meetodite ja adopteerimise kohta võib leida ka sellest dokumentatsioonilehelt.

Helm 3

Erilist tähelepanu väärib hiljuti välja antud uus peamine versioon Helm — v3, — mis samuti kasutab 3-way-merge patch'e ja loob Tilleri. Uus versioon Helm nõuab migreerimise juba olemasolevate installatsioonide konverteerimist uude väljaande salvestamise formaati.

Werf on enda poolt juba eemaldanud Tilleri kasutamise, läinud üle 3-way-merge'ile ja lisanud palju muud, olles samas ühilduv olemasolevate Helm 2 installatsioonidega (migratsiooni skripte ei ole vaja teostada). Seetõttu, kuni werf ei ole üle läinud Helm 3-le, ei kaota werfi kasutajad Helm 3 peamisi eeliseid võrreldes Helm 2-ga (need on olemas ka werfis).

Siiski on werfi üleminek Helm 3 koodibaasi ja tuleb lähiajal. Eeldatavasti on see werf 1.1 või werf 1.2 (hetkel on werfi peamine versioon 1.0; lisainfot werfi versioonimise struktuuri kohta vt. siit). Selle aja jooksul jõuab Helm 3 stabiliseeruda.

P.S.

Lugege ka meie blogist:

• Werfi uuenduste ring:
  • «Werfi kasutamine keerukate Helm-chart'ide välja toomiseks»;
  • «Monorepo ja multirepo tugi werf'is ja kuidas siia sobib Docker Registry»;
  • «Docker-iltide kogumist werfis saab nüüd teha ka tavalise Dockerfile'i abil».
• «werf — meie CI/CD tööriist Kubernetesis (ülevaade ja videoettekanne)»;
• «Ühesuguste mikroteenuste kogumine ja juurutamine werfi ja GitLab CI-ga.»;
• «Tutvustame Helm 3».

Allikas: habr.com