Kubernetes Apply, Replace ja Patch õige võrdlemine

Kubernetesel on mitmeid võimalusi ressursside uuendamiseks: apply, edit, patch ja replace. On segadust selle üle, mida igaühe puhul teha ja millal neid rakendada. Vaatame üle.

Kui otsida Google'ist fraasi "kubernetes apply vs replace", leitakse vastus StackOverflow's, mis ei ole õige. Otsides "kubernetes apply vs patch" on esimene link — dokumentatsioon kubectl patch, mis ei sisalda võrdlust apply ja patch. Selles artiklis käsitletakse erinevaid võimalusi ning igaühe õiget kasutamist.

Kubernetes ressursi elutsükli jooksul (teenus, deployment, ingress jne) on mõnikord vajalik muuta, lisada või eemaldada mõningaid selle ressursi omadusi. Näiteks lisada kommentaar või suurendada/väheneda replikate arvu.

Kubernetes CLI

Kui töötate juba Kubernetes klastritega CLI kaudu, siis olete juba tuttav apply ja edit. Käsk apply mis loeb ressursi specifikatsiooni failist ja teeb "upsert" Kubernetes klastrisse, st loob ressursi, kui seda ei ole, ja uuendab seda, kui see eksisteerib. Käsk edit loeb ressursi API kaudu, seejärel kirjutab ressursi specifikatsiooni kohalikku faili, mis avatakse seejärel tekstiredaktoris. Pärast seda, kui olete faili redigeerinud ja salvestanud, kubectl saadab tehtud muudatused tagasi API kaudu, mis hoolikalt rakendab need muudatused ressursile.

Mitmed inimesed ei tea, et käsk patch ja replace. Käsk patch lubab muuta osa ressursi spetsifikatsioonist, esitades ainult muudetud osa käsureas. Käsk replace töötab sama moodi nagu edit, kuid kõik tuleb teha käsitsi: peate alla laadima ressursi praeguse versiooni, näiteks kasutades kubectl get -o yaml, redigeerige seda, seejärel kasutage replace ressursi uuendamiseks muudetud spetsifikatsiooni põhjal. Käsk replace ei tööta, kui ressursi lugemise ja asendamise vahel on toimunud muudatuseid.

Kubernetes API

Te olete tõenäoliselt tuttav meetoditega CoreV1().Pods().Update(), replaceNamespacedService või patch_namespaced_deployment, kui töötate klastritega läbi Kubernetes API klientraamatukoguga mõne programmeerimiskeele abil. Raamatukogu haldab neid meetodeid HTTP-protokolli kaudu tehtud päringute abil, kasutades meetodeid PUT ja PATCH. Sellega samas update ja replace kasutavad PUT, vaid patch, kuidas see ka ei kõlaks, kasutab PATCH.

Oluline on märkida, et kubectl töötab samuti klastritega API kaudu. Teisisõnu, kubectlon see on Go keele klienditeegi kohal olev wrapper, mis annab suuresti võimaluse esitada subkomande kompaktsemal ja loetavamal viisil, lisaks API vaikimisi funktsioonidele. Näiteks, nagu olete juba võib-olla tähele pannud, meetod apply ei olnud eelnevas lõigus mainitud. Praegu (mai 2020, tõlkija märkus) kogu loogika kubectl apply, st mitteeksteerivate ressursside loomine ja olemasolevate värskendamine, töötab täiesti koodipoolsel küljel kubectl. Tehakse katseid loogika viimiseks apply API poole, kuid see on endiselt beetatestimise faasis. Kirjeldan allpool lähemalt.

Vaikevärskendus

On parim rakendada patch, kui soovite ressurssi värskendada. Nii töötavad nii klienditeegid API فوق Kubernetes kui ka kubectl (pole üllatav, et see on klienditeegi wrapper, tõlkija märkus).

Töötada strateegiliselt

Kõik käsud kubectl apply, edit ja patch kasutavad meetodit PATCH HTTP taotlustes olemasoleva ressursi värskendamiseks. Kui vaadata käsu rakendusi lähemalt, siis kõigis kasutatakse lähenemist strateegilise ühinemise värskendamine ressursside värskendamiseks, kuigi käsk patch võib kasutada ka teistsuguseid lähenemisi (selle kohta rohkem allpool). Strateegilise ühinemise värskendamine üritab "teha kõike õigesti", kui liita antud spetsifikatsioon olemasoleva spetsifikatsiooniga. Täpsemalt üritab see ühendada nii objekte kui ka massiive, mis tähendab, et muudatused on reeglina liituvad. Näiteks, käsk patch uue keskkonnamuutujaga pod-i konteineri spetsifikatsioonis, viib selleni, et see keskkonnamuutuja lisatakse olemasolevatele keskkonnamuutujatele, mitte ei asenda neid. Selle lähenemisega eemaldamiseks tuleb antud spetsifikatsioonis parameetri väärtus nulliks sundida. Millised käsud kubectl värskendamiseks on kõige paremad?

Kui loote ja haldate oma ressursse kubectl apply, on värskenduste tegemisel alati parem kasutada kubectl apply, et kubectl saaks hallata konfiguratsiooni ja õigesti jälgida taotletud muudatusi rakenduste seas. Eelis, mida alati kasutada apply on see, et see jälgib varasemalt rakendatud spetsifikatsiooni, võimaldades tal teada, millal spetsifikatsiooni omadused ja massiivi elemendid on selgelt eemaldatud. See võimaldab kasutada apply massiivide omaduste ja elementide eemaldamiseks, samas kui tavapärane strateegiline ühinemine ei toimi. Käsklused edit ja patch ei värskenda märkmeid, mida kubectl apply rakendab oma muudatuste jälgimiseks, seetõttu ei ole kõik muudatused, mis jälgitakse ja tehakse läbi API Kubernetes, kuid tehtud käskude kaudu edit ja patch, nähtamatud järgmiste käskude jaoks apply, see tähendab apply ei eemalda neid, isegi kui need ei ilmu sisendspekifikatsioonis apply Dokumendis on öeldud, et edit ja patch teevad märkmete värskendusi, mida apply, aga praktikas – ei).

Kui te ei kasuta käsku apply, saab kasutada nii edit, kui ka patch, valides selle käsu, mis sobib rohkem muudetava muudatusega. Omaduste lisamisel ja muutmisel on mõlemad lähenemisviisid suurusjärgus samad. Spetsifikatsiooni omaduste või massiivielementide eemaldamisel edit käitub kui ühekordne käivitamine apply, sealhulgas jälgib, milline oli spetsifikatsioon enne ja pärast selle redigeerimist, seetõttu on võimalik selgelt eemaldada omadused ja massiivielemendid ressursist. Tuleb selgelt seada omaduse väärtus nulliks spetsifikatsioonis patch, et eemaldada see ressursist. Massiivielemendi eemaldamine strateegilise ühinemise patchimisega on keerulisem, kuna nõuab ühinemisdirektiivide kasutamist. Vaadake allpool teisi uuendamise lähenemisviise, et valida sobivamad alternatiivid.

Klienditeegis uuendamise meetodite rakendamiseks, mis käituvad sarnaselt ülaltoodud käskudele kubectl, tuleks päringutes määrata content-type ja application/strategic-merge-patch+json. Kui soovite spetsifikatsioonis omadusi eemaldada, tuleb nende väärtused selgelt seada nulliks sarnaselt kubectl patch. Kui on vajalik massiivielementide eemaldamine, tuleks lisada ühinemisdirektiive uuendamise spetsifikatsiooni või kasutada muud lähenemisviisi uuendustele.

Teised lähenemisviisid uuendustele

Kubernetes toetab kahte muud lähenemisviisi uuendustele: JSON ühinemise patch ja JSON patch. JSON merge patch lähenemine võtab Kubernetes'e osalise spesifikatsiooni sisendina ja toetab objektide sulandumist nagu strategic-merge patching lähenemist. Nende vahe seisneb selles, et see toetab ainult massiivide asendamist, sealhulgas konteinerite massiivi pod'i spesifikatsioonis. See tähendab, et JSON merge patch'i kasutamisel peate esitama täiseditsioonid kõigi konteinerite jaoks, kui muudate mõne konteineri omadust. Seetõttu on see lähenemine kasulik elementide eemaldamiseks massiivist spetsifikatsioonis. Käskude rida kasutades saate valida JSON merge patch'i, kasutades kubectl patch --type=merge. Kubernetes API-ga töötades tuleks kasutada päringumeetodit PATCH ja seadistamine content-type ja application/merge-patch+json.

JSON patch lähenemine, selle asemel et esitada osaline spetsifikatsioon ressursist, kasutab muudatuste esitamist, mida soovite ressursis teha, massiivina, kus iga massiivi element esindab muudatuse kirjeldust, mis tehakse ressursis. See lähenemine on paindlikum ja võimsam muudatuste väljendamise viis, kuid sellest tulenevalt, et muudatuste loetelu on eraldi, mitte Kubernetes'e formaadis, selle asemel, et saata osaline ressursi spetsifikatsioon. Saate valida JSON patch'i, kasutades kubectl kubectl patch --type=json . Kubernetes API kasutamisel töötab see lähenemine päringumeetodigaapplication/json-patch+json PATCH ja seadistamine content-type ja Vajad usaldusväärsust — kasutame replace'i.

Mõnel juhul on vajalik kindel veendumus, et ressursse ei muudeta vahetult enne selle lugemist ja värskendamist. Teisisõnu, on oluline veenduda, et kõik muudatused oleksid

aatomaarne . Sel juhul tasub kasutada ressursi värskendamiseks. Näiteks, kui on ConfigMap, mille loendurit uuendavad mitmed allikad, tuleks olla kindel, et kaks allikat ei uuenda loendurit samal ajal, mis tooks kaasa värskenduse kaotamise. Näiteks kujutage ette sündmuste järjestust, kasutades lähenemist replaceA ja B saavad ressursi praeguse oleku API-st patch:

• Mõlemad uuendavad kohalikult spetsifikatsiooni, suurendades loenduri väärtust ühe võrra ning lisades vastavalt "A" või "B" tähelepanekusse "updated-by"
• A uuendab ressursi veidi kiiremini
• B uuendab ressursi
• B uuendab ressursi

Seega A uuendus on kadunud. Viimane operatsioon patch võidab, loendur suureneb ühe asemel kahe võrra ja märkuse "updated-by" väärtus lõppeb "B"-ga ning ei sisalda "A". Vaatame, kuidas see võrreldes eelneva kontekstiga, kui uuendusi teostatakse lähenemisega replace:

• Mõlemad uuendavad kohalikult spetsifikatsiooni, suurendades loenduri väärtust ühe võrra ning lisades vastavalt "A" või "B" tähelepanekusse "updated-by"
• A uuendab ressursi veidi kiiremini
• B uuendab ressursi
• B püüab ressurssi uuendada, kuid API tagastab uuenduse tagasi, kuna ressursi versioon spetsifikatsioonis replace ei kattu Kubernetes'e praeguse ressursi versiooniga, kuna ressursi versioon on A poolt toimunud asendamise operatsiooni käigus suurenenud.

Ülaltoodud juhul peab B ressursi uuesti hankima, tegema muudatused uude seisundisse ja proovima jälle teha replace. Seega suureneb loendur kahe võrra ja märkuses "updated-by" on lõpus "AB".

Eeltoodud näide tähendab, et teostatakse replace kogu ressursi täielik asendamine. Spetsifikatsioon, mida kasutatakse replace, peab olema mitte osaline ega osadeks nagu apply, vaid täielik, sealhulgas resourceVersion spetsifikatsiooni metadata. Kui te ei sisalda resourceVersion või teie esitatud versioon ei ole praegune, siis asendamine lükatakse tagasi. Seega on parim lähenemine kasutada replace – lugeda ressursi, uuendada seda ja kohe asendada. Kasutades kubectl, võib see välja näha nii:

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

Siiski tuleb märkida, et järgmised kaks käsku, mis on teostatud järjestikku, õnnestuvad, kuna deployment.yaml ei sisalda omadust .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

Näib, et see on vastuolus eelnevalt mainituga, st "lisamine resourceVersion spetsifikatsiooni metadata". Kas on vale nii väita? Ei, see ei ole vale, kuna kui kubectl tähele paneb, et te ei ole määranud resourceVersion, siis loeb ta selle ressursist ja lisab teie määratud spetsifikatsiooni ning alles siis teeb ta replace. Kuna see on potentsiaalselt ohtlik, kui toetuda aatomilisusele, töötab see täielikult kubectlkäeulatuses, seega ei tohi selle peale toetuda, kui kasutada API-dega töötavaid kliendi raamatukogusid. Sel juhul peate lugema praeguse ressursi spetsifikatsiooni, uuendama selle ja seejärel sooritama PUT päringu.

Ei saa teha patch – teeme replace

Mõnikord on vaja teha muudatusi, mida API ei saa töödelda. Sellistel juhtudel on võimalik sundida ressurssi asendama, kustutades ja luues selle uuesti. Seda tehakse kasutades kubectl replace --force. Komando käivitamine kustutab ressursid viivitamatult ja seejärel loob need etteantud spetsifikatsiooni alusel. API-s ei ole "sundasendamise" käitlejat, ja selle tegemiseks API kaudu tuleb täita kaks toimingut. Alustuseks tuleb kustutada ressurss, seadistades selle gracePeriodSeconds nulliks (0) ja propagationPolicy "Background", ja seejärel luua see ressurss uuesti soovitud spetsifikatsiooniga.

Tähelepanu: see lähenemine on potentsiaalselt ohtlik, see võib viia määramatute seisunditeni

Serveri poolse rakendamisega

Nagu eelnevalt mainitud, töötavad Kubernetes'i arendajad välja loogikat apply API-s kubectl Kubernetes. Loogika apply on saadaval Kubernetes 1.18 kaudu kubectl apply --server-side või API kaudu, kasutades meetodit PATCH jot content-type application/apply-patch+YAML.

Märkus: JSON on samuti korrektne YAML, nii et spetsifikatsiooni saab saata JSON-ina, isegi kui content-type see on application/apply-patch+yaml.

Lisaks sellele, et loogika kubectl saab kõikide jaoks kätte API kaudu, apply serveri pool jälgib spetsifikatsioonis väljade eest vastutajaid, võimaldades seega ohutut mitmekordset juurdepääsu konfliktivabaks redigeerimiseks. Teisisõnu, kui apply serveri pool saab laiemat levikut, ilmub universaalne turvaline rajatis ressursside haldamiseks erinevatelt klientidelt, näiteks kubectl, Pulumi või Terraform, GitOps ja ka kohandatud skriptid, mis kasutavad kliendiraamatukogusid.

Summary

Loodan, et see lühike ülevaade erinevatest viisidest klastrite ressursside värskendamiseks oli teile kasulik. Kasulik on teada, et ei ole ainult apply vs replace, kuna ressurssi saab uuendada apply, edit, patch või replace abil. Igal lähenemisel on oma rakendusala. Atomaarsete muudatuste puhul on eelistatav replace, muul juhul tuleks kasutada strateegilist ühinemispatchi läbi apply. Lõppkokkuvõttes loodan, et mõistsite, et ei tohiks usaldada Google'it või StackOverflow'd otsingul "kubernetes apply vs replace". vähemalt kuni selle artikli asendamiseni praeguse vastusega.

Allikas: habr.com