Kubernetes hefur nokkra möguleika til að uppfæra auðlindir: sækja um, breyta, lagfæra og skipta út. Það er ruglingur um hvað hver og einn gerir og hvenær á að nota þá. Við skulum reikna það út.
Ef setningin „kubernetes gilda vs skipta“ er staðsett , sem er ekki rétt. "kubernetes gilda vs patch" fyrsti hlekkurinn er skjölin fyrir kubectl patch, sem felur ekki í sér samanburð apply и patch. Þessi grein mun skoða mismunandi valkosti, svo og rétta notkun hvers og eins.
Á líftíma Kubernetes tilföngs (þjónusta, dreifing, innkoma osfrv.), stundum þarftu að breyta, bæta við eða fjarlægja suma eiginleika þessarar tilföngs. Til dæmis, bæta við athugasemd, fjölga eða fækka eftirlíkingum.
Kubernetes CLI
Ef þú ert nú þegar að vinna með Kubernetes klasa í gegnum CLI, ertu nú þegar kunnugur apply и edit. Lið apply les auðlindaforskriftina úr skránni og gerir "upsert" í Kubernetes klasann, þ.e. býr til auðlindina ef hún er ekki til og uppfærir hana ef hún er til. Lið edit les auðlind í gegnum API, skrifar síðan auðlindaforskriftina í staðbundna skrá sem er síðan opnuð í textaritli. Eftir að þú hefur breytt og vistað skrána, kubectl mun senda breytingarnar sem gerðar eru til baka í gegnum API, sem mun beita þessum breytingum vandlega á auðlindina.
Ekki vita allir skipanirnar patch и replace. Lið patch gerir þér kleift að breyta hluta af auðlindaforskrift og gefur aðeins upp breytta hlutann á skipanalínunni. Lið replace virkar það sama og edit, en allt þarf að gera handvirkt: þú þarft að hlaða niður núverandi útgáfu af auðlindaforskriftinni, til dæmis með því að nota kubectl get -o yaml, breyttu því og notaðu síðan replace að uppfæra tilföng samkvæmt breyttri forskrift. Lið replace mun ekki virka ef einhverjar breytingar urðu á milli lestrar og þess að skipta um tilföng.
Kubernetes API
Þú þekkir líklega aðferðirnar CoreV1().Pods().Update(), replaceNamespacedService eða patch_namespaced_deployment, ef þú vinnur með klasa í gegnum nota eitthvað forritunarmál. Bókasafnið sér um þessar aðferðir með HTTP beiðnum með því að nota aðferðirnar PUT и PATCH... Hvar í update и replace nota PUTOg patch, hversu léttvæg sem það kann að vera, notar PATCH.
Það skal tekið fram að kubectl virkar líka með klasa í gegnum API. Með öðrum orðum, kubectler umbúðir ofan á biðlarasafnið fyrir Go tungumálið, sem veitir að miklu leyti möguleika á að veita undirskipanir á þéttara og læsilegra formi til viðbótar við staðlaða API getu. Til dæmis, eins og þú hefur kannski þegar tekið eftir, aðferðin apply var ekki getið hér að framan í fyrri málsgrein. Eins og er (maí 2020, ca. þýðandi) öll rökfræði kubectl apply, þ.e. að búa til auðlindir sem ekki eru til og uppfæra þær sem fyrir eru, virkar algjörlega á kóðahliðinni kubectl. Unnið er að átaki apply til API hliðarinnar, en það er enn í beta. Ég mun skrifa nánar hér að neðan.
Patch sjálfgefið
Best notað patch, ef þú vilt uppfæra auðlindina. Svona virka bæði viðskiptavinasöfnin ofan á Kubernetes API og kubectl (ekki á óvart, þar sem það er umbúðir fyrir viðskiptavinabókasafnið, ca. þýðandi).
Vinna stefnumótandi
Öll lið kubectl apply, edit и patch nota aðferðina PATCH í HTTP beiðnir um að uppfæra núverandi tilföng. Ef þú kafar nánar í útfærslu skipana, þá nota þær allar nálgunina til að uppfæra auðlindir, þó skipunin patch getur notað aðrar aðferðir (meira um þetta hér að neðan). Strategic-merge patching nálgunin reynir að „fá rétt“ með því að sameina meðfylgjandi forskrift við núverandi forskrift. Nánar tiltekið reynir það að sameina bæði hluti og fylki, sem þýðir að breytingarnar hafa tilhneigingu til að bæta við. Til dæmis að keyra skipunina patch með nýrri umhverfisbreytu í belgílátslýsingunni, veldur því að þeirri umhverfisbreytu er bætt við núverandi umhverfisbreytur frekar en að skrifa yfir þær. Til að fjarlægja með því að nota þessa nálgun verður þú að þvinga færibreytugildið á núll í uppgefinni forskrift. Hvert liðanna kubectl Er best að nota það til að uppfæra?
Ef þú býrð til og stjórnar auðlindum þínum með því að nota kubectl apply, þegar þú uppfærir er betra að nota alltaf kubectl applyTil kubectl gæti stjórnað stillingum og fylgst rétt með umbeðnum breytingum frá forriti til forrits. Kostur alltaf að nota apply er að það heldur utan um áður notaða forskrift, sem gerir honum kleift að vita hvenær forskriftareiginleikar og fylkisþættir eru beinlínis fjarlægðir. Þetta gerir þér kleift að nota apply til að fjarlægja eiginleika og fylkisþætti, á meðan venjuleg stefnumótandi sameining virkar ekki. Liðin edit и patch ekki uppfæra athugasemdir sem kubectl apply notar til að rekja breytingar sínar, svo allar breytingar sem eru raktar og gerðar í gegnum Kubernetes API, en gerðar með skipunum edit и patch, ósýnilegt fyrir síðari skipanir applyÞað er, apply fjarlægir þær ekki þó þær komi ekki fram í inntakslýsingu fyrir apply (Skjalið segir það edit и patch gera uppfærslur á glósunum sem notaðar eru apply, en í reynd - nei).
Ef þú notar ekki skipunina apply, er hægt að nota sem editOg patch, velja þá skipun sem hentar best breytingunni sem verið er að gera. Þegar bætt er við og breytt uppskriftareiginleikum eru báðar aðferðir nokkurn veginn eins. Þegar forskriftareiginleikum eða fylkisþáttum er eytt edit hegðar sér eins og eitt skipti apply, þar á meðal að halda utan um hvernig forskriftin var fyrir og eftir að henni var breytt, svo þú getur beinlínis fjarlægt eiginleika og fylkisþætti úr auðlind. Þú þarft sérstaklega að stilla eignargildið á núll í forskriftinni fyrir patchtil að fjarlægja það úr auðlindinni. Það er flóknara að fjarlægja fylkisþátt með því að nota stefnumótandi sameiningu plástra vegna þess að það krefst notkunar samrunatilskipana. Sjáðu aðrar uppfærsluaðferðir hér að neðan fyrir raunhæfari valkosti.
Til að innleiða uppfærsluaðferðir í biðlarasafninu sem hegða sér svipað og skipanirnar hér að ofan kubectl, ætti að vera sett í beiðnum content-type в application/strategic-merge-patch+json. Ef þú vilt fjarlægja eiginleika í forskrift þarftu að stilla gildi þeirra beinlínis á núll á svipaðan hátt kubectl patch. Ef þú þarft að fjarlægja fylkisþætti ættirðu að setja samrunatilskipanir í uppfærsluforskriftina eða nota aðra nálgun við uppfærslur.
Aðrar aðferðir við uppfærslur
Kubernetes styður tvær aðrar uppfærsluaðferðir: и . JSON sameining plástra nálgunin tekur Kubernetes forskrift að hluta sem inntak og styður sameiningu hluta svipað og stefnumótandi sameiningu plástra nálgun. Munurinn á þessu tvennu er að það styður aðeins skiptingu á fylki, þar á meðal gámafylkinguna í belgforskriftinni. Þetta þýðir að þegar þú notar JSON samruna plástur þarftu að gefa upp fullkomnar forskriftir fyrir alla gáma ef einhver eign í gámum breytist. Þannig að þessi aðferð er gagnleg til að fjarlægja þætti úr fylki í uppskrift. Á skipanalínunni geturðu valið JSON sameina plástur með því að nota kubectl patch --type=merge. Þegar þú vinnur með Kubernetes API ættirðu að nota beiðniaðferðina PATCH og uppsetningu content-type в application/merge-patch+json.
JSON patch nálgunin, frekar en að gefa upp hluta forskrift um tilföng, notar að útvega breytingarnar sem þú vilt gera á tilfanginu sem fylki, þar sem hver þáttur fylkisins táknar lýsingu á breytingunni sem verið er að gera á tilfanginu. Þessi nálgun er sveigjanlegri og öflugri leið til að tjá breytingarnar sem verið er að gera, en á kostnað þess að skrá breytingarnar sem eru gerðar á sérstöku sniði sem er ekki Kubernetes, frekar en að senda hlutaforskrift tilfanga. IN kubectl þú getur valið JSON plástur með því að nota kubectl patch --type=json. Þegar þú notar Kubernetes API virkar þessi aðferð með því að nota beiðniaðferðina PATCH og uppsetningu content-type в application/json-patch+json.
Við þurfum sjálfstraust - notaðu í staðinn
Í sumum tilfellum þarftu að vera viss um að engar breytingar séu gerðar á tilfangi frá því að tilfangið er lesið þar til það er uppfært. Með öðrum orðum, þú ættir að ganga úr skugga um að allar breytingar verði lotukerfi. Í þessu tilfelli, til að uppfæra auðlindir sem þú ættir að nota replace. Til dæmis, ef þú ert með ConfigMap með teljara sem er uppfærður af mörgum aðilum, ættir þú að vera viss um að tvær heimildir uppfærir ekki teljarann á sama tíma, sem veldur því að uppfærslan glatast. Til að sýna fram á, ímyndaðu þér röð atburða með því að nota nálgunina patch:
- A og B fá núverandi stöðu auðlindarinnar frá API
- Hver og einn uppfærir forskriftina á staðnum með því að hækka teljarann um einn og bæta einnig "A" eða "B" í sömu röð við "updated-by" athugasemdina
- Og það uppfærir auðlindina aðeins hraðar
- B uppfærir auðlindina
Fyrir vikið glatast uppfærsla A. Síðasta aðgerð patch vinnur, er teljarinn hækkaður um einn í stað tveggja, og gildi "updated-by" seðilsins endar á "B" og inniheldur ekki "A". Við skulum bera saman ofangreint við það sem gerist þegar uppfærslur eru gerðar með aðferðinni replace:
- A og B fá núverandi stöðu auðlindarinnar frá API
- Hver og einn uppfærir forskriftina á staðnum með því að hækka teljarann um einn og bæta einnig "A" eða "B" í sömu röð við "updated-by" athugasemdina
- Og það uppfærir auðlindina aðeins hraðar
- B reynir að uppfæra auðlindina en uppfærslunni er hafnað af API vegna þess að auðlindaútgáfan er í forskriftinni
replacepassar ekki við núverandi útgáfu tilfangsins í Kubernetes vegna þess að útgáfa tilfangsins var aukin með skiptaaðgerð A.
Í ofangreindu tilviki verður B að sækja auðlindina aftur, gera breytingar á nýju ástandi og reyna aftur replace. Þetta mun valda því að teljarinn hækkar um tvo og "uppfært eftir" athugasemdin mun innihalda "AB" í lokin.
Ofangreint dæmi gefur til kynna að þegar verið er að framkvæma replace Allt auðlindin er algjörlega skipt út. Forskrift notuð fyrir replace, má ekki vera að hluta eða í hlutum eins og í apply, en heill, þar á meðal viðbótin resourceVersion inn í lýsigögn forskriftarinnar. Ef þú hefur ekki virkjað resourceVersion eða útgáfan sem þú gefur upp er ekki uppfærð, þá verður skiptingunni hafnað. Svo besta aðferðin til að nota er replace – lestu auðlindina, uppfærðu hana og skiptu henni strax út. Notar kubectl, gæti litið svona út:
$ kubectl get deployment my-deployment -o json
| jq '.spec.template.spec.containers[0].env[1].value = "new value"'
| kubectl replace -f -Þess má geta að eftirfarandi tvær skipanir, framkvæmdar í röð, munu framkvæma með góðum árangri, þar sem deployment.yaml inniheldur ekki eign .metadata.resourceVersion
$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yamlÞetta virðist stangast á við það sem sagt var hér að ofan, þ.e. “ bætir við resourceVersion inn í lýsigögn forskriftarinnar." Er það rangt að segja það? Nei, það er það ekki, því ef kubectl tekur eftir því sem þú tilgreindir ekki resourceVersion, mun það lesa það úr auðlindinni og bæta því við forskriftina sem þú tilgreindir og aðeins þá framkvæma hana replace. Vegna þess að þetta er hugsanlega hættulegt ef þú treystir á atómvirkni, þá virkar galdurinn algjörlega á hliðinni kubectl, þú ættir ekki að treysta á það þegar þú notar viðskiptavinasöfn sem vinna með API. Í þessu tilviki verður þú að lesa núverandi forskrift aðfanga, uppfæra hana og framkvæma síðan PUT beiðni.
Þú getur ekki gert plástur - við gerum skipti
Stundum þarftu að gera nokkrar breytingar sem ekki er hægt að höndla með API. Í þessum tilfellum geturðu þvingað til að skipta um tilföng með því að eyða og búa hana til aftur. Þetta er gert með því að nota kubectl replace --force. Að keyra skipunina fjarlægir auðlindirnar strax og endurskapar þær síðan úr meðfylgjandi forskrift. Það er enginn „force replace“ meðhöndlari í API og til þess að gera það í gegnum API þarftu að framkvæma tvær aðgerðir. Fyrst þarftu að eyða auðlindinni með því að stilla það gracePeriodSeconds í núll (0) og propagationPolicy í „Bakgrunnur“ og búðu síðan til þessa auðlind aftur með viðeigandi forskrift.
Viðvörun: Þessi aðferð er hugsanlega hættuleg og getur leitt til óskilgreinds ástands.
Sækja um á miðlara hlið
Eins og getið er hér að ofan eru verktaki Kubernetes að vinna að innleiðingu rökfræðinnar apply á kubectl í Kubernetes API. Rökfræði apply fáanlegt í Kubernetes 1.18 í gegnum kubectl apply --server-side eða í gegnum API með aðferðinni PATCH с content-type application/apply-patch+YAML.
Athugið: JSON er einnig gilt YAML, svo þú getur sent forskriftina sem JSON jafnvel þó
content-typemunapplication/apply-patch+yaml.
Fyrir utan þá rökfræði kubectl verður aðgengilegt öllum í gegnum API, apply á miðlarahlið, heldur utan um hver er ábyrgur fyrir reitunum í forskriftinni og leyfir þannig öruggan margfaldan aðgang fyrir átök án átaka. Með öðrum orðum, ef apply á netþjóninum mun verða útbreiddari, alhliða öruggt auðlindastjórnunarviðmót mun birtast fyrir mismunandi viðskiptavini, til dæmis, kubectl, Pulumi eða Terraform, GitOps, auk sjálfskrifaðra forskrifta sem nota viðskiptavinasöfn.
Niðurstöður
Ég vona að þér hafi fundist þetta stutta yfirlit yfir mismunandi leiðir til að uppfæra tilföng í klösum gagnlegt. Það er gott að vita að það er ekki bara beita á móti skipta, það er hægt að uppfæra tilföng með því að nota app, breyta, plástra eða skipta út. Eftir allt saman, í grundvallaratriðum, hefur hver nálgun sitt eigið notkunarsvið. Fyrir frumeindabreytingar er betra að skipta út; annars ættirðu að nota stefnumótandi sameiningu plástur í gegnum umsókn. Að minnsta kosti býst ég við að þú skiljir að þú getur ekki treyst Google eða StackOerflow þegar þú leitar að "kubernetes apply vs replace". Að minnsta kosti þar til þessi grein kemur í stað núverandi svars.
Heimild: www.habr.com