Ang dugay namong gipaabot (ug dili lang kami) nahitabo: , ang among Open Source utility para sa paghimo og mga aplikasyon ug paghatud niini sa Kubernetes, karon nagsuporta sa pagpadapat sa mga kausaban gamit ang 3-way merge patch! Dugang pa niini, posible ang pagsagop sa kasamtangan nga mga kapanguhaan sa K8 ngadto sa mga pagpagawas sa Helm nga dili matukod pag-usab kini nga mga kapanguhaan.
Kon kini mubo kaayo, unya atong ibutang WERF_THREE_WAY_MERGE=enabled - nakakuha kami deployment "sama sa kubectl apply", compatible sa kasamtangan nga Helm 2 installations ug bisan sa usa ka gamay pa.
Apan magsugod kita sa teorya: unsa gyud ang 3-way-merge nga mga patch, giunsa sa mga tawo paghimo ang pamaagi sa paghimo niini, ug ngano nga kini hinungdanon sa mga proseso sa CI / CD nga adunay imprastraktura nga nakabase sa Kubernetes? Ug pagkahuman niana, tan-awon naton kung unsa ang 3-way-merge sa werf, kung unsang mga mode ang gigamit nga default ug kung giunsa kini pagdumala.
Unsa ang 3-way-merge patch?
Mao nga, magsugod kita sa tahas sa paglansad sa mga kapanguhaan nga gihulagway sa YAML nga gipakita sa Kubernetes.
Aron magtrabaho uban sa mga kapanguhaan, ang Kubernetes API nagtanyag sa mosunod nga mga batakang operasyon: paghimo, pag-patch, pag-ilis ug pagtangtang. Gituohan nga sa ilang tabang gikinahanglan ang paghimo sa usa ka kombenyente nga padayon nga paglusad sa mga kahinguhaan sa cluster. Giunsa?
kubectl imperative commands
Ang unang pamaagi sa pagdumala sa mga butang sa Kubernetes mao ang paggamit sa kubectl imperative commands sa paghimo, pag-usab, ug pagtangtang niadtong mga butanga. Sa yanong pagkasulti:
- team
kubectl runmahimo nimong ipadagan ang Deployment o Job:kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE - team
kubectl scale- usba ang gidaghanon sa mga replika:kubectl scale --replicas=3 deployment/mysql - ug uban pa.
Kini nga pamaagi daw kombenyente sa unang pagtan-aw. Apan adunay mga problema:
- Lisod na automate.
- Sa unsang paagi nga nagpakita sa configuration sa Git? Giunsa pagrepaso ang mga pagbag-o nga nahitabo sa cluster?
- Unsaon paghatag reproducibility mga configuration sa pagsugod pag-usab?
- ...
Klaro nga kini nga pamaagi dili mohaum sa pagtipig sa aplikasyon ug imprastraktura ingon code (IaC; o bisan isip usa ka mas modernong opsyon, nga nahimong popular sa Kubernetes ecosystem). Busa, kini nga mga sugo wala makadawat og dugang nga kalamboan sa kubectl.
Paghimo, pagkuha, pag-ilis ug pagtangtang sa mga operasyon
Uban sa panguna paglalang kini yano: ipadala ang manifest sa operasyon create kube api ug ang kapanguhaan nahimo na. Ang YAML nga representasyon sa manifest mahimong tipigan sa Git ug himoon gamit ang command kubectl create -f manifest.yaml.
Π‘ pagtangtang yano usab: ilisan ang parehas manifest.yaml gikan sa Git ngadto sa team kubectl delete -f manifest.yaml.
Operasyon replace nagtugot kanimo sa hingpit nga pag-ilis sa resource configuration sa usa ka bag-o, nga walay paghimo pag-usab sa kapanguhaan. Kini nagpasabot nga sa dili pa maghimo ug kausaban sa usa ka kapanguhaan, makatarunganon nga ipangutana ang kasamtangan nga bersyon sa operasyon get, usba kini ug i-update kini sa operasyon replace. Ang kube apiserver gitukod sa ug, kon human sa operasyon get ang butang nausab, dayon ang operasyon replace dili kini molihok.
Aron tipigan ang configuration sa Git ug i-update kini gamit ang replace, kinahanglan nimo nga buhaton ang operasyon get, isagol ang config gikan sa Git sa among nadawat, ug i-execute replace. Sa kasagaran, ang kubectl nagtugot lamang kanimo sa paggamit sa sugo kubectl replace -f manifest.yamldiin manifest.yaml - usa ka hingpit nga andam (sa among kaso, gihiusa) nga pagpakita nga kinahanglan i-install. Kini nahimo nga ang tiggamit kinahanglan nga ipatuman ang paghiusa nga mga pagpakita, ug kini usa ka dili hinungdanon nga butang ...
Angay usab nga hinumdoman nga bisan pa manifest.yaml ug gitipigan sa Git, dili nato mahibal-an daan kung gikinahanglan ba ang paghimo sa usa ka butang o pag-update niini - kini kinahanglan nga buhaton sa software sa user.
Total: makahimo ba kita sa usa ka padayon nga rollout gamit lang ang paghimo, pag-ilis ug pagtangtang, pagsiguro nga ang configuration sa imprastraktura gitipigan sa Git kauban ang code ug kombenyente nga CI / CD?
Sa prinsipyo, mahimo naton ... Alang niini kinahanglan nimo nga ipatuman ang operasyon sa paghiusa mga manifesto ug usa ka matang sa pagbugkos nga:
- nagsusi sa presensya sa usa ka butang sa cluster,
- naghimo sa inisyal nga paghimo sa kapanguhaan,
- pag-update o pagtangtang niini.
Kung nag-update, palihug timan-i kana ang kahinguhaan mahimong nausab sukad sa miaging get ug awtomatiko nga pagdumala sa kaso sa malaumon nga pag-lock - paghimo og balik-balik nga pagsulay sa pag-update.
Apan, nganong reinvent ang ligid sa diha nga ang kube-apiserver nagtanyag og laing paagi sa pag-update sa mga kapanguhaan: ang operasyon patch, nga makapahupay sa tiggamit sa pipila sa gihulagway nga mga problema?
patch
Karon kita moadto sa mga patsa.
Ang mga patch mao ang nag-unang paagi sa paggamit sa mga pagbag-o sa mga butang nga anaa sa Kubernetes. Operasyon patch kini nagtrabaho sama niini:
- ang kube-apiserver user kinahanglan nga magpadala usa ka patch sa JSON nga porma ug ipiho ang butang,
- ug ang apiserver mismo ang mag-atubang sa kasamtangan nga kahimtang sa butang ug dad-on kini sa gikinahanglan nga porma.
Dili kinahanglan ang pagkamalaumon nga pag-lock sa kini nga kaso. Kini nga operasyon mas deklaratibo kay sa pag-ilis, bisan tuod sa sinugdan kini daw sa laing paagi.
Sa niini nga paagi:
- gamit ang usa ka operasyon
createnaghimo kami usa ka butang sumala sa gipakita gikan sa Git, - sa panabang
delete- kuhaa kung ang butang dili na kinahanglan, - sa panabang
patch- gibag-o namon ang butang, gidala kini sa porma nga gihulagway sa Git.
Bisan pa, aron mahimo kini, kinahanglan nimo nga maghimo husto nga patch!
Giunsa pagtrabaho ang mga patch sa Helm 2: 2-way-merge
Sa una nimong pag-instalar og release, ang Helm maoy mohimo sa operasyon create alang sa mga kapanguhaan sa tsart.
Kung nag-update sa usa ka pagpagawas sa Helm para sa matag kapanguhaan:
- gikonsiderar ang patch tali sa bersyon sa kapanguhaan gikan sa miaging tsart ug sa karon nga bersyon sa tsart,
- magamit kini nga patch.
Tawgon nato kini nga patch 2-way merge patch, tungod kay 2 ka manifesto ang nalangkit sa paghimo niini:
- resource manifest gikan sa miaging pagpagawas,
- resource manifest gikan sa kasamtangan nga kapanguhaan.
Sa pagtangtang sa operasyon delete sa kube apiserver gitawag alang sa mga kapanguhaan nga gipahayag sa miaging pagpagawas, apan wala gipahayag sa karon.
Ang 2 nga paagi sa paghiusa sa patch nga pamaagi adunay problema: kini padulong sa wala sa sync sa tinuod nga kahimtang sa kapanguhaan sa cluster ug ang manifest sa Git.
Ilustrasyon sa problema uban sa usa ka pananglitan
- Sa Git, ang usa ka tsart nagtipig sa usa ka manifest diin ang field
imageImportante ang deploymentubuntu:18.04. - User pinaagi sa
kubectl editgiusab ang bili niini nga field ngadto saubuntu:19.04. - Kung i-deploy pag-usab ang Helm chart dili makamugna og patch, tungod kay ang uma
imagesa miaging bersyon sa pagpagawas ug sa kasamtangan nga tsart pareho ra. - Human sa pag-deploy pag-usab
imagenagpabilinubuntu:19.04, bisan tuod ang tsart nag-ingonubuntu:18.04.
Nakuha namo ang desynchronization ug nawala ang pagkadeklara.
Unsa ang usa ka synchronized nga kapanguhaan?
Sa kinatibuk-an kompleto Imposible nga makakuha usa ka tugma tali sa resource manifest sa usa ka running cluster ug sa manifest gikan sa Git. Tungod kay sa usa ka tinuod nga pagpakita mahimo nga adunay mga anotasyon sa serbisyo / label, dugang nga mga sudlanan ug uban pang mga datos nga gidugang ug gikuha gikan sa kapanguhaan nga dinamiko sa pipila nga mga tigkontrol. Dili namo mahimo ug dili gusto nga itago kini nga datos sa Git. Bisan pa, gusto namon ang mga natad nga tin-aw namon nga gipiho sa Git nga makuha ang angay nga mga kantidad pagkahuman sa paglansad.
Kini nahimo nga kinatibuk-an gi-synchronize nga lagda sa kapanguhaan: sa dihang maglunsad og kahinguhaan, mahimo nimong usbon o papason ang mga field lang nga klarong gipiho sa manifest gikan sa Git (o gipiho sa miaging bersyon ug natangtang na karon).
3-way merge patch
Pangunang ideya : nagmugna kami og patch tali sa katapusang gi-apply nga bersyon sa manifest gikan sa Git ug sa target nga bersyon sa manifest gikan sa Git, nga gikonsiderar ang kasamtangan nga bersyon sa manifest gikan sa running cluster. Ang resulta nga patch kinahanglang mosunod sa gi-synchronize nga resource rule:
- bag-ong mga natad nga gidugang sa target nga bersyon gidugang gamit ang usa ka patch;
- ang naa na kaniadto nga mga natad sa katapusan nga gi-apply nga bersyon ug wala sa target nga bersyon gi-reset gamit ang usa ka patch;
- Ang mga natad sa kasamtangan nga bersyon sa butang nga lahi sa target nga bersyon sa manifest gi-update gamit ang patch.
Sa kini nga prinsipyo nga kini nagpatunghag mga patch kubectl apply:
- ang katapusang gipadapat nga bersyon sa manifest gitipigan sa anotasyon sa butang mismo,
- target - gikuha gikan sa piho nga YAML file,
- ang kasamtangan gikan sa usa ka running cluster.
Karon nga among nahan-ay ang teorya, panahon na nga isulti kanimo kung unsa ang among gibuhat sa werf.
Pagpadapat sa mga pagbag-o sa werf
Kaniadto, ang werf, sama sa Helm 2, migamit ug 2-way-merge nga mga patch.
Pag-ayo sa patch
Aron makabalhin sa usa ka bag-ong tipo sa mga patch - 3-way-merge - ang una nga lakang nga among gipaila ang gitawag nga pag-ayo sa mga patch.
Kung nag-deploy, gigamit ang usa ka standard nga 2-way-merge nga patch, apan ang werf dugang nga nagmugna usa ka patch nga mag-synchronize sa tinuud nga kahimtang sa kapanguhaan sa kung unsa ang nasulat sa Git (ang ingon nga patch gihimo gamit ang parehas nga gi-synchronize nga lagda sa kapanguhaan nga gihulagway sa ibabaw) .
Kung mahitabo ang desynchronization, sa katapusan sa deployment makadawat ang user og WARNING nga adunay katugbang nga mensahe ug usa ka patch nga kinahanglan i-apply aron madala ang resource sa usa ka synchronized nga porma. Kini nga patch girekord usab sa usa ka espesyal nga anotasyon werf.io/repair-patch. Gituohan nga ang mga kamot sa tiggamit sa iyang kaugalingon i-apply kini nga patch: dili kini magamit sa werf.
Ang paghimo og mga patch sa pag-ayo usa ka temporaryo nga sukod nga nagtugot kanimo sa tinuud nga pagsulay sa paghimo sa mga patch base sa 3-way-merge nga prinsipyo, apan dili awtomatik nga magamit kini nga mga patch. Sa pagkakaron, kini nga operating mode gipalihok pinaagi sa default.
3-way-merge nga patch para lang sa mga bag-ong release
Sugod sa Disyembre 1, 2019, nagsugod ang beta ug alpha nga bersyon sa werf pinaagi sa default gamita ang bug-os nga 3-way-merge nga mga patch aron magamit ang mga pagbag-o sa mga bag-ong pagpagawas sa Helm nga gilusad pinaagi sa werf. Ang mga kasamtangan nga pagpagawas magpadayon sa paggamit sa 2-way-merge + repair patch approach.
Kini nga operating mode mahimong ma-enable sa dayag pinaagi sa pag-set WERF_THREE_WAY_MERGE_MODE=onlyNewReleases karon.
ΠΡΠΈΠΌΠ΅ΡΠ°Π½ΠΈΠ΅: ang bahin nagpakita sa werf sa daghang mga pagpagawas: sa alpha channel nahimo kini nga andam sa bersyon , ug sa beta channel - uban sa .
3-way-merge nga patch para sa tanang pagpagawas
Sugod sa Disyembre 15, 2019, ang beta ug alpha nga bersyon sa werf nagsugod sa paggamit sa bug-os nga 3-way-merge nga mga patch nga default aron magamit ang mga pagbag-o sa tanan nga gipagawas.
Kini nga operating mode mahimong ma-enable sa dayag pinaagi sa pag-set WERF_THREE_WAY_MERGE_MODE=enabled karon.
Unsa ang buhaton sa resource autoscaling?
Adunay 2 ka matang sa autoscaling sa Kubernetes: HPA (horizontal) ug VPA (vertical).
Awtomatikong gipili sa Horizontal ang gidaghanon sa mga replika, bertikal - ang gidaghanon sa mga kahinguhaan. Ang gidaghanon sa mga replika ug mga kinahanglanon sa kahinguhaan gipiho sa resource manifest (tan-awa ang Resource Manifest). spec.replicas o spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory ΠΈ ).
Problema: kung ang usa ka tiggamit mag-configure sa usa ka kapanguhaan sa usa ka tsart aron kini magtino sa piho nga mga kantidad alang sa mga kahinguhaan o mga replika ug ang mga autoscaler gipagana alang niini nga kapanguhaan, unya sa matag pag-deploy werf i-reset kini nga mga kantidad sa kung unsa ang nahisulat sa gipakita sa tsart .
Adunay duha ka solusyon sa problema. Sa pagsugod, labing maayo nga likayan ang tin-aw nga pagpiho sa mga autoscaled nga kantidad sa gipakita sa tsart. Kung kini nga kapilian dili angay alang sa usa ka hinungdan (pananglitan, tungod kay kombenyente ang pagtakda sa mga inisyal nga mga limitasyon sa kapanguhaan ug ang gidaghanon sa mga replika sa tsart), nan ang werf nagtanyag sa mosunod nga mga anotasyon:
-
werf.io/set-replicas-only-on-creation=true -
werf.io/set-resources-only-on-creation=true
Kung naa ang ingon nga annotation, dili i-reset sa werf ang katugbang nga mga kantidad sa matag pag-deploy, apan itakda ra kini kung ang kapanguhaan sa sinugdan gihimo.
Alang sa dugang nga mga detalye, tan-awa ang dokumentasyon sa proyekto para sa ΠΈ .
Idili ang paggamit sa 3-way-merge patch
Mahimong idili karon sa user ang paggamit sa bag-ong mga patch sa werf gamit ang environment variable WERF_THREE_WAY_MERGE_MODE=disabled. Apan, nagsugod Gikan sa Marso 1, 2020, kini nga pagdili dili na magamit. ug mahimo ra nga gamiton ang 3-way-merge nga mga patch.
Pagsagop sa mga kahinguhaan sa werf
Ang pag-master sa pamaagi sa pag-apply sa mga pagbag-o gamit ang 3-way-merge nga mga patch nagtugot kanamo nga ipatuman dayon ang ingon nga bahin sama sa pagsagop sa mga kapanguhaan nga naa sa cluster ngadto sa pagpagawas sa Helm.
Ang Helm 2 adunay problema: dili ka makadugang usa ka kapanguhaan sa mga pagpakita sa tsart nga naa na sa cluster nga wala gi-recreate kini nga kapanguhaan gikan sa wala (tan-awa. , ). Gitudloan namo ang werf sa pagdawat sa kasamtangan nga mga kapanguhaan alang sa pagpagawas. Aron mahimo kini, kinahanglan nimo nga i-install ang usa ka anotasyon sa karon nga bersyon sa kapanguhaan gikan sa nagdagan nga cluster (pananglitan, gamit ang kubectl edit):
"werf.io/allow-adoption-by-release": RELEASE_NAMEKaron ang kapanguhaan kinahanglan nga ihulagway sa tsart ug sa sunod higayon nga ang werf mag-deploy sa usa ka pagpagawas nga adunay angay nga ngalan, ang kasamtangan nga kapanguhaan madawat sa kini nga pagpagawas ug magpabilin nga kontrolado niini. Dugang pa, sa proseso sa pagdawat sa usa ka kapanguhaan alang sa pagpagawas, ang werf magdala sa kasamtangan nga kahimtang sa kapanguhaan gikan sa running cluster ngadto sa estado nga gihulagway sa tsart, gamit ang parehas nga 3-way-merge nga mga patch ug ang gi-synchronize nga resource rule.
ΠΡΠΈΠΌΠ΅ΡΠ°Π½ΠΈΠ΅: setting WERF_THREE_WAY_MERGE_MODE dili makaapekto sa pagsagop sa mga kahinguhaan - sa kaso sa pagsagop, kanunay nga gigamit ang 3-way-merge patch.
Mga Detalye - sa .
Mga konklusyon ug mga plano sa umaabot
Nanghinaut ko nga pagkahuman sa kini nga artikulo nahimong mas klaro kung unsa ang 3-way-merge nga mga patch ug kung ngano nga kini naabut sa kanila. Gikan sa usa ka praktikal nga punto sa pagtan-aw sa pag-uswag sa proyekto sa werf, ang ilang pagpatuman usa pa ka lakang padulong sa pagpaayo sa pag-deploy nga sama sa Helm. Karon mahimo nimong kalimtan ang bahin sa mga problema sa pag-synchronize sa pag-configure nga kanunay nga mitungha kung gigamit ang Helm 2. Sa samang higayon, usa ka bag-ong mapuslanon nga bahin sa pagsagop sa na-download na nga mga kapanguhaan sa Kubernetes gidugang sa pagpagawas sa Helm.
Adunay pa pipila ka mga isyu ug mga hagit sa mga pag-deploy nga sama sa Helm, sama sa paggamit sa mga template sa Go, nga padayon namon nga atubangon.
Ang kasayuran bahin sa mga pamaagi sa pag-update sa kapanguhaan ug pagsagop makita usab sa .
Helmo 3
Takus sa espesyal nga nota sa miaging adlaw usa ka bag-ong mayor nga bersyon sa Helm - v3 - nga naggamit usab sa 3-way-merge nga mga patch ug nagtangtang sa Tiller. Ang bag-ong bersyon sa Helm nagkinahanglan anaa na nga mga instalasyon aron mabag-o kini ngadto sa bag-ong format sa pagtipig sa pagpagawas.
Ang Werf, sa bahin niini, sa pagkakaron nagwagtang sa paggamit sa Tiller, gibalhin ngadto sa 3-way-merge ug gidugang , samtang nagpabilin nga compatible sa kasamtangan nga Helm 2 installations (walay migration scripts ang kinahanglang ipatuman). Busa, hangtud nga ang werf mobalhin ngadto sa Helm 3, ang mga tiggamit sa werf dili mawad-an sa mga nag-unang bentaha sa Helm 3 kay sa Helm 2 (werf usab adunay kanila).
Bisan pa, ang pagbalhin sa werf sa Helm 3 codebase dili kalikayan ug mahitabo sa umaabot nga umaabot. Tingali kini mao ang werf 1.1 o werf 1.2 (sa pagkakaron, ang nag-unang bersyon sa werf kay 1.0; alang sa dugang nga impormasyon mahitungod sa werf versioning device, tan-awa ). Niini nga panahon, ang Helm 3 adunay panahon sa pag-stabilize.
PS
Basaha usab sa among blog:
- Usa ka serye sa mga nota bahin sa mga inobasyon sa werf:
- Β«";
- Β«";
- Β«".
- Β«";
- Β«";
- Β«".
Source: www.habr.com