Kubernetes ji bo nûvekirina çavkaniyan gelek vebijark hene: sepandin, biguherîne, paç bike û biguhezîne. Di derheqê ku her yek çi dike û kengê wan bikar tîne de tevliheviyek heye. Werin em wê bihesibînin.
ger hevoka "kubernetes sepandin vs şûna" heye , ku ne rast e. "kubernetes li dijî patchê bicîh dikin" zencîreya yekem ji bo belgekirinê ye kubectl patch, ku tê de berawird nake apply и patch. Ev gotar dê li vebijarkên cihêreng, û hem jî karanîna rast a her yekê binêre.
Di dema jiyana çavkaniyek Kubernetes de (xizmet, bicihkirin, ketin, hwd.), carinan hûn hewce ne ku hin taybetmendiyên vê çavkaniyê biguhezînin, zêde bikin an jê bikin. Mînakî, notek lê zêde bike, hejmara kopiyan zêde bike an kêm bike.
Kubernetes CLI
Heke hûn jixwe bi CLI-ê bi komên Kubernetes re dixebitin, hûn jixwe pê nas in apply и edit. Kom apply taybetmendiya çavkaniyê ji pelê dixwîne û ji koma Kubernetes re "ser" çêdike, ango. heke çavkaniyê tune be diafirîne û heke hebe nû dike. Kom edit çavkaniyek bi navgîniya API-ê dixwîne, dûv re taybetmendiya çavkaniyê li pelek herêmî dinivîse, ku paşê di edîtorek nivîsê de tê vekirin. Piştî ku hûn pelê biguherînin û hilînin, kubectl dê guheztinên ku hatine çêkirin bi navgîniya API-yê vegerîne, ku dê van guhertinan bi baldarî li ser çavkaniyê bicîh bîne.
Her kes fermanan nizane patch и replace. Kom patch destûrê dide te ku hûn beşek taybetmendiyek çavkaniyekê biguhezînin, tenê beşa guherbar li ser rêza fermanê peyda dikin. Kom replace heman kar dike edit, lê pêdivî ye ku her tişt bi destan were kirin: hûn hewce ne ku guhertoya heyî ya taybetmendiya çavkaniyê dakêşin, mînakî, bikar bînin kubectl get -o yaml, biguherînin, paşê bikar bînin replace ji bo nûvekirina çavkaniyek li gorî taybetmendiyek guherî. Kom replace ger di navbera xwendin û guheztina çavkaniyê de guherîn çêbibin dê nexebite.
Kubernetes API
Hûn belkî bi rêbazan dizanin CoreV1().Pods().Update(), replaceNamespacedService an patch_namespaced_deployment, heke hûn bi koman re dixebitin bikaranîna hin zimanê bernamekirinê. Pirtûkxane van rêbazan bi daxwazên HTTP-ê bi karanîna rêbazan digire PUT и PATCH... Ku tê de update и replace bikaranîn PUTû patch, çiqasî sivik dibe bila bibe, bikar tîne PATCH.
Divê were zanîn ku kubectl di heman demê de bi komên API-ê re jî dixebite. Bi gotineke din, kubectlJi bo zimanê Go pêçek li ser pirtûkxaneya xerîdar e, ku bi giranî ji bilî kapasîteyên standard API-yê binefermanan bi rengekî tevlihevtir û xwendî peyda dike. Mînakî, wekî ku we berê jî dîtiye, rêbaz apply li jor di paragrafa berê de nehatibû gotin. Niha (Gulan 2020, approx. wergêr) hemû mantiq kubectl apply, yanî afirandina çavkaniyên tune û nûvekirina yên heyî, bi tevahî li ser kodê dixebite kubectl. Hewldan tên kirin apply li aliyê API-ê, lê ew hîn jî di betayê de ye. Ez ê li jêr bi berfirehî binivîsim.
Patch by default
Baştirîn bikaranîn patch, heke hûn dixwazin çavkaniyê nûve bikin. Bi vî rengî her du pirtûkxaneyên xerîdar li ser API-ya Kubernetes û kar dikin kubectl (Ne ecêb e, ji ber ku ew ji bo pirtûkxaneya xerîdar pêçek e, approx. wergêr).
Stratejîk kar bikin
Hemû tîmên kubectl apply, edit и patch rêbazê bikar bînin PATCH di HTTP de daxwaz dike ku çavkaniyek heyî nûve bike. Ger hûn bi hûrgulî li ser pêkanîna fermanan hûr bibin, wê hingê hemî wan nêzîkatiyê bikar tînin ji bo rojanekirina çavkaniyan, tevî ku emrê patch dikare nêzîkatiyên din bikar bîne (li ser vê yekê li jêr). Nêzîkatiya pevgirêdana stratejî-yekhev hewl dide ku "wê rast bigire" bi yekkirina taybetmendiya peydakirî bi taybetmendiya heyî re. Zêdetir, ew hewl dide ku hem tiştan û hem jî rêzikan bi hev re bike, ku tê vê wateyê ku guhertinên zêde dibin. Mînakî, fermanê dimeşîne patch bi guhêrbarek nû ya jîngehê ya di taybetmendiya konteynerê pod de, dibe sedem ku ew guhêrbara jîngehê li şûna ku wan ji nû ve binivîsîne, li guhêrbarên jîngehê yên heyî were zêdekirin. Ji bo rakirina vê nêzîkatiyê, divê hûn zorê bidin ku nirxa parametreyê di taybetmendiya peydakirî de betal bike. Kîjan ji tîmên kubectl Ma çêtirîn e ku meriv ji bo nûvekirinê bikar bîne?
Ger hûn çavkaniyên xwe bikar bînin û bi rê ve bibin kubectl apply, dema nûvekirinê çêtir e ku hûn her gav bikar bînin kubectl applyheta kubectl dikaribû veavakirinê bi rê ve bibe û guhertinên daxwazkirî ji serîlêdanê heya serîlêdanê rast bişopîne. Avantaj her tim bikar bînin apply ev e ku ew taybetmendiyek berê hatî sepandin dişopîne, dihêle ku ew zanibe kengê taybetmendiyên taybetmendiyê û hêmanên rêzê bi eşkere têne rakirin. Ev dihêle hûn bikar bînin apply rakirina taybetmendî û hêmanên rêzê, dema ku yekbûnek stratejîk a normal dê nexebite. Teams edit и patch notên ku nûve nekin kubectl apply ji bo şopandina guhertinên xwe bikar tîne, ji ber vê yekê her guhertinên ku bi navgîniya Kubernetes API ve têne şopandin û têne çêkirin, lê bi fermanan têne çêkirin. edit и patch, ji fermanên paşîn re nayê dîtin applyew e apply wan jê nake heta ku ew di taybetmendiya têketinê de xuya nebin jî apply (Belge wiha dibêje edit и patch nûvekirina notên hatine bikar anîn bikin apply, lê di pratîkê de - na).
Heke hûn fermanê bikar neynin apply, dikare wekî bikar bînin edit, û patch, emrê ku herî baş li gorî guherîna ku tê çêkirin hilbijêrin. Dema ku taybetmendiyên BOM-ê zêde dikin û diguhezin, her du nêzîkatî bi qasî hev in. Dema ku taybetmendiyên taybetmendiyê an hêmanên array jêbirin edit mîna destpêkirina yek carî tevdigere apply, di nav de şopandina ka diyardeya berî û piştî ku hate guherandin çawa bû, ji ber vê yekê hûn dikarin bi eşkere taybetmendî û hêmanên rêzê ji çavkaniyekê derxînin. Pêdivî ye ku hûn bi eşkereyî nirxa milkê di navnîşan de ji bo null destnîşan bikin patchku ew ji çavkaniyê jêbirin. Rakirina hêmanek rêzê bi karanîna pêvekirina stratejîk-hevgirtinê tevlihevtir e ji ber ku ew karanîna rêwerzên hevgirtinê hewce dike. Ji bo alternatîfên maqûltir nêzîkatiyên nûvekirina din li jêr bibînin.
Ji bo pêkanîna rêbazên nûvekirinê yên di pirtûkxaneya xerîdar de ku bi heman fermanên jorîn tevdigerin kubectl, divê di daxwazan de bêne danîn content-type в application/strategic-merge-patch+json. Heke hûn dixwazin di taybetmendiyekê de taybetmendiyan derxînin, hûn hewce ne ku bi eşkereyî nirxên wan bi rengek wekhevî null bikin. kubectl patch. Heke hûn hewce ne ku hêmanên rêzê jê bikin, divê hûn rêwerzên hevgirtinê di taybetmendiya nûvekirinê de bicîh bikin an jî ji nûvekirinan re nêzîkatiyek cûda bikar bînin.
Nêzîkatiyên din ên nûvekirinê
Kubernetes du nêzîkatiyên nûvekirina din piştgirî dike: и . Nêzîkatiya patchê ya yekbûyî ya JSON taybetmendiyek Kubernetes-ê ya qismî wekî têketinê digire û yekkirina tiştên mîna nêzîkatiya pevgirêdana stratejîk-hevgirtinê piştgirî dike. Cûdahiya di navbera her duyan de ev e ku ew tenê guheztina rêzê piştgirî dike, tevî rêzika konteynerê di taybetmendiya pod de. Ev tê vê wateyê ku dema ku pêçek hevgirtina JSON bikar tînin, hûn hewce ne ku ji bo hemî konteyneran taybetmendiyên bêkêmasî peyda bikin ger ku taybetmendiyek konteynerê biguhere. Ji ber vê yekê ev nêzîkatî ji bo rakirina hêmanên ji rêzek di BOM-ê de bikêr e. Li ser rêza fermanê hûn dikarin pêçeka hevgirtina JSON bikar bînin hilbijêrin kubectl patch --type=merge. Dema ku bi Kubernetes API re dixebitin, divê hûn rêbaza daxwaznameyê bikar bînin PATCH û sazkirinê content-type в application/merge-patch+json.
Nêzîkatiya patchê ya JSON, ji dêvla ku taybetmendiyek qismî ya çavkaniyekê peyda bike, guheztinên ku hûn dixwazin li ser çavkaniyê bikin wekî rêzek bikar tîne, ku tê de her hêmanek rêzê ravekirina guhartina ku li çavkaniyê hatî çêkirin destnîşan dike. Ev nêzîkatî rêyek maqûltir û bi hêztir e ji bo îfadekirina guheztinên ku têne çêkirin, lê bi bihayê navnîşkirina guheztinên ku di formek cûda, ne-Kubernetes de têne çêkirin, li şûna şandina taybetmendiyek çavkaniyek qismî. LI kubectl hûn dikarin pêçek JSON bikar bînin hilbijêrin kubectl patch --type=json. Dema ku Kubernetes API bikar tîne, ev nêzîkatî bi karanîna rêbaza daxwaznameyê dixebite PATCH û sazkirinê content-type в application/json-patch+json.
Pêdiviya me bi pêbaweriyê heye - şûna bikar bînin
Di hin rewşan de, hûn hewce ne ku pê ewle bin ku di navbera dema ku çavkanî tê xwendin û dema ku tê nûvekirin de di çavkaniyekê de guhertin çênebe. Bi gotinek din, divê hûn pê ewle bin ku hemî guhertin dê bibin atomî. Di vê rewşê de, ji bo nûvekirina çavkaniyan divê hûn bikar bînin replace. Mînakî, heke we KonfigMapek bi jimarvanek heye ku ji hêla gelek çavkaniyan ve hatî nûve kirin, divê hûn pê ewle bin ku du çavkanî di heman demê de hejmarê nûve nakin, û dibe sedem ku nûvekirin winda bibe. Ji bo ku nîşan bidin, rêzek bûyeran bi karanîna nêzîkbûnê xeyal bikin patch:
- A û B rewşa heyî ya çavkaniyê ji API-yê digirin
- Her yek herêmî bi zêdekirina jimarvan bi yek û her weha bi rêzê "A" an "B" li nota "ji hêla nûvekirî" ve zêdekirina taybetmendiyê nûve dike.
- Û ew çavkaniyê hinekî zûtir nûve dike
- B çavkaniyê nû dike
Wekî encamek, nûvekirina A winda dibe. Operasyona dawî patch serdikeve, jimarevan li şûna duyan yek bi yek zêde dibe, û nirxa nota "bi nûvekirin" bi "B" diqede û "A" tê de tune. Werin em tiştên li jor bi çi diqewime dema ku nûvekirin bi karanîna nêzîkbûnê têne kirin berhev bikin replace:
- A û B rewşa heyî ya çavkaniyê ji API-yê digirin
- Her yek herêmî bi zêdekirina jimarvan bi yek û her weha bi rêzê "A" an "B" li nota "ji hêla nûvekirî" ve zêdekirina taybetmendiyê nûve dike.
- Û ew çavkaniyê hinekî zûtir nûve dike
- B hewl dide ku çavkaniyê nûve bike, lê nûvekirin ji hêla API-ê ve tê red kirin ji ber ku guhertoya çavkaniyê di diyardeyê de ye
replacebi guhertoya heyî ya çavkaniyê ya Kubernetes re hev nagire ji ber ku guhertoya çavkaniyê bi operasyona şûna A-yê zêde bû.
Di rewşa jorîn de, B neçar e ku çavkaniyê ji nû ve bîne, guheztina rewşa nû bike û dîsa biceribîne replace. Ev ê bibe sedem ku hejmar bi duyan zêde bibe û nota "ji hêla nûvekirî" ve di dawiyê de "AB" bigire.
Mînaka jorîn tê vê wateyê ku dema darvekirinê replace Tevahiya çavkaniyê bi tevahî tê guhertin. Specification ji bo bikaranîn replace, divê ne qismî be, an jî di beşan de wek di apply, lê temam, di nav de lêzêdekirin resourceVersion nav metadata taybetmendiyê de. Ger we çalak nekiribe resourceVersion an jî guhertoya ku hûn pêşkêş dikin ne niha ye, dê veguheztin were red kirin. Ji ber vê yekê nêzîkatiya herî çêtirîn a karanîna ye replace - çavkaniyê bixwînin, wê nûve bikin û tavilê biguhezînin. Bikaranîna kubectl, dibe ku bi vî rengî xuya bike:
$ kubectl get deployment my-deployment -o json
| jq '.spec.template.spec.containers[0].env[1].value = "new value"'
| kubectl replace -f -Hêjayî gotinê ye ku du fermanên jêrîn, ku bi rêzê têne darve kirin, dê bi serfirazî bêne bicîh kirin, ji ber ku deployment.yaml milk tê de nîne .metadata.resourceVersion
$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yamlEv xuya dike ku berevajî ya ku li jor hate gotin, ango. "zêde kirin resourceVersion di nav metadata taybetmendiyê de." Ma ev gotin xelet e? Na, ne wusa ye, ji ber ku heke kubectl agahiyên ku we diyar nekiriye resourceVersion, ew ê wê ji çavkaniyê bixwîne û li taybetmendiya ku we diyar kiriye lê zêde bike, û tenê wê hingê wê bicîh bike replace. Ji ber ku ev potansiyel xeternak e heke hûn xwe bispêrin atomê, sêrbaz bi tevahî li alîkî dixebite kubectl, dema ku hûn pirtûkxaneyên xerîdar ên ku bi API-yê re dixebitin bikar tînin divê hûn pê ve nesekinin. Di vê rewşê de hûn ê hewce ne ku hûn taybetmendiya çavkaniya heyî bixwînin, wê nûve bikin û paşê bicîh bikin PUT tika.
Hûn nikarin paçek bikin - em şûna xwe dikin
Carinan hûn hewce ne ku hin guhertinan bikin ku ji hêla API-ê ve neyên xebitandin. Di van rewşan de, hûn dikarin bi jêbirin û ji nû ve avakirina çavkaniyê zorê bidin şûna çavkaniyê. Ev bi kar tîne kubectl replace --force. Rêvekirina fermanê tavilê çavkaniyan jê dike û dûv re wan ji taybetmendiya peydakirî ji nû ve diafirîne. Di API-ê de rêvekerek "guheztina zorê" tune, û ji bo ku hûn wiya bi API-yê bikin, hûn hewce ne ku du operasyonan bikin. Pêşî hûn hewce ne ku çavkaniyê bi sazkirina wê jêbirin gracePeriodSeconds heta sifirê (0) û propagationPolicy di "Background" de û paşê vê çavkaniyê bi taybetmendiya xwestinê ji nû ve biafirînin.
Hişyarî: Ev nêzîkatî potansiyel xeternak e û dibe ku bibe sedema rewşek nediyar.
Li aliyê serverê bicîh bikin
Wekî ku li jor behs kir, pêşdebirên Kubernetes li ser pêkanîna mantiqê dixebitin apply ji kubectl di Kubernetes API de. Logics apply di Kubernetes 1.18 de peyda dibe kubectl apply --server-side an jî bi riya API-ê bi karanîna rêbazê PATCH с content-type application/apply-patch+YAML.
Nîşe: JSON di heman demê de YAML derbasdar e, ji ber vê yekê hûn dikarin taybetmendiyê wekî JSON jî bişînin
content-typedê bibeapplication/apply-patch+yaml.
Ji bilî wê mantiqê kubectl bi rêya API-ê ji her kesî re peyda dibe, apply li aliyê serverê, bişopîne ka kî ji zeviyên di diyardeyê de berpirsiyar e, bi vî rengî rê dide gihandina pir ewle ji bo guherandina wê ya bê pevçûn. Bi gotineke din, eger apply li aliyê serverê dê berbelavtir bibe, navgînek rêveberiya çavkaniya ewledar a gerdûnî dê ji bo xerîdarên cihêreng xuya bibe, mînakî, kubectl, Pulumi an Terraform, GitOps, û her weha nivîsarên xwe-nivîsandî ku bi karanîna pirtûkxaneyên xerîdar têne bikar anîn.
Encam
Ez hêvî dikim ku ev nihêrîna kurt a awayên cûda yên nûvekirina çavkaniyan di koman de ji we re arîkar bû. Baş e ku hûn zanibin ku ew ne tenê serîlêdan e li hember veguheztin, ew gengaz e ku çavkaniyek bi karanîna serîlêdan, biguherîne, pace an biguhezîne nûve bike. Beriya her tiştî, di prensîbê de, her nêzîkatî qada xwe ya serîlêdanê heye. Ji bo guhertinên atomî, veguheztin tercîh e, wekî din, divê hûn bi serîlêdanê ve patch-hevgirêdana stratejîk bikar bînin. Bi kêmanî, ez ji we hêvî dikim ku hûn fêm bikin ku hûn nekarin ji Google an StackOerflow bawer bikin dema ku li "kubernetes sepandin vs şûna" digerin. Bi kêmanî heya ku ev gotar şûna bersiva heyî bigire.
Source: www.habr.com