Kubernetesek hainbat aukera ditu baliabideak eguneratzeko: aplikatu, editatu, adabakitu eta ordezkatu. Nahasmena dago bakoitzak zer egiten duen eta noiz erabili. Asma dezagun.
Bada "kubernetes aplikatu vs ordeztu" esaldia kokatzen da , zuzena ez dena. "kubernetes apply vs patch" lehen esteka dokumentazioa da kubectl patch, konparazioa barne hartzen ez duena apply ΠΈ patch. Artikulu honetan aukera desberdinak aztertuko dira, baita bakoitzaren erabilera egokia ere.
Kubernetes baliabide baten bizi-zikloan (zerbitzua, inplementazioa, sarrera, etab.), batzuetan baliabide honen propietate batzuk aldatu, gehitu edo kendu behar dituzu. Adibidez, gehitu ohar bat, handitu edo txikitu erreplika kopurua.
Kubernetes CLI
Dagoeneko Kubernetes klusterrekin lanean ari bazara CLI bidez, dagoeneko ezagutzen dituzu apply ΠΈ edit. Taldea apply fitxategitik baliabideen zehaztapena irakurtzen du eta Kubernetes klusterari "hasi" egiten dio, hau da. baliabidea sortzen ez badago eta existitzen bada eguneratzen du. Taldea edit APIaren bidez baliabide bat irakurtzen du, gero baliabideen zehaztapena fitxategi lokal batean idazten du, eta testu-editore batean irekiko da. Fitxategia editatu eta gorde ondoren, kubectl egindako aldaketak APIaren bidez bidaliko ditu, eta horrek arreta handiz aplikatuko ditu aldaketa horiek baliabidean.
Guztiek ez dakite aginduak patch ΠΈ replace. Taldea patch baliabide baten zehaztapenaren zati bat aldatzeko aukera ematen du, komando lerroan aldatutako zatia soilik emanez. Taldea replace berdin funtzionatzen du edit, baina dena eskuz egin behar da: baliabideen zehaztapenaren uneko bertsioa deskargatu behar duzu, adibidez, erabiliz kubectl get -o yaml, editatu eta gero erabili replace baliabide bat aldatutako zehaztapen baten arabera eguneratzeko. Taldea replace ez du funtzionatuko baliabidea irakurri eta ordeztearen artean aldaketarik gertatuz gero.
Kubernetes APIa
Seguruenik metodoak ezagutzen dituzu CoreV1().Pods().Update(), replaceNamespacedService edo patch_namespaced_deployment, klusterrekin lan egiten baduzu bidez programazio-lengoaia batzuk erabiliz. Liburutegiak metodo hauek HTTP eskaeren bidez kudeatzen ditu metodoak erabiliz PUT ΠΈ PATCH... Non update ΠΈ replace erabilitako PUTEta patch, nahiz eta hutsala izan, erabilerak PATCH.
Kontuan hartu behar da kubectl klusterrekin ere lan egiten du API bidez. Beste hitz batzutan, kubectlGo hizkuntzarako bezero liburutegiaren gainean dagoen bilgarri bat da, eta, neurri handi batean, azpikomandoak forma trinkoago eta irakurgarriagoan eskaintzeko gaitasuna ematen du API gaitasun estandarrez gain. Esate baterako, dagoeneko nabarituko duzun bezala, metodoa apply ez zen aurreko paragrafoan aipatu. Gaur egun (2020ko maiatza, gutxi gorabehera. itzultzailea) logika guztia kubectl apply, hau da. existitzen ez diren baliabideak sortzea eta daudenak eguneratzea, guztiz kodearen aldetik funtzionatzen du kubectl. Ahaleginak egiten ari dira apply API aldean, baina oraindik beta-n dago. Jarraian zehatzago idatziko dut.
Adabakia lehenespenez
Erabili onena patch, baliabidea eguneratu nahi baduzu. Horrela funtzionatzen dute bi bezero liburutegiek Kubernetes APIaren gainean eta kubectl (ez da harritzekoa, bezeroen liburutegirako bilgarri bat denez, gutxi gorabehera. itzultzailea).
Estrategikoki lan egin
Talde guztiak kubectl apply, edit ΠΈ patch erabili metodoa PATCH lehendik dagoen baliabide bat eguneratzeko HTTP eskaeretan. Komandoen ezarpenean xehetasun gehiagorekin sakontzen baduzu, denek erabiltzen dute ikuspegia baliabideak eguneratzeko, komandoa izan arren patch beste ikuspegi batzuk erabil ditzake (behean honi buruz gehiago). Estrategiko-fusioaren adabakien ikuspegia "ondo egiten" saiatzen da, emandako zehaztapena lehendik dagoen zehaztapenarekin batuz. Zehazkiago, objektuak eta arrayak konbinatzen saiatzen da, hau da, aldaketak gehigarriak izan ohi dira. Adibidez, komandoa exekutatzea patch pod edukiontziaren zehaztapenean ingurune-aldagai berri batekin, ingurune-aldagai hori lehendik dauden ingurune-aldagaietara gehitzea eragiten du haiek gainidatzi beharrean. Ikuspegi hau erabiliz kentzeko, parametroaren balioa null izatera behartu behar duzu emandako zehaztapenean. Taldeetako zein kubectl Hobe da eguneratzeko erabiltzea?
Zure baliabideak erabiliz sortu eta kudeatzen badituzu kubectl apply, eguneratzean hobe da beti erabiltzea kubectl applyTo kubectl konfigurazioa kudeatu eta eskatutako aldaketak behar bezala jarrai ditzake aplikaziotik aplikaziora. Abantaila beti erabili apply aldez aurretik aplikatutako zehaztapen baten jarraipena egiten duela da, zehaztapen-propietateak eta array-elementuak esplizituki kentzen diren jakin ahal izateko. Honek erabiltzeko aukera ematen dizu apply propietateak eta array-elementuak kentzeko, bateratze estrategiko arrunt batek ez du funtzionatuko. Taldeak edit ΠΈ patch ez eguneratu oharrak kubectl apply bere aldaketen jarraipena egiteko erabiltzen du, beraz, Kubernetes APIaren bidez jarraitu eta egiten diren aldaketak, baina komandoen bidez egiten diren edit ΠΈ patch, hurrengo komandoetarako ikusezina applyHau da, apply ez ditu kentzen sarrerako zehaztapenean agertzen ez badira ere apply (Dokumentazioak hori dio edit ΠΈ patch erabilitako oharren eguneraketak egin apply, baina praktikan - ez).
Komandoa erabiltzen ez baduzu apply, gisa erabil daiteke editEta patch, egiten den aldaketara hobekien egokitzen den komandoa aukeratuz. BOM propietateak gehitzean eta aldatzean, bi ikuspegiak gutxi gorabehera berdinak dira. Zehaztapen-propietateak edo array-elementuak ezabatzean edit behin-behineko abiarazte baten antzera jokatzen du apply, zehaztapena editatu aurretik eta ondoren nolakoa izan den jarraitzea barne, baliabide batetik propietateak eta array-elementuak esplizituki kendu ahal izateko. Espresuki ezarri behar duzu propietatearen balioa null gisa for zehaztapenean patchbaliabidetik kentzeko. Estrategiko-juntura adabakia erabiliz array-elementu bat kentzea konplexuagoa da, batzeko zuzentarauak erabiltzea eskatzen duelako. Ikusi behean beste bertsio berritze batzuk alternatiba bideragarriagoak ikusteko.
Goiko komandoen antzeko portaera duten bezeroen liburutegian eguneratzeko metodoak ezartzeko kubectl, eskaeretan ezarri behar da content-type Π² application/strategic-merge-patch+json. Zehaztapen batean propietateak kendu nahi badituzu, beren balioak espresuki ezarri behar dituzu antzeko modu batean nulu gisa. kubectl patch. Array-elementuak kendu behar badituzu, eguneratze-zehaztapenean bateratzeko zuzentarauak sartu behar dituzu edo eguneratzeetarako beste ikuspegi bat erabili.
Eguneratzeen beste ikuspegi batzuk
Kubernetes-ek beste bi eguneratze ikuspegi onartzen ditu: ΠΈ . JSON bateratze adabakien ikuspegiak Kubernetesen zehaztapen partziala hartzen du sarrera gisa eta batuketa estrategikoko adabakien ikuspegiaren antzeko objektuak bateratzea onartzen du. Bien arteko aldea array-aren ordezkapena bakarrik onartzen duela da, edukiontzi-matrizea barne pod zehaztapenean. Horrek esan nahi du JSON bateratze-adabaki bat erabiltzean, edukiontzi guztien zehaztapen osoa eman behar duzula edukiontziren baten jabetza aldatzen bada. Beraz, ikuspegi hau erabilgarria da BOM bateko array batetik elementuak kentzeko. Komando-lerroan JSON bateratze adabakia hauta dezakezu erabiliz kubectl patch --type=merge. Kubernetes APIarekin lan egiten duzunean, eskaera-metodoa erabili beharko zenuke PATCH eta instalazioa content-type Π² application/merge-patch+json.
JSON adabakiaren ikuspegiak, baliabide baten zehaztapen partziala eman beharrean, baliabidean egin nahi dituzun aldaketak matrize gisa ematea erabiltzen du, eta bertan, arrayko elementu bakoitzak baliabidean egiten ari den aldaketaren deskribapena adierazten du. Ikuspegi hau egiten diren aldaketak adierazteko modu malguagoa eta indartsuagoa da, baina Kubernetes ez den formatu bereizi batean egiten diren aldaketak zerrendatzearen kostuarekin, baliabideen zehaztapen partziala bidali beharrean. IN kubectl JSON adabakia hautatu dezakezu erabiliz kubectl patch --type=json. Kubernetes APIa erabiltzean, ikuspegi honek eskaera metodoa erabiliz funtzionatzen du PATCH eta instalazioa content-type Π² application/json-patch+json.
Konfiantza behar dugu - ordezkatu erabili
Zenbait kasutan, ziurtatu behar duzu baliabide batean ez dela aldaketarik egiten baliabidea irakurtzen denetik eguneratzen den bitartean. Beste era batera esanda, aldaketa guztiak izango direla ziurtatu beharko zenuke atomikoa. Kasu honetan, erabili behar dituzun baliabideak eguneratzeko replace. Adibidez, hainbat iturrik eguneratzen duten kontagailua duen ConfigMap bat baduzu, ziurtatu behar duzu bi iturrik ez dutela kontagailua aldi berean eguneratzen, eguneratzea galtzea eraginez. Frogatzeko, imajinatu hurbilketa erabiliz gertaeren sekuentzia bat patch:
- A eta B-k baliabidearen uneko egoera lortzen dute APItik
- Bakoitzak lokalean eguneratzen du zehaztapena, kontagailua bat handituz eta "A" edo "B" hurrenez hurren gehituz "eguneratuz" oharrari
- Eta baliabidea apur bat azkarrago eguneratzen du
- B-k baliabidea eguneratzen du
Ondorioz, A eguneratzea galtzen da. Azken operazioa patch irabazten du, kontagailua biren ordez bat handitzen da, eta "eguneratu-by" oharraren balioa "B"-rekin amaitzen da eta ez du "A". Konpara dezagun goikoa hurbilketa erabiliz eguneraketak egiten direnean gertatzen denarekin replace:
- A eta B-k baliabidearen uneko egoera lortzen dute APItik
- Bakoitzak lokalean eguneratzen du zehaztapena, kontagailua bat handituz eta "A" edo "B" hurrenez hurren gehituz "eguneratuz" oharrari
- Eta baliabidea apur bat azkarrago eguneratzen du
- B baliabidea eguneratzen saiatzen da, baina eguneratzea baztertzen du APIak, baliabidearen bertsioa zehaztapenean dagoelako
replaceez dator bat Kubernetes-en baliabidearen uneko bertsioarekin, baliabidearen bertsioa A-ren ordezkapen-eragiketaren bidez handitu delako.
Goiko kasuan, B-k baliabidea berriro eskuratu beharko du, egoera berrian aldaketak egin eta berriro saiatu beharko du. replace. Honek kontagailua bitan handituko du eta "eguneratuz" oharrak "AB" sartuko du amaieran.
Goiko adibidea exekutatzen denean esan nahi du replace Baliabide osoa guztiz ordezkatzen da. Horretarako erabiltzen den zehaztapena replace, ez da partziala izan behar, ezta zatika ere apply, baina osoa, gehitzea barne resourceVersion zehaztapen metadatuak sartu. Gaitu ez baduzu resourceVersion edo ematen duzun bertsioa ez da oraingoa, ordezkoa baztertu egingo da. Beraz, erabiltzeko modurik onena da replace β irakurri baliabidea, eguneratu eta berehala ordezkatu. Erabiliz kubectl, honelakoa izan daiteke:
$ kubectl get deployment my-deployment -o json
| jq '.spec.template.spec.containers[0].env[1].value = "new value"'
| kubectl replace -f -Azpimarratzekoa da ondoko bi komandoak, sekuentzialki exekutatuta, arrakastaz exekutatuko direla, geroztik deployment.yaml ez du jabetzarik .metadata.resourceVersion
$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yamlHorrek gorago esandakoarekin kontraesanean dagoela dirudi, hau da. "gehitzen resourceVersion zehaztapen metadatuetan sartu." Gaizki al dago hori esatea? Ez, ez da, zeren eta kubectl zehaztu ez duzula ohartzen da resourceVersion, baliabidetik irakurriko du eta zuk zehaztutako zehaztapenera gehituko du, eta orduan bakarrik exekutatu replace. Hau potentzialki arriskutsua denez atomotasunean oinarritzen bazara, magiak guztiz alde egiten du kubectl, ez zenuke horretaz fidatu behar APIarekin lan egiten duten bezero liburutegiak erabiltzean. Kasu honetan uneko baliabideen zehaztapena irakurri, eguneratu eta gero exekutatu beharko duzu PUT eskaera.
Ezin duzu adabakirik egin; guk ordezkatzen dugu
Batzuetan APIak kudeatu ezin dituen aldaketa batzuk egin behar dituzu. Kasu horietan, baliabidea ordezkatzea behartu dezakezu ezabatu eta berriro sortuz. Hau erabiliz egiten da kubectl replace --force. Komandoa exekutatzeak baliabideak berehala kentzen ditu eta, ondoren, emandako zehaztapenetik birsortzen ditu. APIan ez dago "behartu ordezkatzeko" kudeatzailerik, eta APIaren bidez horretarako, bi eragiketa egin behar dituzu. Lehenik eta behin, baliabidea ezabatu behar duzu ezarriz gracePeriodSeconds zerora (0) eta propagationPolicy "Atzeko planoan" atalean eta, ondoren, berriro sortu baliabide hau nahi den zehaztapenarekin.
Abisua: hurbilketa hau arriskutsua izan daiteke eta zehaztu gabeko egoera bat ekar dezake.
Aplikatu zerbitzariaren aldean
Goian esan bezala, Kuberneteseko garatzaileak logika inplementatzen ari dira apply - kubectl Kubernetes APIan. Logikak apply eskuragarri Kubernetes 1.18 bidez kubectl apply --server-side edo API bidez metodoa erabiliz PATCH Ρ content-type application/apply-patch+YAML.
Oharra: JSON ere baliozkoa da YAML, beraz, zehaztapena JSON gisa bidal dezakezu, nahiz eta
content-typeizango daapplication/apply-patch+yaml.
Logika horretaz gain kubectl guztiontzat eskuragarri dago API bidez, apply zerbitzariaren aldean, zehaztapeneko eremuen arduradunaren jarraipena egiten du, eta horrela, gatazkarik gabeko ediziorako sarbide anitz segurua ahalbidetzen du. Beste era batera esanda, bada apply zerbitzariaren aldean hedatu egingo da, baliabide seguruen kudeaketa interfaze unibertsala agertuko da bezero ezberdinentzat, adibidez, kubectl, Pulumi edo Terraform, GitOps, baita bezeroen liburutegiak erabiliz auto-idatzitako scriptak ere.
Emaitzak
Espero dut klusterretan baliabideak eguneratzeko modu ezberdinen ikuspegi labur hau lagungarria izan zaizula. Ona da jakitea ez dela aplikatzea baino ez ordezkatzea; posible da baliabide bat eguneratzea aplikatu, editatu, adabaki edo ordezkatu erabiliz. Azken finean, printzipioz, ikuspegi bakoitzak bere aplikazio eremua du. Aldaketa atomikoetarako, ordezkatzea hobe da; bestela, batzeko adabaki estrategikoa erabili beharko zenuke aplikatu bidez. Gutxienez, espero dut ulertzea ezin duzula Google-n edo StackOerflow-en fidatu "kubernetes aplikatu vs ordezkatu" bilatzean. Artikulu honek oraingo erantzuna ordezkatu arte behintzat.
Iturria: www.habr.com