ProHoster > Blogs > Administrācija > TrÄ«s veidu sapludināŔana ar werf: izvietoÅ”ana Kubernetes ar Helm ā€œuz steroÄ«diemā€

TrÄ«s veidu sapludināŔana ar werf: izvietoÅ”ana Kubernetes ar Helm ā€œuz steroÄ«diemā€

Notika tas, ko mēs (un ne tikai mēs) ilgi esam gaidÄ«juÅ”i: werf, mÅ«su atvērtā pirmkoda utilÄ«ta lietojumprogrammu veidoÅ”anai un piegādei Kubernetes, tagad atbalsta izmaiņu piemēroÅ”anu, izmantojot trÄ«svirzienu sapludināŔanas ielāpus! Papildus tam ir iespējams izmantot esoÅ”os K3s resursus Helm laidienos, nepārbÅ«vējot Å”os resursus.

TrÄ«s veidu sapludināŔana ar werf: izvietoÅ”ana Kubernetes ar Helm ā€œuz steroÄ«diemā€

Ja tas ir ļoti Ä«ss, tad liekam WERF_THREE_WAY_MERGE=enabled ā€” mēs saņemam izvietoÅ”anu ā€œkā in kubectl apply", kas ir savietojams ar esoÅ”ajām Helm 2 instalācijām un pat nedaudz vairāk.

Bet sāksim ar teoriju: kas Ä«sti ir trÄ«svirzienu sapludināŔanas ielāpi, kā cilvēki izdomāja pieeju to Ä£enerÄ“Å”anai un kāpēc tie ir svarÄ«gi CI/CD procesos ar Kubernetes bāzētu infrastruktÅ«ru? Un pēc tam apskatÄ«sim, kas ir werf 3-way-mege, kādi režīmi tiek izmantoti pēc noklusējuma un kā to pārvaldÄ«t.

Kas ir trīsvirzienu sapludināŔanas ielāps?

Tātad, sāksim ar uzdevumu ieviest YAML manifestos aprakstītos resursus Kubernetes.

Lai strādātu ar resursiem, Kubernetes API piedāvā Ŕādas pamatdarbÄ«bas: izveide, ielāps, aizstāŔana un dzÄ“Å”ana. Tiek pieņemts, ka ar viņu palÄ«dzÄ«bu ir nepiecieÅ”ams izveidot ērtu nepārtrauktu resursu ievieÅ”anu klasterÄ«. Kā?

kubectl imperatīvas komandas

Pirmā pieeja objektu pārvaldÄ«bai Kubernetes ir izmantot kubectl imperative komandas, lai izveidotu, modificētu un dzēstu Å”os objektus. VienkārÅ”i liec:

  • komanda kubectl run varat palaist izvietoÅ”anu vai darbu: 
    kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE
  • komanda kubectl scale ā€” mainÄ«t kopiju skaitu: 
    kubectl scale --replicas=3 deployment/mysql
  • uc

Å Ä« pieeja no pirmā acu uzmetiena var Ŕķist ērta. Tomēr ir problēmas:

  1. Tas ir grūti automatizēt.
  2. Kā atspoguļo konfigurāciju in Git? Kā pārskatÄ«t klasterÄ« notiekoŔās izmaiņas?
  3. Kā nodroÅ”ināt reproducējamÄ«ba konfigurācijas restartējot?
  4. ...

Ir skaidrs, ka Ŕī pieeja nav labi piemērota lietojumprogrammas un infrastruktÅ«ras glabāŔanai kā kods (IaC vai pat GitOps kā modernāka iespēja, iegÅ«stot popularitāti Kubernetes ekosistēmā). Tāpēc Ŕīs komandas nesaņēma turpmāku attÄ«stÄ«bu kubectl.

Izveidojiet, iegūstiet, nomainiet un dzēsiet darbības

Ar primāro radÄ«Å”anu tas ir vienkārÅ”i: nosÅ«tiet manifestu uz operāciju create kube api un resurss ir izveidots. Manifesta YAML attēlojumu var saglabāt Git un izveidot, izmantojot komandu kubectl create -f manifest.yaml.

Š” noņemÅ”ana arÄ« vienkārÅ”i: aizstājiet to paÅ”u manifest.yaml no Git uz komandu kubectl delete -f manifest.yaml.

DarbÄ«ba replace ļauj pilnÄ«bā aizstāt resursa konfigurāciju ar jaunu, neizveidojot resursu no jauna. Tas nozÄ«mē, ka pirms izmaiņu veikÅ”anas resursā ir loÄ£iski vaicāt paÅ”reizējo versiju ar operāciju get, mainiet to un atjauniniet to ar operāciju replace. kube apiserver ir iebÅ«vēts optimistiska bloÄ·Ä“Å”ana un, ja pēc operācijas get ir mainÄ«jies objekts, tad darbÄ«ba replace tas nedarbosies.

Lai saglabātu konfigurāciju Git un atjauninātu to, izmantojot aizstāŔanu, jums ir jāveic darbÄ«ba get, sapludiniet konfigurāciju no Git ar to, ko mēs saņēmām, un izpildiet replace. Pēc noklusējuma kubectl ļauj izmantot tikai komandu kubectl replace -f manifest.yamlKur manifest.yaml ā€” jau pilnÄ«bā sagatavots (mÅ«su gadÄ«jumā apvienots) manifests, kas jāinstalē. Izrādās, ka lietotājam ir jāievieÅ” sapludināŔanas manifesti, un tas nav mazsvarÄ«gs...

Ir arÄ« vērts atzÄ«mēt, ka, lai gan manifest.yaml un tiek glabāts Git, mēs nevaram iepriekÅ” zināt, vai ir nepiecieÅ”ams izveidot objektu vai to atjaunināt - tas ir jādara lietotāja programmatÅ«rai.

Kopā: vai mēs varam izveidot nepārtrauktu izlaiÅ”anu tikai izmantojot izveidot, aizstāt un dzēst, nodroÅ”inot, ka infrastruktÅ«ras konfigurācija tiek saglabāta Git kopā ar kodu un ērtu CI/CD?

Principā mēs varam... Par Å”o jums bÅ«s jāīsteno apvienoÅ”anas darbÄ«ba manifesti un sava veida saistÄ«ba, kas:

  • pārbauda objekta klātbÅ«tni klasterÄ«,
  • veic sākotnējo resursu izveidi,
  • atjaunina vai dzÄ“Å” to.

Atjauninot, lÅ«dzu, ņemiet vērā to resurss var bÅ«t mainÄ«jies kopÅ” pēdējās get un automātiski apstrādājiet optimistiskas bloÄ·Ä“Å”anas gadÄ«jumu ā€” veiciet atkārtotas atjaunināŔanas mēģinājumus.

Tomēr kāpēc no jauna izgudrot riteni, ja kube-apiserver piedāvā citu veidu, kā atjaunināt resursus: darbību patch, kas atbrīvo lietotāju no dažām aprakstītajām problēmām?

plāksteris

Tagad mēs nonākam pie ielāpiem.

Ielāpi ir galvenais veids, kā lietot izmaiņas esoÅ”ajos Kubernetes objektos. DarbÄ«ba patch tas darbojas Ŕādi:

  • kube-apiserver lietotājam ir jānosÅ«ta ielāps JSON formā un jānorāda objekts,
  • un apiserver pats tiks galā ar objekta paÅ”reizējo stāvokli un izveidos to vajadzÄ«gajā formā.

Optimistiska bloÄ·Ä“Å”ana Å”ajā gadÄ«jumā nav nepiecieÅ”ama. Å Ä« darbÄ«ba ir vairāk deklaratÄ«va nekā aizstāŔana, lai gan sākotnēji var Ŕķist otrādi.

Tādā veidā:

  • izmantojot operāciju create mēs izveidojam objektu saskaņā ar Git manifestu,
  • via delete ā€” dzēst, ja objekts vairs nav vajadzÄ«gs,
  • via patch ā€” mainām objektu, nogādājot to Git aprakstÄ«tajā formā.

Tomēr, lai to izdarītu, jums ir jāizveido pareizs plāksteris!

Kā ielāpi darbojas Helm 2: divvirzienu sapludināŔana

Pirmoreiz instalējot laidienu, Helm veic operāciju create diagrammas resursiem.

Atjauninot Helm laidienu katram resursam:

  • ņem vērā ielāpu starp resursa versiju no iepriekŔējās diagrammas un paÅ”reizējo diagrammas versiju,
  • lieto Å”o ielāpu.

Mēs sauksim Å”o ielāpu Divvirzienu sapludināŔanas ielāps, jo tā izveidē ir iesaistÄ«ti 2 manifesti:

  • resursu manifests no iepriekŔējās laidiena,
  • resursa manifests no paÅ”reizējā resursa.

Noņemot operāciju delete in kube apiserver tiek izsaukts resursiem, kas tika deklarēti iepriekŔējā laidienā, bet nav deklarēti paÅ”reizējā.

Divvirzienu sapludināŔanas ielāpu pieejai ir problēma: tā noved pie nav sinhronizācijas ar reālo resursa stāvokli klasterÄ« un manifestu Git.

Problēmas ilustrācija ar piemēru

  • Programmā Git diagrammā tiek saglabāts manifests, kurā lauks image IzvietoÅ”anai ir nozÄ«me ubuntu:18.04.
  • Lietotājs, izmantojot kubectl edit mainÄ«ja Ŕī lauka vērtÄ«bu uz ubuntu:19.04.
  • Atkārtoti izvietojot Helm diagrammu neÄ£enerē ielāpu, jo lauks image iepriekŔējā izdevuma versijā un paÅ”reizējā diagrammā ir vienādas.
  • Pēc atkārtotas izvietoÅ”anas image paliek ubuntu:19.04, lai gan diagrammā teikts ubuntu:18.04.

Mēs saņēmām desinhronizāciju un zaudējām deklarativitāti.

Kas ir sinhronizēts resurss?

VispārÄ«gi runājot pabeigt Nav iespējams iegÅ«t atbilstÄ«bu starp resursa manifestu darbojas klasterÄ« un manifestu no Git. Jo reālā manifestā var bÅ«t pakalpojuma anotācijas/iezÄ«mes, papildu konteineri un citi dati, ko daži kontrolieri dinamiski pievieno un noņem no resursa. Mēs nevaram un nevēlamies saglabāt Å”os datus Git. Tomēr mēs vēlamies, lai lauki, kurus mēs skaidri norādÄ«jām pakalpojumā Git, pēc izlaiÅ”anas iegÅ«tu atbilstoŔās vērtÄ«bas.

Tas izrādās tik vispārÄ«gi sinhronizēto resursu kārtula: izlaižot resursu, varat mainÄ«t vai dzēst tikai tos laukus, kas ir skaidri norādÄ«ti Git manifestā (vai tika norādÄ«ti iepriekŔējā versijā un tagad ir dzēsti).

Divvirzienu sapludināŔanas ielāps

galvenā doma Divvirzienu sapludināŔanas ielāps: mēs Ä£enerējam ielāpu starp pēdējo lietoto manifesta versiju no Git un manifesta mērÄ·a versiju no Git, ņemot vērā paÅ”reizējo manifesta versiju no darbÄ«bas klastera. IegÅ«tajam ielāpam jāatbilst sinhronizētā resursa noteikumam:

  • jauni lauki, kas pievienoti mērÄ·a versijai, tiek pievienoti, izmantojot ielāpu;
  • IepriekÅ” esoÅ”ie lauki pēdējā lietotajā versijā un nepastāvējuÅ”i mērÄ·a versijā tiek atiestatÄ«ti, izmantojot ielāpu;
  • Lauki objekta paÅ”reizējā versijā, kas atŔķiras no manifesta mērÄ·a versijas, tiek atjaunināti, izmantojot ielāpu.

Pēc Ŕī principa tas Ä£enerē ielāpus kubectl apply:

  • pēdējā lietotā manifesta versija tiek saglabāta paÅ”a objekta anotācijā,
  • mērÄ·is - ņemts no norādÄ«tā YAML faila,
  • paÅ”reizējais ir no darbojas klastera.

Tagad, kad esam sakārtojuÅ”i teoriju, ir pienācis laiks pastāstÄ«t, ko mēs darÄ«jām werf.

Izmaiņu piemēroÅ”ana werf

IepriekŔ werf, tāpat kā Helm 2, izmantoja divvirzienu sapludināŔanas ielāpus.

Remonta plāksteris

Lai pārietu uz jauna veida ielāpiem - 3-way-merge -, pirmais solis tika ieviests t.s. remonta ielāpi.

Izvietojot tiek izmantots standarta divvirzienu sapludināŔanas ielāps, bet werf papildus Ä£enerē ielāpu, kas sinhronizētu reālo resursa stāvokli ar Git rakstÄ«to (Ŕāds ielāps tiek izveidots, izmantojot to paÅ”u iepriekÅ” aprakstÄ«to sinhronizētā resursa kārtulu) .

Ja notiek desinhronizācija, izvietoÅ”anas beigās lietotājs saņem BRÄŖDINĀJUMU ar atbilstoÅ”u ziņojumu un ielāpu, kas jāpielieto, lai resurss nonāktu sinhronizētā formā. Å is ielāps ir ierakstÄ«ts arÄ« Ä«paŔā anotācijā werf.io/repair-patch. Tiek pieņemts, ka lietotāja rokās pats uzliks Å”o ielāpu: werf to neuzliks vispār.

LaboÅ”anas ielāpu Ä£enerÄ“Å”ana ir pagaidu pasākums, kas ļauj faktiski pārbaudÄ«t ielāpu izveidi, pamatojoties uz trÄ«svirzienu sapludināŔanas principu, bet nelietot Å”os ielāpus automātiski. Å obrÄ«d Å”is darbÄ«bas režīms ir iespējots pēc noklusējuma.

Trīsvirzienu sapludināŔanas ielāps tikai jauniem izdevumiem

Sākot ar 1. gada 2019. decembri, sāksies werf beta un alfa versijas pēc noklusējuma izmantojiet pilnvērtÄ«gus trÄ«svirzienu sapludināŔanas ielāpus, lai izmaiņas lietotu tikai jaunajiem Helm laidieniem, kas izlaisti caur werf. EsoÅ”ie laidieni turpinās izmantot divvirzienu sapludināŔanas un laboÅ”anas ielāpu pieeju.

Å o darbÄ«bas režīmu var tieÅ”i iespējot, iestatot WERF_THREE_WAY_MERGE_MODE=onlyNewReleases tagad.

Piezīme: funkcija parādījās werf vairākos laidienos: alfa kanālā tā kļuva gatava ar versiju v1.0.5-alpha.19, bet beta kanālā - ar v1.0.4-beta.20.

3 virzienu sapludināŔanas ielāps visiem laidieniem

Sākot ar 15. gada 2019. decembri, werf beta un alfa versijas pēc noklusējuma sāk izmantot pilnus trÄ«svirzienu sapludināŔanas ielāpus, lai piemērotu izmaiņas visiem laidieniem.

Å o darbÄ«bas režīmu var tieÅ”i iespējot, iestatot WERF_THREE_WAY_MERGE_MODE=enabled tagad.

Ko darÄ«t ar resursu automātisko mērogoÅ”anu?

Programmā Kubernetes ir 2 automātiskās mērogoÅ”anas veidi: HPA (horizontālā) un VPA (vertikālā).

Horizontāli automātiski izvēlas reprodukciju skaitu, vertikālā - resursu skaitu. Gan reprodukciju skaits, gan resursu prasÄ«bas ir norādÄ«tas resursa manifestā (skatiet Resursu manifestu). spec.replicas vai spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory Šø pārējie).

Problēma: ja lietotājs diagrammā konfigurē resursu tā, lai tas norādÄ«tu noteiktas vērtÄ«bas resursiem vai replikām un Å”im resursam ir iespējoti automātiskie mērogotāji, tad ar katru izvietoÅ”anu werf atiestatÄ«s Ŕīs vērtÄ«bas uz diagrammas manifestā rakstÄ«tajām vērtÄ«bām. .

Problēmai ir divi risinājumi. Sākumā vislabāk ir izvairÄ«ties no automātiskās mērogoÅ”anas vērtÄ«bu skaidras norādÄ«Å”anas diagrammas manifestā. Ja Ŕī opcija kāda iemesla dēļ nav piemērota (piemēram, tāpēc, ka diagrammā ir ērti iestatÄ«t sākotnējos resursu ierobežojumus un reprodukciju skaitu), werf piedāvā Ŕādas anotācijas:

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

Ja ir Ŕāda anotācija, werf neatiestatÄ«s atbilstoŔās vērtÄ«bas katrā izvietoÅ”anā, bet iestatÄ«s tās tikai tad, kad resurss tiks sākotnēji izveidots.

SÄ«kāku informāciju skatiet projekta dokumentācijā HPA Šø BPN.

Aizliegt izmantot 3-way-mege plāksteri

Lietotājs paÅ”laik var aizliegt jaunu ielāpu izmantoÅ”anu werf, izmantojot vides mainÄ«go WERF_THREE_WAY_MERGE_MODE=disabled. Tomēr sākot No 1. gada 2020. marta Å”is aizliegums vairs nebÅ«s spēkā. un bÅ«s iespējams izmantot tikai 3-way-mege ielāpus.

Resursu pieņemÅ”ana werf

Izmaiņu pielietoÅ”anas metodes apguve ar trÄ«svirzienu sapludināŔanas ielāpiem ļāva mums nekavējoties ieviest tādu lÄ«dzekli kā klasterÄ« esoÅ”o resursu pārņemÅ”ana Helm laidienā.

Helm 2 ir problēma: jÅ«s nevarat pievienot resursu diagrammas manifestiem, kas jau pastāv klasterÄ«, ja Å”is resurss nav izveidots no jauna (sk. #6031, #3275). Mēs mācÄ«jām werf pieņemt esoÅ”os resursus atbrÄ«voÅ”anai. Lai to izdarÄ«tu, ir jāinstalē anotācija paÅ”reizējā resursa versijā no darbojoŔās klastera (piemēram, izmantojot kubectl edit):

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

Tagad resurss ir jāapraksta diagrammā, un nākamreiz, kad werf izvietos laidienu ar atbilstoÅ”u nosaukumu, esoÅ”ais resurss tiks pieņemts Å”ajā laidienā un paliks tā kontrolē. Turklāt, pieņemot resursa izlaiÅ”anai, werf nodos paÅ”reizējo resursa stāvokli no darba klastera lÄ«dz stāvoklim, kas aprakstÄ«ts diagrammā, izmantojot tos paÅ”us trÄ«sceļu sapludināŔanas ielāpus un sinhronizētā resursa kārtulu.

PiezÄ«me: iestatÄ«Å”ana WERF_THREE_WAY_MERGE_MODE neietekmē resursu pieņemÅ”anu - adopcijas gadÄ«jumā vienmēr tiek izmantots 3 virzienu sapludināŔanas ielāps.

Sīkāka informācija - iekŔā dokumentācija.

Secinājumi un nākotnes plāni

Ceru, ka pēc Ŕī raksta ir kļuvis skaidrāks, kas ir 3-way-merge ielāpi un kāpēc tie nonāca pie tiem. No werf projekta izstrādes praktiskā viedokļa to Ä«stenoÅ”ana bija vēl viens solis Helm lÄ«dzÄ«gās izvietoÅ”anas uzlaboÅ”anai. Tagad varat aizmirst par problēmām ar konfigurācijas sinhronizāciju, kas bieži radās, izmantojot Helm 2. Tajā paŔā laikā Helm izlaidumam tika pievienota jauna noderÄ«ga funkcija, kas ļauj pieņemt jau lejupielādētos Kubernetes resursus.

Joprojām pastāv dažas problēmas un problēmas ar Helm lÄ«dzÄ«gu izvietoÅ”anu, piemēram, Go veidņu izmantoÅ”anu, kuras mēs turpināsim risināt.

Informāciju par resursu atjaunināŔanas metodēm un pieņemÅ”anu var atrast arÄ« vietnē Å”ajā dokumentācijas lapā.

Stūre 3

ÄŖpaÅ”as piezÄ«mes vērts atbrÄ«vots tikai citu dienu jauna galvenā Helm versija ā€” v3 ā€”, kas arÄ« izmanto trÄ«svirzienu sapludināŔanas ielāpus un atbrÄ«vojas no Tiller. Jaunajai Helm versijai ir nepiecieÅ”ams migrācija esoŔās instalācijas, lai tās pārvērstu jaunā laidiena krātuves formātā.

Savukārt Werf paÅ”laik ir atbrÄ«vojies no Tiller izmantoÅ”anas, pārgājis uz 3-way-mege un pievienojis daudz vairāk, vienlaikus saglabājot saderÄ«bu ar esoÅ”ajām Helm 2 instalācijām (nav jāizpilda migrācijas skripti). Tāpēc lÄ«dz brÄ«dim, kad werf pāriet uz Helm 3, werf lietotāji nezaudē Helm 3 galvenās priekÅ”rocÄ«bas salÄ«dzinājumā ar Helm 2 (tās ir arÄ« werf).

Tomēr werf pāreja uz Helm 3 kodu bāzi ir neizbēgama un notiks tuvākajā nākotnē. Domājams, ka Ŕī bÅ«s werf 1.1 vai werf 1.2 (Å”obrÄ«d werf galvenā versija ir 1.0; plaŔāku informāciju par werf versiju veidoÅ”anas ierÄ«ci sk. Å”eit). Å ajā laikā Helm 3 bÅ«s laiks stabilizēties.

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru