Yr hyn yr ydym ni (ac nid ni yn unig) wedi bod yn aros ers amser maith wedi digwydd: , mae ein cyfleustodau Ffynhonnell Agored ar gyfer adeiladu cymwysiadau a'u cyflwyno i Kubernetes, bellach yn cefnogi cymhwyso newidiadau gan ddefnyddio clytiau uno 3-ffordd! Yn ogystal â hyn, mae'n bosibl mabwysiadu adnoddau K8 presennol i mewn i ddatganiadau Helm heb ailadeiladu'r adnoddau hyn.
Os yw'n fyr iawn, yna rydyn ni'n rhoi WERF_THREE_WAY_MERGE=enabled - rydym yn cael lleoli “fel yn kubectl apply", sy'n gydnaws â gosodiadau Helm 2 presennol a hyd yn oed ychydig yn fwy.
Ond gadewch i ni ddechrau gyda'r ddamcaniaeth: beth yn union yw clytiau 3-cyfuno, sut y gwnaeth pobl feddwl am y dull o'u cynhyrchu, a pham eu bod yn bwysig mewn prosesau CI/CD gyda seilwaith yn seiliedig ar Kubernetes? Ac ar ôl hynny, gadewch i ni weld beth yw cyfuniad 3-ffordd mewn werff, pa foddau a ddefnyddir yn ddiofyn a sut i'w reoli.
Beth yw darn 3-ffordd-uno?
Felly, gadewch i ni ddechrau gyda'r dasg o gyflwyno'r adnoddau a ddisgrifir yn YAML a amlygir i Kubernetes.
I weithio gydag adnoddau, mae API Kubernetes yn cynnig y gweithrediadau sylfaenol canlynol: creu, clytio, disodli a dileu. Tybir, gyda'u cymorth hwy, bod angen adeiladu proses barhaus gyfleus o gyflwyno adnoddau i'r clwstwr. Sut?
gorchymmynion kubectl
Y dull cyntaf o reoli gwrthrychau yn Kubernetes yw defnyddio gorchmynion hanfodol kubectl i greu, addasu a dileu'r gwrthrychau hyn. Yn syml, rhowch:
- tîm
kubectl rungallwch redeg Deployment neu Job:kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE - tîm
kubectl scale— newid y nifer o atgynyrchiadau:kubectl scale --replicas=3 deployment/mysql - ac ati
Gall y dull hwn ymddangos yn gyfleus ar yr olwg gyntaf. Fodd bynnag, mae yna broblemau:
- Mae'n anodd awtomeiddio.
- Fel adlewyrchu cyfluniad yn Git? Sut i adolygu newidiadau sy'n digwydd i'r clwstwr?
- Sut i ddarparu atgenhedliad ffurfweddiadau wrth ailgychwyn?
- ...
Mae'n amlwg nad yw'r dull hwn yn cyd-fynd yn dda â storio cymhwysiad a seilwaith fel cod (IaC; neu hyd yn oed fel opsiwn mwy modern, gan ennill poblogrwydd yn ecosystem Kubernetes). Felly, ni chafodd y gorchmynion hyn eu datblygu ymhellach yn kubectl.
Creu, cael, disodli a dileu gweithrediadau
Gyda cynradd creu mae'n syml: anfonwch y maniffest i'r llawdriniaeth create kube api ac mae'r adnodd wedi'i greu. Gellir storio cynrychiolaeth YAML y maniffest yn Git a'i greu gan ddefnyddio'r gorchymyn kubectl create -f manifest.yaml.
С tynnu hefyd symlaf: amnewid yr un manifest.yaml o Git i dîm kubectl delete -f manifest.yaml.
Gweithredu replace yn eich galluogi i ddisodli'r ffurfweddiad adnoddau yn llwyr gydag un newydd, heb ail-greu'r adnodd. Mae hyn yn golygu, cyn gwneud newid i adnodd, ei bod yn rhesymegol cwestiynu'r fersiwn gyfredol gyda'r gweithrediad get, ei newid a'i ddiweddaru gyda'r llawdriniaeth replace. apiserver kube wedi'i adeiladu i mewn ac, os ar ôl llawdriniaeth get y gwrthrych wedi newid, yna y llawdriniaeth replace ni fydd yn gweithio.
I storio'r cyfluniad yn Git a'i ddiweddaru gan ddefnyddio disodli, mae angen i chi wneud y llawdriniaeth get, uno'r ffurfwedd o Git â'r hyn a gawsom, a gweithredu replace. Yn ddiofyn, mae kubectl ond yn caniatáu ichi ddefnyddio'r gorchymyn kubectl replace -f manifest.yamllle manifest.yaml — maniffest sydd eisoes wedi'i baratoi'n llawn (yn ein hachos ni, wedi'i gyfuno) y mae angen ei osod. Mae'n ymddangos bod angen i'r defnyddiwr weithredu maniffestau uno, ac nid yw hwn yn fater dibwys ...
Mae'n werth nodi hefyd, er manifest.yaml ac yn cael ei storio yn Git, ni allwn wybod ymlaen llaw a oes angen creu gwrthrych neu ei ddiweddaru - rhaid i feddalwedd defnyddwyr wneud hyn.
Cyfanswm: gallwn adeiladu cyflwyniad parhaus defnyddio creu, disodli a dileu yn unig, gan sicrhau bod y ffurfwedd seilwaith yn cael ei storio yn Git ynghyd â'r cod a CI/CD cyfleus?
Mewn egwyddor, gallwn... Ar gyfer hyn bydd angen i chi weithredu'r gweithrediad uno maniffestos a rhyw fath o rwymiad sy'n:
- gwirio presenoldeb gwrthrych yn y clwstwr,
- cyflawni creu adnoddau cychwynnol,
- ei ddiweddaru neu ei ddileu.
Wrth ddiweddaru, nodwch hynny efallai bod yr adnodd wedi newid ers diwethaf get a thrin achos cloi optimistaidd yn awtomatig - gwnewch ymdrechion diweddaru dro ar ôl tro.
Fodd bynnag, pam ailddyfeisio'r olwyn pan fydd kube-apiserver yn cynnig ffordd arall o ddiweddaru adnoddau: y llawdriniaeth patch, sy'n lleddfu'r defnyddiwr o rai o'r problemau a ddisgrifir?
Patch
Nawr rydyn ni'n cyrraedd y clytiau.
Clytiau yw'r brif ffordd o gymhwyso newidiadau i wrthrychau presennol yn Kubernetes. Gweithrediad patch mae'n gweithio fel hyn:
- mae angen i'r defnyddiwr kube-apiserver anfon clwt ar ffurf JSON a nodi'r gwrthrych,
- a bydd apiserver ei hun yn delio â chyflwr presennol y gwrthrych ac yn dod ag ef i'r ffurf ofynnol.
Nid oes angen cloi optimistaidd yn yr achos hwn. Mae'r llawdriniaeth hon yn fwy datganol na llawdriniaeth arall, er y gall ymddangos fel arall ar y dechrau.
Felly:
- defnyddio llawdriniaeth
createrydym yn creu gwrthrych yn ôl y maniffest o Git, - gyda help
delete— dileu os nad oes angen y gwrthrych mwyach, - gyda help
patch— rydym yn newid y gwrthrych, gan ddod ag ef i'r ffurf a ddisgrifir yn Git.
Fodd bynnag, i wneud hyn, mae angen i chi greu darn cywir!
Sut mae clytiau'n gweithio yn Helm 2: 2-way-uno
Pan fyddwch chi'n gosod datganiad am y tro cyntaf, mae Helm yn perfformio'r llawdriniaeth create ar gyfer adnoddau siart.
Wrth ddiweddaru datganiad Helm ar gyfer pob adnodd:
- yn ystyried y darn rhwng y fersiwn adnoddau o'r siart blaenorol a'r fersiwn siart gyfredol,
- yn cymhwyso'r darn hwn.
Byddwn yn galw'r darn hwn Clytiau uno 2-ffordd, oherwydd bod 2 faniffesto yn ymwneud â’i greu:
- adnoddau amlwg o'r datganiad blaenorol,
- adnoddau amlwg o'r adnodd presennol.
Wrth ddileu gweithrediad delete yn kube apiserver yn cael ei alw am adnoddau a ddatganwyd yn y datganiad blaenorol, ond heb eu datgan yn yr un cyfredol.
Mae gan y dull patsh uno 2 ffordd broblem: mae'n arwain at allan o gydamseriad â chyflwr gwirioneddol yr adnodd yn y clwstwr a'r maniffest yn Git.
Darlun o'r broblem gydag enghraifft
- Yn Git, mae siart yn storio maniffest yn y maes
imageMaterion lleoliubuntu:18.04. - Defnyddiwr trwy
kubectl editnewid gwerth y maes hwn iubuntu:19.04. - Wrth ail-leoli'r siart Helm nid yw'n cynhyrchu clwt, oherwydd y maes
imageyn y fersiwn flaenorol o'r datganiad ac yn y siart cyfredol yr un fath. - Ar ôl ail-leoli
imageolionubuntu:19.04, er bod y siart yn dweudubuntu:18.04.
Cawsom ddadgydamseru a cholli datganolrwydd.
Beth yw adnodd wedi'i gydamseru?
A siarad yn gyffredinol cyflawn Mae'n amhosibl cael cyfatebiaeth rhwng yr adnodd a amlygir mewn clwstwr rhedeg a'r maniffest gan Git. Oherwydd mewn maniffest go iawn gall fod anodiadau/labeli gwasanaeth, cynwysyddion ychwanegol a data arall sy'n cael eu hychwanegu a'u tynnu o'r adnodd yn ddeinamig gan rai rheolwyr. Ni allwn ac nid ydym am gadw'r data hwn yn Git. Fodd bynnag, rydym am i'r meysydd a nodwyd gennym yn benodol yn Git gymryd y gwerthoedd priodol ar eu cyflwyno.
Mae'n troi allan mor gyffredinol rheol adnoddau cydamserol: wrth gyflwyno adnodd, gallwch newid neu ddileu dim ond y meysydd hynny sydd wedi'u nodi'n benodol yn y maniffest o Git (neu a nodwyd mewn fersiwn flaenorol ac sydd bellach wedi'u dileu).
Clytiau uno 3-ffordd
Prif syniad : rydym yn cynhyrchu darn rhwng y fersiwn gymhwysol olaf o'r maniffest o Git a'r fersiwn darged o'r maniffest o Git, gan ystyried y fersiwn gyfredol o'r maniffest o'r clwstwr rhedeg. Rhaid i'r darn canlyniadol gydymffurfio â'r rheol adnoddau cydamserol:
- meysydd newydd a ychwanegir at y fersiwn targed yn cael eu hychwanegu gan ddefnyddio clwt;
- mae meysydd sydd eisoes yn bodoli yn y fersiwn gymhwysol ddiwethaf ac nad ydynt yn bodoli yn y fersiwn darged yn cael eu hailosod gan ddefnyddio clwt;
- mae meysydd yn fersiwn gyfredol y gwrthrych sy'n wahanol i fersiwn darged y maniffest yn cael eu diweddaru gan ddefnyddio'r clwt.
Ar yr egwyddor hon y mae'n cynhyrchu clytiau kubectl apply:
- bod y fersiwn gymhwysol olaf o'r maniffest yn cael ei storio yn anodiad y gwrthrych ei hun,
- targed - wedi'i gymryd o'r ffeil YAML penodedig,
- mae'r un presennol yn dod o glwstwr rhedeg.
Nawr ein bod ni wedi datrys y ddamcaniaeth, mae'n bryd dweud wrthych chi beth wnaethon ni yn werf.
Cymhwyso newidiadau i werff
Yn flaenorol, roedd wefr, fel Helm 2, yn defnyddio clytiau 2-ffordd uno.
Clwt atgyweirio
Er mwyn newid i fath newydd o glytiau - 3-way-merge - y cam cyntaf fe wnaethom gyflwyno'r hyn a elwir yn atgyweirio clytiau.
Wrth ei ddefnyddio, defnyddir clwt 2-ffordd-uno safonol, ond mae werf hefyd yn cynhyrchu clwt a fyddai'n cydamseru cyflwr gwirioneddol yr adnodd â'r hyn sydd wedi'i ysgrifennu yn Git (crëir clwt o'r fath gan ddefnyddio'r un rheol adnoddau cydamserol a ddisgrifir uchod) .
Os bydd dad-gydamseriad yn digwydd, ar ddiwedd y gosodiad mae'r defnyddiwr yn derbyn RHYBUDD gyda neges gyfatebol a chlwt y mae'n rhaid ei gymhwyso i ddod â'r adnodd i ffurf wedi'i chydamseru. Mae'r darn hwn hefyd wedi'i gofnodi mewn anodiad arbennig werf.io/repair-patch. Tybir bod dwylo'r defnyddiwr ei hun a fydd yn cymhwyso'r clwt hwn: ni fydd werff yn ei gymhwyso o gwbl.
Mae cynhyrchu clytiau atgyweirio yn fesur dros dro sy'n eich galluogi i brofi creu clytiau yn seiliedig ar yr egwyddor uno 3-ffordd, ond nid ydynt yn cymhwyso'r clytiau hyn yn awtomatig. Ar hyn o bryd, mae'r modd gweithredu hwn wedi'i alluogi yn ddiofyn.
Clytia 3-ffordd-uno yn unig ar gyfer datganiadau newydd
Gan ddechrau Rhagfyr 1, 2019, mae fersiynau beta ac alffa o werff yn dechrau yn ddiofyn defnyddio clytiau 3-cyfuno 2-ffordd llawn i gymhwyso newidiadau yn unig i ollyngiadau Helm newydd a gyflwynir trwy werff. Bydd datganiadau presennol yn parhau i ddefnyddio'r dull clytiau atgyweirio XNUMX-ffordd-uno +.
Gellir galluogi'r modd gweithredu hwn yn benodol trwy osod WERF_THREE_WAY_MERGE_MODE=onlyNewReleases yn awr.
Nodyn: ymddangosodd y nodwedd yn werf dros sawl datganiad: yn y sianel alffa daeth yn barod gyda fersiwn , ac yn y sianel beta - gyda .
Clytia 3-ffordd-uno ar gyfer pob datganiad
Gan ddechrau Rhagfyr 15, 2019, mae fersiynau beta ac alffa o werf yn dechrau defnyddio clytiau uno 3-ffordd llawn yn ddiofyn i gymhwyso newidiadau i bob datganiad.
Gellir galluogi'r modd gweithredu hwn yn benodol trwy osod WERF_THREE_WAY_MERGE_MODE=enabled yn awr.
Beth i'w wneud â graddio adnoddau'n awtomatig?
Mae 2 fath o raddfa awtomatig yn Kubernetes: HPA (llorweddol) a VPA (fertigol).
Mae llorweddol yn dewis nifer y replicas yn awtomatig, fertigol - nifer yr adnoddau. Mae nifer y copïau a'r gofynion adnoddau wedi'u nodi yn y maniffest adnoddau (gweler y Maniffest Adnoddau). spec.replicas neu spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и ).
Problem: os yw defnyddiwr yn ffurfweddu adnodd mewn siart fel ei fod yn pennu gwerthoedd penodol ar gyfer adnoddau neu atgynyrchiadau a bod awto-sgalers yn cael eu galluogi ar gyfer yr adnodd hwn, yna gyda phob werf lleoli bydd yn ailosod y gwerthoedd hyn i'r hyn sydd wedi'i ysgrifennu ym maniffest y siart .
Mae dau ateb i'r broblem. I ddechrau, mae'n well osgoi nodi gwerthoedd awtoraddol yn benodol ym maniffest y siart. Os nad yw'r opsiwn hwn yn addas am ryw reswm (er enghraifft, oherwydd ei bod yn gyfleus gosod terfynau adnoddau cychwynnol a nifer y copïau yn y siart), yna mae werf yn cynnig yr anodiadau canlynol:
-
werf.io/set-replicas-only-on-creation=true -
werf.io/set-resources-only-on-creation=true
Os oes anodiad o'r fath yn bresennol, ni fydd werf yn ailosod y gwerthoedd cyfatebol ar bob gosodiad, ond dim ond pan fydd yr adnodd yn cael ei greu i ddechrau y bydd yn eu gosod.
Am ragor o fanylion, gweler dogfennaeth y prosiect ar gyfer и .
Gwahardd defnyddio clwt 3-cyfuno
Gall y defnyddiwr ar hyn o bryd wahardd y defnydd o glytiau newydd mewn werff gan ddefnyddio newidyn amgylchedd WERF_THREE_WAY_MERGE_MODE=disabled. Fodd bynnag, gan ddechrau O 1 Mawrth, 2020, ni fydd y gwaharddiad hwn yn berthnasol mwyach. a dim ond clytiau 3-cyfuno fydd yn bosibl eu defnyddio.
Mabwysiadu adnoddau yn werff
Roedd meistroli'r dull o gymhwyso newidiadau gyda chlytiau uno 3-ffordd yn ein galluogi i weithredu nodwedd o'r fath ar unwaith fel mabwysiadu adnoddau sy'n bodoli yn y clwstwr i ryddhad Helm.
Mae gan Helm 2 broblem: ni allwch ychwanegu adnodd at faniffestau siart sydd eisoes yn bodoli yn y clwstwr heb ail-greu’r adnodd hwn o’r dechrau (gweler. , ). Dysgon ni werf i dderbyn adnoddau presennol i'w rhyddhau. I wneud hyn, mae angen i chi osod anodiad ar fersiwn gyfredol yr adnodd o'r clwstwr rhedeg (er enghraifft, defnyddio kubectl edit):
"werf.io/allow-adoption-by-release": RELEASE_NAMENawr mae angen disgrifio'r adnodd yn y siart a'r tro nesaf y bydd werf yn defnyddio datganiad gyda'r enw priodol, bydd yr adnodd presennol yn cael ei dderbyn i'r datganiad hwn ac yn parhau o dan ei reolaeth. Ar ben hynny, yn y broses o dderbyn adnodd i'w ryddhau, bydd werf yn dod â chyflwr presennol yr adnodd o'r clwstwr rhedeg i'r cyflwr a ddisgrifir yn y siart, gan ddefnyddio'r un clytiau 3-ffordd-uno a'r rheol adnoddau cydamserol.
Nodyn: gosod WERF_THREE_WAY_MERGE_MODE nid yw'n effeithio ar fabwysiadu adnoddau - yn achos mabwysiadu, defnyddir darn 3-ffordd uno bob amser.
Manylion - yn .
Casgliadau a chynlluniau ar gyfer y dyfodol
Rwy'n gobeithio ar ôl yr erthygl hon ei bod wedi dod yn gliriach beth yw clytiau 3-ffordd-uno a pham y daethant atynt. O safbwynt ymarferol ar ddatblygiad y prosiect werff, roedd eu gweithredu yn gam arall tuag at wella'r defnydd tebyg i Helm. Nawr gallwch chi anghofio am y problemau gyda chydamseru cyfluniad, a gododd yn aml wrth ddefnyddio Helm 2. Ar yr un pryd, ychwanegwyd nodwedd ddefnyddiol newydd o fabwysiadu adnoddau Kubernetes sydd eisoes wedi'u llwytho i lawr at y datganiad Helm.
Mae rhai problemau a heriau o hyd gyda gosodiadau tebyg i Helm, megis defnyddio templedi Go, y byddwn yn parhau i fynd i'r afael â hwy.
Mae gwybodaeth am ddulliau diweddaru adnoddau a mabwysiadu hefyd ar gael yn .
Llyw 3
Teilwng o sylw arbennig dim ond y diwrnod o'r blaen fersiwn fawr newydd o Helm - v3 - sydd hefyd yn defnyddio clytiau 3-ffordd-uno ac yn cael gwared ar Tiller. Mae'r fersiwn newydd o Helm yn gofyn gosodiadau presennol i'w trosi i'r fformat storio rhyddhau newydd.
Ar hyn o bryd mae Werf, o'i ran ef, wedi cael gwared ar ddefnyddio Tiller, wedi newid i uno 3-ffordd ac wedi ychwanegu , tra'n parhau i fod yn gydnaws â gosodiadau Helm 2 presennol (nid oes angen gweithredu unrhyw sgriptiau mudo). Felly, nes bod werf yn newid i Helm 3, nid yw defnyddwyr werf yn colli prif fanteision Helm 3 dros Helm 2 (mae gan werf nhw hefyd).
Fodd bynnag, mae newid werff i sylfaen cod Helm 3 yn anochel a bydd yn digwydd yn y dyfodol agos. Mae'n debyg mai werf 1.1 neu werf 1.2 fydd hwn (ar hyn o bryd, prif fersiwn werf yw 1.0; am ragor o wybodaeth am y ddyfais fersiynu werf, gweler ). Yn ystod yr amser hwn, bydd Helm 3 yn cael amser i sefydlogi.
PS
Darllenwch hefyd ar ein blog:
- Cyfres o nodiadau am ddatblygiadau arloesol mewn werf:
- «";
- «";
- «'.
- «";
- «";
- «'.
Ffynhonnell: hab.com