„Kubernetes“ turi keletą išteklių atnaujinimo parinkčių: taikyti, redaguoti, pataisyti ir pakeisti. Kyla painiavos dėl to, ką kiekvienas daro ir kada jas naudoti. Išsiaiškinkime.
jei yra frazė „kubernetes taikyti vs pakeisti“. , kas nėra teisinga. "kubernetes taikyti vs patch" pirmoji nuoroda yra dokumentacija kubectl patch, kuriame nėra palyginimo apply и patch. Šiame straipsnyje bus nagrinėjamos įvairios parinktys ir tinkamas kiekvieno iš jų naudojimas.
Per „Kubernetes“ šaltinio gyvavimo ciklą (paslaugą, diegimą, įėjimą ir pan.) kartais reikia pakeisti, pridėti arba pašalinti kai kurias šio ištekliaus savybes. Pavyzdžiui, pridėkite pastabą, padidinkite arba sumažinkite kopijų skaičių.
Kubernetes CLI
Jei jau dirbate su Kubernetes klasteriais per CLI, jau esate susipažinę su apply и edit. Komanda apply nuskaito resurso specifikaciją iš failo ir padaro "upsert" į Kubernetes klasterį, t.y. sukuria šaltinį, jei jo nėra, ir atnaujina, jei jis yra. Komanda edit nuskaito išteklius per API, tada įrašo resurso specifikaciją į vietinį failą, kuris atidaromas teksto rengyklėje. Redagavus ir išsaugojus failą, kubectl atsiųs pakeitimus, atliktus per API, kuri atsargiai pritaikys šiuos pakeitimus ištekliui.
Ne visi žino komandas patch и replace. Komanda patch leidžia pakeisti dalį išteklių specifikacijos, komandinėje eilutėje pateikiant tik pakeistą dalį. Komanda replace veikia taip pat kaip edit, bet viską reikia daryti rankiniu būdu: reikia atsisiųsti dabartinę išteklių specifikacijos versiją, pavyzdžiui, naudodami kubectl get -o yaml, redaguokite, tada naudokite replace atnaujinti išteklius pagal pakeistą specifikaciją. Komanda replace neveiks, jei tarp šaltinio skaitymo ir pakeitimo įvyko kokių nors pakeitimų.
Kubernetes API
Tikriausiai esate susipažinę su metodais CoreV1().Pods().Update(), replaceNamespacedService arba patch_namespaced_deployment, jei dirbate su klasteriais per naudojant tam tikrą programavimo kalbą. Biblioteka apdoroja šiuos metodus per HTTP užklausas, naudodama metodus PUT и PATCH... Kur update и replace naudoti PUTIr patch, kad ir koks nereikšmingas jis būtų, naudoja PATCH.
Reikėtų pažymėti, kad kubectl taip pat veikia su klasteriais per API. Kitaip tariant, kubectlyra „Go“ kalbos kliento bibliotekos viršuje esantis paketas, kuris, be standartinių API galimybių, suteikia galimybę teikti antrines komandas kompaktiškesne ir skaitomesne forma. Pavyzdžiui, kaip jau pastebėjote, metodas apply nebuvo paminėta ankstesnėje pastraipoje. Šiuo metu (2020 m. gegužės mėn. apytiksliai vertėjas) visa logika kubectl apply, t.y. neegzistuojančių išteklių kūrimas ir esamų atnaujinimas veikia tik kodo pusėje kubectl. Dedamos pastangos apply į API pusę, bet vis dar yra beta versijos. Toliau parašysiu plačiau.
Patch pagal numatytuosius nustatymus
Geriausiai naudojamas patch, jei norite atnaujinti šaltinį. Taip abi klientų bibliotekos veikia kartu su Kubernetes API ir kubectl (nenuostabu, nes tai yra kliento bibliotekos paketas, apytiksliai vertėjas).
Dirbti strategiškai
Visos komandos kubectl apply, edit и patch naudoti metodą PATCH HTTP užklausose atnaujinti esamą šaltinį. Jei išsamiau įsigilinsite į komandų įgyvendinimą, tada visos jos naudoja metodą atnaujinti išteklius, nors komanda patch gali naudoti kitus metodus (daugiau apie tai žemiau). Strateginio sujungimo pataisymo metodas bando „sutvarkyti“ sujungdamas pateiktą specifikaciją su esama specifikacija. Tiksliau, jis bando sujungti objektus ir masyvus, o tai reiškia, kad pakeitimai paprastai būna papildomi. Pavyzdžiui, paleiskite komandą patch su nauju aplinkos kintamuoju pod konteinerio specifikacijoje, tas aplinkos kintamasis pridedamas prie esamų aplinkos kintamųjų, o ne perrašomas. Norėdami pašalinti naudodami šį metodą, pateiktoje specifikacijoje turite priversti parametro reikšmę į nulį. Kuri iš komandų kubectl Ar geriausia naudoti naujinimui?
Jei kuriate ir valdote savo išteklius naudodami kubectl apply, atnaujinant geriau visada naudoti kubectl applytaip kad kubectl galėtų valdyti konfigūraciją ir teisingai sekti prašomus pakeitimus iš vienos programos į kitą. Privalumas visada naudokite apply yra tai, kad ji seka anksčiau pritaikytą specifikaciją, leidžiančią žinoti, kada specifikacijos savybės ir masyvo elementai yra aiškiai pašalinti. Tai leidžia naudoti apply pašalinti savybes ir masyvo elementus, o įprastas strateginis sujungimas neveiks. Komandos edit и patch neatnaujinkite pažymi, kad kubectl apply naudoja savo pakeitimams stebėti, taigi bet kokie pakeitimai, kurie yra stebimi ir atliekami per Kubernetes API, bet atliekami naudojant komandas edit и patch, nematomas tolesnėms komandoms applyTai reiškia, kad apply nepašalina jų, net jei jų nėra įvesties specifikacijoje apply (Dokumentuose taip rašoma edit и patch atnaujinti naudojamus užrašus apply, bet praktiškai – ne).
Jei nenaudojate komandos apply, gali būti naudojamas kaip editIr patch, pasirinkdami komandą, kuri geriausiai atitinka daromą pakeitimą. Pridedant ir keičiant KS ypatybes, abu metodai yra maždaug vienodi. Naikinant specifikacijos savybes arba masyvo elementus edit elgiasi kaip vienkartinis paleidimas apply, įskaitant stebėjimą, kokia specifikacija buvo prieš ir po jos redagavimo, kad galėtumėte aiškiai pašalinti ypatybes ir masyvo elementus iš šaltinio. Specifikacijoje turite aiškiai nustatyti nuosavybės vertę į nulį patchkad pašalintumėte jį iš šaltinio. Masyvo elemento pašalinimas naudojant strateginio sujungimo pataisymą yra sudėtingesnis, nes tam reikia naudoti sujungimo direktyvas. Žemiau žiūrėkite kitus atnaujinimo būdus, kad gautumėte perspektyvesnių alternatyvų.
Norėdami įdiegti naujinimo metodus kliento bibliotekoje, kurie elgiasi panašiai kaip anksčiau pateiktos komandos kubectl, turėtų būti nustatytas prašymuose content-type в application/strategic-merge-patch+json. Jei norite pašalinti ypatybes specifikacijoje, turite aiškiai nustatyti jų reikšmes į null panašiu būdu kubectl patch. Jei reikia pašalinti masyvo elementus, į naujinimo specifikaciją turėtumėte įtraukti sujungimo direktyvas arba naudoti kitokį naujinimų metodą.
Kiti požiūriai į atnaujinimus
„Kubernetes“ palaiko du kitus atnaujinimo būdus: и . JSON sujungimo pataisos metodas naudoja dalinę Kubernetes specifikaciją kaip įvestį ir palaiko objektų sujungimą, panašų į strateginio sujungimo pataisų metodą. Skirtumas tarp šių dviejų yra tas, kad palaiko tik masyvo pakeitimą, įskaitant talpyklos masyvą pod specifikacijoje. Tai reiškia, kad naudodami JSON sujungimo pataisą turite pateikti išsamias visų sudėtinių rodinių specifikacijas, jei pasikeistų bet kurios sudėtinio rodinio ypatybės. Taigi šis metodas yra naudingas pašalinant elementus iš KS masyvo. Komandinėje eilutėje galite pasirinkti JSON sujungimo pataisą naudodami kubectl patch --type=merge. Dirbdami su Kubernetes API, turėtumėte naudoti užklausos metodą PATCH ir montavimas content-type в application/merge-patch+json.
Taikant JSON pataisos metodą, užuot pateikus dalinę ištekliaus specifikaciją, norimi atlikti resurso pakeitimai pateikiami kaip masyvas, kuriame kiekvienas masyvo elementas yra ištekliaus pakeitimo aprašas. Šis metodas yra lankstesnis ir veiksmingesnis būdas išreikšti atliekamus pakeitimus, tačiau už tai, kad pakeitimai pateikiami atskiru, ne „Kubernetes“ formatu, o ne siunčiama dalinė išteklių specifikacija. IN kubectl Galite pasirinkti JSON pataisą naudodami kubectl patch --type=json. Naudojant Kubernetes API, šis metodas veikia naudojant užklausos metodą PATCH ir montavimas content-type в application/json-patch+json.
Mums reikia pasitikėjimo – naudokite pakeisti
Kai kuriais atvejais turite būti tikri, kad nuo šaltinio skaitymo iki atnaujinimo jokie šaltinio pakeitimai nebus atliekami. Kitaip tariant, turėtumėte įsitikinti, kad visi pakeitimai bus atlikti atominis. Tokiu atveju, norėdami atnaujinti išteklius, turėtumėte naudoti replace. Pavyzdžiui, jei turite ConfigMap su skaitikliu, kurį atnaujina keli šaltiniai, turėtumėte būti tikri, kad du šaltiniai neatnaujins skaitiklio vienu metu, todėl naujinimas bus prarastas. Norėdami parodyti, įsivaizduokite įvykių seką naudodami metodą patch:
- A ir B dabartinę išteklių būseną gauna iš API
- Kiekvienas iš jų lokaliai atnaujina specifikaciją, padidindamas skaitiklį vienu ir taip pat pridėdamas „A“ arba „B“ atitinkamai prie pastabos „atnaujinta“.
- Ir jis atnaujina šaltinį šiek tiek greičiau
- B atnaujina šaltinį
Dėl to atnaujinimas A prarandamas. Paskutinė operacija patch laimi, skaitiklis padidinamas vienu, o ne dviem, o užrašo „atnaujinta“ reikšmė baigiasi „B“ ir joje nėra „A“. Palyginkime aukščiau pateiktą informaciją su tuo, kas nutinka, kai atnaujinimai atliekami naudojant šį metodą replace:
- A ir B dabartinę išteklių būseną gauna iš API
- Kiekvienas iš jų lokaliai atnaujina specifikaciją, padidindamas skaitiklį vienu ir taip pat pridėdamas „A“ arba „B“ atitinkamai prie pastabos „atnaujinta“.
- Ir jis atnaujina šaltinį šiek tiek greičiau
- B bando atnaujinti išteklius, bet naujinimą atmeta API, nes ištekliaus versija yra specifikacijoje
replaceneatitinka dabartinės ištekliaus versijos Kubernetes, nes ištekliaus versija buvo padidinta A pakeitimo operacija.
Pirmiau nurodytu atveju B turės iš naujo gauti išteklius, atlikti naujos būsenos pakeitimus ir bandyti dar kartą replace. Dėl to skaitiklis bus padidintas dviem, o pastabos „atnaujinta“ pabaigoje bus įtraukta „AB“.
Aukščiau pateiktas pavyzdys reiškia, kad vykdant replace Visas išteklius visiškai pakeistas. Naudojama specifikacija replace, negali būti dalinis arba dalimis, kaip nurodyta apply, bet pilnas, įskaitant papildymą resourceVersion į specifikacijos metaduomenis. Jei neįjungėte resourceVersion arba jūsų pateikta versija nėra naujausia, pakeitimas bus atmestas. Taigi geriausias būdas naudoti yra replace – perskaitykite šaltinį, atnaujinkite jį ir nedelsdami pakeiskite. Naudojant kubectl, tai gali atrodyti taip:
$ kubectl get deployment my-deployment -o json
| jq '.spec.template.spec.containers[0].env[1].value = "new value"'
| kubectl replace -f -Verta paminėti, kad šios dvi komandos, vykdomos nuosekliai, bus sėkmingai vykdomos, nes deployment.yaml neturi nuosavybės .metadata.resourceVersion
$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yamlTai tarsi prieštarautų tam, kas buvo pasakyta aukščiau, t.y. "pridedant resourceVersion į specifikacijos metaduomenis." Ar neteisinga taip sakyti? Ne, ne, nes jei kubectl pastebi, kad nenurodėte resourceVersion, jis nuskaitys jį iš šaltinio ir pridės prie jūsų nurodytos specifikacijos ir tik tada vykdys replace. Kadangi tai gali būti pavojinga, jei pasikliaujate atomiškumu, magija veikia tik iš šono kubectl, neturėtumėte juo pasikliauti, kai naudojate klientų bibliotekas, kurios veikia su API. Tokiu atveju turėsite perskaityti esamą išteklių specifikaciją, ją atnaujinti ir tada vykdyti PUT prašymas.
Negalite pataisyti – mes atliekame pakeitimą
Kartais reikia atlikti kai kuriuos pakeitimus, kurių negali atlikti API. Tokiais atvejais galite priversti išteklius pakeisti jį ištrindami ir sukurdami iš naujo. Tai daroma naudojant kubectl replace --force. Vykdant komandą ištekliai iš karto pašalinami ir vėl sukuriami iš pateiktos specifikacijos. API nėra priverstinio pakeitimo tvarkyklės, o norėdami tai padaryti per API, turite atlikti dvi operacijas. Pirmiausia turite ištrinti išteklius jį nustatydami gracePeriodSeconds iki nulio (0) ir propagationPolicy „Fonas“ ir iš naujo sukurkite šį šaltinį su norima specifikacija.
Įspėjimas: šis metodas yra potencialiai pavojingas ir gali sukelti neapibrėžtą būseną.
Taikyti serverio pusėje
Kaip minėta aukščiau, „Kubernetes“ kūrėjai stengiasi įgyvendinti logiką apply iš kubectl Kubernetes API. Logikos apply galima Kubernetes 1.18 per kubectl apply --server-side arba per API naudojant metodą PATCH с content-type application/apply-patch+YAML.
Pastaba: JSON taip pat galioja YAML, todėl galite siųsti specifikaciją kaip JSON, net jei
content-typevaliaapplication/apply-patch+yaml.
Be tos logikos kubectl tampa prieinama visiems per API, apply serverio pusėje seka, kas yra atsakingas už specifikacijos laukus, taip suteikdamas saugią daugkartinę prieigą be konfliktų redaguoti. Kitaip tariant, jei apply serverio pusėje vis labiau plis, atsiras universali saugaus resursų valdymo sąsaja skirtingiems klientams, pvz., kubectl, Pulumi ar Terraform, GitOps, taip pat savarankiškai rašomi scenarijai, naudojant klientų bibliotekas.
rezultatai
Tikiuosi, kad ši trumpa įvairių būdų, kaip atnaujinti išteklius grupėse, apžvalga buvo jums naudinga. Verta žinoti, kad tai ne tik taikymas, o keitimas; išteklius galima atnaujinti naudojant taikyti, redaguoti, pataisyti arba pakeisti. Galų gale, iš esmės kiekvienas metodas turi savo taikymo sritį. Atliekant atominius pakeitimus, pageidautina pakeisti; kitu atveju turėtumėte naudoti strateginio sujungimo pataisą naudodami taikyti. Tikiuosi, kad bent jau suprasite, kad negalite pasitikėti „Google“ ar „StackOerflow“, kai ieškote „kubernetes taikyti ir pakeisti“. Bent jau tol, kol šis straipsnis pakeis dabartinį atsakymą.
Šaltinis: www.habr.com