Guk (eta ez gu bakarrik) aspalditik itxaroten genuena gertatu zen: , aplikazioak eraikitzeko eta Kubernetesera bidaltzeko kode irekiko gure utilitatea, orain aldaketak aplikatzea onartzen du 3 norabideko bateratze-adabakiak erabiliz! Honetaz gain, posible da lehendik dauden K8s baliabideak Helm bertsioetan hartzea baliabide horiek berreraiki gabe.
Oso laburra bada, orduan jartzen dugu WERF_THREE_WAY_MERGE=enabled β hedapena lortzen dugu "in kubectl apply", lehendik dauden Helm 2 instalazioekin eta apur bat gehiagorekin bateragarria.
Baina has gaitezen teoriatik: zer dira zehazki 3 bide-batze adabakiak, nola sortu zen jendeak horiek sortzeko planteamendua eta zergatik dira garrantzitsuak Kubernetes-en oinarritutako azpiegitura duten CI/CD prozesuetan? Eta horren ostean, ikus dezagun zer den werf-en 3-way-fusion, zein modu lehenetsitako erabiltzen diren eta nola kudeatu.
Zer da 3 norabide-batze adabaki bat?
Beraz, has gaitezen YAML manifestuetan deskribatutako baliabideak Kubernetes-era zabaltzeko zereginarekin.
Baliabideekin lan egiteko, Kubernetes APIak oinarrizko eragiketa hauek eskaintzen ditu: sortu, adabaki, ordezkatu eta ezabatu. Suposatzen da haien laguntzarekin beharrezkoa dela klustererako baliabideak etengabe hedatzea erosoa eraikitzea. Nola?
Kubectl komando inperatiboak
Kubernetes-en objektuak kudeatzeko lehen hurbilketa kubectl komando ezinbestekoak erabiltzea da objektu horiek sortzeko, aldatzeko eta ezabatzeko. Besterik gabe:
- taldeak
kubectl runDeployment edo Job exekutatu dezakezu:kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE - taldeak
kubectl scaleβ aldatu erreplika kopurua:kubectl scale --replicas=3 deployment/mysql - eta abar.
Ikuspegi hau komenigarria dirudi lehen begiratuan. Hala ere, arazoak daude:
- Zaila da automatizatu.
- Bezala islatu konfigurazioa Git-en? Nola berrikusi klusterrean gertatzen diren aldaketak?
- Nola eman erreproduzigarritasuna berrabiarazteko konfigurazioak?
- ...
Argi dago ikuspegi hau ez datorrela ondo aplikazioak eta azpiegiturak kode gisa gordetzearekin (IaC; edo are gehiago aukera modernoago gisa, ospea lortuz Kubernetes ekosisteman). Hori dela eta, komando hauek ez zuten kubectl-en garapen gehiago jaso.
Sortu, lortu, ordezkatu eta ezabatu eragiketak
Lehen mailakoekin sorkuntza sinplea da: bidali manifestua operaziora create kube api eta baliabidea sortu da. Manifestuaren YAML irudikapena Git-en gorde daiteke eta komandoa erabiliz sor daiteke kubectl create -f manifest.yaml.
Π‘ kendu sinplea ere: berdin ordezkatu manifest.yaml Git-etik taldera kubectl delete -f manifest.yaml.
eragiketa replace baliabideen konfigurazioa guztiz ordezteko aukera ematen du berri batekin, baliabidea birsortu gabe. Horrek esan nahi du baliabide batean aldaketa bat egin aurretik, logikoa dela eragiketarekin uneko bertsioa kontsultatzea get, aldatu eta eguneratu eragiketarekin replace. kube apiserver eraikita dago eta, ebakuntza ondoren bada get objektua aldatu da, gero eragiketa replace ez du funtzionatuko.
Konfigurazioa Git-en gordetzeko eta ordezkatu erabiliz eguneratzeko, eragiketa egin behar duzu get, batu Git-eko konfigurazioa jaso dugunarekin eta exekutatu replace. Lehenespenez, kubectl-ek komandoa erabiltzeko aukera ematen dizu soilik kubectl replace -f manifest.yamlNon manifest.yaml β dagoeneko guztiz prestatuta (gure kasuan, bateratua) instalatu behar den manifestua. Erabiltzaileak bateratze-manifestuak ezarri behar dituela ematen du, eta hori ez da hutsala...
Aipatzekoa da ere, nahiz eta manifest.yaml eta Git-en gordetzen da, ezin dugu aldez aurretik jakin objektu bat sortzea edo eguneratzea beharrezkoa den; hori erabiltzailearen softwareak egin behar du.
Guztira: etengabeko hedapena eraiki dezakegu sortu, ordezkatu eta ezabatu soilik erabiliz, azpiegituraren konfigurazioa Git-en gordeta dagoela ziurtatuz, kodearekin eta CI/CD erosoarekin batera?
Printzipioz, ahal dugu... Horretarako bateratze eragiketa ezarri beharko duzu manifestuak eta nolabaiteko lotura hori:
- klusterrean objektu bat dagoen egiaztatzen du,
- hasierako baliabideen sorrera egiten du,
- eguneratzen edo ezabatzen du.
Eguneratzean, kontutan izan baliteke baliabidea aldatu izana azkenetik get eta automatikoki kudeatu blokeo baikorren kasua - egin behin eta berriz eguneratze saiakerak.
Hala ere, zergatik berrasmatu gurpila kube-apiserver-ek baliabideak eguneratzeko beste modu bat eskaintzen duenean: eragiketa patch, eta horrek erabiltzailea arintzen du deskribatutako arazo batzuetatik?
adabaki
Orain adabakietara iritsiko gara.
Adabakiak Kubernetes-en dauden objektuei aldaketak aplikatzeko modu nagusia dira. Operazioa patch honela funtzionatzen du:
- kube-apiserver erabiltzaileak adabaki bat bidali behar du JSON formularioan eta objektua zehaztu,
- eta apiserver berak objektuaren uneko egoeraz arduratuko da eta behar den formara eramango du.
Blokeo optimista ez da beharrezkoa kasu honetan. Eragiketa hau ordezkatzea baino adierazgarriagoa da, hasieran alderantziz badirudi ere.
Modu honetan:
- eragiketa bat erabiliz
createobjektu bat sortzen dugu Git-en manifestuaren arabera, - laguntzarekin
deleteβ ezabatu objektua beharrezkoa ez bada, - laguntzarekin
patchβ objektua aldatzen dugu, Git-en deskribatutako formara eramanez.
Hala ere, horretarako, sortu behar duzu adabaki zuzena!
Helm 2-n adabakiek nola funtzionatzen duten: 2-way-fusion
Bertsio bat lehen aldiz instalatzen duzunean, Helm-ek egiten du eragiketa create diagramen baliabideetarako.
Baliabide bakoitzeko Helm bertsio bat eguneratzean:
- aurreko grafikoko baliabideen bertsioaren eta egungo diagramaren bertsioaren arteko adabakia hartzen du kontuan,
- adabaki hau aplikatzen du.
Adabaki honi deituko diogu 2 norabideko bateratze adabakia, bere sorreran 2 manifestuk parte hartzen dutelako:
- aurreko bertsioko baliabideen manifestua,
- baliabidearen manifestua uneko baliabidetik.
Eragiketa kentzean delete kube-n apiserver aurreko bertsioan deklaratu ziren baina oraingoan deklaratu ez ziren baliabideetarako deitzen da.
Bi modu bateratze adabakien ikuspegiak arazo bat du: eramaten du Sinkronizatuta dago klusterreko baliabidearen eta Git-eko manifestuaren benetako egoerarekin.
Arazoaren ilustrazioa adibide batekin
- Git-en, diagrama batek eremua manifestu bat gordetzen du
imageInplementazioa kontuakubuntu:18.04. - Erabiltzailea bidez
kubectl editeremu honen balioa aldatu duubuntu:19.04. - Helm diagrama berriro zabaltzean ez du adabakirik sortzen, zelaia delako
imagebertsioaren aurreko bertsioan eta egungo taulan berdinak dira. - Berriz zabaldu ondoren
imageaztarnakubuntu:19.04, taulak dioen arrenubuntu:18.04.
Dessinkronizazioa lortu dugu eta deklaratibotasuna galdu dugu.
Zer da baliabide sinkronizatu bat?
Oro har osatu Ezinezkoa da exekutatzen ari den kluster bateko baliabideen manifestuaren eta Git-eko manifestuaren arteko bat etortzea. Benetako manifestu batean zerbitzuen oharrak/etiketak, edukiontzi gehigarriak eta kontrolagailu batzuek baliabidetik dinamikoki gehitzen eta kentzen dituzten beste datu batzuk egon daitezkeelako. Ezin ditugu datu hauek Git-en gorde eta ez ditugu nahi. Hala ere, Git-en esplizituki zehaztu ditugun eremuek balio egokiak hartzea nahi dugu zabaltzean.
Hain orokorra da sinkronizatutako baliabideen araua: baliabide bat zabaltzen duzunean, Git-etik manifestuan esplizituki zehaztutako eremuak bakarrik alda edo ezaba ditzakezu (edo aurreko bertsio batean zehaztu ziren eta orain ezabatu).
3 norabideko bateratze adabakia
erdiko ideia : Git-en manifestuaren azken bertsio aplikatuaren eta Git-en manifestuaren xede-bertsioaren artean adabaki bat sortzen dugu, exekutatzen ari den clusterreko manifestuaren uneko bertsioa kontuan hartuta. Lortutako adabakiak sinkronizatutako baliabideen araua bete behar du:
- xede-bertsioari gehitutako eremu berriak adabaki baten bidez gehitzen dira;
- Aplikaturiko azken bertsioan lehen zeuden eremuak eta helburuko bertsioan ez dauden eremuak adabaki baten bidez berrezartzen dira;
- Manifestuaren xede-bertsiotik desberdinak diren objektuaren uneko bertsioko eremuak adabakia erabiliz eguneratzen dira.
Printzipio horren arabera sortzen ditu adabakiak kubectl apply:
- Manifestuaren azken bertsioa objektuaren beraren oharpenean gordetzen da,
- xedea - zehaztutako YAML fitxategitik hartutakoa,
- oraingoa martxan dagoen kluster batekoa da.
Teoria ordenatu dugularik, werf-en zer egin genuen kontatzeko garaia da.
Aldaketak aplikatzea werfean
Aurretik, werf-ek, Helm 2-k bezala, bi norabideko bateratze adabakiak erabiltzen zituen.
Konponketa adabakia
Adabaki mota berri batera aldatzeko - 3-way-fusion - lehen urratsa deitzen dena sartu genuen. konponketa adabakiak.
Inplementatzean, 2 norabideko bateratze adabaki estandarra erabiltzen da, baina werf-ek baliabidearen benetako egoera Git-en idatzitakoarekin sinkronizatuko lukeen adabaki bat sortzen du (halako adabaki bat goian deskribatutako baliabide sinkronizatuen arau bera erabiliz sortzen da) .
Dessinkronizazioa gertatzen bada, inplementazioaren amaieran erabiltzaileak ABISUA jasotzen du dagokion mezu batekin eta baliabidea sinkronizatuta eramateko aplikatu beharreko adabaki batekin. Adabaki hau oharpen berezi batean ere grabatuta dago werf.io/repair-patch. Suposatzen da erabiltzailearen eskuak ΡΠ°ΠΌ adabaki hau aplikatuko du: werf-ek ez du batere aplikatuko.
Konponketa-adabakiak sortzea aldi baterako neurri bat da, 3-bideko bateratze-printzipioan oinarritutako adabakien sorrera benetan probatzeko aukera ematen duena, baina ez ditu adabaki horiek automatikoki aplikatzen. Momentuz, funtzionamendu modu hau lehenespenez gaituta dago.
3 moduko bateratze adabakia bertsio berrietarako soilik
1ko abenduaren 2019etik aurrera, werf-en beta eta alfa bertsioak hasiko dira lehenespenez Erabili 3 bideen bateratze adabaki osoak werf bidez zabaldutako Helm bertsio berrietan soilik aldaketak aplikatzeko. Lehendik dauden bertsioek 2 bideko batzea + konponketa adabakien ikuspegia erabiltzen jarraituko dute.
Eragiketa-modu hau berariaz gaitu daiteke ezarpenaren bidez WERF_THREE_WAY_MERGE_MODE=onlyNewReleases orain.
Kontuan izan: funtzioa werf-en agertu zen hainbat bertsiotan: alfa kanalean bertsioarekin prest zegoen , eta beta kanalean --rekin .
Argitalpen guztietarako 3 moduko bateratze adabakia
15ko abenduaren 2019etik aurrera, werf-en beta eta alfa bertsioak lehenespenez hiru norabideko bateratze adabaki osoak erabiltzen hasiko dira bertsio guztietan aldaketak aplikatzeko.
Eragiketa-modu hau berariaz gaitu daiteke ezarpenaren bidez WERF_THREE_WAY_MERGE_MODE=enabled orain.
Zer egin baliabideen eskalatze automatikoarekin?
Kubernetesen 2 autoeskalatze mota daude: HPA (horizontala) eta VPA (bertikala).
Horizontalak automatikoki hautatzen du erreplika kopurua, bertikala - baliabide kopurua. Erreplika kopurua eta baliabideen eskakizunak baliabideen manifestuan zehazten dira (ikus Baliabideen manifestua). spec.replicas edo spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory ΠΈ ).
Arazoa: erabiltzaile batek baliabide bat grafiko batean konfiguratzen badu baliabide edo errepliketarako balio batzuk zehazten baditu eta baliabide honetarako eskalagailu automatikoak gaituta badaude, hedapen bakoitzean werf-ek balio hauek berrezarriko ditu diagramako manifestuan idatzitakoarekin. .
Arazoari bi irtenbide daude. Hasteko, hobe da diagramako manifestuan eskalatutako balioak esplizituki ez zehaztea. Aukera hau arrazoiren batengatik egokia ez bada (adibidez, hasierako baliabideen mugak eta grafikoko erreplika kopurua ezartzea komenigarria delako), orduan werf-ek ohar hauek eskaintzen ditu:
-
werf.io/set-replicas-only-on-creation=true -
werf.io/set-resources-only-on-creation=true
Oharpen hori badago, werf-ek ez ditu inplementazio bakoitzean dagozkion balioak berrezarriko, baina baliabidea hasiera batean sortzen denean soilik ezarriko ditu.
Xehetasun gehiago lortzeko, ikusi proiektuaren dokumentazioa ΠΈ .
Debekatu 3 bideen bateratze adabakia erabiltzea
Erabiltzaileak une honetan werf-en adabaki berriak erabiltzea debekatu dezake ingurune-aldagai bat erabiliz WERF_THREE_WAY_MERGE_MODE=disabled. Hala ere, hasita 1ko martxoaren 2020etik aurrera, debeku hau ez da aplikatuko. eta 3 moduko bateratze adabakiak soilik erabili ahal izango dira.
Baliabideak hartzea werf-en
Aldaketak 3-bideko bateratze adabakiekin aplikatzeko metodoa menperatzeari esker, berehala inplementatu ahal izan dugu klusterrean dauden baliabideak Helm bertsioan.
Helm 2-k arazo bat du: ezin duzu baliabiderik gehitu klusterrean dagoeneko existitzen diren grafikoen manifestuetan, baliabide hau hutsetik berregin gabe (ikus. , ). Lehendik zeuden baliabideak askatzeko onartzen irakatsi genion werf. Horretarako, ohar bat instalatu behar duzu exekutatzen ari den klusterreko baliabidearen uneko bertsioan (adibidez, erabiliz kubectl edit):
"werf.io/allow-adoption-by-release": RELEASE_NAMEOrain baliabidea taulan deskribatu behar da eta werf-ek izen egokia duen bertsio bat zabaltzen duen hurrengoan, dagoen baliabidea bertsio honetan onartuko da eta bere kontrolpean jarraituko du. Gainera, kaleratzeko baliabide bat onartzeko prozesuan, werf-ek baliabidearen uneko egoera exekutatzen ari den klusterretik taulan deskribatutako egoerara eramango du, 3-bideko bateratze adabaki berdinak eta sinkronizatutako baliabideen araua erabiliz.
Kontuan izan: ezarpena WERF_THREE_WAY_MERGE_MODE ez du baliabideen adopzioan eragiten - adopzioaren kasuan, beti erabiltzen da 3 moduko bateratze adabakia.
Xehetasunak - in .
Ondorioak eta etorkizuneko planak
Espero dut artikulu honen ondoren argiago geratu izana zer diren 3-way-fusion adabakiak eta zergatik iritsi diren. Werf proiektuaren garapenaren ikuspuntu praktikotik, haien ezarpena Helm moduko hedapena hobetzeko beste urrats bat izan zen. Orain Helm 2 erabiltzean askotan sortzen ziren konfigurazio sinkronizazioaren arazoak ahaztu ditzakezu. Aldi berean, dagoeneko deskargatutako Kubernetes baliabideak hartzeko eginbide erabilgarri berri bat gehitu zen Helm bertsioan.
Helm-en antzeko inplementazioekin badaude oraindik arazo eta erronka batzuk, hala nola, Go txantiloien erabilera, jorratzen jarraituko ditugunak.
Baliabideak eguneratzeko metodoei eta hartzeari buruzko informazioa hemen ere aurki daiteke .
Helmuga 3
Ohar berezia merezi du herenegun Helm-en bertsio nagusi berri bat - v3 - 3 bide-batzeko adabakiak ere erabiltzen dituena eta Tiller kentzen duena. Helm-en bertsio berriak eskatzen du dauden instalazioak bertsio berriko biltegiratze formatuan bihurtzeko.
Werf-ek, bere aldetik, gaur egun Tiller erabiltzea kendu du, 3-way-fusion-era aldatu eta gehitu du. , lehendik dauden Helm 2 instalazioekin bateragarria izaten jarraitzen duen bitartean (ez da migrazio scriptik exekutatu behar). Hori dela eta, werf Helm 3ra aldatzen den arte, werf erabiltzaileek ez dituzte Helm 3ren abantaila nagusiak Helm 2ren aldean galtzen (werf-ek ere baditu).
Hala ere, werf Helm 3 kode-basera aldatzea saihestezina da eta etorkizun hurbilean gertatuko da. Ustez hau werf 1.1 edo werf 1.2 izango da (momentuz, werf-en bertsio nagusia 1.0 da; werf bertsioa egiteko gailuari buruzko informazio gehiago lortzeko, ikus ). Denbora horretan, Helm 3-k egonkortzeko denbora izango du.
PS
Irakurri ere gure blogean:
- Werf-eko berrikuntzei buruzko ohar sorta bat:
- «»;
- «»;
- Β«'.
- «»;
- «»;
- Β«'.
Iturria: www.habr.com